Email Dictionary Attack
hello
for about 2 days now, whm has been trying to send random mails to email addresses that we do not have.
"No such person at this address" in whm
After 100 mails
Number of failed recipients exceeded. Come back in a few hours.
it shows as in the attachment.
Mails sent to us with dictionary attack are cut off at 100.
When I look at the IPs, they all appear as spam IPs in abuipdb.
I wonder how I can prevent this situation.
in whm
Dictionary attack protection > on
Ratelimit suspicious SMTP servers > on
Ratelimit incoming connections with only failed recipients > on
in the case.
for example, can we block an SMTP server that tries to send us an erroneous mail at 10 mails instead of 100?
or how can we solve this problem completely.
Regards
-
It looks as if, starting this weekend, they've also started targetting IMAP/POP3. So don't be surprised if you see this happening on your server.
0 -
mtindor I think those will be blocked automatically since they will count as failed logins, no? Or could you please define the behaviour you're seeing in the attack?
0 -
Same - unless they are just opening dead connections somehow, I would expect those connections to get blocked at services requiring a login.
0 -
We'll see once they reply, but maybe what mtindor meant is that the attacker will use 100 IP addresses at once to connect to the IMAP port and then idle it out until IMAP login times out, which I think is only a couple seconds (EDIT: nope, by default it's 30 seconds!) but still, I think there's potential to cause issues for legitimate users if that's what mtindor meant.
0 -
Benjamin D. - what about this option?
https://support.cpanel.net/hc/en-us/articles/4409959071511-How-to-configure-CSF-for-DDoS-mitigation
Yes, it's CSF so it's not directly us, but it blocks based on the number of connections to the server per IP. Would that work for this situation? This also means you wouldn't need to manually block IP addresses.
0 -
I have experimented with this setting a couple months ago for Apache DoS attacks and found out that it causes harm to legitimate traffic, because the CT_LIMIT setting is for all the ports combined. If one would want to block Exim related traffic only, then they could set CT_PORT to only the email ports, but then they would leave Apache completely unregulated, which would be dangerous because while it would mitigate the email related DoS attacks, it would ALLOW for Apache DoS attacks.
I wish there was that sort of thing in the firewall, but with different CT_LIMIT values for each port. So for ports 25/587/110/993 (SMTP/IMAP/POP) I would set it to 3 while for ports 80/443 (Apache) I would set it to maybe 200, but unfortunately, it's only 1 value regardless of the ports you want to track connection count. I played with this last year and had to leave it to some value quite high to not impact website visit performance.
I know it doesn't really matter, but over the last few days (after thousands of blacklisted IP addresses) I'm only seeing 1 Exim attack per hour or so. Blocking thousands of IP addresses from the attacker's pool helped calm the attacks down a lot. If anyone wants the list, let me know. I can provide it.
0 -
You can specify multiple ports in that configuration. According to the file at https://download.configserver.com/csf/readme.txt you can do this:
So, a setting of CONNLIMIT = "22;5,80;20" means: 1. Only allow up to 5 concurrent new connections to port 22 per IP address 2. Only allow up to 20 concurrent new connections to port 80 per IP address Note: Existing connections are not included in the count, only new SYN packets, i.e. new connections Note: Run /etc/csf/csftest.pl to check whether this option will function on the server
0 -
This is a different setting. Ours is set to 10 on most useful ports already and it doesn't do anything for the issue at hand, since they're all doing this within the same connection attempt. I guess maybe that's why I haven't seen the other DoS attack issue that mtindor referred to earlier today. This would be useful to them.
0 -
Something is definitely going on, as far as I can see I'm not the only one who has seen this attack behavior. For now my solution has been to rely on the firewall (CSF) using custom rules and automatically blocking IPs with too many failed attempts ("no such user here").
0 -
Yes, they all try 100 times at once and then go away for a few hours and then come back. It's a new kind of DoS attack but only targeting the Exim port so that your IMAP and POP email services are super slow and eventually time out for you and your customers. If you want my CSF deny list, I have carefully analyzed these attacks over the last 2 months and built a very thorough deny list. Now I'm only getting 3 or 4 new IP addresses per day, but at the beginning, it was 1 new IP address attacking per minute.
0 -
In case it helps anyone else: CSF has a custom option so you can tell it to monitor a specific log file and if it finds a specific pattern, it will block the IP that can be read in that pattern. You can check the instructions and examples in the regex.custom.pm file that you can find in the /usr/local/csf/bin path
This has helped me monitor the exim log and automatically block the IPs with many "rejected RCPT"0 -
David Cordovez - very nice! I wasn't aware of that particular option, but that sounds like a perfect tool for this situation.
0 -
I had looked into it in January but did not find it to be any more effective than blocking the IP addresses through a cron job. The reason is because, just like you would with a cron job, this needs to read the logs and in order for the log file to be written, the attack has to be done/finished already. So this is going to block the IP only after the fact. They never attack twice within the same hour and most of the time the same IP will not even attack twice within the same day. Therefore, it will do absolutely nothing to stop/interrupt the 100 attempts that an IP address does, but it will, on the other hand, prevent them from coming again next time. What makes it a drop of water in the ocean is because they use tens of thousands of different IP addresses in a rotating chain, therefore what you block today is only going to come back after maybe 20,000 other, different IP addresses have taken their turn in attacking your server.
0 -
cPRex, And it works great, I just had to add the correct regex and tell it which file to look at (/var/log/exim_mainlog). It is a very useful tool.
But... why doesn't the cPanel configuration work in this case? I mean
Exim Configuration > Dictionary Attacks
I've always had that active but it doesn't seem to work.
0 -
The dictionary attack tool only blocks the same IP address after 4 failed attempts. With the way this one is distributed it isn't meeting those requirements.
0 -
cPRex, There are several IPs but each one tries dozens of times in a row at once!
example from my log:
2025-03-06 16:07:25 H=(hebei.8.60.in-addr.arpa) [60.8.50.150]:60352 F=<fmflhcqmamsff6@nanyo-bm.co.jp> rejected RCPT <mray@nxxxxxxxxxs.cl>: No Such User Here
2025-03-06 16:07:25 H=(hebei.8.60.in-addr.arpa) [60.8.50.150]:60352 F=<fmflhcqmamsff6@nanyo-bm.co.jp> rejected RCPT <twi8szqutuvi@nxxxxxxxxxs.cl>: No Such User Here
2025-03-06 16:07:25 H=(hebei.8.60.in-addr.arpa) [60.8.50.150]:60352 F=<fmflhcqmamsff6@nanyo-bm.co.jp> rejected RCPT <mistico.c@nxxxxxxxxxs.cl>: No Such User Here
2025-03-06 16:07:25 H=(hebei.8.60.in-addr.arpa) [60.8.50.150]:60352 F=<fmflhcqmamsff6@nanyo-bm.co.jp> rejected RCPT <maria.jose@nxxxxxxxxxs.cl>: No Such User Here
2025-03-06 16:07:26 H=(hebei.8.60.in-addr.arpa) [60.8.50.150]:60352 F=<fmflhcqmamsff6@nanyo-bm.co.jp> rejected RCPT <larochelle@nxxxxxxxxxs.cl>: No Such User Here
2025-03-06 16:07:26 H=(hebei.8.60.in-addr.arpa) [60.8.50.150]:60352 F=<fmflhcqmamsff6@nanyo-bm.co.jp> rejected RCPT <krobertson@nxxxxxxxxxs.cl>: No Such User Here
2025-03-06 16:07:26 H=(hebei.8.60.in-addr.arpa) [60.8.50.150]:60352 F=<fmflhcqmamsff6@nanyo-bm.co.jp> rejected RCPT <r4o4lmtgf4yemx@nxxxxxxxxxs.cl>: No Such User Here
2025-03-06 16:07:26 H=(hebei.8.60.in-addr.arpa) [60.8.50.150]:60352 F=<fmflhcqmamsff6@nanyo-bm.co.jp> rejected RCPT <kristyn@nxxxxxxxxxs.cl>: No Such User Here
2025-03-06 16:07:26 H=(hebei.8.60.in-addr.arpa) [60.8.50.150]:60352 F=<fmflhcqmamsff6@nanyo-bm.co.jp> rejected RCPT <sr5bddaw3qgmb1v@nxxxxxxxxxs.cl>: No Such User Here
2025-03-06 16:07:26 H=(hebei.8.60.in-addr.arpa) [60.8.50.150]:60352 F=<fmflhcqmamsff6@nanyo-bm.co.jp> rejected RCPT <jp4d1gx7mrvq3j@nxxxxxxxxxs.cl>: No Such User Here
2025-03-06 16:07:26 H=(hebei.8.60.in-addr.arpa) [60.8.50.150]:60352 F=<fmflhcqmamsff6@nanyo-bm.co.jp> rejected RCPT <kost@nxxxxxxxxxs.cl>: No Such User Here
2025-03-06 16:07:26 H=(hebei.8.60.in-addr.arpa) [60.8.50.150]:60352 F=<fmflhcqmamsff6@nanyo-bm.co.jp> rejected RCPT <m0co4goq95xm@nxxxxxxxxxs.cl>: No Such User Here0 -
Any chance you could create a ticket for that?
0 -
David Cordovez:
each one tries dozens of times in a row at once!
100 times each.
0 -
cPRex, Yes, I will do it. I hope that with this they can investigate and solve the problem that I believe is affecting many.
0 -
Thanks!
0 -
For those who want to use CSF to monitor and block IPs that try to send many emails to non-existent addresses, here is the solution that worked for me:
In the file /etc/csf/csf.conf , in the Log file locations" section I have added the exim log
CUSTOM1_LOG = "/var/log/exim_mainlog"
then in the file /usr/local/csf/bin/regex.custom.pm I have added this rule:
# Exim Dictionary Attack:
if (($globlogs{CUSTOM1_LOG}{$lgfile}) and ($line =~ /^\S+ \S+ \S+ \[(\d+.\d+.\d+.\d+)\]:\d+ \S+ \w*\s*rejected RCPT.*/)) {
return ("Exim Dictionary Attack",$1,"EXIMDIC","10","25,26,465,587","3600","0");
}(applies blocking if it detects more than 10 matches, the blocking is on ports 25,26,465 and 587, the blocking is for 1 hour)
After the changes, it is necessary to restart the firewall. Test carefully, in my case it worked well but I cannot be held responsible for the results on other servers ;)
0 -
In this kind of attack, the same IP address will never attack more than once per hour so this is completely useless. You should block for at least 1 week (or permanently would be best). Trust me, I have studied this attack extensively over the last 2 months. 99% of the IP addresses that perform this attack score 100% confidence spammer over on AbuseIPDB. There is zero reason not to permanently block them. Nothing good will ever come from those IP addresses. The remaining 1% that don't score 100% confidence is because they're newly zombified IP addresses and they will score 100% in a few days when hundreds of reports pour in.
e.g. https://www.abuseipdb.com/check/200.69.85.193
0 -
Yes, I agree, but that is configurable to each person's taste. In my case, due to the rules that I have in the CSF, after 5 temporary blocks, it becomes a permanent one.
0 -
Ah, then it makes perfect sense 👍
0 -
Additional information that may be useful:
checking the settings of exim I found something (which appears to be relatively new) that I did not have active: "Introduce a delay into the SMTP transaction for unknown hosts and messages detected as spam".
After activating it I have noticed a drop in connections that result in a "No Such User Here"
Edit:
After a few hours it seems that this was the final solution. No new IP has been blocked anymore because the connections are no longer reaching point in the transaction where the false recipient is specified, the connection is stopped before by exim itself via ratelimit.
I am copying here some interesting data about why the dictionary attack configuration would not be working, which was given to me by cPanel support:
We were looking at some reasons why the dictionary attack doesn't trigger for manby connectiosn recently. It was found that this was primarily due to where in the ACL list the dictionary attack appears. Dictionary attack protection occurs much further down in the ACL list compared to something like delay potentially spammer connections.
For example:
acl_smtp_connect:- blockcountryips
- delay unknown hosts
- ratelimit suspicious connections
^ These are the first 3 ACLs that process under smtp connect.
Meanwhile, dictionary attack doesn't occur until after recipient verification.
acl_smtp_connect: delay unknown hosts
acl_smtp_data:
acl_smtp_etrn:
acl_smtp_helo:
acl_smtp_mail:
acl_smtp_mailauth:
acl_smtp_mime:
acl_smtp_notquit:
acl_smtp_predata:
acl_smtp_quit:
acl_smtp_rcpt: dictionary attack checks
acl_smtp_starttls:
Given the nature of the attacks, it seems like maybe an SMTP connect ACL is likely what is needed to drop the connection or reject the connection well before a recipient check occurs.
I believe that would explain why the delay option is helping overall. I suspect our developers placed dictionary attacks far down in the ACL list due to needing to inspect recipient data to access whether or not it is a potential attack. If one connection is reaching recipient data for 100s of connection that does seem like the mail is likely being processed through a different ACL so it never reached dictionary checks.0 -
I have exactly the same situation on my WHM server as the original poster. I've got a thread on the forums called "Under attack, in coming emails..." if you wish the check it out.
The attack has been ongoing for over a month now. So far, I have been collecting IP addresses from the
exim_mainlogfile and blocking them. This method has been effective so far.I'm not convinced (yet) that the setting David suggested would solve this issue for good.
I noticed that the setting "Introduce a delay into the SMTP transaction for unknown hosts and messages detected as spam." was disabled in the Exim settings, even though it should be enabled by default.
I enabled the "introduce a delay" feature two days ago, and my first observation was that the "no such user here" errors stopped. However, I also noticed that more of the following error messages started appearing in the log files: "SMTP connection from [0.0.0.1]:61913 lost D=10s."
These "SMTP connection lost" lines are now appearing continuously 1–5 times per second throughout the day. The same IP addresses have been losing connections for the second day in a row.I'm wondering what kind of harm this might cause to the Exim service? Maybe after a week there's 100 IP addresses doing the same all day, every day. How many connections the Exim can keep and delay?
0 -
The issue with this is that you're just moving the problem. They will use another attack vector which is to fill in all your Exim sockets with 10 second long time outs. This will probably be worse at some point, because for instance if you have 100 ports open, then all they need is 100 IP addresses to fill them in and then your legitimate customers will NOT be able to access their email anymore. I would not recommend this "fix". IMHO, it's best to be spammed with "No such user here" every minute for 1 second than to be spammed with the same for 10 seconds.
The solution I did is to run a cron job every 10 minutes that greps the exim log and compiles a list of all the IP addresses that have more than 50 lines of "No such user here" and then I add them to CSF deny list. After only 2 hours, your server will feel a lot better and after a day or two, you will not have many "No such user here" spammers anymore. Maybe a handful per day compared to a handful per minute.
Our deny list (for this specific issue discussed in this thread) now contains approximately 5,000 different IP addresses. You will find out once you begin gathering them that there exists many whole compromised subnets that will repeat with different IP addresses. For instance these ones from "Chunghwa Telecom Co.,Ltd" are pretty bad and account for nearly 600 (in our case) IP addresses with just those 9 lines in CSF instead of 600 lines:
111.70.3.0/24
111.70.13.0/24
111.70.19.0/24
111.70.22.0/24
111.70.23.0/24
111.70.29.0/24
111.70.38.0/24
111.70.32.0/24
111.70.49.0/240
Please sign in to leave a comment.
Comments
57 comments