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

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. :)

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.

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.