Use Host Screening to quickly block abuse

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

14. I know this is an old thread but I found it very informative, I been having issues with blocking a few IP’s and was a little frustrated until I read Dave Warren comment ‘this feature is not intended to be used for massive blacklisting’, im an idiot we have perfectly UTM/USG devices which are made for this job.

    Thank you, Dave, for breathing some sanity into this tread.

    I think the issue is that you see all the wonderful tools in Mdaemon and go wow, (I know I did) and of course if all you have is a hammer then everything else is a nail.

15. Just thought I add to the as screening main culprits at ELHO is very efficient I recently realised, right tool for the right job and all that.

    I like to block all domain that ends in number.anything e.g 163.com, in regex terms it would be ([0-9]){2,4}+\.[a-zA-Z]{2,11}$

    Would be correct in assuming that:
    all *#-* refuse would do that?

    >>> my current list is, should it be useful <<<

    all -* refuse
    all *_* refuse
    all #.#.#.# refuse
    all *.invalid refuse
    all */* refuse
    all *|* refuse
    all friend refuse
    all ylmf-pc refuse
    all *.website refuse
    all *.xyz refuse
    all *.win refuse
    all *.date refuse
    all *.faith refuse
    all *.review refuse
    all *.racing refuse
    all *.download refuse
    all *.club refuse
    all *.bid refuse
    all *.top refuse
    all *.buzz refuse
    all *.bar refuse
    all *.cyou refuse
    all qq.com refuse
    all 163.com refuse
    all mytel.com.mm refuse
    all noreply.com refuse
    all arteconews.it refuse
    all web-mail.com refuse
    all zentan.co.tw refuse
    all woast-etier.com refuse
    all kioskandvendingoperator.com refuse

16. Well here it is about 8 years later and this is still a great way to block scam/spammers. I used the “hostname” block feature (Security>Security Manager>Screening>Host Screen) and it works a charm. I would caution some that use the above lists though, as .faith is a very popular domain for churches so you may be blocking something you need to allow. Content filtering will be a better option there.
    Thanks!

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