This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

I'm being attacked by the PushDo spamming botnet (see serverfault.com/.../email-server-attack-from-telnet), identified by the following lines which repeat in my SMTP log:

2016:02:02-16:00:56 fw exim-in[5767]: 2016-02-02 16:00:56 SMTP connection from [104.40.23.216]:49657 (TCP/IP connection count = 2)
2016:02:02-16:00:57 fw exim-in[12914]: 2016-02-02 16:00:57 SMTP connection from (ylmf-pc) [104.40.23.216]:49657 lost

I've tried to manually drop this traffic, by setting up a firewall rule for 104.40.23.216 to my external address, service=SMTP to "drop".  This doesn't seem to work, as (I believe) the SMTP proxy receives the traffic before the firewall rule can drop it.

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



This thread was automatically locked due to age.
Parents
  • What about to add the IP to Host/Network Blacklist under Email Protection -> SMTP -> Relaying?
  • 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
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Seems pretty clear: "Networks and hosts specified in this list will be instantly rejected by the SMTP proxy."

    This is what I was needing -- the proxy to refuse to talk to a particular host.

    I backed out the protections against the perpetrator, but it looks like it's moved on and isn't attacking me anymore, so I don't have an easy way to test this.
  • Hi Bob, I did not tested that function, nope.
    But I am on a utm architect class, right now, where we have talked about this feature to get rid of attackers sending massive Email traffic to your MTA/UTM.
    Since the utm does not make any difference between 'allowed Hosts' in the relaying section (open relay problem) I would expect the utm not to do a difference in the 'block Hosts/Networks' either.
    I asume that these checkboxes simply create an auto firewall rule for smtp traffic in the input chain of iptables. This could be verified by checking iptables over ssh console.
    Hope this helps.
  • Thanks, Tobias - so, the instructor confirms this functionality? This would be good news as it would allow several of my clients to clean up their NAT rules.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • the blocked hosts command does not block hosts. It has nothing to do with iptables. All the boxes under smtp interact with exim and the way it performs and not the iptables (other than turning smtp on/off). By using block host, exim will deny relay to that host
    You will get a 550 Access denied (host blacklisted)

    The OP is trying to stop telnet sessions and this won't stop that. Dnat is still the best way, the question is under what conditions (too many connections per second/ too many different hosts too fast) is it practical to block by iptables compared to letting exim close connections before you have to contact your ISP to null route such traffic.

    In both cases, it will be impractical to use UTM to block large attacks. In very small scenarios, my contention is that exim by itself can fend of such attacks without any help from iptables. At the end, you are root/god of your own box so its upto you.
  • I have confirmed that this works as Tobias says. One of my clients that most needed this functionality had already discovered it in August of last year. Given the result of the version command, he was on 9.310 at the time. Ya learn sumthin' new everyday!

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Hi Bob, my earlier message got blackholed in the spam control mechanism. Lets try again...

    In short, Deny host relay section will not change any iptables rules.

    All it does it sends a 550 host denied message as is implied in webadmin. This message is generated by the MTA itself saying you are not allowed to relay mail from your host (IP). This would work fine if you are getting spam that regular control measures like dnsbl etc don't stop and you want to block a certain IP that is constantly sending you spam but will do NOTHING to stop telnet connections to your mail server which the OP is trying to stop.

    DNAT is the only way to block telnet probes and my argument was that is it worth denying random telnet connections that only show up in your logs and don't affect your mail operations?

    In any case, I think I have beat the dead horse long enough [;)]
Reply
  • Hi Bob, my earlier message got blackholed in the spam control mechanism. Lets try again...

    In short, Deny host relay section will not change any iptables rules.

    All it does it sends a 550 host denied message as is implied in webadmin. This message is generated by the MTA itself saying you are not allowed to relay mail from your host (IP). This would work fine if you are getting spam that regular control measures like dnsbl etc don't stop and you want to block a certain IP that is constantly sending you spam but will do NOTHING to stop telnet connections to your mail server which the OP is trying to stop.

    DNAT is the only way to block telnet probes and my argument was that is it worth denying random telnet connections that only show up in your logs and don't affect your mail operations?

    In any case, I think I have beat the dead horse long enough [;)]
Children
No Data