Feature request #1787: Rate limit brute force POP connection attempts

pam_unix(pop:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=  user=root
pam_unix(pop:auth): check pass; user unknown
pam_unix(pop:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= 
pam_unix(pop:auth): check pass; user unknown

Comments

1. Greg Hurrell 2011-02-24T16:22:28Z

   Product changed:

   • From: none
   • To: wincent.dev

2. Greg Hurrell 2011-02-25T12:23:49Z

   Ok, today was able to catch one of these attacks in progress. Load averages were insane during the attack:

   # uptime
    06:29:06 up *** days, 22:45,  1 user,  load average: 0.28, 5.41, 51.87

   Unfortunately, once the attack stopped the mail server was in such a state that it couldn't recover, requiring a restart:

   # service cyrus-imapd restart

   Corresponding entries from /var/log/maillog' (during the attack):

   Feb 25 06:16:24 domU-12-31-39-00-E9-02 pop3[28912]: badlogin: server213-171-220-245.live-servers.net [213.171.220.245] plaintext carlos SASL(-13): authentication failure: checkpass failed
   Feb 25 06:16:24 domU-12-31-39-00-E9-02 pop3[29207]: badlogin: server213-171-220-245.live-servers.net [213.171.220.245] plaintext chad SASL(-13): authentication failure: checkpass failed
   Feb 25 06:16:24 domU-12-31-39-00-E9-02 pop3[29209]: badlogin: server213-171-220-245.live-servers.net [213.171.220.245] plaintext betsy SASL(-13): authentication failure: checkpass failed
   Feb 25 06:16:24 domU-12-31-39-00-E9-02 pop3[29326]: badlogin: server213-171-220-245.live-servers.net [213.171.220.245] plaintext bahram SASL(-13): authentication failure: checkpass failed
   Feb 25 06:16:24 domU-12-31-39-00-E9-02 pop3[29180]: badlogin: server213-171-220-245.live-servers.net [213.171.220.245] plaintext brett SASL(-13): authentication failure: checkpass failed

   And after the attack, when the mail server hadn't properly recovered:

   Feb 25 06:45:26 domU-12-31-39-00-E9-02 deliver[3473]: connect(/var/lib/imap/socket/lmtp) failed: Connection timed out
   

3. Greg Hurrell 2011-02-26T10:56:31Z

   Trying out these rules:

   # iptables -N bansshee
   # iptables -A bansshee -p tcp --dport 110 -m state --state NEW -m recent --set --name pop3connect
   # iptables -A bansshee -p tcp --dport 110 -m state --state NEW -m recent --rcheck --seconds 60 --hitcount 10 --name pop3connect -j DROP
   # iptables -I INPUT -j bansshee
   # iptables -L
   Chain INPUT (policy ACCEPT)
   target     prot opt source               destination
   bansshee   all  --  anywhere             anywhere
   
   Chain FORWARD (policy ACCEPT)
   target     prot opt source               destination
   
   Chain OUTPUT (policy ACCEPT)
   target     prot opt source               destination
   
   Chain bansshee (1 references)
   target     prot opt source               destination
              tcp  --  anywhere             anywhere            tcp dpt:pop3 state NEW recent: SET name: pop3connect side: source
   DROP       tcp  --  anywhere             anywhere            tcp dpt:pop3 state NEW recent: CHECK seconds: 60 hit_count: 10 name: pop3connect side: source

   Basically:

   • Create a custom "bansshee" chain which can easily be added or removed from default INPUT chain
   • Record the IP addresses making any new POP connections in a list named "pop3connect"
   • If any IP address makes more than 10 such new connections in any 60 second period, drop the packets on the floor
   • Insert the "bansshee" chain in the default INPUT chain

   If it works well, will make the rules permanent.

4. Greg Hurrell 2011-02-26T11:09:46Z

   To make the rules permanent:

   # service iptables save # writes config to /etc/sysconfig/iptables
   # chkconfig iptables on

5. Greg Hurrell 2011-02-26T11:10:01Z

   Status changed:

   • From: new
   • To: closed

Add a comment

Comments are now closed for this issue.