pf trying to block repeated failed pop3 or imap logins

[pauljames]

Hi,

The firewall setup we have seems to work but perhaps a little better than was needed. As you see from the code below, $mail contains ports 25, 110, 143, 587, 993, 995.

The goal is to stop massive pop3 and imap failed logins, since these logins are just scripts trying to make use of a mail server on the Internet.

pass in on $ext_if proto tcp from any to any port $mail flags S/SA synproxy state \
        (max-src-conn-rate 9/15, overload <naughty> flush global)

The problem is, that clients that have say 10 or more email accounts on this mail server are going to fall into the naughty table because it says 9 connections from same IP in 15 seconds.

Same thing if someone has an email list and it sends out to a lot of people that happens to be on our email server.

Perhaps the code above has to be changed and break up $mail and have it more finely tuned?

Thanks in advance for your response.

 

[gkontos]

It definitely needs tuning for your environment but here is mine for pop3:

pass in on $mail proto tcp to any port pop3 flags S/SA keep state (max-src-conn 20, max-src-conn-rate 15/5, overload <mail_abuse> flush)

 

[pauljames]

Hi gkontos,

Thank you for replying.

So it seems you've got it right. Block pop3 connections if they are more than 15 in 5 seconds and if there are more than 20 connections from the same IP. However if you have clients that have 50 or more mail boxes, the max-src-conn 20
there will be problems because the IP will be blocked.

What I would like to implement (if I can) is, for say more than 6/5 "pop3d: LOGIN FAILED" "imapd-ssl: LOGIN FAILED" or just 'LOGIN FAILED" as it shows in our maillog, then block the IP. This would really work well because the spammers trying to send email would not be able to login, not tie up the server either.

 

[gkontos]

You are right it will also block legitimate attempts that's why I said it needs fine tuning.
Have a look at denyhosts I haven't used it but it looks good and maybe you can modify your mail logs to log on auth.log also.

 

[danger@]

you can have a look at security/bruteforceblocker but you will need to add a few regexpes yourself...

 

[kpa]

Hi gkontos,

Thank you for replying.

So it seems you've got it right. Block pop3 connections if they are more than 15 in 5 seconds and if there are more than 20 connections from the same IP. However if you have clients that have 50 or more mail boxes, the max-src-conn 20
there will be problems because the IP will be blocked.

What I would like to implement (if I can) is, for say more than 6/5 "pop3d: LOGIN FAILED" "imapd-ssl: LOGIN FAILED" or just 'LOGIN FAILED" as it shows in our maillog, then block the IP. This would really work well because the spammers trying to send email would not be able to login, not tie up the server either.

You shouldn't base your blocking rules on POP3 or IMAP connections but on plain SMTP connection on port 25. POP3 and IMAP are not used for sending email but only reading it.
Also consider implementing spam filtering on your mail server using blocklists (like spamhaus zen) and spamassassin (or something equivalent).

 

[gkontos]

You shouldn't base your blocking rules on POP3 or IMAP connections but on plain SMTP connection on port 25. POP3 and IMAP are not used for sending email but only reading it.
Also consider implementing spam filtering on your mail server using blocklists (like spamhaus zen) and spamassassin (or something equivalent).

You are right for most part but don't forget 2 things.

1) pop3 /imap hammering can cause a DOS issue. (been there)

2) most smtp servers accept authentication based upon the username & password of pop3 accounts. Therefore, a successful brute force attack can open doors to spammers.

 

[kpa]

Yeah you're right. I just feel that blocking based on number of connections within a set time is a bit too simplistic aproach and hard to get right. I would probably try for example security/sshguard-pf first because it would block based on failed logins and is not limited to just ssh and works with POP3 and IMAP as well.

 

[gkontos]

Yeah you're right. I just feel that blocking based on number of connections within a set time is a bit too simplistic aproach and hard to get right. I would probably try for example security/sshguard-pf first because it would block based on failed logins and is not limited to just ssh and works with POP3 and IMAP as well.

A very good suggestion :beer

 

[pauljames]

The problem I have seen in maillog is the attempts coming from same ip and trying hundreds of names@domain to login but only on pop3 (110) port. What I did so far to stop this is..

mail="{ 25, 143, 587, 993, 995 }"
pass in on $ext_if proto tcp from any to any port $mail keep state
.
.
.
pass in on $ext_if proto tcp from any to any port pop3 flags S/SA synproxy state \
        (max-src-conn 60, max-src-conn-rate 10/5, overload <pop3> flush global)

So far, watching the log for a while, it seems to have stopped the traffic at the firewall, letting our mail system do mail. Since some of our clients have 50-55 users in their office and potentially can login at the same time, we allow for that many connections from same src ip address.

 

[gkontos]

The problem I have seen in maillog is the attempts coming from same ip and trying hundreds of names@domain to login but only on pop3 (110) port.

1) First get more information regarding the attacker:

[CMD=""]$whois xxx.xxx.xxx.xxx[/CMD]

In most cases you can find a patten relating these IPs to countries, ISPs etc.

2) In whois information you will find abuse contacts. Email them letting them know of this behavior.

3) If you don't have any clients from those countries, ISPs etc. create a table with those networks and block them at your firewall level. You can decide if you just want to block pop3 service or everything.

 

[pauljames]

We have tried before sending mail to abuse accounts. We have found it's useless. I know of a user who managed to have his real email user/pass exploited (perhaps from a key logger) and I happen to see in log/main/current login using his credentials from a strange ip address.

Contacted that user and told the user to change their passwd. Contacted by email the ISP where it was coming from and they did not reply. So that sort of thing is really useless.

In our mail system, once a person can login with pop3, they can then send out email. Same with login for smtp. What we don't want is for someone running these scripts to luckily have a correct user/pass that happens to be further down their list to gain access and start either spamming or worse.

In all attempts I have seen, its a constant sending of user/pass because of LOGIN failures and by setting a reasonable limit on how many LOGIN attempts in x seconds, one can simply stop the abuse on the Server. No, the method cannot stop them from trying, but it only gets as far as PF because the IP is blocked.

I would rather let the Server for mail spend its cpu time running spam and virus checking than just fake LOGIN attempts.