PushDo Attack: Does anyone know how to DROP all incoming SMTP traffic from a specific IP address?

Blackhole DNAT. Like a normal DNAT, but you forward the traffic to a non-existent host IP (blackhole) on your network. DNAT has precedence over proxy traffic, so should work like a charm.

Bingo. Thanks a bunch.

For posterity, I identified an IP address in my network that was unused, and reserved it as a blackhole. Then I created a DNAT rule for any incoming service from the offending address to rewrite the destination as the blackhole. (Originally, I did this for SMTP only, but it seems like those f-----ers are also trying 587 and some other ports, so I just blocked "any". Perhaps just blocking the email ports 25, 587, 465 would have been ok, but whatever, this is easier).

Now, when I look at the firewall log, I see the DNAT happening, followed by the DROP rule (which I never removed). So I have two rules that together flush this thing, but that works for me.

My only worry now is that if I get attacked by several machines (i.e., different IP addresses), then I'll be playing whack-a-mole.

Just as an FYI, if you're using the UTM for DHCP, it doesn't do true reservations. Static-IPs need to be outside the scope offered by the UTM DHCP server instance. As an example, if the scope is currently 192.168.0.2-192.168.0.254, change it to 192.168.0.2-192.168.0.253 and use .254 as the blackhole. :)

No offense to Sophos, but I wouldn't dream of using UTM as my DHCP server.

Hi Scott, I was going to suggest DNAT when I first saw this post but after thinking about it, I don't see any need to DNAT . The only difference is that the offending IP will show up in your firewall log instead of SMTP log.

Here is my reasoning... The MTA will close the connection automatically after receiving bogus telnet commands. Since the MTA is only doing mail transactions and the backend server is taking care of the actual users, it will take a large enough attack to bog down the MTA.

On the other hand when we DNAT traffic to a non existing IP address (blackhole), you are creating unnecessary conntrack entries. Since the firewall doesn't know that the blackhole IP doesn't exist, those entries would keep on increasing till the conntrack times out.

Besides (ylmf-pc) is not a fqdn so the IP in OPs post would change frequently and soon enough he will have many DNAT entries creating many opened connections waiting to timeout.

I am just thinking out loud the pros and cons of dnatting such traffic. Your thoughts?
Regards

Here's my thought, and I'm no expert:

My real problem is that blocking the source IP address didn't yield any blocking (because the SMTP proxy handling happens before the blocking). This is worked around by DNAT -- essentially, instead of UTM seeing "here's incoming SMTP, send it to the SMTP proxy, and skip the firewall checks", it's told "here's an incoming connection, change the destination, process the firewall checks ... and oh, DROP."

I think the DNAT solution yields lower load; rewriting the destination and then dropping the connection is easier on the UTM device than actually attempting to do SMTP interactions. Furthermore, a drop without communication is likely to send the attacker off elsewhere sooner too.

Glad things are working out for you [;)] You dont' need a firewall rule to drop dnatted traffic as the default rule will drop the traffic anyway. (I had forgotten about the default DENY without explicitly allowing traffic)

However under heavy loads, I wonder if limiting traffic by IP and further limiting mails per connection would yield better results than trying to find offending IPs specially if they change frequently and generate a large number of connection attempts.

What about to add the IP to Host/Network Blacklist under Email Protection -> SMTP -> Relaying?

Oh! Looks like that might work too.

Hi, Tobias, and welcome to the UTM Community!

This is the first I've noticed that box. Have you tested that functionality? Since it's on the 'Relaying' tab, I would have expected it to affect mail being sent instead of mail being received, but the documentation isn't clear on that.

Cheers - Bob