PF protect imap from failed attacks with different nonrepeating IP addresses

[spacecoast]

Does anyone know a clever way to protect imap, like we can do with obspamd for smtp ? With obspamd we can use HUGE lists, it uses db with fake mail server and rdr pf rules....

Many of the imap attacks are from IPs on dnsbl-1-uceprotect that I rsync and clean with a cron, but it is too large to use in a table on pf.

Open to helpful suggestions, tia.

======== background for question ==========
I know I should have given up on uw-imap long ago, but I only have less that fifty legacy email accounts on server and uw imap has worked fine for decades and each have a lot of archived email in mixed formats. I am using xinetd to wrap it and pf as firewall. I have a homegrown mix of blacklists and I rsync uceprotect and cbl-list and dnsbl-1-uceprotect but they are to large for pf tables. I feed cbl-list into obspamd by breaking into chunks and for protecting sendmail that has worked very well. Blacklists like cbl and uceprotect are way to huge to use as a pf table.

Over the last couple of days I am getting a very large number of imap guessing attempts and the variations of the ips are so great and non repeating, max try 1 each, that methods like fail2ban don't matter because even if it triggered, hundreds of IP addresses are being used to try guessing passwords. Fortunately most of the IPs are listed on the uceprotect table, but unfortunately the uceprotect-1 is so huge I cannot use with firewall as a table, 180K+ entries.
wc -l dnsbl-1-uceprotect.cidr
183706 dnsbl-1-uceprotect.cidr

Yes I should migrate to dovecot, but over the years we have a mix of mail formats that are incompatible and would require email file/folders to be converted individually from uw to replacment.
But could dovecot do anybetter against attacks like this? can dovecot use an external HUGE blacklist? could any tcpwrapper use a huge external blacklist?

 

[spacecoast]

OKAY THIS IS UGLY, and has not crashed server yet.

set cron to run script to split the file into 10K chunks something like
/usr/bin/split -l 10000 /var/www/spamd-setup/dnsbl-1-uceprotect.cidr.txt /var/www/spamd-setup/dnsbl-1-uceprotect.cidr.



add to /etc/pf.conf.test
and pfctl -f /etc/pf.conf.test (so if crashes uses /etc/pf.conf on repower)

table <uceprotectaa> persist file "/var/www/spamd-setup/dnsbl-1-uceprotect.cidr.aa"
table <uceprotectab> persist file "/var/www/spamd-setup/dnsbl-1-uceprotect.cidr.ab"
table <uceprotectac> persist file "/var/www/spamd-setup/dnsbl-1-uceprotect.cidr.ac"
table <uceprotectad> persist file "/var/www/spamd-setup/dnsbl-1-uceprotect.cidr.ad"
table <uceprotectae> persist file "/var/www/spamd-setup/dnsbl-1-uceprotect.cidr.ae"
table <uceprotectaf> persist file "/var/www/spamd-setup/dnsbl-1-uceprotect.cidr.af"
table <uceprotectag> persist file "/var/www/spamd-setup/dnsbl-1-uceprotect.cidr.ag"
table <uceprotectah> persist file "/var/www/spamd-setup/dnsbl-1-uceprotect.cidr.ah"
table <uceprotectai> persist file "/var/www/spamd-setup/dnsbl-1-uceprotect.cidr.ai"
table <uceprotectaj> persist file "/var/www/spamd-setup/dnsbl-1-uceprotect.cidr.aj"
table <uceprotectak> persist file "/var/www/spamd-setup/dnsbl-1-uceprotect.cidr.ak"
table <uceprotectal> persist file "/var/www/spamd-setup/dnsbl-1-uceprotect.cidr.al"
table <uceprotectam> persist file "/var/www/spamd-setup/dnsbl-1-uceprotect.cidr.am"
table <uceprotectan> persist file "/var/www/spamd-setup/dnsbl-1-uceprotect.cidr.an"
table <uceprotectao> persist file "/var/www/spamd-setup/dnsbl-1-uceprotect.cidr.ao"
table <uceprotectap> persist file "/var/www/spamd-setup/dnsbl-1-uceprotect.cidr.ap"
table <uceprotectaq> persist file "/var/www/spamd-setup/dnsbl-1-uceprotect.cidr.aq"
table <uceprotectar> persist file "/var/www/spamd-setup/dnsbl-1-uceprotect.cidr.ar"
table <uceprotectas> persist file "/var/www/spamd-setup/dnsbl-1-uceprotect.cidr.as"

block in log on $ext_if proto {tcp, udp} from <uceprotectaa> to any port {143,993,110,995}
block in log on $ext_if proto {tcp, udp} from <uceprotectab> to any port {143,993,110,995}
block in log on $ext_if proto {tcp, udp} from <uceprotectac> to any port {143,993,110,995}
block in log on $ext_if proto {tcp, udp} from <uceprotectad> to any port {143,993,110,995}
block in log on $ext_if proto {tcp, udp} from <uceprotectae> to any port {143,993,110,995}
block in log on $ext_if proto {tcp, udp} from <uceprotectaf> to any port {143,993,110,995}
block in log on $ext_if proto {tcp, udp} from <uceprotectag> to any port {143,993,110,995}
block in log on $ext_if proto {tcp, udp} from <uceprotectah> to any port {143,993,110,995}
block in log on $ext_if proto {tcp, udp} from <uceprotectai> to any port {143,993,110,995}
block in log on $ext_if proto {tcp, udp} from <uceprotectaj> to any port {143,993,110,995}
block in log on $ext_if proto {tcp, udp} from <uceprotectak> to any port {143,993,110,995}
block in log on $ext_if proto {tcp, udp} from <uceprotectal> to any port {143,993,110,995}
block in log on $ext_if proto {tcp, udp} from <uceprotectam> to any port {143,993,110,995}
block in log on $ext_if proto {tcp, udp} from <uceprotectan> to any port {143,993,110,995}
block in log on $ext_if proto {tcp, udp} from <uceprotectao> to any port {143,993,110,995}
block in log on $ext_if proto {tcp, udp} from <uceprotectap> to any port {143,993,110,995}
block in log on $ext_if proto {tcp, udp} from <uceprotectaq> to any port {143,993,110,995}
block in log on $ext_if proto {tcp, udp} from <uceprotectar> to any port {143,993,110,995}
block in log on $ext_if proto {tcp, udp} from <uceprotectas> to any port {143,993,110,995}


------------
and maybe a cron to run script to rsync the data, and pfctl to update the 18 tables

ugly, but for the majority of the imap guessing attacks have faded.

 

[sko]

It isn't the IMAP-servers job to handle blacklists to drop/block connections, that's the firewalls job.


Pushing around huge lists of IPs (or subnets) sounds like a job for BGP. Peter Hessler has given a nice talk about this topic on various occations [1]. A quick search also brought up his old website about this project [2].
It focuses on OpenBSD, but the core principles apply to OpenBGPd and PF on FreeBSD as well. I've used his ideas as a starting point to distribute various blacklists (some of which are huge and highly dynamic) between our mail servers, routers and firewalls.
The spamhaus DROP list (especially the extended list) might be also of interest under this topic.
Those lists could be either fed into PF tables or used to null-route any traffic from/to those IPs. The second approach is more effective and resource-friendly, but you have to adjust the hosts routing quite a bit - with the risk of completely cutting off that host if something goes wrong and you don't have physical or OOB-access to the host.


OTOH - a high rate of bruteforce attacks on IMAP usually indicates that mail addresses/maildomains that server is responsible for have been part of breaches where mailaddresses + passwords have been leaked. Check your hosted addresses and domains against the HIBP database! We've had multiple waves of (failed) login attempts over the years for mailaccounts that have been part of breaches, and the biggest spikes in such attacks often coincided with major leaks/breaches which were reported by HIBP more or less at the same time.
If your users only connect from a certain region/country you could also implement geoIP-based blacklisting. If most of those automated attacks originate from another continent this is _very_ effective to reduce the noise.

But again: all of those measures have to be implemented at the firewall level, not the imap-server. Drop the connection as soon as it reaches the host, not after it already used up resources and cpu time (and then uses additional resources because the imap-server has to run another check and gracefully end the connection).


[1] e.g. https://www.bsdcan.org/2014/schedule/events/458.en.html
[2] http://64.142.121.62/
[3] http://www.spamhaus.org/drop/

 

[SirDice]

OTOH - a high rate of bruteforce attacks on IMAP usually indicates that mail addresses/maildomains that server is responsible for have been part of breaches where mailaddresses + passwords have been leaked.

Not really. My server has never been compromised or any of its accounts leaked and I still get copious amounts of attempts. There are bots doing nothing but scanning for open ports, as soon as they find one they'll bombard it with attempts. It does seem to come in waves, probably running out of compromised (or guessed) accounts at some point and it takes a little while for some other botnet to start the whole show all over again. Unfortunate fact of internet life these days.

 

[sko]

Yes, that's the normal background noise and especially common for ssh and other "high profile" ports. On SMTP(S) or Submission Ports there is also a considerable amount of noise (aside from normal spam...) from bots trying to use a server as a relay, but on IMAP I've really never seen such a high level of obviously braindead random noise - they were always at least somewhat targeted to only try adresses within the domains for which that host is listed as an MX or in the SPF records. E.g. I've never seen bots trying to log in with @gmail.com accounts at our servers, except for very rare and very stupid waves of bots which usually disapper within minutes...
The most stupid and annoying 'attacks' nowadays are IMHO the random attempts to access unprotected scripts or folders from wordpress, phpmyadmin, adminpanels and other crap. Not that nginx (or apache) couldn't cope with this crap, but this can completely render webserver-logs unusable for proper debugging.

edit: just checked the logs of 3 smaller mailservers (with ~2-35 users) and found only 3 IMAP login attempts for foreign domains. 2 of those mailservers (or their IPs) have been used for 8 years, so they usually attract quite a high level of background noise (their spamd-blacklist tables with 24h threshold time usually have 3500-4000 entries...)

 

[SirDice]

on IMAP I've really never seen such a high level of obviously braindead random noise - they were always at least somewhat targeted to only try adresses within the domains for which that host is listed as an MX or in the SPF records. E.g. I've never seen bots trying to log in with @gmail.com accounts at our servers, except for very rare and very stupid waves of bots which usually disapper within minutes...

I haven't managed to capture one of those bots. I mean I've seen them hammering on my IMAP but never managed to grab the actual bot code that's doing it.

The most stupid and annoying 'attacks' nowadays are IMHO the random attempts to access unprotected scripts or folders from wordpress, phpmyadmin, adminpanels and other crap. Not that nginx (or apache) couldn't cope with this crap, but this can completely render webserver-logs unusable for proper debugging.

These bots I have managed to grab a few of them. They all seem to be variations of a familiar IRC bot written in Perl (judging by the variable names the original author was Spanish speaking). I filter all these out to a local nginx instance through HAProxy. HAProxy only forwards the correct URLs to backends and everything else gets dumped to that local nginx instance. That helps weed out a lot of crap unless the attacks are specifically directed at the valid URLs.

 

[sko]

I haven't managed to capture one of those bots. I mean I've seen them hammering on my IMAP but never managed to grab the actual bot code that's doing it.

I also haven't dissected any of those bots. All of my "knowledge" is only based on lots and lots of logs, experimenting with especially stupid bots/attack patterns and some blog entries one stumbles upon over the years...

I filter all these out to a local nginx instance through HAProxy. HAProxy only forwards the correct URLs to backends and everything else gets dumped to that local nginx instance. That helps weed out a lot of crap unless the attacks are specifically directed at the valid URLs.

This sounds very interesting. I've never used HAProxy but I'll definitely look into that!

(and sorry for OT-talk)