On 01/07/13 02:18, Wietse Venema wrote: > John Fawcett: >> I would like to propose the following addition. As well as logging >> error_count as per the original patch, it also logs the number of >> messages accepted during the smtp session. The aim of that would be to >> identify clients that repeatedly connect and never attempt delivery. > Why do you even care? Remember, when the client sends no mail, then > the error count reflects all rejected commands in the entire session. > > I don't think it is a good idea to expose random pieces of SMTP > engine internals. > > Wietse Due to another failure of fail2ban (hopefully now solved) I had the chance to analyze another spambot attempt like the one that prompted my original post, this time 580 connections in 5 minutes.
Although inexplicable to me, seems like the attack started off by connecting and disconnecting without sending any commands, so with an error_count of 0. This continued even when the concurrency limit was reached. Then from the 16th attempt the bot actually started sending AUTH commands. My idea was to detect the first attempts and block earlier, though there is not much difference in it. Another idea is to parse the log for repeated concurrency limit (smtpd_client_connection_count_limit) being reached in a small timeframe. That is already available in the log, though was probably triggered in this case because I have changed it from the default. John
