Connection from XXX.XXX.XXX.XXX refused, SMTP s... | MDaemon Technologies Community Forum
  1. Forum
  2. MDaemon
  3. Connection from XXX.XXX.XXX.XXX refused, SMTP server too busy.

Connection from XXX.XXX.XXX.XXX refused, SMTP server too busy.

  • N

    Hello!

    I have a problem. We've been under attack from hackers lately.

    in the logs they create many smtp connections which immediately terminate

    Thu 2024-01-11 16:03:30.196: Accepting SMTP connection from 154.64.236.217:20360 to 192.168.17.11:25
    Thu 2024-01-11 16:03:30.197: Location Screen says connection is from United States, North America
    Thu 2024-01-11 16:03:30.198: --> 220 mail.host.com ESMTP Thu, 11 Jan 2024 16:03:30 +0300
    Thu 2024-01-11 16:04:18.859: *  Socket error 10054 - Connection was reset by the other side!
    Thu 2024-01-11 16:04:18.859: SMTP session terminated (Bytes in/out: 0/56)

    At the same time, I see the following errors in the system log:

    Thu 2024-01-11 16:27:37.435: Connection from 89.31.146.150 refused, SMTP server too busy.

    I assume that due to the large number of simultaneous connections, some possibly useful ones are not accepted

    I increased the number of maximum concurent SMTP inbound sessions - 150, but it didn't seem to have any effect.

    Does anyone have any ideas on how to protect against this kind of attack?

    0 likes
  • A

    Its referred to as a DoS attack. If the connecting IP addresses are predicatable, block them as early as you possibly can, typically at your firewall.  Your firewall may even have features to help detect and block the malicious traffic. Allowing them to continue to MDaemon just so MDaemon can block them takes time and resources that should preserved for valid connections.  Thats not to say that MDaemon can't help by blocking connections that get through the firewall.  There are settings in MDaemon to limit the number of simutaneious connections from a single IP address. (Setup / Server Settings / Servers & Delivery / Sessions)  There are also options to block IPs that connect more than X times in Y minutes. (Security / Security Settings / Screening / SMTP Screening)

    If they are not predictable its a DDOS attack and they are much more difficult to deal with.  You may want to look into DDOS protection from 3rd party services.  

    You can try increasing the number of allowed inbound sessions, but in most cases the attacker will have more resources than you.  You'll also want to be watching the other services that you have available on the internet as they may start getting attacked.

    --
    Arron Caruth

    0 likes
  • N

    I analyzed the firewall and SMTP server logs
    In my case, the host connects and waits 1-2 minutes, then disconnects without saying anything.
    IP addresses are repeated, but within 10-20 minutes, then they change.

    Unfortunately, my firewall is not smart enough to block such attacks.
    I liked the idea "block IPs that connect more than X times in Y minutes",  but here we need to weigh everything, I’m afraid that some partners who send us a lot of letters will be blocked

    Does Security Gateway know how to block such attacks?

    0 likes
  • A

    If the IP is the same for 10-20 minutes, limit the simultaneous connections allowed from any IP address to something like 10.  That will hopefully prevent them from delaying real mail and in most cases shouldn't prevent partners from sending lots of mail.  Assuming they are not sending so much mail that it requires 5-10 connections open at all times.

    You could also try lowering the connection timeout.  (Setup / Server Settings / Servers & Delivery / Timeouts) The default is 10 minutes.

    When the IPs change, do they change to an entirely new IP block or are they using the same IP block?  If they are staying within the same IP block or range, just configure your firewall to block connections from that IP block.  If they are changing to entirely different blocks or ranges, the only way I know of to protect yourself is a 3rd party.    

    --
    Arron Caruth

    0 likes
  • N

    I analyzed the connection logs and based on this I calculated the guaranteed threshold when spammers get into it and good ones don’t
    For me this is 50 connections in 5 minutes.
    For several days I have been observing how spammers have been blocked, the logs are almost clean

    Thanks for the help!

    0 likes
  • A

    Great! Thank you for letting us know!

    --
    Arron Caruth

    0 likes
  • N

    unfortunately my problems continue

    the attackers have changed their tactics, now they connect once, but with different hosts
    Within 24 hours, 150k IP addresses were connected.
    The logic is the same - they just connect and do nothing for a little less than a minute.

    I don’t know what to do in this case.
    I randomly checked and where 50% of the attacking hosts are banned from the spamhouse. If DNSSLB would fire immediately upon connection, then I think this would partially solve the problem, but I haven’t found how to do it.

     

    0 likes
  • A

    There is not a way to have DNSBL lookups done immediately.

    You can use the Reverse DNS lookups and Location Screening to help block connection.  These lookups are done at the very beginning of the session.

    Are you doing PTR lookups on inbound sessions?  Security / Security Manager / Reverse Lookups.  Check the box for Perform PTR lookup on inbound SMTP connections and Send 501 and close connection if no PTR record exists.  Uncheck the box for Exempt authenticated sessions.  

    This will cause MDaemonn to immediately do a lookup for Reverse DNS, if no reverse DNS record exists for the IP, the connection will be dropped.

    You may also be able to find a list of bad IP addresses in a file that you could add to the IP block list in MDaemon. I found sereral using google, but I'm not sure how reliable the list will be. 

    If you find a list you like, I'd suggest adding it to your firewall.  Also, is your firewall able to perform lookups on the IPs that are connecting?  Perhaps you could implement the DNSBL lookup in your firewall?

    Have you tried collecting a list of bad IPs from your MDaemon logs? You could probably use Powershell get a list of IPs that have connected and then the session timed out.  You may also be able to use MDAemon\app\MDStats.exe, go to the Log Page and open your inbound SMTP log.  Save the file in CSV format.  Then you should be able to get a list of host names and IPs from the host column, you just have to manipulate the list to get only the bad IPs.

    --
    Arron Caruth

    0 likes
  • N

    PTR lookup does not work, because this check is started after the dialog starts, after EHLO(?)

    Sun 2024-02-18 11:55:50.963: 05: Session 09273081; child 0015
    Sun 2024-02-18 11:55:50.963: 05: Accepting SMTP connection from CLIENT_IP:46628 to 192.168.17.11:25
    Sun 2024-02-18 11:55:50.964: 03: --> 220 mail.domain.com ESMTP Sun, 18 Feb 2024 11:55:50 +0300
    Sun 2024-02-18 11:55:51.015: 02: <-- EHLO cleint-dns.domain.com
    Sun 2024-02-18 11:55:51.015: 03: --> 250-mail.domain.com Hello cleint-dns.domain.com [CLIENT_IP], pleased to meet you
    Sun 2024-02-18 11:55:51.015: 03: --> 250-ETRN
    Sun 2024-02-18 11:55:51.015: 03: --> 250-AUTH LOGIN CRAM-MD5 PLAIN
    Sun 2024-02-18 11:55:51.015: 03: --> 250-8BITMIME
    Sun 2024-02-18 11:55:51.015: 03: --> 250-ENHANCEDSTATUSCODES
    Sun 2024-02-18 11:55:51.015: 03: --> 250-STARTTLS
    Sun 2024-02-18 11:55:51.015: 03: --> 250 SIZE
    Sun 2024-02-18 11:55:51.042: 02: <-- STARTTLS
    Sun 2024-02-18 11:55:51.042: 03: --> 220 2.7.0 Ready to start TLS
    Sun 2024-02-18 11:55:51.126: 01: SSL negotiation successful (TLS 1.2, 256 bit key exchange, 128 bit AES encryption)
    Sun 2024-02-18 11:55:51.153: 02: <-- EHLO cleint-dns.domain.com
    Sun 2024-02-18 11:55:51.153: 03: --> 250-mail.domain.com Hello cleint-dns.domain.com [CLIENT_IP], pleased to meet you
    Sun 2024-02-18 11:55:51.153: 03: --> 250-ETRN
    Sun 2024-02-18 11:55:51.153: 03: --> 250-AUTH LOGIN CRAM-MD5 PLAIN
    Sun 2024-02-18 11:55:51.153: 03: --> 250-8BITMIME
    Sun 2024-02-18 11:55:51.153: 03: --> 250-ENHANCEDSTATUSCODES
    Sun 2024-02-18 11:55:51.153: 03: --> 250-REQUIRETLS
    Sun 2024-02-18 11:55:51.153: 03: --> 250 SIZE
    Sun 2024-02-18 11:55:51.180: 02: <-- MAIL FROM:<test@domain.com> SIZE=7142 AUTH=<> BODY=8BITMIME
    Sun 2024-02-18 11:55:51.180: 05: Performing PTR lookup (XXX.XXX.XXX.XXX.IN-ADDR.ARPA)
    Sun 2024-02-18 11:55:51.180: 05: *  D=XXX.XXX.XXX.XXX.IN-ADDR.ARPA TTL=(1410) PTR=[cleint-dns.domain.com]

    It’s not difficult to get the attackers’ IP, but the problem is that they don’t repeat themselves and banning them has no effect.

    I'm currently looking for some third-party programs that can help me, but somehow I can't find them very well.

    Ideally, there would be a setting in MD - “first command timeout in seconds”

    0 likes
  • A

    For the PTR lookups, did you uncheck the box for "Exempt authenticated sessions"? 

    --
    Arron Caruth

    0 likes
  • N

    @Arron Thank you for helping

     

    I tried to remove "Exempt authenticated sessions" after that all my clients sending via SMTP over the Internet were unable to do this. This method doesn't work for me.
    It’s a pity that MD doesn’t have connectors like Exchange

    0 likes
  • A

    I tried to remove "Exempt authenticated sessions" after that all my clients sending via SMTP over the Internet were unable to do this.

    There are a number of ways to work around this issue.

    You can exempt the clients IP addresses from the PTR requirement by adding their IPs to the exempt list.

    You can change clients to use the MSA port (587), when sending mail to MDaemon.  

    Users can use webmail.

    Users can use ActiveSync.

    --
    Arron Caruth

    0 likes
  • N

    Oh, use only MSA for clients would be a lifesaver for me.
    Right now I tested it and saw that SSL TLS does not work through MSA, 

    I made a separate topic on this issue https://mdaemon.com/community/forums/topic/122489/msa-over-ssltls-not-supported

    0 likes
Please login to reply to this topic!

Participants