Case Study: Hack Attack!
One of our managed IT clients has been the target of hackers as of lately, and we are currently battling their attempts. Due to this, I decided to make a case study on how we fight their attempts and block them out!
The Situation:
Client has a virtual server that they use remote desktop to access into and run their software. There are at least 75 user accounts, and the users generally don’t forget their passwords.
We have monitoring software that started emailing me informing that 8,000+ failed login attempts have happened, and every hour has had no less than 5,000 attempts since. The password restrictions in place ensure that the hackers will spend at least 1 billion attempts before gaining access using brute force. The administrator password alone is 15+ randomized characters, so it will take YEARS before they can brute it.
The real problem however is that with a virtual server, resources are at a premium. You pay for more CPU and RAM by the hour. There are currently 2 attempts a second, and that has been eating into resources and slowing the server down. During heavy attacks, we are seeing CPU running at or near 100% usage. This is no longer just a hack attempt, but essentially a Denial of Service attempt and could stop the company from working.
Digging Deeper:
Pouring through the logs shows that they are trying a set batch of usernames such as Administrator, Super, FTP, etc. Even [Null](no user name) comes up fairly regular. The biggest and hardest part about this though is that it is done using a Botnet. There are hundreds of unique IP’s all attempting passwords. I made a list of 15 IP’s and tracked them to all different parts of the world. One was a server on Amazon’s Web Services in their Japan datacenter, another some random computer in Bulgaria, etc. The one unique thing about the attack is that every IP has the port 4444 open on their machine. Port 4444 is a well-known port for the W32.Blaster.Worm virus. Apparently when a computer gets infected with the Blaster worm, it opens that port to listen for commands from the person running the botnet. Their current commands are to hack my clients’ server!
Time to find a way to block this attempt!
Fix #1
I’ve used a nice tool called Fail2Ban on some Unix/Linux servers that we manage, and it works quite well. After a set amount of failed password attempts, it ban’s the IP on the internal firewall for a set amount of time. I wanted to find something similar to quickly get some protection in place while we move to a whitelist only solution.
That is when RdpGuard enters the story! RdpGuard is essentially a Windows version of the GitHub classic Fail2Ban. It essentially operates at the service level in Windows, and has a rather simple GUI to view the attempts and watch it work. I installed a 30 day trial with the intent to purchase if I like how it operates. The $80 price tag is well worth it, especially when you are in a pinch!
My first configuration of it was after 6 failed attempts, it would block the IP address for 24 hours. I ran this for the first day and it banned several hundred IP’s. No more failed attempts from those IP’s meant that CPU/RAM resources were lowered.
After the 24 hours, it started unblocking the IP’s and I saw the same computers trying to brute the server again. RdpGuard doesn’t really give you an option to choose to never unblock the IP’s, and you can only max out at 999 hours. This will be a good start, but I’d really like there to be an option to ban the IP, and never hear from it again. I am guessing that if I put in a 0 for the hours, that is what happens, but it isn’t easily spelled out and I haven’t looked into that. I have just decided to set the unban time to 999 hours and re-access the situation in a few days.
This will be a workable solution for now, but we really need a better option in place.
Next Steps:
Fix #2 will ultimately be a move to a whitelist IP access ONLY. No random IP’s, just only allowing their IP’s to remote in. Ultimately this will cause a lot of headache for users as they travel (this particular business has lots of employees that travel). We could choose to go with a MAC ID address whitelist only instead of IP, as then we aren’t worried about traveling, just the device level itself. It seems like it would be more of a pain to manage, but provide the correct security needed. A VPN could also be another solution, but I am not in love with VPN’s. They can be more trouble than they are worth.
Stay tuned for the next update on this Case Study! We will be making a part 2 in the near future. If anyone has any comments or would like to offer ideas on securing this server, feel free to contact me at marc@geeks2you.com and provide your input!
Other Blogs You May Be Interested In
Categories