GeoIP not fully functional

Raise/discuss any potential issues with MailEnable for consideration in project issue register.
Post Reply
Green
Posts: 31
Joined: Tue Apr 25, 2006 6:46 am

GeoIP not fully functional

Post by Green »

I have several cases of foreign IPs being allowed to bruteforce passwords when the account they try is on a postoffice set to allow only a single country to authenticate. The allowed country is ZA, and by implication country IT should therefore not be allowed to even try or have a successful connection.

Yet, this IP:
http://whois.domaintools.com/87.23.150.148

Was temporarily blocked by ME Ent 9 for the second time in as many days for doing SMTP dictionary attacks.
Capture.PNG
Capture.PNG (33.64 KiB) Viewed 15979 times
Neither of the accounts this IP tried actually exists - which I think is also the problem. GeoIP seems to work for existing accounts but not for non-existing ones. By implication then, it is only a question of time before this IP will figure out an existing account and then only a question of time for it to break the password even when the IP is not allow to even connect to ME. Below we can see how the above IP is allowed to try passwords again and again, even though the mailbox it is trying does not actually exist and the default domain / postoffice is set not to allow the IP above.

Logically what should happen is that ME should allow the connection and the moment it has a mailbox username, it should check the AuthPolicy from the localhost to the PostOffice to the Mailbox and ensure the IP is allowed to even attempt an authentication and the connection immediately cut as a consequence. A second attempt at a password should not be allowed, nor should it be allowed to continue on and on until the IP is temporarily blocked as a result of a localhost Policy violation? The whole idea behind GeoIP is to stop the attack earlier than having even 10 passwords tested. Below the attack could and should have been stopped after line 3 - you have the IP, the password and mailbox and the IP could therefore have been blocked already. As it was, the attack lasted several minutes before it was finally stopped for a policy violation instead of being stopped by GeoIP.

In fact, if ME was smart enough, it could have merge cached all the GeoIP conditions from all postoffices together and therefore know beforehand which IPs are allowed and which not, thereby it could prevent a auth.connection before it even started. E.g. if all the GeoIP conditions of all the postoffices together read to only allow AU and say US IPs, then why even allow an IP from NZ (even if you don't know the username/mailbox yet)? It wastes time and resources to indulge the IP a connection any further.

Code: Select all

09/14/15 10:30:26	SMTP-IN	BC0F3D2030EC4E07BD1A939B1B791F2B.MAI	2344	87.23.150.148			220 mail ESMTP MailEnable Service, Version: 9.00--9.00 ready at 09/14/15 10:30:25	0	0		
09/14/15 10:30:26	SMTP-IN	BC0F3D2030EC4E07BD1A939B1B791F2B.MAI	2344	87.23.150.148	EHLO	EHLO ylmf-pc	250-mail [87.23.150.148], this server offers 6 extensions	175	14		
09/14/15 10:30:26	SMTP-IN	BC0F3D2030EC4E07BD1A939B1B791F2B.MAI	2344	87.23.150.148	AUTH	AUTH LOGIN	334 VXNlcm5hbWU6	18	12		
09/14/15 10:30:27	SMTP-IN	BC0F3D2030EC4E07BD1A939B1B791F2B.MAI	2344	87.23.150.148	AUTH	{blank}	334 UGFzc3dvcmQ6	18	22	administracion	
09/14/15 10:30:27	SMTP-IN	BC0F3D2030EC4E07BD1A939B1B791F2B.MAI	2344	87.23.150.148	AUTH	YWRtaW5pc3RyYWNpb24=	504 Invalid Username or Password	34	22	administracion	
09/14/15 10:30:28	SMTP-IN	407EDA06626B4D8080188CD81E76A8DE.MAI	2416	87.23.150.148			220 scibit ESMTP MailEnable Service, Version: 9.00--9.00 ready at 09/14/15 10:30:28	0	0		
09/14/15 10:30:28	SMTP-IN	407EDA06626B4D8080188CD81E76A8DE.MAI	2416	87.23.150.148	EHLO	EHLO ylmf-pc	250-mail [87.23.150.148], this server offers 6 extensions	175	14		
09/14/15 10:30:29	SMTP-IN	407EDA06626B4D8080188CD81E76A8DE.MAI	2416	87.23.150.148	AUTH	AUTH LOGIN	334 VXNlcm5hbWU6	18	12		
09/14/15 10:30:29	SMTP-IN	407EDA06626B4D8080188CD81E76A8DE.MAI	2416	87.23.150.148	AUTH	{blank}	334 UGFzc3dvcmQ6	18	22	administracion	
09/14/15 10:30:29	SMTP-IN	407EDA06626B4D8080188CD81E76A8DE.MAI	2416	87.23.150.148	AUTH	YWRtaW5pc3RyYWNpb24xMjM=	504 Invalid Username or Password	34	26	administracion	
ME Ent Pre 9.62
WinOS 2012R2

mexelby
Posts: 25
Joined: Wed Jul 09, 2014 5:24 am

Re: GeoIP not fully functional

Post by mexelby »

Hi Green,

I have that same problem by that same host ylmf-pc and it was able to make connections even after I blocked him from multiple attack vectors and subsequently sent a bunch of unsolicited mail. My solution to this was to do EHLO block of "ylmf-pc" in the registry (pre 9.0 release). It basically dropped his connection as soon as the bot made it thus not giving him the liberty to send password dictionary attacks.

I believe you can set GeoIP's at both a post office level or higher level (think top level of the post offices). Not sure how you have it setup but both ways don't work for me. It's like the application simply ignores these settings. I've found I'm using access control to block the IP's (not very effective if they come from multiple addresses), I have POP before SMTP value enabled so they have to auth before they can send mail (limits the ability to send if they attempt a spoof or sending outside of our domain), lastly I enroll in ELHO blocking and subsequently drops the connections but it's a very crude and un-manageable way of connection prevention. Since no one will be sending e-mail from outside the country and this piece of the software doesn't work as you are having the same issue as i am, we are essentially handcuffed.

Mike

MailEnable-Ian
Site Admin
Posts: 9738
Joined: Mon Mar 22, 2004 4:44 am
Location: Melbourne, Victoria, Australia

Re: GeoIP not fully functional

Post by MailEnable-Ian »

Hi,

The country authentication blocking needs to be done after the users credentials are sent in order for the service to know the mailbox to retrieve the options for. Abuse detection in the SMTP service is done before this, and is not linked to any mailbox. Incorrect credentials are viewed by the system as not belonging to a mailbox at all, so no location check is done for these (since they are already blocked there is no reason to do further checks).
Regards,

Ian Margarone
MailEnable Support

Green
Posts: 31
Joined: Tue Apr 25, 2006 6:46 am

Re: GeoIP not fully functional

Post by Green »

Hi Ian,

Thanks for the explanation and yes, I can see how this may make logical sense to you - but it does not resolve the issue?

You are looking at this short term, whilst we have to sit and watch how the same bots try 20 passwords every single day for years. And while you may temporarily block the IP for abuse in the SMTP, it is just a question of time before a password is guessed correctly, isn't it? Not if, just when. Even if checking only 6,000 passwords a year, eventually the bot will strike gold with a good guess and a poor password. So once the bot is in with the correct credentials, all he has to do now is figure out a way to proxy to the SMTP to access it from the correct country based IP?

The purpose of my initial post was to focus your attention on the fact that you already have the tools in ME to prevent the initial dictionary ( @ 20 passwords per day) attack. As you said yourself, you need the mailbox name, which you get in the very first attempt at authentication, after which it becomes a simple case of a) checking if the mailbox even exists; b) checking if the mailbox/postoffice is geo-limited and c) blocking the source IP immediately if it doesn't comply. So even without checking the actual password first, you can already temporarily block the IP on attempt #1 simply because the attempt was made from an invalid IP instead of allowing 10/20 passwords to be tried first. So ME goes from allowing 6,000 passwords to be checked annually, to zero with a few well placed if statements.

Not only that, but then we can safely uncheck the localhost policy that says to block abusing IPs and to lock out a user for one hour - as both of these cause support issues (read: make us lose money on unnecessary support calls) when a user happens to type in their password incorrectly and leave to get a coffee and their Outlooks or ActiveSync Mobiles tries 20 times to authenticate with the incorrect credentials. Which then results in the whole office's router IP being blocked, which means anything between 1 and 1000 people without ME access, angry support calls, lost SLAs, etc. You get the picture.

But until we can cut down 99.9% of these bots with GeoIP, we have no choice but to enable above checkboxes and fielding the resulting support calls and issues which could have been pro-actively prevented by ME. Why sit and wait for your competitors to take the lead Ian when you can sit back and watch them squirm to catch up with ME? Surely you don't want just another mail server, but one of the best enterprise collaboration platforms in the world, come hell or spambot?

Thanks for listening.
ME Ent Pre 9.62
WinOS 2012R2

Admin
Site Admin
Posts: 1127
Joined: Mon Jun 10, 2002 6:31 pm
Location: Melbourne, Victoria, Australia

Re: GeoIP not fully functional

Post by Admin »

Green wrote:So once the bot is in with the correct credentials, all he has to do now is figure out a way to proxy to the SMTP to access it from the correct country based IP?
This is really no different to them just getting blocked by location initially and doing the dictionary attack from the same country. If you block due to location immediately they can then just do the attack from a different IP then, rather than do the attack, and then change IP. Either way, if they are patient and are willing to change IP addresses they may eventually get a valid login.
Green wrote: As you said yourself, you need the mailbox name, which you get in the very first attempt at authentication, after which it becomes a simple case of a) checking if the mailbox even exists; b) checking if the mailbox/postoffice is geo-limited and c) blocking the source IP immediately if it doesn't comply.
Yes, that is what it is doing. But a) is done by checking the credentials. We don't do two configuration lookups. We don't check if mailbox exists and then check the credentials. We check credentials to see if the mailbox exists. But otherwise, yes the steps are the same. Yes, the abuse detection is done before the credentials are checked since the abuse detection uses a local cache which is much faster than checking credentials. Since the mailbox lookup is done at the same time as checking credentials, we know whether it is a dictionary attack and can block before we do a location lookup which is even slower than abuse detection or credential check.

Either way, whether we look up the mailbox first, check location, then drop connection, or check abuse cache and drop connection, you will still see the same login attempt in your logs.
Green wrote:Not only that, but then we can safely uncheck the localhost policy that says to block abusing IPs and to lock out a user for one hour - as both of these cause support issues (read: make us lose money on unnecessary support calls) when a user happens to type in their password incorrectly and leave to get a coffee and their Outlooks or ActiveSync Mobiles tries 20 times to authenticate with the incorrect credentials.
That would normally not happen since the abuse detection will not count retries if the same incorrect password is attempted. It only counts if different incorrect passwords are attempted. You would need clients with two different IP addresses both with the incorrect password to trigger this. You should not enable the option to lock out users for 1 hour if incorrect password - this is an old option that we put in on multiple requests many years ago that we only keep for backwards compatibility.

I am not sure how doing location authentication blocking would allow you to disable the abuse detection - you would still want this enabled for any local dictionary attacks.
Green wrote:Thanks for listening.
We do listen! I don't discount what you say, but we tried to pick the best of the options available for location blocking of authentication. From what I can gather, we're only disputing whether to do abuse detection before or after the location blocking. Unfortunately there are good arguments on both sides.

Green
Posts: 31
Joined: Tue Apr 25, 2006 6:46 am

Re: GeoIP not fully functional

Post by Green »

Hi Admin,

Yes, thanks for the nice explanation and tip on rather disabling the one hour lockout. Makes sense.

Listening to your arguments, I am inclined to agree with you... for now... I'll also rather take speed over purpose, i.e. blocking based on cached data. As developer myself I understand that the GeoIP lookups will slowdown any code.

But I want to leave you with one of my initial thoughts of considering to also compile and cache the GeoIP dataset and using that along with your current abuse detection. Consider this real world scenario:

50 x companies / postoffices (all located in one country; therefore all only suppose to ever authenticate from one country bar the odd overseas vacation)
Even if the geo IP is set per postoffice or even allowed per mailbox, the net result would be a single country (maybe two or 3 given a vacation here and there). So if you compile, work out and cache all 50 postoffices' restrictions, your SMTP service would know not to allow ANY authentications from ANYwhere but country A, B and C. In the time you wait for the blacklists to return results you can simply check the GeoIP in parallel so long and therefore know if the IP is allowed to authenticate by the time it tries to authenticate. In short, instead of working re-actively with the geoips, that is, waiting for authentication before checking IP, you work pro-actively by blocking an IP wishing to authenticate long before you even had to figure out for which mailbox it was intended.

Either way, just a thought. Thanks much for the GeoIP features, it works and works well even if reactively. I would hope to see the settings soon in the webmail and webadmin side of things, i.e. currently you can set the GeoIP per mailbox, which is excellent, but then don't give the end-user a chance of changing/configuring the restriction themselves. For ex. would be nice if a user could add UK themselves if they happen to know that they will be in the UK for the next two weeks on vacation or business, ala as one would configure the Out of Office themselves.

Regards
ME Ent Pre 9.62
WinOS 2012R2

Green
Posts: 31
Joined: Tue Apr 25, 2006 6:46 am

Re: GeoIP not fully functional

Post by Green »

I just have to add another a final note. After having run this feature now for a good while, I truly love the fact that the spammers keep on trying to authenticate (bruteforce) and even though their IPs get temporarily banned they keep on coming back for more after a few hours ... not suspecting they will never get to authenticate even with the correct password and will also never know it as the server simply fails their authentication as if it was the wrong password even though it was because of their geo location. Their efforts are literally completely futile and irrelevant. Think about it for a moment. They test a million passwords just to have the correct password (literally the one in the million password) also fail and none the wiser for it.

Even though this idea originally comes from me as a feature request months back in version 8, I must just give ME their kudos for a good implementation of it. ME now has the bragging rights of having this feature built into a mail server for the first time on the planet, a feature usually only found on firewalls - if even. Not Exchange or any other big vendor has even considered doing the same. If everyone on the planet followed this example it will force a complete rethink of strategy for spammers and hackers. Their hijacked servers would drop from 100% to <1% overnight.
ME Ent Pre 9.62
WinOS 2012R2

Post Reply