Use Host Screening to quickly block abuse

One of the advantages of running my own MDaemon server is that I keep an eye on a lot of the spam and abuse that’s floating around on the internet.

Over the years I’ve put together a list of EHLO strings that can be used by MDaemon’s host screening tool to block inbound connections. Most of these are invalid based on their syntax, but yet are hitting a reasonable number of spam delivery attempts. Find the HostScreen.dat file \MDaemon\App directory and add the following:

all localhost refuse
all user refuse
all friend refuse
all -* refuse
all *_* refuse
all #.#.#.# refuse
all *.invalid refuse
all *# refuse
all */* refuse
all *|* refuse
all ylmf-pc refuse

Save the file, and then create a “hostscreen.sem” in the \MDaemon\App directory to reload the contents of the HostScreen.dat file.

If you haven’t used MDaemon’s semaphore (SEM) files before, the following command will do it:

echo. > C:\MDaemon\App\hostscreen.sem

I have yet to observe any false positives, although it’s not impossible, so watch your logs if you’re worried.

I do periodically update this list, and if anyone has any entries to contribute, please do so in the comments. When the post is updated, it will be promoted to the top of the list, but generally no email notifications will be sent.

CC BY-NC-ND 4.0 Use Host Screening to quickly block abuse by Dave Warren (everything-mdaemon.com) is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.

9 Replies to “Use Host Screening to quickly block abuse”

  1. Hi Dave.

    Thanks for sharing.

    I receive a lot of SMTP auth attacks lately, and more than 90% of them are presenting as

    ylmf-pc

    I’m using this one (with success) in each MDaemon installation screening (i’ve got arround 100 or more connections for about ten minutes, same IP; after that remote IP changes, EHLO stays the same).

    This is how screening log looks like (10 seconds!):

    Tue 2016-03-15 16:47:49.867: Host screening refused connection to 192.168.x.x from ylmf-pc
    Tue 2016-03-15 16:47:50.289: Host screening refused connection to 192.168.x.x from ylmf-pc
    Tue 2016-03-15 16:47:54.648: Host screening refused connection to 192.168.x.x from ylmf-pc
    Tue 2016-03-15 16:47:55.117: Host screening refused connection to 192.168.x.x from ylmf-pc
    Tue 2016-03-15 16:47:55.570: Host screening refused connection to 192.168.x.x from ylmf-pc
    Tue 2016-03-15 16:47:56.133: Host screening refused connection to 192.168.x.x from ylmf-pc
    Tue 2016-03-15 16:47:56.555: Host screening refused connection to 192.168.x.x from ylmf-pc

    Maybe this helps.

    T

    PS: some tool to block (or list / output) the IP after first EHLO with a known bad name could be handy. :)

  2. So this is weird, I run SecurityGateway and MDaemon, both of which listen on port 25. SecurityGateway has no hits at all, but MDaemon has tons. I wonder what criteria they’re using to find servers? mail.$domain or similar perhaps, but apparently not scanning for open SMTP services.

  3. Yes Dave (to answer your previous comment), it’s SMTP(in).

    I don’t know about Security Gateway, I am not using, but all production MDaemon I oversee have enough hits for this one.

    Some of them (about 70 percent) have minimum to moderate activity regarding ylmf-pc EHLO, but rest of them have “tons” of it (see my example above). All are production servers, all are old enough (since version 9 at least), almost all running latest version (15.5.x) MDaemon Pro with different user count licenses.

    I can only relate increased activity to last time MX IPs were changed, the more affected having same IP for a long time (they are configured on customers /29 public subnets, so primary MX hasn’t changed for “ages”). It’s not a 100% rule, but it’s close to that.

    The good part of this is that – since 14.5.0 I think – MDaemon allows to screen hosts immediately after EHLO, so no harm is done, but would also be nice to find a solution to screen also IPs related to this EHLO strings in order to refuse connections from those IPs after few “bad” sessions tryouts.

    I will keep it under watch and I will try to open a support case with AltN regarding this, maybe will get it on a wishlist :)

    Thanks,

    T

  4. on top of the mentioned ones, i also employ the following as they are mainly spam:

    all *.dailyfortuity.net refuse
    all server.server.com refuse
    all *.server.com refuse
    all *.work refuse
    all *.serverhub.com refuse
    all *.website refuse
    all *.xyz refuse
    all *.win refuse
    all *.date refuse
    all *.faith refuse
    all *.review refuse
    all *.racing refuse
    all *.in.net refuse
    all *.download refuse
    all *.club refuse
    all *.bid refuse
    all *.top refuse
    all *.bmsend.com refuse
    all *ylmf-pc refuse
    all *.ylmf-pc refuse
    all ylmf-pc refuse
    all *.science refuse

  5. I use this “regex” in my hostscreen.dat:

    all #.#.#.# refuse
    all #-#-#-# refuse
    all #.#.#.#* refuse
    all #-#-#-#* refuse
    all *#.#.#.# refuse
    all *#-#-#-# refuse
    all *#.#.#.#* refuse
    all *#-#-#-#* refuse
    all */* refuse
    all *|* refuse

  6. First, just to be clear, these are not regexs and are just glob-ish pattern matches. Also, several of those are redundant, and may block too widely, for example, these three are all included in the last one, so the first couple can be dropped:

    all #-#-#-#* refuse
    all *#-#-#-# refuse
    all *#-#-#-#* refuse

    Also, you may not necessarily want to do that, as some large mail vendors may use that format for their rDNS and EHLO values, so monitor carefully — You will get a lot of spam from bots living on DUL type end user connections, but, the false positives are potentially scary.

  7. Hi Dave,

    Thanks for your informative blog.

    I know you don’t provide “support”, but I’ve encountered an interesting situation that may not be common. I’ve recently been getting a spate of unsuccessful authentication attempts from known hacker addresses, reporting “HELO *.*”. If I try to block this guy by using *.* in the “Host Screen” based on HELO values, MDaemon sees this as a wildcard entry.

    Sat 2017-04-29 01:04:49: 250 smtp.xxxx.com Hello *.*, pleased to meet you

    Is there a way to block a hacker using an HELO of *.* ?

  8. Huh. That’s clever. I vaguely recall there might be a way to handle this, I’ll take a look.

  9. Interestingly, I did enter *.* into the Host Screening, but hours later realised the dilemma. I then expected that my entry of *.* might have blocked everyone, but in addition to not blocking the emails from the *.* guy, it seemed not to be blocking anyone. But perhaps my other “allow” entries were the successful ones and I just didn’t see the ones that were blocked.

    Thanks again for your help.

Leave a Reply

Your email address will not be published. Required fields are marked *

*