[quote] We have thousands attempts every day targetting MercuryP/I and MercuryS - they're all blocked automatically by the built in functionality of the modules short term black listing when repeated compliance fails.[/quote]

That is exactly the functionality I wish for, unfortunately there is no Blacklistig just for failed LOGIN attempts.

[quote]However to your fear, you have to enforce a password policy among your users that isn't all that easy to crack.[/quote]

Yep, looks like that is the only of defense right now.

At any rate, thanks to all who answered, your help is much appreciated.

Regards

Ceph

Hi folks,

 every other week I notice an SMTP AUTH attack on my MercuryS, excerpt from logfile:

T 20090111 000004 4960ca51 Connection from 93.97.194.193
T 20090111 000005 4960ca51 EHLO windows
T 20090111 000007 4960ca52 Connection from 93.97.194.193
T 20090111 000007 4960ca53 Connection from 93.97.194.193
T 20090111 000007 4960ca52 EHLO windows
T 20090111 000008 4960ca53 EHLO windows
T 20090111 000008 4960ca51 AUTH LOGIN
T 20090111 000011 4960ca52 AUTH LOGIN
T 20090111 000012 4960ca51 QUIT
T 20090111 000012 4960ca51 Connection closed with 93.97.194.193, 8 sec. elapsed.
T 20090111 000012 4960ca53 AUTH LOGIN
T 20090111 000013 4960ca52 QUIT
T 20090111 000013 4960ca52 Connection closed with 93.97.194.193, 6 sec. elapsed.
T 20090111 000014 4960ca53 QUIT
T 20090111 000014 4960ca53 Connection closed with 93.97.194.193, 7 sec. elapsed.
T 20090111 000031 4960ca54 Connection from 93.97.194.193
T 20090111 000032 4960ca54 EHLO windows
T 20090111 000036 4960ca54 AUTH LOGIN
T 20090111 000038 4960ca54 QUIT
T 20090111 000038 4960ca54 Connection closed with 93.97.194.193, 7 sec. elapsed.

These attacks continue usually for one hour, so far none succeded. I'd love to break these attacks by blacklisting the attacker after say three unsuccessful AUTH LOGIN tries from the same IP within 5 minutes or so, any way to do this?

I guess Mercury's Graywall-Function won't help here as it's purpose is to delay mails for delivery and not to delay AUTH LOGIN commands.

Thanks in advance,

Ceph

Seems like a somewhat slow pace for an automated attack, with a 17 sec wait after the 3 first connections had terminated. I suppose there wasn't any chance to get a session log of any of these connections to see exactly what happens?

It would be possible to write a MercuryS event daemon to something in the line of what you suggest, but I don't think there is one around now.

/Rolf 

[quote] Seems like a somewhat slow pace for an automated attack, with a 17 sec wait after the 3 first connections had terminated. [/quote]

I still think it's an automated attack, the EHLO command always reads "EHLO windows", it's always almost exactly one hour such an attack lasts (give or take less than a minute), the IPs vary wildly from each attack to the next, IP locations vary from UK to US to Germany and Asia (.hk), most but not all source IPs are dynamic. IMO the sources are zombies for probing.

 [quote] I suppose there wasn't any chance to get a session log of any of these connections to see exactly what happens? [/quote]

Unfortunately not, sorry. Would require kind of filter trigger to create only session logs for login attacks starting with "EHLO windows", found so far no option for such a filter trigger.

[quote] It would be possible to write a MercuryS event daemon to something in the line of what you suggest, but I don't think there is one around now. [/quote]

That would be exactly what I thought of, yes, but I'm not bright enough to write something like this myself ^^. My idea would be a trigger almost like the already present "limit max. number of failed RCPTs to" option. And I think such a transaction restriction would be very useful as without it, any MercuryS is subject to such DOS / Brute Force attacks without a way to stop them.

Unfortunately not, sorry. Would require kind of filter trigger to

create only session logs for login attacks starting with "EHLO

windows", found so far no option for such a filter trigger.

Should be able to block this guy with a transaction type filter looking for EHLO windows with an action to close the connection. 

H, "windows", R, "554 Get out of here, you worthless scumbag."

[quote] Should be able to block this guy with a transaction type filter looking for EHLO windows with an action to close the connection.  H, "windows", R, "554 Get out of here, you worthless scumbag."  [/quote]

Sure it is, already tested successfully. But...what would this help actually? It does not solve the basic problem itself (e.g. let the attacker change "EHLO windows" to anything else like "EHLO computer") and - you know users - what if any of my users decides to name his PC "windows"? FYI, I provide my Mercury mailservices for a a couple of personal friends and relatives who are located in different countries, i.e. I don't have any control over their rigs.

As I said, without such a fiter-trigger-blocking mechanism as descibed above, all MercuryS installations are potential victims to those DOS /Brute Force attacks with no way to prevent or block them.

Sure it is, already tested successfully. But...what would this help

actually? It does not solve the basic problem itself (e.g. let the

attacker change "EHLO windows" to anything else like "EHLO computer")

and - you know users - what if any of my users decides to name his PC

"windows"? FYI, I provide my Mercury mail services for a a couple of

personal friends and relatives who are located in different countries,

i.e. I don't have any control over their rigs.

Agreed but it stops this one.  In addition, this may in fact be coming from one of these friends infected computers since in many cases the virus simply picks up the server data from the users system and then starts trying to make the connection.  This is especially true if it's happening on a scheduled basis working within the confines of the current users connection schedule. 

As I said, without such a fitter-trigger-blocking mechanism as described above, all MercuryS installations are potential victims to

those DOS /Brute Force attacks with no way to prevent or block them.

Agreed, I get hundreds, maybe thousands of these a month from many different IP addresses using a number of EHLO strings but they have little or no affect on the server.  The connect and rejection of a system on the short-term blacklist takes almost the same time and CPU cycles as the connect, AUTH attempt and reject does so I'm not at all sure it would help all that much.  As long as you use relatively good usernames and passwords it should not be all that much of a problem.

[quote] In addition, this may in fact be coming from one of these friends infected computers since in many cases the virus simply picks up the server data from the users system and then starts trying to make the connection. [/quote]

The IPs don't match at all any of the "real" clients, e.g. different ISPs, different times etc.

[quote] Agreed, I get hundreds, maybe thousands of these a month from many different IP addresses using a number of EHLO strings but they have little or no affect on the server.  The connect and rejection of a system on the short-term blacklist takes almost the same time and CPU cycles as the connect, AUTH attempt and reject does so I'm not at all sure it would help all that much.  As long as you use relatively good usernames and passwords it should not be all that much of a problem.[/quote]

I have to disagree here. A blocking mechanism, even if it would consume more CPU cycles than the repeated AUTH LOGIN-reject pattern, would be very useful as it would effectively stop any brute force attemtps. When an attacker is limited to say 5 consecutive tries every 5 minutes, a brute force attack is meaningless. In contrast, the current situation does not provide any protection against long term attacks, even with good password an attack will be successful given enough time. And tell me about educating users to use real good strong passwords ^^. Granted, I could force strong passwords, but still... I'm looking for a solution, not a work around. Take for example the common best practice Windows-Password policy, it says block any login attempts for 5 minutes after 5 wrong passwords within 5 minutes. There must be a reason why this is the recommended policy (which I agree fully agree to, btw.)

I have to disagree here. A blocking mechanism, even if it would consume

more CPU cycles than the repeated AUTH LOGIN-reject pattern, would be

very useful as it would effectively stop any brute force attemtps. When

an attacker is limited to say 5 consecutive tries every 5 minutes, a

brute force attack is meaningless.

In contrast, the current situation

does not provide any protection against long term attacks, even with

good password an attack will be successful given enough time.

And tell

me about educating users to use real good strong passwords ^^.

Granted, I could force strong passwords, but still... I'm looking for a

solution, not a work around. Take for example the common best practice

Windows-Password policy, it says block any login attempts for 5 minutes

after 5 wrong passwords within 5 minutes. There must be a reason why

this is the recommended policy (which I agree fully agree to, btw.)

The solution is to completely block the connecting host forever if you really want to stop  this sort of attack.  The problem with this solution is that you will block good mail in at least some cases.  FWIW, our corporate systems blocked login for 30 minutes after 3 bad login attempts to Windows and other operating systems but this was protecting data and that's a very different situation than what you have here.  The AUTH is not protecting data, it's just trying to block spammers from using our systems to relay.  A nuisance to handle, but no data is involved.

We have thousands attempts every day targetting MercuryP/I and MercuryS - they're all blocked automatically by the built in functionality of the modules short term black listing when repeated compliance fails.

However to your fear, you have to enforce a password policy among your users that isn't all that easy to crack.