All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Use IPTables to Block Some Open Relay Scanners from Mail Server
Inspired by a question from @wlanboy on VPSBoard, I want to quickly share with you the IPTables rules I used to block some open relay scanners (or spammers) from mail servers. These IPTables rules are by no means complete or accurate. USE AT YOUR OWN RISK. Note: May not work on an OpenVZ VPS.
If you've seen these from your mail logs:
RCPT TO: <[email protected]> RCPT TO: <[email protected]> RCPT TO: <[email protected]>
This particular scanner always greet with "EHLO 192.168.2.33". Use these rules to stop them:
iptables -t raw -A PREROUTING -i eth+ -p tcp --dport 25 -m string --string "192.168.2.33" --algo bm -m recent --set --name SBOT iptables -I INPUT -i eth+ -p tcp --dports 25 -m recent --rcheck --name SBOT -j REJECT --reject-with tcp-reset
And that's it! Once recognized by IPTables, the scanner's TCP connection will be reset on the spot and unable to do harm to your servers. And eventually, these scanner's IPs will all be blacklisted on your server (until a reboot) and you will see no more of these.
Some other open relay scanners I've seen can be blocked with these additional rules:
iptables -t raw -A PREROUTING -i eth+ -p tcp --dport 25 -m string --string "<[email protected]>" --algo bm -m recent --set --name SBOT iptables -t raw -A PREROUTING -i eth+ -p tcp --dport 25 -m string --string "<[email protected]>" --algo bm -m recent --set --name SBOT iptables -t raw -A PREROUTING -i eth+ -p tcp --dport 25 -m string --string "<[email protected]>" --algo bm -m recent --set --name SBOT iptables -t raw -A PREROUTING -i eth+ -p tcp --dport 25 -m string --string "<[email protected]>" --algo bm -m recent --set --name SBOT iptables -t raw -A PREROUTING -i eth+ -p tcp --dport 25 -m string --string "<[email protected]>" --algo bm -m recent --set --name SBOT
Optionally, you can raise the IPTables recent module's limits. By default, each "recent" list will hold 100 IPs, while at most 20 packets from each IP will be remembered. In other words, older IPs will be removed once a list reaches 100 IPs, and we cannot set the "--hitcount" parameter to values higher than 20. To remove this restriction, create a file at "/etc/modprobe.d/xt_recent.conf" with a line such as the following, and reboot your server.
options xt_recent ip_pkt_list_tot=100 ip_list_tot=2000
Questions or comments are welcome.
Comments
Excellent, thank you.
I'm getting a lot of these scans coming from various IP addresses (always changing).
I've setup a fail2ban rule and it's currently sitting at 751 IPs blacklisted but I never noticed the idiots are using the same HELO command.
I've put the -m string into my firewall, thanks again.
That would often fail as rDNS is supposed to be used there I believe.
I kept thinking all day about a way in which to check these strings (email addresses) only in the header (eg: before the DATA command) or at least some sort of clever regex (doesn't seem to be supported natively in iptables) that matches ^rcpt to .[email protected].$
I'm trying to avoid false positives where an email address in a legitimate email body will get dropped.
Any thoughts?
Thanks
humm nice
People, just be aware this wont work 100%. If the sender chooses to evade detection they could easily just send the first half in one packet and the rest in the following. The string match module doesn't assemble fragmented packets, and is not connection aware (string over multiple packets in the same stream).
Also the string match module is very slow, I would recommend adding a limit rule before this so as not be run into a CPU exhaustion issue.
IPTables does not support Regex, its entirely doable to implement (it could even be done with NFQUEUE in userspace). However given that the string module itself is an imperfect hack, I doubt anyone would implement a regex module - its just not usually the right tool for the job.
Its probably better to do this filtering in userspace (your mail server).
@hwdsl2, @SplitIce:
I use a combo: CSF with its in-built portscanning blocks + ASSP + fail2ban to monitor mailserver & ASSP logs to nullroute offenders automatically (initially for a brief period, maybe a day or so, and then MUCH longer if they repeat the behavior).
Quite effective.
I'm not too worried about 'smart' scanners (as normally they are quite dumb) and if they go through the effort of evading the string detection they will only hit the postfix rejection rule (and spamming my logs which I'm trying to avoid in the first place).
I found quite a good solution which seems to work so far. the string module has the --to parameter to limit the number of bytes that are searched. Also, I'm looking at RCPT packets and the rules have become:
iptables -t raw -A PREROUTING -p tcp --dport 25 -m string --string "RCPT TO:$i" --algo bm --to 75 -m recent --set --name SBOT
iptables -t raw -A PREROUTING -p tcp --dport 25 -m string --string "RCPT TO:<$i" --algo bm --to 75 -m recent --set --name SBOT
iptables -t raw -A PREROUTING -p tcp --dport 25 -m string --string "rcpt to:$i" --algo bm --to 75 -m recent --set --name SBOT
iptables -t raw -A PREROUTING -p tcp --dport 25 -m string --string "rcpt to:<$i" --algo bm --to 75 -m recent --set --name SBOT
(i had to use all four for the same bot as they may use lower case/upper case or put the < delimiter or not. Obviously, the $i variable is picked up from a blacklist file.
Hopefully this will help someone that tries to keep clean logs (and spot any real rejects that shouldn't happen from many spam bots).
One of the problems with fail2ban is that the 'offenders' are most of the time hacked computers/servers that are normally harmless. Banning them (one by one) won't stop the huge botnet and the other to-be-hacked.
Nevertheless, it's important to have fail2ban to prevent brute force attacks from the same IP address.
@tcpdump, you've hit upon one of the key points in this effort: there is no one strategy or solution that can do the job by itself.
IMHO you have to use multiple strategies in concert for the most effective (and sustainable) solution.
I use a fail2ban filter for open relay scanners. I've modified the default postfix.conf (http://www.fail2ban.org/wiki/index.php/Postfix) and added the following :
Rules like this are actually a quite terrible idea.
A crafted packet with a spoofed origin can match a rule and allow an attacker to cause a ban of an arbitrary IP address.
If have these rules enabled, anyone can mess with you by getting your firewall to ban the IP addresses of legitimate mail servers, as well as Googlebot, etc.
Agreed. But you would have to consider the goals here. Most VPSs/small servers out there need protection from the majority of attacks (e.g. mass/scripted/bot attacks, brute force scanners, script kiddies playing around).
The situation you're talking about is more related to the next levels of attacks, as in, more targeted. They will probably get to that point when they are targeted but until then a better solution can be implemented.
What would you suggest as an alternative ? If thinking about behaviour based detection I would like to see some software suggestions there.
Actually I thought more about the loophole, and it seems to me that just adding -m state to check for an established connection fixes most of the problems.
But.. the scanner is already unable to do harm to my servers...
Agree with both @SplitIce and @singsing : IPTable rules for something like this can either be thwarted or misused.
Typical software for antispam use a combination of Naive Bayes and keyword search. Training the algorithm takes time and usually needs a lot of tweaking before you get good results. Barracuda sells a commercial spam filter.
Even GMail doesn't get spam-filtering perfect, so keep your expectations low
BTW, Apache has SpamAssassin if you are looking at an open-source alternative.