Yet another scan for open relays

[wlanboy]

Back in december my mail server was hit by a huge amount of open relay scans.

About 100 per week and now they seem to come back:


Apr 1 10:38:54 wlan postfix/smtpd[13299]: connect from unknown[....]
Apr 1 10:38:54 wlan postfix/smtpd[13299]: NOQUEUE: reject: RCPT from unknown[....]: 554 5.7.1 <[email protected]>: Relay access denied; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<[....]>
Apr 1 10:38:55 wlan postfix/smtpd[13299]: disconnect from unknown[....]

They use different targets:


RCPT TO: <[email protected]>
RCPT TO: <[email protected]>
RCPT TO: <[email protected]>
RCPT TO: <[email protected]>
RCPT TO: <[email protected]>
RCPT TO: <[email protected]>
RCPT TO: <[email protected]>
RCPT TO: <[email protected]>
RCPT TO: <[email protected]>
RCPT TO: <[email protected]>
RCPT TO: <[email protected]>
RCPT TO: <[email protected]>
RCPT TO: <[email protected]>
RCPT TO: <[email protected]>
RCPT TO: <[email protected]>
RCPT TO: <[email protected]>
RCPT TO: <[email protected]>
RCPT TO: <[email protected]>
RCPT TO: <[email protected]>
RCPT TO: <[email protected]>
RCPT TO: <[email protected]>

Quite anoying to get all the fail2ban mails, because every single attempt is using another ip address.

Does anyone else notice this?

 

[howardsl2]

Yes I have seen the exact thing on my servers. Let me show you what I did to stop this.

I noticed that this particular scanner always start with "EHLO 192.168.2.33". So I implemented these:


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 and you will see no more of these.

Some other spammers 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

 

[Flapadar]

You could probably have some fun and TARPIT them instead of resetting the connection. Wastes their resources and has the same effect.