Postfix
work-in-progressPostfix
work-in-progressTrickle attack defense | Postscreen zombie defense | TLS (SSL) renegotiation attacks
[Last update: January 2012]
Trickle attacks are old, but have received attention recently in the context of web servers. The idea is that an attacker sends a request slowly, for example, one byte at a time. Since many servers implement per-read time limits, instead of per-transaction time limits, an attacker can keep a connection busy for a very long time. Namely, the maximum number of seconds before a read operation times out, multiplied by the maximum number of bytes per transaction, multiplied by the number of transactions per session.
The postscreen daemon, available with Postfix 2.8 and later, already implements time limits to receive one complete SMTP command line. Postscreen uses a default time limit of 300s for RFC compliance, but it will switch to a 10s limit under overload conditions. Postscreen limits the number of commands per session and never receives mail, so this is a complete solution.
Support for per-line time limits in the Postfix SMTP server and client is now part of the stable Postfix 2.9 release. This solves most of the problem; it limits the time to send or receive one complete SMTP command or reply, but it does not yet limit the total amount of time to receive or transmit the content of an email message. In the SMTP server, use the existing Postfix mechanisms to reject mail before the SMTP "DATA" command, and to limit the number of sessions and MAIL transactions per client.
The whole thing is implemented in very little code in the lowest-layer Postfix routines. With per-line time limits, Postfix behaves exactly in the same way as before, except when someone trickles the bytes.
[Last update: November 2010]
Postscreen is the code name for a new daemon that sits in front of Postfix and that does connection-level filtering. The program is currently part of the Postfix 2.8 experimental release.
The major goals of the program are:
Keep the zombies away from the Postfix SMTP server. According to the August 2010 report by MessageLabs, 92% of all email was spam, and 95% of spam was sent by botnets.
Improve Postfix scalability by moving potentially time-consuming operations such as DNS blocklist lookups and SMTP protocol checks out of the SMTP server.
Early results for several weeks of spam were presented at the 2010 LISA conference in San Jose:
Anomalies in spammer SMTP client implementations. Spammers are in a hurry to send spam, and therefore they cut corners in the SMTP protocol. Postscreen currently detects SMTP clients that start talking too early (pregreeters). Postscreen contains a dummy SMTP engine that logs the sender and recipient of rejected mail. This dummy engine can also detect spambots that send multiple commands (pipelining) and that make other mistakes.
Parallel lookups from DNS blocklists and whitelists, with configurable weights and reject threshold.
Geolocation and time-of-day patterns for spam connections to servers in Europe. Geolocation is done off-line, based on logfile analysis.
Data were collected with help by Ralf Hildebrandt. In an earlier pilot experiment in 2009, Ralf reported that by dropping all pregreeter connections to one server, he reduced the frequency of the "all server ports busy" condition from several times a day to once a week.
There is a lengthy history of prior work in this field. For example, OpenBSD spamd, MailChannels TrafficControl, and work by Michael Tokarev in the early 2000s.
[Last update: November 2009]
Early November 2009 there was big news about a security hole in the TLS protocol that allows a man-in-the-middle to prepend data to a fully-secure TLS session. That is, the server certificate verifies, and therefore no-one can read or modify the network traffic. Or so we thought. The initial discussions were focused on the impact on HTTP applications.
While looking at the impact of this for SMTP mail, Wietse came up with an attack that redirects and modifies SMTP mail that is sent over a fully-secure TLS connection; Victor came up with an attack that changes the first command in a TLS session. You can find a preliminary analysis at:
http://www.porcupine.org/postfix-mirror/smtp-renegotiate.pdf
This writeup comes with a little tutorial on SMTP over TLS, and on TLS renegotiation attacks.
The impact of TLS-based attacks on SMTP should not be over-stated. Presently, most SMTP clients don't verify the TLS certificates of SMTP servers. Such clients are already vulnerable to ordinary man-in-the-middle attacks, and TLS renegotiation introduces no new threats for them.
The Postfix SMTP server with OpenSSL is not affected by the TLS renegotiation attack that redirects and modifies SMTP mail, due to accidental details of the Postfix and OpenSSL implementations. Other SMTP server implementations may be affected (my report describes some of the requirements). There may of course be other attacks that I wasn't aware of when I wrote the analysis.
Most SMTP client implementations, including Postfix, will not detect the SMTP-level after-effects from a TLS renegotiation attack. Victor and Wietse have looked into a number of workarounds that can be implemented in the SMTP client, pending a bugfix in the TLS protocol and in TLS implementations. Some of these workarounds may end up in Postfix.