Increase in Hacker attempts on Windows / Exchange Servers – One Way to Slow Them Down!

In an earlier post I advised about an increase in hacking attempts that I had been seeing on Experts Exchange and also on the servers that we support for our customers.

My Earlier Post:
https://alanhardisty.wordpress.com/2010/09/28/increase-in-frequency-of-security-alerts-on-servers-from-hackers-trying-brute-force-password-programs/

Having recently been alerted to yet another round of sustained attacks on a couple of servers we receive daily alerts for, I started to dig a little deeper and came up with an interesting thought. A lot of the hackers seems to be passing random usernames such as 1234 / 123 / Claire etc and because these users don’t exist on any of our servers, the Account Lockout Policy does not kick in after x many invalid login attempts. As a result – they just keep on trying in vain!

So – what to do?

Well – it seems that lots of the hackers seem to be trying to use SMTP to attempt to hack a username / password, so I got thinking. On the majority of servers, the SMTP Virtual Server / Receive Connector has Anonymous Authentication / Basic Authentication / Integrated Windows Authentication enabled.

Anonymous Authentication is required if you want to receive emails from other servers around the world, so disabling that is not an option because you would not receive any email at all!

Basic Authentication is required if you want users to send mail with Usernames / Passwords but don’t want to send them securely (why would you?)

Integrated Windows Authentication is required if you want your domain users to to be able to use SMTP and supply their credentials from their Windows accounts to verify access to the server.

As the vast majority of our Server we manage have RPC over HTTPS / Outlook Anywhere configured on them – the Basic / Integrated Windows Authentication is not required in the slightest, so I disabled them both on the servers that were receiving unwanted attention.

Two days later – no more hacker attempts are being reported / logged in the Security Event Logs!

So – if you want a more secure server and don’t have users with SMTP / POP3 accounts sending via your own Exchange Server and have not already disabled Basic & Integrated Windows Authentication on your SMTP Virtual Server / Receive Connector – what are you waiting for?

One less point of attack for hackers is good news in my books.

Increase in frequency of security alerts on servers from hackers trying brute force password programs

Over the past few months I have seen a noticeable increase in the number of servers that I look after that have alerts raised due to large number of Hacker Attempts trying to pass Usernames and Passwords to the server in the vague hope of eventually finding a combination that actually works.

Once a combination of Username and Password is successfully found, the server will invariably be used to send out vast amounts of spam, which will ultimately result in the innocent victim having problems sending mail because the fixed IP Address that they have will be listed on one or more Blacklist websites.

One such server that I was called to that had suffered from such an attack had been sent about 380,000 spam emails to send out in a very short space of time. Identifying the problem account and cleaning up the mess caused can be a tricky process, but with the right information to hand, an understanding of why this has happened and the optional use of software such as Vamsoft ORF which has excellent logging capabilities, the problem can quickly and easily be identified, the account being used either disabled or the password changed and the SMTP service restarted.

What can you do to prevent such an attack from hitting your server?

Well, there are several preventative measures that you can take to reduce the risk:

1. Configure Passwords to be complex (to include Uppercase letters, Lowercase letters, Numbers and Special Characters e.g., !”£$%^&*()_+}{][#’@~?></.,)
2. Make sure passwords have a minimum length – the longer the better but at least 7 or 8 characters as a minimum.
3. Force passwords to be changed regularly (at least every 30 – 60 days)
4. Enable account lockouts after a low number of invalid login attempts (between 3 and 5 invalid attempts). Make sure the accounts are locked out for approx 15 minutes to slow down the hacker.
5. Make sure your firewall is configured to only allow the protocols that you need allowed through and close off any others that are not needed.
6. Regularly review your firewall settings to verify the open ports are needed.
7. Make sure your firewall logs all access to your systems so that you can track down the source IP Address that requests are coming from. The logs will be invaluable in determining the source of multiple login attempts.
8. When the firewall logs get full, make sure you have them emailed to you and keep them in a safe place.
9. Setup alerts for the Security Log and make sure you get notified of multiple invalid login attempts. The sooner you act, the less chance the hackers have to probe your security, usernames and passwords.
10. Make sure you don't have an account called Administrator on your server that is active. If you do, create a new Server Admin account, copying the Administrator account and then disable the Administrator account – it is an obvious target account and hackers will try this account almost every time.
11. Regularly review your user accounts and make sure you either disable or delete ones that are no longer needed.
12. Make sue that all your server user accounts are easily located in Active Directory, ideally in a single OU, so that you don't have to hunt around for accounts and thus can easily overlook and account that is located in an obscure OU that you never look at.

If you currently don't implement any form of password security, you may meet stiff resistance from staff to enforcing the above changes to passwords, but the first time you are hacked and suffer problems sending mail as a result of being hacked in this way, your users might actually understand why these settings are needed.

If you implement some or all of the above, you should limit the possibilites of being hacked and used as a spammers relay to spew forth their rubbish. If you don't – then you can't say I didn't warn you : )