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.

13 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.

  10. Hello,

    I don’t know this is still alive just question.

    Does IPScreen.dat have some limitation? I mean # of lines or something like that.
    My IPSceen.dat actualy contain 3500+ lines and actually I facing problem when even listed IP or IP block again and again pop-up in my mails with temp-block again and again.

  11. There is a limit after which MDaemon will ignore any further lines, but I can’t find a reference to what exactly that limit is. I’d recommend setting up wrbldns which will dynamically read a text file and return an appropriate response to MDaemon via DNS. This does take a bit of configuration to get it going though.

  12. Thank you for reply, but I don’t trust these kind of software.

    Maybe it’s time to switch to better mail server if mdaemon can’t handle this simple and basic function properly.

  13. I understand where you are coming from, but the reality is that this feature is not intended to be used for massive blacklisting, and in my consulting experience when I see someone doing such a quick inspection of the logs shows that the vast majority were useless (either no traffic came from the IP, or said traffic was otherwise blocked anyway).

    I’m not sure what you mean by “these kind of software” though, rbldnsd is widely deployed across the industry and is open-source. There are other DNS based approaches if you prefer, you could use named with nsupdate to make changes if desired although this is far less efficient.

Leave a Reply

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

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.