• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Resolved How to Block SMTP AUTH attempts using a RBL

ChrisMonder

Basic Pleskian
Hello,

I'm getting a lot of SMTP AUTH intents, I have installed CSF, Juggernauth security plug and well all the intents become banned, but the "hacker" is trying every minute using a lot of different IP's

I know, it's quite common, but I want to block them, I have a very good RBL, I have checked a lot of times, and most all the IP's the "hacker" uses are listed, so I want to do this:
1.- Any connection to SMTP AUTH is first checked vs RBL, if the IP is listed, then DROP and/or BLOCK.
2.- If the IP is not listed then the user can try to use SMTP AUTH

I understand what this could carry some false/positives, I don't care, I really have checked a lot of times/days the RBL vs our real users IP's and they are not listed, vs the "bad" ones, yes, mostly are listed in that RBL.

Thanks in advance
 
I think this is an excellent idea. Because many servers that are infected are listed on e.g. Spamhaus' xbl list, so it would make a lot fo sense to disallow SMTPAUTH from such sources. Unfortunately though I don't think that this has been developed yet. At least I am not aware of such a solution. Merely posting this here to make sure I'll get an update if someone comes up with an existing solution.
 
Thanks Peter,

Yeah, would be great to accomplish this, I tried using Postfix main.cf, with these options added:

smtpd_client_restrictions = permit_mynetworks, reject_rbl_client XXXX.XXX (RBL list)
smtpd_delay_reject = no

But at the end, it blocked all the attempts, not based on RBL
 
No, that won't work, because the RBLs return an IP address, e.g. something like 127.0.0.3. That's not really an ip address, but an encoded response. The last octet normally defines what the RBL thinks about the sender address, e.g. 3 might mean = spammer. When you reject everything from such an address, you basically reject everything local.

What would be needed is a plugin, a modification to Postfix, a module, that checks the IP address of a person who wants to login against RBLs, and - if rejected - responds with the proper IP address. That's a new piece of software.
 
@ChrisMonder another thing that you can do is disable SMTP AUTH on port 25 in postfix then use Juggernaut Firewall to only allow access to the submission port 587 from countries that send mail though your server (Allow Countries to Port Settings). This will block most attacks.
 
@ChrisMonder another thing that you can do is disable SMTP AUTH on port 25 in postfix then use Juggernaut Firewall to only allow access to the submission port 587 from countries that send mail though your server (Allow Countries to Port Settings). This will block most attacks.
Could be good idea, can you tell me how to disable SMTP AUTH on 25?
We're using bitninja.io, you might want to give it a try. It works really good.
Hmm it's spam? does this does what I'm looking for? I´m happy with Juggernauth, just lacking of this protection that could be useful.
 
@ChrisMonder why don't you do the second option that I recommended (Disabling SMTP AUTH on port 25)?

To disable SMTP auth on port 25
1. Edit your /etc/postfix/master.cf
From:
Code:
smtp      inet  n       -       n       -       -       smtpd
To:
Code:
smtp      inet  n       -       n       -       -       smtpd -o smtpd_sasl_auth_enable=no
Restart Postfix
Code:
systemctl restart postfix

2. In Juggernaut ->Settings -> Firewall -> Port Settings -> remove port 587 and 465 from the TCP in and TCP6 in.
3. In Juggernaut -> Settings -> Country Settings -> Allow countries to ports add the countries you want to allow to those ports. Add port 587 and 465 to Allow countries to TCP ports. Then restart the firewall and login failure daemon. (I have included a screenshot).

Now ports 587 and 465 will only be accessible to those countries. All those other bots from other countries will be blocked. Just be aware that you have to have the submission port enabled under Tools and Settings -> Mail Server Settings and your clients will have to send though the submission port 587 or port 465.
 

Attachments

  • 2021-12-17_10h03_55.png
    2021-12-17_10h03_55.png
    320.9 KB · Views: 11
@ChrisMonder One last thing I would recommend. The default Juggernaut SMTP_AUTH trigger under Settings -> Login Failure Blocking is set to 5 failures which is fairly loose. If you are under active attack I recommend lowering that to 1 or 2. That way you should be able to block the attack a lot quicker. Also the netblock blocking will block the attacking networks quicker too.
 

Attachments

  • 2021-12-17_10h44_57.png
    2021-12-17_10h44_57.png
    395.4 KB · Views: 9
@ChrisMonder One last thing I would recommend. The default Juggernaut SMTP_AUTH trigger under Settings -> Login Failure Blocking is set to 5 failures which is fairly loose. If you are under active attack I recommend lowering that to 1 or 2. That way you should be able to block the attack a lot quicker. Also the netblock blocking will block the attacking networks quicker too.
Yep, I have them to 1 months ago, we don't have many clients, so in any false/positive is best for us to block all the wrong tries.

But like I wrote, the have a LOT of IP's, it's a directed attack as they know the usernames, so is not kind of a "wide" attack, if we had the possibility to use the RBL to block all the SMTP AUTH attempts before they try to AUTH, i'm sure we can down to a 3% of attempts.

Thanks anyway
 
@ChrisMonder Well if its a directed attack then an RBL isn't going to help you anyway. Usually what I do in this case:

1. Raise the perm deny limit in Juggernaut -> Settings -> Firewall -> General Settings to something like 20,000 so that attacking IP addresses are not rotated out.
2. Lower the SMTP_AUTH trigger to 1. and let the botnet do the attack then dump all the smtp_auth triggers from /etc/csf/csf.deny to a separate file like /etc/csf/csf.botnet.
3. CSF supports Include statements so you can use Include /etc/csf/csf.botnet inside of /etc/csf/csf.deny.

Usually the attacker will burn through his botnet within a day or two and I have a nice collection of the botnet IP address in /etc/csf/csf.botnet which I can use as I wish (keep it included in deny to always block it).
 
Yes, I have already months ago:

1.- To 15,000 IPs
2.- SMTP_AUTH = 1

I have a really good RBL that I checked a lot of times vs attacker IP's and my client IP's and it's 99% exact with the attacker IP's, so, yes a RBL will work if there's a way to block the SMTP AUTH using it.
 
> I have a really good RBL that I checked a lot of times vs attacker IP's and my client IP's and it's 99% exact with the attacker IP's, so, yes a RBL will work if there's a way to block the SMTP AUTH using it.

Use postscreen then as this is what it was designed for:
 
@danami Thanks for sharing this awesome tool!

Do you use Postscreen in any of your products by any chance?
I've used it in the past on some servers. I only recommend it for advanced users though because some of Plesk's older command line tools (like mchk) don't like heavy postfix customization so they break.

Postscreen is fine as long as you don't enable any of the "deep protocol" tests. If you don't use those options then postscreen can hand off the "live" connection to a Postfix SMTP server process without having the mail server retry. You can still enable options like postscreen_greet_action, postscreen_dnsbl_action, etc without having any delays.
 
> I have a really good RBL that I checked a lot of times vs attacker IP's and my client IP's and it's 99% exact with the attacker IP's, so, yes a RBL will work if there's a way to block the SMTP AUTH using it.

Use postscreen then as this is what it was designed for:
No, doesn’t work for my needs, my problem is not spammers, it’s a hacker.

Post screen is nice working for 25 port, and spam, but not for before SMTP AUTH, that’s my problem, in SMTP AUTH attempts.
 
@ChrisMonder Did you look at the articles? It supports pregreet DNSBLs with the postscreen_dnsbl_sites option. You can set the RBL weights so that Postscreen would reject the SMTP client.
 
Yes, but I can't enable on 465 or 587.

From the article:
"Note: Postscreen listens on port 25 only, so authenticated users from port 587 or 465 won’t be affected by Postscreen."

From the author:
"No. Postscreen only works on port 25. Port 587 is used for SMTP Auth. It’s not used for receiving emails from other SMTP servers."
 
Back
Top