sudden spike in brute force attacks to exim

L

lightningbit

Verified User
Joined
Nov 7, 2008
Messages
35
Hi,

just looking for some advice or experiences

I'm hit (or my server is) with a sudden increase of brute force attacs to exim
it comes from a various range of IP addresses (germany, vietnam, china, russia, france, ... besically, Europe and Asia...)
they all target info, admin, support AT thesamedomain.be
(so it seems they attacker only targets 1 domain for now)

(those users do not exist for that domain)

in BFM I can see
for each ipaddress I find 2 lines :

Code: 
2014-02-10 14:04:49 login authenticator failed for (home-PC) [5.102.206.28]: 535 Incorrect authentication data ([email protected])
2014-02-10 14:04:48 plain authenticator failed for (home-PC) [5.102.206.28]: 535 Incorrect authentication data ([email protected])

then the same with another IP
about 1 attempt every minute, sometimes 2 or 3

I noticed this on friday

I'm also using CSF on this server, for the brute force settings I've set
Notify Admins after an IP has 3 login failures on any account.
Notify Admins after a User has 3 login failures from any IP.

and I am using the the block script
(so that after 3 attempts from the same IP, it gets blocked in CSF)

I'm inclined to even put that to 1 for a while, so the ip gets blocked immediately after 1 attempt

is there anything else I can do to kill or cut off that attack?

e.g block it in CSF directly, without BFM ? (will it make a difference, performance wise, and reaction-time wise?)

I thought of using the country block in CSF, but blocking out Asia for a while probably will kill the performance of the server, because of the amount of lines added to iptables to do so.

any adivice is much appreciated


Thanks
 
forwarder

It is possible to make the [email protected] a forwarder to a personal mailbox (or several mailboxes) instead of a mailbox. It is not possible to send emails with a forwarder via exim afaik.

What you probably already did is to enable difficult password enforcement in administrator settings. This way brute force attacks are less efficient.
 
lightningbit said:
Hi,

just looking for some advice or experiences

I'm hit (or my server is) with a sudden increase of brute force attacs to exim
it comes from a various range of IP addresses (germany, vietnam, china, russia, france, ... besically, Europe and Asia...)
they all target info, admin, support AT thesamedomain.be
(so it seems they attacker only targets 1 domain for now)

(those users do not exist for that domain)

in BFM I can see
for each ipaddress I find 2 lines :

Code: 
2014-02-10 14:04:49 login authenticator failed for (home-PC) [5.102.206.28]: 535 Incorrect authentication data ([email protected])
2014-02-10 14:04:48 plain authenticator failed for (home-PC) [5.102.206.28]: 535 Incorrect authentication data ([email protected])

then the same with another IP
about 1 attempt every minute, sometimes 2 or 3

I noticed this on friday

I'm also using CSF on this server, for the brute force settings I've set
Notify Admins after an IP has 3 login failures on any account.
Notify Admins after a User has 3 login failures from any IP.

and I am using the the block script
(so that after 3 attempts from the same IP, it gets blocked in CSF)

I'm inclined to even put that to 1 for a while, so the ip gets blocked immediately after 1 attempt

is there anything else I can do to kill or cut off that attack?

e.g block it in CSF directly, without BFM ? (will it make a difference, performance wise, and reaction-time wise?)

I thought of using the country block in CSF, but blocking out Asia for a while probably will kill the performance of the server, because of the amount of lines added to iptables to do so.

any adivice is much appreciated


Thanks
Click to expand...

Hi,

Have the same issue overhere in NL.. Any help would be more than welcome..

Eric
 
I also saw the same the last weeks. Installed CSF and blocking everything after 5 login failures. The big ones all came on a .us domain.
 
I've also had a strong wave of BF's the other day.
All seems quiet again here, or at least back to normal.
 
I take back my previous reply.
1 certain domain with just 2 mail-entries get hammered steadily on my (Dutch) server.
It's obvious there's an IP-spoofer at work here as the hackers IP changes all the time.
I've turned down the blocking from 5 to 3 attempts on CSF but it doesn't 'do much' to stop it of course, and only blocks IP's that won't be used again probably.

And another thing, the constant new blocked IP's also 'pushes out' the older blocked IP's out of the CSF blocklist because of the number of blocks limit.
 
If IPs belong to one and the same sub-net, then you might want to block the whole sub-net or even AS. If you don't know how to do it, please check with your DC, as they can block it on their gateway routers.
 
The IP's are (supposedly) originating from all kinds of countries. I'm pretty sure the IP's are spoofed and the blocking actions are kinda futile, other then they stop the current BF-attack.
For instance, my server gets 3 bf-attacks from Turkey on 1 certain domain and service (ftp or mainly mail-accounts), then the IP gets blocked by csf.
Then just some time later, another 3 attacks occur, seemingly originating from another (country's) IP, but the same domains get attacked, that is until the IP gets blocked also again. The country IP's seem to span the globe (except "CN" China which I have blocked all together).

Other then mentioned earlier, I'm now also seeing more domains on my server getting targeted.

I just deleted about 150 emails with 'permanent block'-notifications since yesterday.

My csf-blocklist has a limit of 200 at the moment. The 'oldest' IP-block in my IP blocklist is just from Feb 14th.
The entire blocklist gets 'renewed' every few days it seems.

Here are the most recent 20 ip-blocks from CSF-blocklist, (which happen to be all SMTP hack attempts at the moment);

[size=-4]220.143.185.228 # lfd: (smtpauth) Failed SMTP AUTH login from 220.143.185.228 (TW/Taiwan/220-143-185-228.dynamic.hinet.net): 3 in the last 3600 secs - Tue Feb 18 13:41:48 2014
14.48.124.220 # lfd: (smtpauth) Failed SMTP AUTH login from 14.48.124.220 (KR/Korea, Republic of/-): 3 in the last 3600 secs - Tue Feb 18 13:42:08 2014
123.16.103.18 # lfd: (smtpauth) Failed SMTP AUTH login from 123.16.103.18 (VN/Vietnam/localhost): 3 in the last 3600 secs - Tue Feb 18 13:42:23 2014
113.167.125.104 # lfd: (smtpauth) Failed SMTP AUTH login from 113.167.125.104 (VN/Vietnam/localhost): 3 in the last 3600 secs - Tue Feb 18 13:42:33 2014
121.158.206.61 # lfd: (smtpauth) Failed SMTP AUTH login from 121.158.206.61 (KR/Korea, Republic of/-): 3 in the last 3600 secs - Tue Feb 18 13:42:38 2014
190.100.164.155 # lfd: (smtpauth) Failed SMTP AUTH login from 190.100.164.155 (CL/Chile/pc-155-164-100-190.cm.vtr.net): 3 in the last 3600 secs - Tue Feb 18 13:44:43 2014
202.185.64.217 # lfd: (smtpauth) Failed SMTP AUTH login from 202.185.64.217 (MY/Malaysia/-): 3 in the last 3600 secs - Tue Feb 18 13:44:53 2014
113.173.72.86 # lfd: (smtpauth) Failed SMTP AUTH login from 113.173.72.86 (VN/Vietnam/localhost): 3 in the last 3600 secs - Tue Feb 18 13:46:28 2014
37.213.99.53 # lfd: (smtpauth) Failed SMTP AUTH login from 37.213.99.53 (BY/Belarus/-): 3 in the last 3600 secs - Tue Feb 18 13:52:38 2014
109.160.25.69 # lfd: (smtpauth) Failed SMTP AUTH login from 109.160.25.69 (BG/Bulgaria/-): 3 in the last 3600 secs - Tue Feb 18 13:56:08 2014
41.137.69.41 # lfd: (smtpauth) Failed SMTP AUTH login from 41.137.69.41 (MA/Morocco/-): 3 in the last 3600 secs - Tue Feb 18 13:56:49 2014
186.109.94.82 # lfd: (smtpauth) Failed SMTP AUTH login from 186.109.94.82 (AR/Argentina/host82.186-109-94.telecom.net.ar): 3 in the last 3600 secs - Tue Feb 18 13:57:04 2014
200.175.4.116 # lfd: (smtpauth) Failed SMTP AUTH login from 200.175.4.116 (BR/Brazil/200.175.4.116.static.gvt.net.br): 3 in the last 3600 secs - Tue Feb 18 13:58:54 2014
213.22.26.164 # lfd: (smtpauth) Failed SMTP AUTH login from 213.22.26.164 (PT/Portugal/a213-22-26-164.cpe.netcabo.pt): 3 in the last 3600 secs - Tue Feb 18 14:01:14 2014
37.193.31.46 # lfd: (smtpauth) Failed SMTP AUTH login from 37.193.31.46 (RU/Russian Federation/l37-193-31-46.novotelecom.ru): 3 in the last 3600 secs - Tue Feb 18 14:08:25 2014
139.195.24.225 # lfd: (smtpauth) Failed SMTP AUTH login from 139.195.24.225 (ID/Indonesia/-): 3 in the last 3600 secs - Tue Feb 18 14:14:15 2014
41.99.76.172 # lfd: (smtpauth) Failed SMTP AUTH login from 41.99.76.172 (DZ/Algeria/-): 3 in the last 3600 secs - Tue Feb 18 14:24:35 2014
42.113.234.232 # lfd: (smtpauth) Failed SMTP AUTH login from 42.113.234.232 (VN/Vietnam/-): 3 in the last 3600 secs - Tue Feb 18 14:35:10 2014
2002:af2c:83e::af2c:83e # lfd: (ftpd) Failed FTP login from 2002:af2c:83e::af2c:83e (-/-/-): 3 in the last 3600 secs - Tue Feb 18 15:12:58 2014
179.199.42.77 # lfd: (smtpauth) Failed SMTP AUTH login from 179.199.42.77 (BR/Brazil/179-199-42-77.user.veloxzone.com.br): 3 in the last 3600 secs - Tue Feb 18 18:54:53 2014[/size]
Click to expand...
 
Been getting hit hard here too. Tweaked pureftp to -C option to 4 instead of 25 per host. Tweaked the exim max accept connections a bit. CSF is getting fed IP's from DA's brute force and I have the numbers knocked way down there as well. IP's spoofed or not are all over the place not just the usual suspects.
 
It's pretty undoable to spoof an ip used in a tcp connection as you would have to guess a (random!) 32bit syn-ack from the target as a result of your ack to setup the connection.
And you'll have to do that for EVERY packet... so you can rule out spoofing unless you have someone sniffing your netwerk between the routers and the target.
 
Thanks for the clarification.
Would it more likely to be some botnet doing seemingly automated access-attempts?
 
It's more likely a botnet. Recently some zero-day exploits in IE were revealed and my guess is that the botnet is just trying to get whatever they can until they're taken down.

Most ip's we see are already listen on several RBL's as being spamware sites. This doesn't help much of course because (if i remember correctly) the rbl's are checked after the smtp-authentication checks.
So by using the smtp-auth, they bypass the rbl's lists.

Now, exim (the DA version) doesn't come with greylisting but there is a (somewhat technical) hack to misuse this function.

First you'll need to enable the mysql lookup function in exim (this requires altering the Local/Makefile in the exim source and recompiling)
Next you'll have to create a function in mysql to check when mails arrive for the first and last time and if the difference is a predefined time (say 5 minutes) return a 'yes', otherwise a 'no'.
In exim.conf you define a 'defer' acl used for the greylisting.
So far so good. Tutorials enough to setup greylisting.

The tricky part is that 'normally' you would place the defer acl after the accept acl, otherwise authorized users will get there mails denied by the greylisting ans they'll have to resent the mail after 5 minutes.
But... this is where it gets hacky...
You do place the greylist function in front of the accept acls, so everything to the mailserver get's geylisted, but... you also add mysql udf plugin to mysql. This mysql plugin (lib_mysqludf_sys) is able to execute shell scripts from whithin mysql.
This script executes a linux 'host' command against (e.g.) zen.spamhaus.org and checks if the ipadres of the sender is listen. If it is... just have the mysql function remove the graylisting record so the sender wil alway's stay in the greylist and his mail will never get through until he's not listed in the rbl anymore.
If the sender is not listed, change the time to 0 so the authorized mail doesn't get bounced.

Ofcourse you can also use the shellscript to add a deny rule to your firewall, but that might leave your firewall with thousands of deny rules.

Ignore the above if you're looking for a quick fix ;)

And a little warning: do not use this kind of udf functions on a shared mysqlserver. Only run it on a dedicated server/vps because using udf's that execute shell commands are available to every user and can mess up your system if not managed correctly.
 
Last edited:
sysdev said:
It's more likely a botnet. Recently some zero-day exploits in IE were revealed and my guess is that the botnet is just trying to get whatever they can until they're taken down.
- story -
Click to expand...

So if I understand correctly, you could use RBL to block login attempts, before they've entered the user/password, so they can't bruteforce based on their IP?

If it'd be easy to implement I suppose people would be doing this.

Anyway, if you have a strong password (a few characters, avoid dictionary/words) then they could never (in time) get the password by constantly authenticating through exim. Even if they have the machine power on their end, I don't think exim can answer all those requests. It would turn out more as a ddos attack. Most passwords can be bruteforced if they have the hash locally already.

The brute force attacks in this topic are just fishing for default/simple passwords. They just try support@ a few times, then admin@, webmaster@ etc.

In a general rule I think you could say you're only getting your pass brute forced like this if you use a very easy password.

By looking at the time interval between the blockings pasted in this topic, there is no reason to be worried.
 
By looking at the time interval between the blockings pasted in this topic, there is no reason to be worried.
Click to expand...
^
^
This.

These "attacks" come and go, they're far from being ddos attempts and as long as you add the IPs to the firewall after a couple of attempts, it would take them years to guess a password.
 
We got distributed smtp attacks for some weeks now. Indeed they come and go. They just get blocked and that's it.
 
>>and as long as you add the IPs to the firewall after a couple of attempts

What is everyone using to slow down or block these brute force attempts?
 
Nothing to slow them down. I'm just using CSF which blocks them automatically for a couple of days or hours, depending on your setup.
 
I've got hard also last few days on my (Dutch) server. These are harmless attempts if you have you're passwords set right (= difficult) and let CSF block them automatically.
The annoying thing is all the extra **** it brings like email warnings and extra firewall rules.
 
I am also getting hammered, server is in New York DC, getting up-to 200 plain authenticator failed (smtpauth) connections every day for the last few days, today being the most 50 every hour for a solid 6 hours until we closed port 25 outgoing from CSF for 12 hours while we were closed. Most if not all are plain authenticator failed to port 25 and always for alias emails and never seem to be the actual main DA user login credentials, so it will fail all the time anyways, just keep an eye on your servers if anything changes, report back here, keep everyone informed if you find a more permanent solution. cheers.
 
seeing this too, no one tld seems to be common

just have brute force auto block through csf and while my message log gets tons of activity every one has been blocked.
most stuf just gets temp blocked and seems to work ok, got 200 or so permanent blocks in last 2 weeks
I am FAR from an expert but I just keep an eye on it and so far I see no actual access or issues.
 
You must log in or register to reply here.
Back
Top