Protecting port 25

Hi Susan,

I wondered if you could offer any advice. I can see from the security events on my SBS2003 server that someone is attempting to get into my server remotely. They are trying multiple usernames and passwords. The most common username they are trying is “DC”, although many others have been attempted. I get up to 200 attempts a day. I feel a bit like a sitting duck, just sitting here waiting for them to guess the correct username/password combimation. I have made sure that I am fully up to date on all Microsoft patches and that only the bare minimum of TCP ports are open. Is there anything you would recommend I should do?. The passwords are all very complex, so hopefully they will not guess correctly. It’s just a bit un-nerving having someone trying to do this to my beloved SBS server.

Many thanks

Hi.. I’m going to guess that these attacks are coming in via port 25.  And that’s one of the things that the use of a hosted mail in front of SBS prevents.  Because I only allow port 25 connections from, I’ve so far (knock on wood) don’t see these port attacks.  Like the poster said, if you have good passwords, don’t panic and don’t fear …but truly if you want a tad more warm fuzzy feeling, have something in front of your SBS box that you trust filtering that email.  Whether that’s or or another spam filtering ‘thing’ in front of your box…. a warm fuzzy between you and the bad guys means that I don’t have those port 25 port pings.

The other warm fuzzy is RWW-guard and AuthAnvil from Scorpion Software to put two factor authentication on that connectivity.  Bang on those ports all they want but without that token in their possession.. they are not getting in.

More information is here Messaging security and Disaster recovery webcast with Hosted services. …and some cost studies here on a Hosted messaging wiki.


8 Thoughts on “Protecting port 25

  1. Anytime you are hosting services available to the public you should make sure you have a very good application layer firewall. These devices care about what kind of traffic comes through a port, not just that a port is open. So in Susan’s example of port 25. In an application firewall you would specify that only incoming email is allowed on port 25. All other requests would be rejected.

  2. You could try running ISA in front of your SBS box which should give you more protection.

  3. Why are we assuming that this is happening “over port 25”? By default, SBS SMTP services only require authentication if a sender wants to relay.
    Instead, the first response should be asking the question – “what do you have open to the Internet?”
    You’ll get these auth attempt events for RWW, Companyweb, FTP; basically any SBS service that:
    – is available to the world
    – reaquires authentication at any point in the process.
    IOW, don’t jump on ports, because they dont’ authenticate – the applications using them do.
    Use that time frame to scan your system and application logs; what service or application logged a similar failure? What happened in the FTP/IIS/SMTP logs at that same time? What is found in the firewall logs (assuming you have one)?

  4. Ahh…the Tony Tsu school of advice again.


  5. bradley on March 29, 2007 at 10:50 pm said:

    Steve it’s “Su” not Tsu. At least spell it right shall we?

    And Mr. me a SBS box getting admin account pings in their log files and 99.999999999999999% of the time it’s port 25.. coming in via email.

    You I’m sure get them from many places including Mr. Su. The rest of us mere mortals more often than not, don’t. We are assuming because more often than not, it is.

  6. Email’s that ping?….

  7. “admin account pings in their log files” – this depends on which log files you choose to observe. Yes, spammers will test your mail services for relay functionality, but these will only appear in the SMTP logs. If that’s all you examine, then yes – that’s all you’ll find.
    My own experience (as well as others more experienced) with authentication attacks has proven your assertion to be limited at best. Internet authentication attacks primarily target web services (HTTP/FTP). Any SMTP-based auth events are secondary at best.
    The point is, just because you think it is, doesn’t make it so. Perfom due diligence and take action based on empirical; not anecdotal evidence.

  8. So how do you trace where the attacks are coming from?

Post Navigation