Regarding that trouble-ticket, concerning a very well-known issue, i like to get your opinions. http://www.hostpoint.ch/support.php?subCatID=CASU3&mod=det&tid=52

Does anyone of you out there has a "fit for all purpose"-solution to such things? We had a similar attack a few weeks ago and solved it with some additional hardware to open more incoming slots. That worked fine and was a proof for our infrastructure concept. But: Are there better solutions available? Do we really have to add hardware + hardware + hardware while the bandwith on the user's side is continously growing?

My solution to this problem (which I called email-harvesting), and other threats is documented here:

http://www.dudes.ch/spamtracker/

I have in the meantime revised the approach slightly to no longer need sendmail source changes (I'm now doing the whole functionality within MIMEDefang). I've also added some optimization which boils down to: - the MySQL database contains the addresses that are supposed to be blocked, including a possible expiration for that block - small script runs in cron every 5 min and reads the list of all currently blocked addresses, and dumps it into an ipfw2 table - there's an ipfw rule that forwards incoming SMTP connections to port 26 for source-addresses that match the previously populated ipfw table - on port 26 finally there's a little daemon who's only purpose is to cache the contents of the MySQL table and answer with a 421 error and the error message stored for that particular block. The connection is then dropped, without forking at all. - during the time when an address is blocked until the firewall is updated, sendmail rejects the now blocked connections with a config rule.

If there is general interest, I'll document the new version.

Of course, there's also a rate-limit per source IP configured for incoming SMTP connections in ipfw.

These measures combined should give you very high resistance to such attacks, but you need to be able to determine within the SMTP handshake phase (at RCPT TO) whether the target email address is valid or not (and not just whether the domain is local). For some mail system setups, this could be tricky.

Oh, and of course, you have to run sendmail for this particular implementation:)

Cheers, Markus

Penalties work quite fine...

In postfix:

Every miss for a valid address get penalized by several seconds, if $count of misses occured, dropping the connection after $count of errors, combined with a connection limit.

Say you allow the same server to connect 5 times per minute, with a 2 seconds delay and a drop after 10 will give:

Number of addresses per minute: 5 * 10 = 50 Delay for 50 addresses = ~100secs (20secs if 5 connections are made in parallel - but the connection will be dropped for the next 40 seconds at the smtp greeting)

The smtp service will probably be hammered though - but it will at least cost you less cpu cycles to drop the connection at the smtp greeting, than checking if the recipient is valid.

There are some nice 3rd-party tools (mailgraph, pflogsum) that give you some insight what's happening and postfix logs the connection statistics - one of this tool will certainly give you some insight what IPs you'd like to nullroute...

I dunno about exim's or sendmail's or $your_favourite_mta's possibilities - but we live with this thing quite well over here...

On Mon, Apr 11, 2005 at 20:50:33 +0200, Matthias Hertzog wrote:

Does anyone of you out there has a "fit for all purpose"-solution to such things? We had a similar attack a few weeks ago and solved it with some additional hardware to open more incoming slots. That worked fine and was a

as always - my 2c Philipp