How To Protect SSH with fail2ban on Debian 7
IntroductionHaving a server or computer connected to a network comes with a certain amount of risk. Any machine, including a server, connected to the internet is a potential target for malicious attacks.
While having a well-configured firewall will prevent many kinds of illegitimate access, you still need to open up certain services to allow yourself the ability to log in and administer the server. SSH is the service most commonly used to log into remote systems, and so it also is one of the most frequently targeted.
Fortunately, there is a tool available that can mitigate this attack vector, called fail2ban. This can be configured to allow legitimate logins using SSH, but ban IP addresses after they have failed to authenticate correctly after a set number of times.
We will be installing and configuring this software on a Debian 7 server.
Step One –– Install fail2banDebian includes fail2ban in its default repositories. We can download and install it with the following set of commands:
This will not only install fail2ban, it will also start the service with the default settings.
Step Two –– Configure fail2banThe fail2ban configuration is kept in the
Because of the way that fail2ban updates its configuration files when the program has a new version, we should not edit the default configuration file.
Instead, we should copy it to a new location and edit it there:
Here, we can change any settings that we do not like that were set in the default configuration.
Default ConfigurationThe section that begins
Most of the settings that have been given are good selections for default options. However, there are some areas that would benefit from configuration.
Ban DefaultsWe can configure the way that fail2ban implements its banning by modifying a few parameters. Here are some of the more important ones:
Define Ban ActionsWhen a ban is needed, fail2ban can procede in quite a few different ways. It decides on the necessary actions by looking at the following parameters:
Configure Email AlertsIf you would like to configure fail2ban to email you when it institutes a ban, you can configure that in the default section as well.
If you have configured a mail server on your machine, you can configure fail2ban to send email to an external address. Otherwise, you can have it delivered to a local unix account.
There are two relevant parameters:
If you do wish to configure email, you will have to edit the
If you have configured local mail delivery, you can check the mail by typing:
Configure Application-Specific JailsFurther down in the file, you should see sections marked like this:
You should be able to decipher most of the parameters.
You can override any of the other default parameters here. For instance, the
Step Three –– Configure iptablesWe will not actually be doing much configuration of iptables, but we will take a look at the configuration file that implements its behavior. This will help us understand how fail2ban implements its banning policies.
Open the file that was specified in our jail configuration under the
Here, we can see what actually happens when fail2ban calls to have an IP banned. It uses the iptables firewall software to implement rules.
When fail2ban begins, it calls these lines:
This initializes the environment to pass traffic through a filtering chain.
The iptables software controls traffic based on "funnels", or "chains". Each of these funnels applies rules on all traffic that is given to it in order to decide if it is acceptable or not.
The first line,
The next line,
The last line,
So, the current flow is that incoming traffic is handled by our INPUT chain. At this point, it hits the rule passing control to the fail2ban chain. The first rule in this chain passes control back to the chain that called it, the INPUT chain.
So, at this point, control is just passed back and forth with nothing actually happening. However, we have set up a control flow that will accomodate additional rules. When we need to ban an IP address, we can add another rule to the fail2ban chain right above where it passes control back to the INPUT chain.
We can see the complementary actions for tearing down the fail2ban rules, for when the service stops, here:
This basically just reverses all of the rules that we've just built up.
When you ban a client, this rule is implemented:
This tells iptables to drop any packets from that IP address, which effectively bans them from even attempting to authenticate again.
When the bantime has elapsed, this rule reverses the ban:
If you would like to see which rules are implemented and which IP addresses are currently banned, you can check the current iptables rules by typing:
If any clients are banned, they will be in the bottom chain.
Step Four –– Restart fail2banWhen you've made any changes to your configuration, you need to restart fail2ban to implement the new rules.
You can do this by typing this command:
To test your new rules, you can create another server instance and authenticate incorrectly on purpose enough times from that machine to trigger the ban rule. After that, your SSH call will not even return a password prompt.
If you look at the iptable rules on the host you configured, you will see a new rule:
You can see the new rule second from the bottom.
ConclusionYou should now have some additional security by making your server a harder target to brute force. While this is a great start, a more complete solution would be disabling password authentication completely and allowing only key-based authentication.
|Posted by: ASPHostServer Administrator - Fri, Dec 27, 2013 at 12:13 AM. This article has been viewed 1834 times.|
|Online URL: http://faq.asphosthelpdesk.com/article.php?id=195|