Just thought I'd put this here since it mentions Lena's excellent code. ...Todd
---------- Forwarded message ---------- From: Todd Lyons Date: Wed, Jul 25, 2012 at 9:45 AM Subject: Failed smtp auth /24's To: patternity ML I found several swamps that are ending up with lots of smtp auth failures. I'm thinking of just outright blocking connections from these /24's very early on in the connection. Can anybody give me some reasons why I shouldn't just outright block them? Only thing I can come up with is that we might have a legitimate customer in one of those netblocks. I'm also going to implement part of Lena's (from the exim mailing list) brute force detection because that forced 22 second delay after the second and beyond failed auth attempt seems like a very good way to slow down their brute force attempts...if they're doing that. I have not detected a blast of smtp auth attempts, it's usually spread out evenly over the day or week. Some of these are accounts that I detected as being compromised last week and earlier this week. In those cases, I just change the password for the mailbox so that it can still receive inbound mail, but stops all smtp auth outbound traffic. That caused a blast of failures as some botnet was actively exploiting the mailbox. The rest of these accounts are probably being actively probed for the password. This is only on one mail server in a load balanced system. Look below for log analysis that shows: 1. First group is the number of failed smtp auth connections for a specific mailbox. 2. Second group is the number of IP addresses in each /24 that attempted smtp auth). CentOS58[root@ivwm51 ~]# egrep "authenticator failed.*535 " /var/log/exim/main.log | perl failed_logins.pl --limit 20 251 => [email protected] 280 => [email protected] 304 => [email protected] 319 => [email protected] 68 => [email protected] 265 => [email protected] 260 => [email protected] 331 => [email protected] 271 => [email protected] 247 => [email protected] 348 => [email protected] 336 => [email protected] 316 => [email protected] 329 => [email protected] 62 => [email protected] 303 => [email protected] 75 => [email protected] 110.52.10.* => 40 110.52.6.* => 142 110.52.7.* => 139 110.52.9.* => 40 110.53.24.* => 176 110.53.25.* => 168 110.53.26.* => 167 110.53.27.* => 178 110.53.30.* => 49 110.53.31.* => 52 115.58.132.* => 25 115.63.10.* => 44 115.63.11.* => 38 115.63.12.* => 51 115.63.13.* => 46 115.63.14.* => 39 115.63.15.* => 49 115.63.8.* => 54 115.63.9.* => 39 125.44.240.* => 22 125.44.241.* => 21 125.44.242.* => 25 125.44.243.* => 26 125.44.247.* => 26 222.140.163.* => 23 42.49.128.* => 168 42.49.132.* => 49 42.49.133.* => 61 42.49.136.* => 40 42.49.137.* => 52 42.49.138.* => 47 42.49.139.* => 41 42.49.140.* => 39 ...Todd -- The total budget at all receivers for solving senders' problems is $0. If you want them to accept your mail and manage it the way you want, send it the way the spec says to. --John Levine -- The total budget at all receivers for solving senders' problems is $0. If you want them to accept your mail and manage it the way you want, send it the way the spec says to. --John Levine -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
