CPANEL-42825 - Ratelimit incoming mail to non-existent accounts
Hi, so I recently migrated to a new server and since the migration been getting thousands of emails to non existent accounts every day (coincidence? maybe. I don't know) I did keep the same ip, just a different box with the same host.
I think it is a dictionary attack, but not sure. Each attack is coming from a different ip address and each ip address is sending 100-200 emails at a time. They are coming from every country on the list including the united states and each one is a different domain name. Some are even using comcast and spectrum ips. All 100+ emails from each ip are happening in a 1 second time frame. Most of them are rejected by sender verify, but some make it to "no such user here" reject. As far as I can tell these attacks seem to be harmless and exim/cpanel/spamassassin are doing their jobs, but it's destroying the logs.
It seems like exim is ratelimiting them somehow, but I don't know for sure. Wondering if anyone knows of a way to do something like this:
If 10.20.30.40 sends more than 5 emails to a non-existent account, then block 10.20.3.40
thanks,
-
I'm now getting so much spam that the message below is popping up on my Mail Delivery Report for a 24 hour lookup: Right now I have over 5,000 failures on my server in just 12 hours. I really hope someone has a solution to this. thanks, This query produced a result set that exceeds the reportable limit. If you cannot find what you are looking for by paging through these results, please restrict the query further by narrowing your search.0 -
In your Exim Configuration Manager, just make sure the following are enabled: - Dictionary attack protection
- Ratelimit suspicious SMTP servers
- Ratelimit incoming connections with only failed recipients
0 -
What @ResellerWiz said above. Can you confirm those are enabled? 0 -
Hi @cPRex, all of the settings mentioned are currently set to "on". I noticed that I was seeing this log several times at one point (generally after 100 connections from the same ip): message = "Number of failed recipients exceeded. Come back in a few hours."
I was able to find that message in the Advanced config in the Dictionary Attack Protection, but I haven't been about to figure out how it works yet. I'm using the default config below:warn log_message = "Detected Dictionary Attack (Let $rcpt_fail_count bad recipients though before eng aging)" condition = ${if > {${eval:$rcpt_fail_count}}{4}{yes}{no}} set acl_m7 = 1 warn condition = ${if eq {${acl_m7}}{1}{1}{0}} ratelimit = 0 / 1h / strict / per_conn log_message = "Increment Connection Ratelimit - $sender_fullhost because of Dictionary Attack" drop condition = ${if eq {${acl_m7}}{1}{1}{0}} message = "Number of failed recipients exceeded. Come back in a few hours."
-- I'm still trying to figure out how the ratelimit formula works:ratelimit = 0 / 1h / strict / per_conn0 -
Exim averages the ratelimits over time. However, the default values on a system are these: ratelimit = 1.2 / 1h / strict / per_conn / noupdate so it appears yours may have been altered. I'd put back the defaults, but then bump the "1h" to something more aggressive like '8h' so it keeps blocking the connection for at least 8 hours. 0 -
So for my default ratelimit in ratelimit (Ratelimit suspicious SMTP servers)
it is already set to what you postedratelimit = 1.2 / 1h / strict / per_conn / noupdate
But for thedictionary_attack (Dictionary attack protection)
it is set toratelimit = 0 / 1h / strict / per_conn
Can you confirm the default ratelimit in thedictionary_attack (Dictionary attack protection)
section in Advanced Config? Also, and either way, that would only change the time of the ratelimit right? And that's great, but they seem to have an infinate number of IP addresses, so I'm really hoping to find a way to limit each ip from sending more than 3 or 4 emails before the ratelimit kicks in and blocks them.0 -
My current status: 0 -
Ah yes, the specific section under the dictionary attack is different, and that is normal. I'd recommend bumping the hour value to 8 under the dictionary section then as well and see if that helps to calm things down. 0 -
So I think the problem now is that the emails are not getting rate limited at all. I haven't seen any log messages that indicate ratelimiting. It's almost as if it's not working at all. The crazy thing is that all this started after the migration. I really think something happened during the migration that's causing the issue. I've got a ticket in now, will report back what I find. 0 -
So I think the problem now is that the emails are not getting rate limited at all. I haven't seen any log messages that indicate ratelimiting. It's almost as if it's not working at all. The crazy thing is that all this started after the migration. I really think something happened during the migration that's causing the issue. I've got a ticket in now, will report back what I find.
That is weird that it only started after migrating. During the migration did you choose to copy the Exim config from the source server? If so, maybe Exim has some inconsistencies? Either way, I"m interested to see what the support team finds.0 -
It sounds like it might be time to make a ticket on this issue. 0 -
Made one yesterday, still waiting on someone to pick it up. 0 -
Can you post the number here so I can follow along? 0 -
#95064510 0 -
Thanks for that - I'm following along with that now. 0 -
Turns out this is a known issue (see below). I'm not sure, but the Internal Case ID looks pretty old.... [QUOTE]After further review, I have found that your server is currently facing a known issue with the Dictionary Attack protection at this time with case ID CPANEL-42825. When the "Default Address" is set to the option to "Fail" a message to a user that does not exist, it creates the following Alias to process this: [-redacted- ~]cPs# cat /etc/valiases/-redacted-.com *: :fail: No such person at this address. At this time, the "Fail" Alias is being processed earlier in the mail process than the Dictionary Attack Protection implementation, Spam Filters, RBL checks, and other protections. Unfortunately, this is allowing Dictionary Attacks to be performed on the server as these protections will not trigger. Instead, the server simply responds with your "Fail" message and continues. Eventually, the attackers are hitting a real email address; as such, the Alias is not processed and the Dictionary Attack Protection is triggered. This then sees the previous attempts, and is why you are seeing "delayed" counts
Wondering if anyone knows why valiases are still being used since the
Which really isn't a solution because trusted clients would not be notified in the event of a misspelled email. I was able to verify this prior to creating the ticket by setting the accounts Default Address to blackhole [Discard (Not Recommended)] and the spam was stopped by RBLs, but blackhole really isn't an option for me. Forwarding isn't an option either as a legitimate sender would never be notified of a fail delivery. So it's looking like the only other solution is to just deal with the spam and hope it quits or find some kind of 3rd party email filter. This is honestly a bit frustrating. I've never experimented with the "pipe to a program" option. Maybe it's possible to pipe those messages back to exim, or maybe pipe to some type of 3rd party mail filter that would check for an active user and if not found then send the 550 error? At the end of the day it seems like it should be an easy thing to move the processing of the valias to some point after the ratelimiting checks... But I don't know....0 -
It turns out the internal case ID CPANEL-42825
is a fairly new case after all and is expected to be fixed, although not sure when. in the meantime I have an idea for a temporary solution. In exim Advanced config, the optionsmtp_accept_max
is set by default to 100. This allows maximum 100 connections to smtp and is effectively limiting the attacks to 100, however, I don't want to edit this as it would likely cause issues with legit mail, so I found thissmtp_accept_max_per_host
which as the following definition from exim: [QUOTE]This option restricts the number of simultaneous IP connections from a single host (strictly, from a single IP address) to the Exim daemon. The option is expanded, to enable different limits to be applied to different hosts by reference to $sender_host_address. Once the limit is reached, additional connection attempts from the same host are rejected with error code 421. This is entirely independent of smtp_accept_reserve. The option"s default value of zero imposes no limit. If this option is set greater than zero, it is required that smtp_accept_max be non-zero. Warning: When setting this option you should not use any expansion constructions that take an appreciable amount of time. The expansion and test happen in the main daemon loop, in order to reject additional connections without forking additional processes (otherwise a denial-of-service attack could cause a vast number or processes to be created). While the daemon is doing this processing, it cannot accept any other incoming connections.
What concerns me is the "Warning". Does anyone know what expansion constructions are?0 -
Thanks for posting! I'm following along with the case now and I'll be sure to post an update once I have one. 0 -
Thank you @cPRex. So I set the smtp_accept_max_per_host
to '20' but it didn't work. Also tried thesmtp_accept_max
to 20 but that didn't work either. It seems like absolutely nothing from Exim is working against dictionary attacks. This is crazy. Still getting exactly 100 messages on each attack, and something is obviously blocking or limiting them to 100, but I don't understand what it is. The only thing I can imagine is that the attacker is only sending 100 at a time, but that really defeats the purpose of sending a dictionary attack.0 -
we are having this issue since some days ago.. this has never happened, and we haven't made any change. but since some days, we are seeing 400k to 1million -remote- mail on every server. and it's exactly the same as this thread. 0 -
@JoseDieguez - thanks for the feedback - I've added that to the case. 0 -
Same issue here.. lot of connections and trying to send to dictionary emails.. Any news about the fix? Any way to mitigate? 0 -
Since it's still so new, I don't see that there has been any action on the case just yet. 0 -
@Rackmarkt, I switched all my email accounts to :blackhole and although not ideal, it's been working. Just crossing my fingers and hoping nobody misspells any of our email addresses! 0 -
Hello, I just filed a similar post and see now that you are experiencing the same issue I am with my hosting servers. No doubt someone has found a new use for AI. Mail sends are from a non-existant address to 100 random addresses at a hosted domain... using corrputed mail servers around the globe... then the next domain, and so on. Our sender verification and a few country code bans keeps all of them out of client boxes, but I'd sure like to take that load off the servers... as they still have to process them. I've also been informed by cPanel that the case is being worked on... to see why the Dictionary setting is not restricting them to 4 per domain. I'm experimenting with allowing "no such user" email to go to the admin account to see if that allows the Dictionary setting to work, but with Sender verification enabled, maybe that setting trumps the dictionary one. I believe the "smtp_max_per_host" setting and the other just limit how many emails can be in the Cc and Bcc fields.... I tried that too. 0
Please sign in to leave a comment.
Comments
27 comments