Diagnosing and securing your network against brute-force and dictionary attacks
I often get calls from customers saying “help someone is attacking my network!”, usually they have noticed excessive failed login attempts in their security logs or user accounts locking out frequently. Some people may find it surprising how common a problem this actually is and may not even realise it is happening to them, chances are if you have internet facing services and websites this is going to happen at some point. Unless you monitor your security logs or a problem manifests like accounts getting locked out it’s easy to miss. People who haven’t experienced this often find it very alarming and immediately start looking for outside help but there are some pretty fundamental things you should be doing before you start hiring pricey security professionals.
Here is my guide to thwarting brute force and dictionary attacks and basic security on your network:
1. Diagnose the type and source of the attack
Firstly lets define the two attacks I have mentioned already ‘brute-force’ and ‘dictionary’. This is a very basic definition for the purposes of this article, the difference isn’t really important and there are various other names given to variations on these attacks. ‘Brute-force’ generally refers to an attack where an account is targeted and possible key combinations are tried against the account, a ‘dictionary’ attack is similar but it uses a more exhaustive list of likely usernames and passwords known as a dictionary.
I find that one of two things alert people to a brute-force or dictionary attack taking place. Firstly if you are monitoring your security logs (and I suggest you ought to be) then you will see an abnormally large number of failed logins appear in short space if time, if you monitor these logs you will know what constitutes abnormal numbers in your network. The other and probably worse scenario is that user accounts are inexplicably locking out over and over.
The first is probably less of a concern if you are following some basic rules with regard to password lockout, length, complexity and age. While at the very least they are annoying these attacks are not as sophisticated as they seem and highly unlikely to succeed. I would consider this type of attack to be almost an inevitability especially in smaller businesses with less sophisticated firewalls.
It is most likely an automated attack cycling through a ‘dictionary’ of common usernames and passwords. One of the things people often assume is that they are being specifically targeted but that is not usually the case, simply having a domain name is enough to attract the attention of these automated attacks. They may not be looking for anything in particular and probably don’t know anything at all about your business or even if you are a business. These ‘bots’ initially just establish a way into your system, often so that they in turn can be used as a ‘bot’, once a way in has been established the perpetrator will examine what they have gained access to and what value it has.
The second scenario is more worrisome because it means the attacker is targeting valid user names, this means that they at least have some chance of success but also indicates the attack could be coming from within. Either this attacker has first hand knowledge of your users or you have a virus on your network, maybe deriving usernames from the global address list or profiles stored on the computer. Essentially on some level they are already in and are looking to spread and gain further access, you need to track down the infected device and remove it from the network.
So now we have discussed these likely types of attack how do we find where they are coming from? Simple really, in the first case you have already found the failed logins in your security logs so from there it is a simple case of looking at ‘logon type’ and ‘source…’ parts of the event. Most common logon type’s are probably type 3 or 8, which are both network logon but 8 is in clear text. Another is type 10, which is a terminal services logon. The source will probably be a public IP address but don’t celebrate yet as it is highly unlikely the attack is coming from only one IP, blocking it on your firewall probably won’t even slow the attack down. Having said that do check several audit failures as you never know, if you are lucky it might be just one IP. For now either confirm the source is external or if it is internal take a note of the hostname and/or IP.
In the second scenario all we know so far is that accounts are getting locked out so we need to locate the audit failures in the security logs. The best place to start is in your domain controllers Windows security logs, filter them for audit failures and you should find your log entries. Once you have found the logs the process is the same as with the first scenario except the source is likely to be internal, probably the name of a computer on your network. If the source is external it could be simple coincidence and that the dictionary being used simply happens to have some names in it that match your usernames. However, if you have had widespread lockouts not just one or two accounts either your attacker has some knowledge of your users or your usernames are too predictable, more on that coming up.
2. Stopping the attack
Now we have found the source and type of attack we need to put a stop to it don’t we? It depends really, we certainly need to try but in our first scenario this maybe easier said than done. You need to have certain services accessible to the outside world, that is unavoidable for most companies. Unfortunately this means you can be attacked and often the best we can do is to make it as difficult as possible for any attackers to succeed and place our more vulnerable systems in a ‘perimeter network’ away from our more critical systems.
In the second scenario, whilst more worrying, we actually have a better chance at outright stopping the attack. Assuming the source of the attack is internal we have identified the device responsible so now all you have to do is go and physically find it and remove it from the network. Hopefully you know where to find it by its name but if not a trick I have used is to search the security log for the hostname in question for success audits and see who logs in from it normally, hopefully someone will know where they work. Once you have removed the PC from the network verify that the attack has stopped. Once the attack is over you can breath easier but you should definitely take the time to investigate what has happened to the device, virus/malware/spyware scans should be your first port of call, if your anti-virus missed it you should alert the provider so they can publish definitions. More often than not the customer actually comes back to me and tells me the device didn’t have anti-virus, for some reason it got forgotten when deployed. At this stage even if I have cleaned the infection I would normally re-image the computer, hopefully you have a system in place that makes this a quick and easy process so why not?
3. Preventative measures
So with the above in mind we know that nobody is beneath the notice of the these attacks or impervious to them. So if we can’t completely prevent them how do we protect our networks?
3.1 User account policy, security membership and disabling built in accounts
So first and foremost in my opinion is this most fundamental of things, user account policy. Particularly in smaller businesses the temptation is there for some admins to slacken off some of the security settings. Maybe their users grumble about changing passwords or having to use complex ones but it is very important you don’t yield to temptation or pressure on this matter.
As covered above the attacks are often simply just a collection of common usernames and passwords, the attack runs through it’s dictionary and then in most cases gives up. With that in mind lets make life difficult for the attacker. By default most of this is in place but there is always room for improvement especially if you disabled any of these settings. In group policy management console lets make sure our policy ensures long passwords, the longer the better but eight or more at least. We should also ensure complexity requirement is enabled, a sensible maximum password age (42 days by default, better not to change this unless making it shorter in my opinion). Also enable password history to ensure users can’t keep re-using the same password. Lastly one of the most important of all is to enable account lockout policy, we want our accounts to lockout after a certain number of failed attempts, without this and with a long enough dictionary or brute-force attack it is just a matter of time.
Another very important thing that isn’t controlled by group policy is your user account naming convention, it is up to you to choose sensible names for your users accounts. First name only is bad practice, consider how easy is it to write a list of first names for a dictionary attack. Now consider a first-name surname combination, it suddenly becomes vastly more unlikely you are going to get any matches. Even more obvious a problem is our built-in accounts, they exist by default on every new Windows or domain installation so an attacker doesn’t have to guess them, they know they are there. The built-in administrator account should be disabled as should the local administrator accounts on your PCs. Another thing to avoid is the use of generic accounts with obvious names like ‘accounts’, ‘admin’ or ‘finance’.
We can also go further by educating our users on some good (or bad) practices when it comes to their user accounts. Sharing of user account details whether that be because someone is on holiday or if it’s a generic account of some sort should be discouraged. Writing down passwords on a post-it note stuck to your monitor is also bad. Storing account details in clear text anywhere on your network is a bad idea. Even a password protected spread sheet containing account details is unacceptable, there are readily available tools that can break the password in an afternoon. Another thing to consider is that ‘Password1’ is technically a ‘complex’ password and with 9 characters it satisfies a lot of user account policies but it clearly is not a secure password. Users should be discouraged from choosing predictable passwords.
Lastly is your security group arrangement. We want our accounts to only be able to access the things they need to access, at least if an account is compromised we know the limitation of the damage. Making everyone’s account domain admin for example (an extreme example) is a really bad idea, if I want domain admin privileges I only have to break any one password in hundreds or thousands instead of one particular password.
3.2 Network security
Lets take a look at preventative measures from a network level. A phrase often used in network security is ‘minimising the attack surface’, so what does this mean? Basically when we talk about minimising the attack surface we are talking of reducing the number of exploitable weaknesses in our network e.g. minimising the number of open ports on a firewall or uninstalling unnecessary software. In potentially over simplified terms, if we have two ports open on our firewall and we close one of them we have halved the attack surface.
Firstly take a look at your firewall, lets say you have 443, 80, 25, 3389 and 1723 open on your firewall, these are pretty common ports and all potential targets. So 443 is open for autodiscover and OWA services, 25 is SMTP for our emails, 3389 is for remote desktop and 1723 for a PPTP VPN. What can we do to retain these services but close some ports? Do we have a non SSL website? If not lets close port 80, we don’t need it. We have a PPTP VPN so we need 1723, but have we considered other VPN types? SSL VPN’s for example use 443, which we already have open for our autodiscover and OWA services. Do we need or want people to remote desktop in from outside if not lets close 3389 but if we do have we considered a Remote Desktop Gateway server? an RDS Gateway uses 443, which we already have open. Alternatively we have a VPN, can our remote desktop users not connect via a VPN tunnel? Port 25 is needed for SMTP but if we are using a hosted messaging hygiene solution have we considered locking the firewall down to only permit traffic from our hosted solutions IP addresses? By following these recommendations we can reduce our open ports down to just 443 and 25, a big improvement.
You can also consider having a perimeter network (or DMZ). The idea of the DMZ is to place our public facing services in a separate network from our internal network, the DMZ may have several ports open to the outside world so that people from outside your network can access websites and applications remotely without compromising more critical systems on your internal network. There are ports open between your internal network and the DMZ but these ports are not accessible directly from the internet. An example of this is the RDS gateway we already mentioned. I can place my RDS Gateway on the perimeter network and my RDS Session Host on the internal network, RDS traffic comes in on 443 to the gateway which proxies the connection to the session host server on 3389. Also servers in the DMZ don’t necessarily always have to be domain members so if they are attacked the domain is uncompromised.
In addition to the above we also need to keep in mind that many attacks are completely automated and rely heavily on the predictability of your network. To reduce the predictability of your network we can also consider using non-standard port numbers for some of our services. We can simply use static NAT rules on our firewall to translate the non-standard port number from the outside to the standard port number on the inside.
We should also look for software that we don’t need and remove it. More software results in more patching and vulnerabilities that can be exploited. Our second scenario where a computer has become infected is a situation that can often be prevented either by regular security updates or by removing any software that isn’t adding any value. With the introduction of Server 2012 it is now more viable than ever to run core versions with no GUI, further reducing the attack surface.
The focus of this article is basic security improvements and identifying the source of an attack with the smaller business in mind but another improvement to your network security could be to invest in a more sophisticated firewall. A lot of firewalls or unified threat management (UTM) devices now offer more than just simple port based protection, they often offer more complex traffic analysis and subscription based services to further improve the security offered.
In summary we often cannot completely prevent attempted attacks on our network but we can identify the attacks and asses the threat they pose and eliminate the threat where possible. By following these simple recommendations we can make sure our network is not an easy target and ensure the likelihood of any attack succeeding is as small as possible. Most attacks are not specifically targeting your network and are looking for easy targets, by toughening up your network you will deter all but the most determined attackers.