Unlisting

Port Knocking for SMTP

---

What is it?

Unlisting reduces the amount of fire-and-forget spam an MTA must process by using a packet filter to block access to all MX hosts unless a connection is attempted to the primary MX first. If a host retries the secondary MX from the same IP address within a specified period, the connection is allowed.

Is it the same as greylisting?

No, but it exploits the same noncompliant behaviour of spamware and viruses, such as those that spread via internal SMTP engines. Greylisting is an approach promoted and rigorously tested by Evan Harris. It is sensible, RFC-compliant, time-proven, and valuable as one part of a multilayer defense against spam. For more information about greylisting, visit Greylisting: The Next Step in the Spam Control War.

Is it the same as Nolisting?

It includes all of the benefits of Nolisting, extending spam prevention to the functioning MX through the use of a packet filter. Nolisting should be fully understood and evaluated before attempting to use Unlisting.

How does Unlisting work?

In 5. Address Resolution and Mail Handling, RFC 2821: Simple Mail Transfer Protocol (SMTP) specifies client behaviour concerning MX lookups:

When the lookup succeeds, the mapping can result in a list of alternative delivery addresses rather than a single address, because of multiple MX records, multihoming, or both. To provide reliable mail transmission, the SMTP client MUST be able to try (and retry) each of the relevant addresses in this list in order, until a delivery attempt succeeds. However, there MAY also be a configurable limit on the number of alternate addresses that can be tried. In any case, the SMTP client SHOULD try at least two addresses.

Two types of information is used to rank the host addresses: multiple MX records, and multihomed hosts.

Multiple MX records contain a preference indication that MUST be used in sorting (see below). Lower numbers are more preferred than higher ones...

If a host connects to a secondary MX without trying the primary, it is highly likely that it is attempting to deliver spam by bypassing the traditionally stricter filters found on primary MX hosts.

By firewalling both MX hosts, a special flag can be set to allow the SMTP client to connect to the secondary MX for a specified time period if the primary MX was tried first and the client connection originates from the same IP address. The secondary MX is configured to handle final delivery, transport rerouting, etc.

Put simply, Unlisting is port knocking for SMTP.

Doesn't port knocking require an extra step for clients?

Yes, but port knocking (or, more accurately, IP knocking) is built into the SMTP protocol, so all RFC-compliant mail servers are already configured to do it! A Mail transfer agent (MTA) retries specified MX hosts in order until it finds a service listening on port 25. This means that it is easy to specify the required sequence of knocks by properly configuring DNS MX records. Since the knocking can be spread over distant or unrelated IP addresses sharing the same firewall, it can be made quite difficult to open the port by accident.

While it may be tempting to create a complex knocking sequence using multiple MX hosts, it's not recommended. Adding unnecessary MX hosts enlarges the target, and will be counterproductive if it results in more overall connections caused by spam. It is also possible that a legitimate client will give up before reaching the end of a long MX host list, since it is only required to retry two addresses (in practice, the number of retries will be longer, but this cannot be depended on).

How do I install it?

Unlisting is an advanced configuration based on Nolisting. It involves the use of multiple protocols. Please read about the issues related to Nolisting before attempting to configure Unlisting.

What are the requirements?

Unlisting requires privileges that are only available to administrators. It is not configurable by end users. To configure Unlisting, an administrator must have the following:

• the ability to configure MX records for the destination domain
• strict control over the MX records for all destination domains that will use the filtered MX hosts
• two IP addresses, within the administrator's control, to assign to the primary and secondary MX hosts
• a single packet filter controlling access to both of the IP addresses specified as the primary and secondary MX hosts
• cooperation of all staff that have control over associated network resources
• user mail submission on port 587 or alternate IP address (highly recommended, but workarounds exist for some environments)

Is it safe?

No.

Unlisting is significantly more fragile than Nolisting. There is absolutely no room for error. Since both MX hosts are unavailable by default, all domains that use the secondary MX must employ Unlisting. There are no exceptions. If a secondary MX configured for Unlisting is mistakenly specified as the primary MX for a domain, mail will be lost, because the client is not making connections in the order necessary to open port 25. It may not be obvious that there is an error in the MX record, since an IP can be referenced by any number of hostnames, and there is no tool that will discover all MX records that use a host on a specific IP address. This is why the administrator must not only have the ability to edit MX records, but must have strict control over them to prevent such errors. Do not attempt this unless you can guarantee that the necessary services will be coordinated properly, and with precision.

Because blocked connections are no longer being logged by the MTA, a misconfiguration or other problem may go undetected for some time. This will delay mail as the sending MTA queues it for future retries. If the problem is not fixed in a timely manner, mail will eventually be returned to the sender. Therefore, it's quite possible that the first indication of a problem will be a call from an angry user who has received proof that an account is not accepting mail. It is highly recommended to send test messages to all affected domains after any configuration change or tweak.

It is relatively easy to deploy Unlisting on a site that is already using Nolisting. Some legitimate hosts may cache and reuse the secondary MX before Unlisting is configured. Such hosts will be denied access immediately after Unlisting is enabled. In most cases, the host will eventually retry the primary MX and thereby regain access to the secondary.

It should be noted that while RFC 2821 specifies that an SMTP client must retry each MX, it does not mention any requirement that the client use the same interface or IP address for the connection. In fact, there is no reasonable expectation for this in the context of creating a reliable mail system, so it would appear that Unlisting could cause problems for such configurations. While this may be uncommon, it has been confirmed that some major email service providers employ round robin techniques to deliver mail. Since this practice appears to be RFC-compliant, it is enough to challenge the viability of Unlisting. This obstacle appears to be insurmountable, and the use of Unlisting in a production system is currently not recommended.

Is it secure?

Any firewalling technique that tracks connections with a finite list or state table is subject to having earlier records of connections flushed if overwhelmed by activity. This leaves Unlisting vulnerable to a distributed denial of service attack (DDoS) or a disruption in service during a particularly large wave of backscatter. There is no magic setting that will solve this for all sites, as it is dependent on various factors. It should be assumed that Unlisting is vulnerable to a planned attack, given the right circumstances. In any event, reverting to Nolisting is a safe response, as it is unaffected by such attacks.

While Nolisting implements a simple block, Unlisting relies on a module that many consider to be experimental. ipt_recent has been patched for security vulnerabilities in the past and is currently being rewritten. Only the most recent version should be used.

Can I whitelist hosts?

Yes. Unlisting depends on a packet filter, so it should be trivial to whitelist hosts when designing the firewall. Note that this may further mask problems with a configuration, so it is important to keep this in mind when troubleshooting.

Will I become an open relay?

Unlisting does not grant any extra privileges, it simply exposes port 25 to hosts that meet certain criteria. Relay access controls are still handled by the MTA and local policy.

I've set up Nolisting. It's been working great for some time. I'm really happy with it. Nobody's complaining about lost mail, and the load on the mail server is a fraction of what it used to be. I understand how it works, and couldn't be happier. Actually, I'd be happier if you told me how Unlisting works.

Unlisting requires a complete understanding and evaluation of Nolisting. You must set it up first. The following directions will be meaningless without a working Nolisting setup.

Nolisting is more tolerant and flexible than Unlisting because it allows unrestricted access to the functioning secondary MX. Unlisting will immediately block this access, so it is important to review all MX records to be sure that none of the domains rely on unrestricted access to the blocked host. It is no longer possible to specify this host as the single MX for a domain. Port 25 will not be opened unless the primary MX is tried first.

Our example uses a single machine with two IP addresses. The primary and secondary MX records are configured in DNS to use these IP addresses. In the example, the primary MX resolves to 192.168.1.3 and the secondary MX resolves to 192.168.1.4. An SMTP server is configured to listen on both of these addresses. The example machine uses iptables as the packet filter, and it must have the recent module loaded into the Linux kernel. These iptables commands will create a working Unlisting setup (and should replace any existing Nolisting firewall rules):

iptables -A INPUT -p tcp -d 192.168.1.3 --dport 25 -m recent --set --name UNLIST -j REJECT --reject-with tcp-reset
iptables -A INPUT -p tcp -d 192.168.1.4 --dport 25 -m recent --rcheck --name UNLIST --seconds 4000 -j ACCEPT
iptables -A INPUT -p tcp -d 192.168.1.4 --dport 25 -j REJECT --reject-with tcp-reset

Order is important, and these rules should be appended in an appropriate location when using firewall scripts. If necessary, use iptables -I <target> <number> <rule> syntax, instead. In the output from iptables -L, the rules should appear in this order:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
REJECT     tcp  --  anywhere             mx1.example.com  tcp dpt:smtp recent: SET name: UNLIST side: source reject-with tcp-reset
ACCEPT     tcp  --  anywhere             mx2.example.com  tcp dpt:smtp recent: CHECK seconds: 4000 name: UNLIST side: source
REJECT     tcp  --  anywhere             mx2.example.com  tcp dpt:smtp reject-with tcp-reset

Umm... Now my users can't submit mail on port 25.

If the secondary MX is on the same IP address used for message submission, users will be unable to connect to port 25, as MUAs have no reason or mechanism to try the primary MX IP first. This problem can be solved using one (or any combination) of the following:

• set up an message submission agent (MSA) on port 587
• provide message submission via port 25 on another server or MTA instance on an alternate IP address
• whitelist known IP addresses in the packet filter
• if running IMAP or POP3 on the same server, configure those ports to set the UNLIST flag in iptables

I highly recommend setting up an MSA on port 587, no matter what environment you have. This allows finer access control to relaying and avoids the blocks that some ISPs are putting on port 25. Running a separate server or MTA instance is also desirable and common in many environments.

Whitelisting is usually only necessary for very simple SMTP clients, such as those found in the firmware of networking devices. Many of these have few configuration options beyond specifying an IP address, and would require an undesirable weakening of restrictions in order to use it with an alternate MSA port. If the device resides on a static IP address, it will be easy to whitelist.

If an IMAP or POP3 server is running on the same machine, it is simple to add another iptables rule to set the UNLIST flag. This will operate somewhat like POP-before-SMTP, in that a user must check mail on the secondary MX before being allowed access to port 25. The additional iptables rule simply sets the UNLIST flag when a host connects to the IMAP(S)/POP3(S) ports:

iptables -A INPUT -p tcp -d 192.168.1.3 --dport 25 -m recent --set --name UNLIST -j REJECT --reject-with tcp-reset
iptables -A INPUT -p tcp -m multiport --dports 110,143,993,995 -m recent --set --name UNLIST
iptables -A INPUT -p tcp -d 192.168.1.4 --dport 25 -m recent --rcheck --name UNLIST --seconds 4000 -j ACCEPT
iptables -A INPUT -p tcp -d 192.168.1.4 --dport 25 -j REJECT --reject-with tcp-reset

As in the previous example, order is important, and the output from iptables -L should look similar to this:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
REJECT     tcp  --  anywhere             mx1.example.com  tcp dpt:smtp recent: SET name: UNLIST side: source reject-with tcp-reset
           tcp  --  anywhere             anywhere            multiport dports pop3,imap,imaps,pop3s recent: SET name: UNLIST side: source
ACCEPT     tcp  --  anywhere             mx2.example.com  tcp dpt:smtp recent: CHECK seconds: 4000 name: UNLIST side: source
REJECT     tcp  --  anywhere             mx2.example.com  tcp dpt:smtp reject-with tcp-reset

An apparent disadvantage to this approach is that a simple connection to these ports unblocks port 25 on the secondary MX, but this isn't any more of a threat than connecting to the primary MX to get Unlisted. It opens the port in the firewall, but does not grant any relay privileges beyond that offered by the MTA. Therefore, zombies or robots are unlikely to gain any real advantage if they perform random sweeps of these ports, even if they are within the network. Still, it's preferable to provide users with authenticated mail submission and retrieval services on a separate IP address.

For how long should SMTP clients be Unlisted?

Be generous. Testing has shown that most MTAs retry the secondary MX within the same second of finding the primary MX to be unavailable. However, no time period between retries has been specified by any RFC, so it will be necessary to make the decision based on real world conditions. I have observed legitimate MTAs retrying the secondary MX as much as five minutes after finding the primary unavailable, indicating that either caching or multihomed clients may play a role. If the Unlisting flag is also being set by IMAP or POP3 access, use a reasonably large window that doesn't conflict with user habits. 4000 seconds is just over an hour, and seems to be a suitable period. Unfortunately, the optimum value is unrelated to local policy, and will take some trial and error to determine. Being overly restrictive will stop more spam, but at the expense of increasing false positives.

Keep in mind that enough time must be allowed to complete the delivery of a message once it has begun the SMTP dialog. It's likely that the firewall rules could be adapted to provide a more stateful connection to prevent interruption, but it doesn't hurt to be generous with the original window.

My connection list is getting flushed, causing some slower, but legitimate, hosts to be expired before they retry the secondary MX. How do I increase the number of entries in the list?

When using the recent module, each named list gets a dedicated file in /proc/net/ipt_recent/ that defaults to 100 IP addresses. To increase the default, I had to run the following commands on my Slackware Linux system:

/etc/rc.d/rc.firewall stop
rmmod ipt_recent
modprobe ipt_recent ip_list_tot=50000
/etc/rc.d/rc.firewall start

My firewall rules are in /etc/rc.d/rc.firewall. In this case, the file includes a simple list of iptables commands. You must use the conventions in place on your system for this to work properly. In particular, it is sometimes unsafe to flush the firewall by issuing the iptables -F command if your firewall is set to deny packets by default. You may get locked out of your system if you do not manage your firewall correctly! It's best to work on the firewall when it is physically accessible, especially if you lack experience.

In the example, I've increased the default ipt_recent list total, but selecting the proper value may require some trial and error. I have yet to determine if setting an arbitrarily large number has an effect on performance or on other packet filter rules that use ipt_recent for different purposes (such as blocking brute force SSH attacks). Once the optimum size is determined, be sure to do whatever is necessary on your system to set this value properly during the boot process.

The number of entries in the list may be checked with the following command (using the name from our example configuration):

wc -l /proc/net/ipt_recent/UNLIST

Run this check periodically to determine an optimum number the site, allowing for periodic peaks.

I don't use Linux. Can this be done with pf or ipf?

I'm still looking for the equivalent functionality to iptable's recent module in pf or ipf. I will be glad to post the firewall configuration here if anyone is willing to provide a working example. In lieu of this, it is possible to create a transparent bridging firewall using Linux to place in front of the MTA. This is beyond the scope of this article, however (code for I don't know how to do it).

It's working great! Can I stop using greylisting?

You should continue to monitor greylisting rejections to determine if it is still an effective part of your defense against spam. Greylisting and Unlisting use different mechanisms. Greylisting enforces RFC-compliance at the application level, rewarding RFC-compliant mailers with continued access after retrying. Unlisting exploits a pattern of behaviour, completely denying access to mailers that attempt direct-to-secondary-MX delivery. Such mailers will never be allowed access simply by retrying the secondary MX later. If, by coincidence, they attempt delivery to the primary within the specified time window, they will be granted access to the secondary MX, where conventional greylisting has an opportunity to present another obstacle to delivery.

It's working exactly as described and sometimes rejects legitimate mail from important ESPs that retry from a different IP address! How do I fix this without disabling Unlisting?

Problematic networks can be whitelisted in the packet filter, so that Unlisting is never applied to them. Of course, this requires knowledge of all potential source IPs for a site, which can change at any time. It also adds the overhead associated with any whitelist.

Another approach is to use Selective Unlisting, which allows Unlisting to be applied narrowly to specific networks. While it doesn't eliminate the potential problems associated with Unlisting, it does allow an administrator to target offending networks that aren't an important source of legitimate mail for the site. Selective Unlisting is described in another page.

I have a conventional setup and merely want to protect my backup MX. Is this possible?

Yes, but only if the backup MX is on the same packet filter. Don't reject mail to the primary MX, but continue to set the UNLIST flag to allow connections to the backup MX. While this will provide backup if the primary MX has a hardware failure, it is of dubious value to have a backup MX in a location that doesn't also protect against network failure. Also, keep in mind that you will lose the benefits of blocking the primary MX, and will allow a significant amount of fire-and-forget spam. This setup will only stop direct-to-secondary-MX connections that do not try the primary MX first.

Will spammers adapt?

Better RFC-compliance or an approach that mimics it will allow a spammer to bypass Unlisting. The message will then be handled by the MTA, which will determine if it is acceptable. Clearly, Unlisting does not care about message content, but raises the hurdle for poorly programmed mailers or ones that attempt to exploit some traditional weaknesses in MX configuration. If the history of the war against spam is any indicator, it is foolish to assume that an advantage gained in this battle will be anything but temporary.

Social engineering can also be employed to fight Unlisting. When a site reports that it cannot deliver mail to a domain protected by Unlisting, there are several possible reasons:

• You have a misconfiguration
• The sending domain may not retry deliveries from the same IP address
• The sending domain uses a noncompliant mailer
• The reporter is lying
• Unlisting sucks

Reports should be treated seriously and thoroughly troubleshooted. Insist on proof. Request evidence in the form of an error message or nondelivery notification from the sender's MTA. This is essential to properly troubleshoot a complex configuration like Unlisting.

Acknowledgements

Wietse Venema, for pointing out the potential impact on service if backscatter flushes the recent state

Source Documentation

RFC 2821: Simple Mail Transfer Protocol (SMTP)

Greylisting: The Next Step in the Spam Control War

Netfilter: Firewalling, NAT, and Packet Mangling for Linux

IPTables/Netfilter Recent Module

Port Knocking - From Wikipedia, the free encyclopedia

Nolisting: Poor Man's Greylisting