When you have servers exposed to the internet with RDP or SSH, it won’t take long before they’ll be flooded with connection requests. The worst-case scenario is of course the complete flooded servers crawling under hundreds and hundreds of connections attempts launched at the same time, to gain access by using brute force dictionary attacks.
The best would be to completely shut the SSH or RDP ports, but when you don’t have a choice you must find another solution.
You might have an environment with a couple of Media servers that get hammered with brute force authentication attempts 24/7 so some kind of blocking tool have to be installed to protect those servers.
We’ll look for a tool that allows setting a ban time during which the IP will be banned for a couple of minutes. The short unban time (modifiable) is usually sufficient to stop your network connection from being flooded by malicious connections.
Today we’ll have a look at a tool called Fail2ban available on Linode that does just that. The tool works the following way. It scans log files located for example at /var/log/apache/error_log and bans IPs that show malicious signs. This sign is too many password failures that are seeking for exploits.
Fail2ban modify and update firewall rules on the server in order to reject the IP addresses. In the out of the box config, Fail2ban is configured with filters for different services such as apache, email, SSH etc.
You can follow the instructions to set your system whether you have CentOS7, Debian, Fedora or ubuntu. As being said, the best would be to disable SSH over the internet completely.
How about Windows Server?
Fail2ban does not work on Windows, but there is a tool that might help. There is an IPBan that prevents Terminal Services flooding, however, this script also works on Linux so if you’re looking a unique utility to handle both environments, you might prefer.
Note that this is not the only tool that works, but it’s free. Other, commercial utilities, such as rdpguard.com works as well, however, they are paid.
(Note that IPBan Pro also exists and claims 1-click install to protect your servers) .
You can download the installation files from this link. IPBan is supported on Windows Server 2012 and Windows 8, or newer.
IPBan can ban IP addresses on Windows and Linux by detecting failed logins from event viewer and/or log files.
If you’re on a Linux then by default, the SSH is watched. If you’re on Windows, then an RDP, OpenSSH, VNC, MySQL, SQL Server and Exchange are watched, but you can add more applications via config file.
And the results look like this. You’ll need to edit the config file to adjust for your environment.
What happens is that a new service called IPBAN has been created. This service cannot be stopped or paused, and ignores shutdown.
Then, open the config file that you can find under the C:\Program Files\IPBan directory and configure the script to fit for your environment. We won’t go into details in this post.
Win2ban is another tool (paid) that packages Fail2ban, Python, Cygwin and other tools that are necessary, to provide a ready-to-use solution for brute-force attack protection. While the tool is a paid tool, it costs only $29 so if you work for a company that really needs to protect their front-end servers, it might be worth to look.
The software works quite simply. It uses a Microsoft Loopback adapter and routes traffic to this adapter that is configured with no local gateway.
QaasWall is just another tool that might be your interest and that helps to limit the number of connections to a host. QaasWall is available on SourceForge, and blocks IP address with more than 100 connection on DNS, MSSQL, MySQL, HTTP. It does not block the host IP and Ips that are whitelisted. Unfortunately, QaasWall does work with x32 systems only.
We have shown a couple of tools that can be used for preventing brute-force attacks. There is more for sure. We know that we have just scratched the surface.
Brute-force attacks and ransomware are pretty common those days. Whether you’re on Windows, Linux, or even VMware ESXi, you must harden your environment.
Recently I saw a thread on Reddit that an ESXi host’s datastore where VMs were running and stored, got the VM files encrypted by ransomware. You might think about how this is possible? Perhaps because the datastore was mounted as NFS on Windows machine or that Windows system was running a backup software and using SAN mode backups where you have to connect to the remote datastore via iSCSI.
Some last suggestions that come to mind. Close everything and open only ports that need to be open. Restrict the management only to the local IP addresses. Shut down services that do not need to run.
More from ESX Virtualization
- How To Harden a backup repository on Windows
- Download vSphere 7.0 U1 – GA is now available
- vSphere 7.0 Page [All details about vSphere and related products here]
- VMware vSphere 7.0 DRS Improvements – What's New
- Upgrade from ESXi 6.7 to 7.0 ESXi Free
- VCP6.7-DCV Study Guide