Fail 2 Ban

How To Protect SSH with Fail2Ban on Ubuntu 14....
Communit
https://www.digitalocean.com/community/tutorial...
Tutorials
Questions
Projects
ubscribe
B: Justin Ellingwood
Meetups
Log In
hare
ign Up
Contents
How To Protect H with Fail2Ban

on Ubuntu 14.04
Posted Ma 7, 2014
389.9k
ECURITY
FIREWALL
LINUX BAIC
102
UBUNTU
Introduction
While connecting to our server through H can be ver secure, the H daemon itself is a service that
must be exposed to the internet to function properl. This comes with some inherent risk and creates a
vector of attack for would-be assailants.
An service that is exposed to the network is a potential target in this wa. If ou pa attention to
application logs for these services, ou will often see repeated, sstematic login attempts that represent
brute force attacks b users and bots alike.
A service called fail2ban can mitigate this problem b creating rules that can automaticall alter our
iptables firewall configuration based on a predefined number of unsuccessful login attempts. This will
allow our server to respond to illegitimate access attempts without intervention from ou.
In this guide, we'll cover how to install and use fail2ban on an Ubuntu 14.04 server.
Install Fail2Ban on Ubuntu 14.04

The installation process for this tool is simple because the Ubuntu packaging team maintains a package in
the default repositories.
First, we need to update our local package index and then we can use apt to download and install the
package:
C R O L L TO TO P
1 of 29
01/19/2017 03:32 PM
$ sudo apt-get update

$ sudo apt-get install fail2ban
As ou can see, the installation is trivial. We can now begin configuring the utilit for our own use.
Configure Fail2Ban with our ervice ettings

The fail2ban service keeps its configuration files in the /etc/fail2ban director. There is a file with
defaults called jail.conf .
ince this file can be modified b package upgrades, we should not edit this file in-place, but rather cop it
so that we can make our changes safel. In order for these two files to operate together successfull, it is
best to onl include the settings ou wish to override in the jail.local file. All default options will be
taken from the jail.conf file.
Even though we should onl include deviations from the default in the jail.local file, it is easier to
create a jail.local file based on the existing jail.conf file. o we will cop over that file, with the
contents commented out, as the basis for the jail.local file. You can do this b tping:
$ awk '{ printf "# "; print; }' /etc/fail2ban/jail.conf | sudo tee /etc/fail2ban/jail.local
Once the file is copied, we can open the original jail.conf file to see how things are set up b default
$ sudo nano /etc/fail2ban/jail.conf
In this file, there are a few settings ou ma wish to adjust. The settings located under the [DEFAULT]
section will be applied to all services enabled for fail2ban that are not overridden in the service's own
section.
/etc/fail2ban/jail.conf
[DEFAULT]
. . .
ignoreip = 127.0.0.1/8
. . .
2 of 29
C R O L L TO TO P
01/19/2017 03:32 PM
The ignoreip setting configures the source addresses that fail2ban ignores. B default, it is configured to
not ban an traffic coming from the local machine. You could add additional addresses to ignore b adding
a [DEFAULT] section with an ignoreip setting under it to the jail.local file. You can add additional
addresses b appending them to the end of the directive, separated b a space.
[DEFAULT]
. . .
bantime = 600
. . .
The bantime parameter sets length of time that a client will be banned when the have failed to
authenticate correctl. This is measured in seconds. B default, this is set to 600 seconds, or 10 minutes.
[DEFAULT]
. . .
findtime = 600
maxretry = 3
. . .
The next two parameters that ou want to pa attention to are findtime and maxretry . These work
together to establish the conditions under which a client is found to be an illegitimate user that should be
banned.
The maxretry variable sets the number of tries a client has to authenticate within a window of time
defined b findtime , before being banned. With the default settings, the fail2ban service will ban a client
that unsuccessfull attempts to log in 3 times within a 10 minute window.
[DEFAULT]
. . .
destemail = root@localhost
sendername = Fail2Ban
mta = sendmail
3 of 29
C R O L L TO TO P
01/19/2017 03:32 PM
. . .
You will want to evaluate the destemail , sendername , and mta settings if ou wish to configure email
alerts. The destemail parameter sets the email address that should receive ban messages. The
sendername sets the value of the "From" field in the email. The mta parameter configures what mail
service will be used to send mail. Again, add these to the jail.local file, under the [DEFAULT] header
and set to the proper values if ou wish to adjust them.
[DEFAULT]
. . .
action = $(action_)s
. . .
This parameter configures the action that fail2ban takes when it wants to institute a ban. The value
action_ is defined in the file shortl before this parameter. The default action is to simpl configure the
firewall to reject traffic from the offending host until the ban time elapses.
If ou would like to configure email alerts, add or uncomment the action item to the jail.local file and
change its value from action_ to action_mw . If ou want the email to include the relevant log lines, ou
can change it to action_mwl . Make sure ou have the appropriate mail settings configured if ou choose
to use mail alerts.
Individual Jail ettings

Finall, we get to the portion of the configuration file that deals with individual services. These are specified
b the section headers, like [ssh] .
Each of these sections can be enabled b uncommenting the header in jail.local and changing the
enabled line to be "true":
/etc/fail2ban/jail.local
[jail_to_enable]
. . .
enabled = true
4 of 29
C R O L L TO TO P
01/19/2017 03:32 PM
. . .
B default, the H service is enabled and all others are disabled.

These sections work b using the values set in the [DEFAULT] section as a basis and modifing them as
needed. If ou want to override an values, ou can do so b adding the appropriate service's section to
jail.local and modifing its values.
ome other settings that are set here are the filter that will be used to decide whether a line in a log
indicates a failed authentication and the logpath which tells fail2ban where the logs for that particular
service are located.
The filter value is actuall a reference to a file located in the /etc/fail2ban/filter.d director,
with its .conf extension removed. These files contain the regular expressions that determine whether a
line in the log is a failed authentication attempt. We won't be covering these files in-depth in this guide,
because the are fairl complex and the predefined settings match appropriate lines well.
However, ou can see what kind of filters are available b looking into that director:
$ ls /etc/fail2ban/filter.d
If ou see a file that looks to be related to a service ou are using, ou should open it with a text editor.
Most of the files are fairl well commented and ou should be able to at least tell what tpe of condition the
script was designed to guard against. Most of these filters have appropriate (disabled) sections in the
jail.conf file that we can enable in the jail.local file if desired.
For instance, pretend that we are serving a website using Nginx and realize that a password-protected
portion of our site is getting slammed with login attempts. We can tell fail2ban to use the nginxhttp-auth.conf file to check for this condition within the /var/log/nginx/error.log file.
This is actuall alread set up in a section called [nginx-http-auth] in our /etc/fail2ban

/jail.conf file. We would just need to uncomment the section in the jail.local file and flip the
enabled parameter to protect our service:
5 of 29
C R O L L TO TO P
01/19/2017 03:32 PM
. . .
[nginx-http-auth]
enabled = true
. . .
If ou enable this, ou'll want to restart our fail2ban service to make sure our rules are constructed
correctl.
Putting It All Together

Now that ou understand the basic idea behind fail2ban, let's run through a basic setup.
We're going to configure a auto-banning polic for H and Nginx, just as we described above. We want
fail2ban to email us when an IP is banned.
First, let's install all of the relevant software.
If ou don't alread have it, ou'll need nginx, since we're going to be monitoring its logs, and ou'll need
sendmail to mail us notifications. We'll also grab iptables-persistent to allow the server to
automaticall set up our firewall rules at boot. These can be acquired from Ubuntu's default repositories:
$ sudo apt-get update

$ sudo apt-get install nginx sendmail iptables-persistent
top the fail2ban service for a moment so that we can establish a base firewall without the rules it adds:
$ sudo service fail2ban stop
Establish a Base Firewall

When that is finished, we should implement a default firewall. You can learn how to configure an iptables
firewall on Ubuntu 14.04 here. We are going to just create a basic firewall for this guide.
We're going to tell it to allow established connections, traffic generated b the server itself, traffic destined
C R O L L TO TO P
for our H and web server ports. We will drop all other traffic. We can set this basic firewall up b tping:
6 of 29
01/19/2017 03:32 PM
$ sudo iptables -A INPUT -i lo -j ACCEPT

$ sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
$ sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
$ sudo iptables -A INPUT -p tcp -m multiport --dports 80,443 -j ACCEPT
$ sudo iptables -A INPUT -j DROP
These commands will implement the above polic. We can see our current firewall rules b tping:
$ sudo iptables -S
Output
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -j DROP
You can save the firewalls so that the survive a reboot b tping:
$ sudo dpkg-reconfigure iptables-persistent
Afterwards, ou can restart fail2ban to implement the wrapping rules:
$ sudo service fail2ban start
We can see our current firewall rules b tping:
$ sudo iptables -S
Output
-P INPUT ACCEPT
7 of 29
C R O L L TO TO P
01/19/2017 03:32 PM
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N fail2ban-ssh
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
-A INPUT -j DROP
-A fail2ban-ssh -j RETURN
We have our default polic for each of our chains, and then the five base rules that we established. In red,
we also have the default structure set up b fail2ban since it alread implements H banning policies b
default. These ma or ma not show up at first, since sometimes fail2ban does not add the structure
until the first ban is implemented.
Adjusting the Fail2ban Configuration

Now, we need to configure fail2ban using the settings we'd like. Open the jail.local file:
$ sudo nano /etc/fail2ban/jail.local
We can set a more severe ban time here. Find and uncomment the [DEFAULT] heading. Under the default
heading, change the bantime setting so that our service bans clients for half an hour:
[DEFAULT]
. . .
bantime = 1800
. . .
We also need to configure our alert email information. First, find the destemail parameter, which should
also be under the [DEFAULT] heading. Put in the email address that ou want to use to collect these
messages:
8 of 29
C R O L L TO TO P
01/19/2017 03:32 PM
[DEFAULT]
. . .
destemail = admin@example.com
. . .
You can set the sendername to something else if ou'd like. It's useful to have a value that can be easil
filtered using our mail service though, or else our regular inbox ma get flooded with alerts if there are a
lot of break in attempts from various places.
Moving down, we need to adjust the action parameter to one of the actions that sends us email. The
choices are between action_mw which institutes the ban and then emails us a "whois" report on the
offending host, or action_mwl which does the above, but also emails the relevant log lines.
We're going to chose action_mwl because the log lines will help us troubleshoot and gather more
information if there are issues:
[DEFAULT]
. . .
action = %(action_mwl)s
. . .
Moving on to our H section, if we want to adjust the amount of unsuccessful attempts that should be
allowed before a ban is established, ou can edit the maxretry entr. If ou are using a port other than
"22", ou'll want to adjust the port parameter appropriatel. As we said before, this service is alread
enabled, so we don't need to modif that.
Next, search for the nginx-http-auth section. Uncomment the header and change the enabled
parameter to read "true".
. . .
[nginx-http-auth]
enabled = true
9 of 29
C R O L L TO TO P
01/19/2017 03:32 PM
. . .
This should be all ou have to do this section unless our web server is operating on non-standard ports or
if ou moved the default error log path.
Restarting the Fail2ban ervice

When ou are finished, save and close the file.
Now, start or restart our fail2ban service. ometimes, it's better to completel shut down the service and
then start it again:
$ sudo service fail2ban stop
Now we can restart it b tping:
$ sudo service fail2ban start
It ma take a few moments for all of our firewall rules to be populated. ometimes, the rules are not added
until the first ban of that tpe is instituted. However, after a time, ou can check the new rules b tping:
$ sudo iptables -S
Output
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N fail2ban-nginx-http-auth
-N fail2ban-ssh
-A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-nginx-http-auth
-A INPUT -j DROP
10 of 29
C R O L L TO TO P
01/19/2017 03:32 PM
-A fail2ban-nginx-http-auth -j RETURN
The lines in red are the ones that our fail2ban policies have created. Right now, the are just directing
traffic to new, almost empt chains and then letting the traffic flow right back into the INPUT chain.
However, these new chains are where the banning rules will be added.
Testing the Banning Policies

From another server, one that won't need to log into our fail2ban server with, we can test the rules b
getting our second server banned.
After logging into our second server, tr to H into the fail2ban server. You can tr to connect using a
non-existent name for instance:
local$ ssh blah@fail2ban_server_IP
Enter random characters into the password prompt. Repeat this a few times. At some point, the fail2ban
server will stop responding with the Permission denied message. This signals that our second server
has been banned from the fail2ban server.
On our fail2ban server, ou can see the new rule b checking our iptables again:
$ sudo iptables -S
Output
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N fail2ban-ssh
11 of 29
C R O L L TO TO P
01/19/2017 03:32 PM

-A INPUT -j DROP
-A fail2ban-ssh -s 203.0.113.14/32 -j REJECT --reject-with icmp-port-unreachable
As ou can see in the highlighted line, we have a new rule in our configuration which rejects traffic to the
H port coming from our second server's IP address. You should have also gotten an email about the ban
in the account ou configured.
Conclusion
You should now be able to configure some basic banning policies for our services. Fail2ban is ver eas
to set up, and is a great wa to protect an kind of service that uses authentication.
If ou want to learn more about how fail2ban works, ou can check out our tutorial on how fail2ban rules
and files work.
For information about how to use fail2ban to protect other services, tr these links:
How To Protect an Nginx erver with Fail2Ban on Ubuntu 14.04
How To Protect an Apache erver with Fail2Ban on Ubuntu 14.04
B: Justin Ellingwood
Upvote
(102)
ubscribe
hare
C R O L L TO TO P
12 of 29
01/19/2017 03:32 PM
What's on our server securit check list?

Find out what steps people are taking to harden their servers in our communit Q&A.
Related Tutorials
How To Test our Firewall Configuration with Nmap and Tcpdump
How the Iptables Firewall Works
How to Configure the Linux Firewall for Docker warm on CentO 7
How To et Up Multi-Factor Authentication for H on Ubuntu 16.04
How to Configure the Linux Firewall for Docker warm on Ubuntu 16.04
71 Comments
Log In to Comment
13 of 29
C R O L L TO TO P
01/19/2017 03:32 PM
brandon- May 9, 2014

0
I've been considering fail2ban but am unsure if I reall need it. I have disabled password login and
setup m iptable rules which are below:
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -d 127.0.0.0/8 ! -i lo -j DROP
-A INPUT -m state --state RELATED,ETABLIHED -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -j DROP
-A FORWARD -j DROP
-A OUTPUT -j ACCEPT
I installed fail2ban, and after it inserted its rules, m iptables now look like this:
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N fail2ban-ssh
-A INPUT -d 127.0.0.0/8 ! -i lo -j DROP
-A INPUT -m state --state RELATED,ETABLIHED -j ACCEPT
-A INPUT -j DROP
-A FORWARD -j DROP
-A OUTPUT -j ACCEPT
I'm guessing there is some redundanc/overkill now. Thoughts?
C R O L L TO TO P
jellingwood
14 of 29
MOD
May 9, 2014
01/19/2017 03:32 PM
Hi brandon:
0
Looking at our configuration, I would sa that fail2ban is still going to be useful for ou. Your first
configuration that ou posted above drops connection attempts that are not directed to port 80, 443,
or 22 (as well as allowing local connections).
However, the point of fail2ban is to ban people who repeatedl fail to authenticate. This means that if
someone is attempting to log into H, the will be banned after a few attempts, causing them to
move on. This rule would be added to the `fail2ban-ssh` chain prior to the `-A fail2ban-ssh -j RETURN`
rule.
While this might not seem like a big deal considering that ou have alread disabled password logins
through the sshd config file, it will help keep our logs clean. This can be incredibl useful when ou
are tring to analze our logs in case of a problem b cutting down on the background noise.
Also, with the Nginx, the Auth_Basic module that provides authentication doesn't have the
functionalit to limit attempts. If ou have sections of our site protected b password authentication,
ou probabl will benefit from a service like fail2ban limiting the number of authentication attempts.
In general though, this is up to ou and if ou feel that fail2ban is not providing value, ou do not have
to use it. However, in m testing, it doesn't use man resources, so it ma be worth it to keep it around
just as an extra level of protection.
brandon- May 9, 2014

0
Thank ou ver much. I'm happ to use fail2ban, but am worried that it might not pla nice with m
current iptables rules. If the above config (m rules + fail2ban rules) looks good, please let me know.
pecificall I was wondering if:
These rules:
-A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-nginx-http-auth -A INPUT -p tcp -m multiport
--dports 22 -j fail2ban-ssh
make these rules irrelevant:
B the wa, our tutorials have been great and I've learn a lot from them!
C R O L L TO TO P
15 of 29
01/19/2017 03:32 PM
jellingwood
0
MOD
May 9, 2014
He brandon:
No, those lines will do different things. Hopefull I can explain wh that is.
With our original configuration, a packet will be compared to each of the rules in our INPUT chain. At
the end of our INPUT chain, ou have a rule to drop an traffic that hasn't matched so far. That's wh
before that rule, ou needed the original lines that explicitl allow generic traffic aimed at our web
server and ssh daemon respectivel. These will catch the web and ssh traffic and allow it to pass
before it gets dropped.
The fail2ban rules that are added initiall simpl do one thing: at the ver beginning of the INPUT
chain, the will temporaril divert generic traffic aimed at those services to a new chain. These new
chains are empt at the beginning except for one rule, which just hands control back to the INPUT
chain, where it will continue on down the line, just like normal. These packets will still be dropped if
the reach the end of the INPUT chain, just like the used to, so our original rules for the web server
and ssh daemon are still necessar.
When a client is banned for failing to authenticate, fail2ban adds a new rule to the new fail2ban-*
chain. The new rule checks whether the traffic is coming from the banned host. If it matches, the
packets are dropped. If the traffic doesn't match, it reaches the rule that returns the packet to the
INPUT chain where it continues as described above.
o all that the initial fail2ban lines do is create an extra loop where additional checks can be made to
den specific clients. The flow is alwas returned to the main INPUT chain for traffic not matching a
banned client. It doesn't make an decision on the fate of the packet if it doesn't match the ban list.
That is left to the rules in our INPUT chain. The ke rule to understand here is the `-j RETURN` rule at
the bottom of the new chains, which tell the packet to continue where it left off in the original INPUT
chain.
luciano.longo May 15, 2014

0
Great tutorial, as alwas!

But I'm having a problem with fail2ban, when tring to get banned, I don't see an modification in m
iptables rules. I use a non-standard ssh port, let's sa 4422, when I changed that configuration in the
jail.local the fail2ban rule no longer has the "-j fail2bah-ssh" at the end, I don't know if this has anthing
to do with the issue.
C R O L L TO TO P
16 of 29
01/19/2017 03:32 PM
Here are m iptable rules:

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N fail2ban-ssh
-A INPUT -p tcp -m multiport --dports 4422
-A INPUT -m conntrack --ctstate RELATED,ETABLIHED -j ACCEPT
-A INPUT -j DROP
An ideas?
Thanks!
dconn6 May 18, 2014

0
Thanks for the tutorial. I have just joined Digital Ocean and didn't realise how man useful tutorials it
has.
I don't quite get the mta = sendmail directive. For this to work, evidentl ou don't need to install
sendmail. I thought that ou did, but I didn't want to use sendmail, so I installed postfix and had fun
configuring it. But, fail2ban reall didn't like me using postfix as the mta. I can post the error, but right
now, I am just interested in generalisations, and I guess I can just go ahead and uninstall postfix, since
fail2ban works without it anwa.
B the wa, I configured postfix to onl deal with local mail, as in mail originating on m machine onl
and delivered to root@localhost onl.
asb
0
MOD
May 19, 2014
@dconn6: postfix also installs a sendmail command. Take a look at "man sendmail" On a sstem using
postfix, it will sa "sendmail - Postfix to endmail compatibilit interface" o even if ou're using
postfix, just have sendmail for the mta directive.
garsoltero May 22, 2014

0
17 of 29
Thank ou!
C R O L L TO TO P
01/19/2017 03:32 PM
I follows the tutorial and worked perfectl. However i am not sure what i did but now i tr to trigger the rule
b attempting failed logins for several times and it is not generating the rule that blocks the ip.
Then i notice i got a notification. It mentioned that an ip attempted 37 times. Until then it generated the rule,
blocked the ip and sent the notification. Wh is it allowing so man attempts when the configuration I set
was for 4 retries?
How can i fix this?
Thank ou
asb
0
MOD
May 22, 2014
@garsoltero: Make sure ou restart it after making an configuration changes: sudo service
fail2ban restart Also make sure findtime isn't set too low.
hello646431 July 7, 2014

0
@andrewB: After integrating fail2ban, I can no longer access m site with https, an ideas as to what might
be the issue?
'sudo iptables -' returns this:
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N fail2ban-ssh
-N udp-flood
-A INPUT -j DROP
-A OUTPUT -p udp -j udp-flood
-A udp-flood -p udp -m limit --limit 50/sec -j RETURN
-A udp-flood -j LOG --log-prefix "UDP-flood attempt: "
-A udp-flood -j DROP
18 of 29
C R O L L TO TO P
01/19/2017 03:32 PM
Constantine
rbgokso July 31, 2014

1
Thanks for this article!

I wonder wh are we editing jail.local file instead of jail.conf? We copied local file from conf file and it started
to be main configuration file!
How does it work?
JonPohlner April 1, 2015

0
I was stuck on the same issue.. it's just a local override, but if ou left it in the .conf package updates
would change our work without ou knowing it. And et it sort of does become the main file, because
it's local it know's to take precedence over the package updates that didn't get a chance to change it.
fideloper August 1, 2014

0
According to the Ubuntu man page on fail2ban, we can also add jail configurations into /etc/fail2ban/jail.d in
addition to creating a jail.local file.
mattnz Septemer 19, 2014

0
After following these instructions I tested fail2ban but it would not ban me after multiple wrong passwords. I
need to do this also:
http://www.fail2ban.org/wiki/index.php
/Fail2ban:Communit_Portal#Count_.22Last_message_repeated_N_times.22_correctl
"It seems Fail2ban undercounts entries from sslog files such as /var/log/sslog and /var/log/auth.log, since it
doesn't seem to be aware that sslog ma log "last message repeated N times" instead of the full message.
For example, if an ssh attack occurs several times in quick succession, there ma be onl one entr "Failed
password for someuser from 1.2.3.4 port 4307 ssh2" followed b "last message repeated 10 times".
GNU/Linux distributions rsslog solution:
Tested in Ubuntu 10.04, should also work Centos/RHEL 5.9 or 6.X if rsslog is used.
1.open /etc/rsslog.conf
2.find RepeatedMsgReduction and change on to off
3.After that, restart rsslog and fail2ban"
C R O L L TO TO P
19 of 29
01/19/2017 03:32 PM
r.l.lopez66 Octoer 9, 2014

0
Thank ou for the great tutorial. However, I ran into a problem. I had installed the "one click Wordpress
install" and then installed Fail2ban using our instructions. Now when I tr to login to m site, I get a
"Welcome to nginx!" welcome page instead of wordpress. Please help.
ErikG Octoer 12, 2014

0
Hi, this is m first post in this communit and I must sa that all the available tutorials here were ver useful
and the taught me to configure m own Magento LEMP+L-EV droplet. Just awesome learn all this in 3
weeks!
Until now it seems that all is running fine, and I'm using these iptables+fail2ban config:
[nginx-http-auth]
enabled = true
filter = nginx-http-auth
port = http,https
logpath = /var/log/nginx/error.log
[nginx-login]
enabled = true
filter = nginx-login
action = iptables-multiport[name=NoLoginFailures, port="http,https"]
logpath = /var/log/nginx/access*.log
bantime = 600
maxretr = 6
[nginx-badbots]
enabled = true
filter = apache-badbots
action = iptables-multiport[name=BadBots, port="http,https"]
logpath = /var/log/nginx/access*.log
bantime = 86400
maxretr = 1
Login filter /etc/fail2ban/filter.d/nginx-login.conf: Blocks IPs that fail to authenticate using web
application's log in page can access log for HTTP 200 + POT /sessions => failed log in
[Definition]
failregex = ^<HOT> -.*POT /sessions HTTP/1.." 200
ignoreregex =
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N fail2ban-BadBots
-N fail2ban-NoLoginFailures
20 of 29
C R O L L TO TO P
01/19/2017 03:32 PM
-N fail2ban-ssh
-N fail2ban-ssh-ddos
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh-ddos
-A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-BadBots
-A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-NoLoginFailures
-A INPUT -m conntrack --ctstate RELATED,ETABLIHED -j ACCEPT
-A INPUT -j DROP
-A fail2ban-BadBots -j RETURN
-A fail2ban-NoLoginFailures -j RETURN
-A fail2ban-ssh-ddos -j RETURN
M questions/doubts are:
Is This enough to mitigate the majorit of attacks? Or, should I implement something more?
Is there an redundanc with "m new" NoLoginFailures and nginx-http-auth default filter?
I'm asking our advice 'cause I'm kinda noob about this...
Just kidding, I'm entirel noob... LOL
Thanks a lot!
oosefi Octoer 13, 2014

0
There are various reasons wh ou shouldn't DROP, but the most important is that the packets aren't actually
dropped, the are replied to in a wa that sas the port is open but unavailable due to timeout. On the other
hand, REJECT will repl that the port is closed, which is less helpful to attackers. DROP lets the attacker know
the network is working and there is something behind the port, REJECT will make the attacker think their
network is broken or there is nothing there. Fail2Ban uses REJECT b default, which is good.
oosefi Octoer 13, 2014

0
I wrote a thing on how to enable rate-limiting for nginx here.

After doing that, ou can have fail2ban check the rate logs and ban for rate limit pests. C R O L L TO TO P
21 of 29
01/19/2017 03:32 PM
This will deter all web brute forcing.

In /etc/fail2ban/jail.local :
[nginx-ratelimit]
enabled
= true
port
= http,https
filter
= nginx-ratelimit
logpath
= /var/log/nginx/error.log
maxretry
= 10
Create /etc/fail2ban/filter.d/nginx-ratelimit :
[Definition]
failregex = ^.* limiting requests, excess: .*, client: <HOST>, .*$
ignoreregex =
Then run service fail2ban reload

How To Optimize Nginx Configuration
b Alex Kavon
Nginx is a fast and lightweight alternative to the sometimes

overbearing Apache 2. However, Nginx just like an kind of server or
software must be tuned to help attain optimal performance. Here's
ademers Novemer 25, 2014

0
Question:
When I run sudo apt-get install nginx sendmail iptables-persistent , I get a window with
the following:
Current iptales rules can e saved to the configuration file /etc/iptales/rules.v4. These rules will then e
loaded automatically during system startup.
Rules are only saved automatically during package installation. See the manual page of iptales-save(8) for
instructions on keeping the rules file up-to-date.
Save current IPv4 rules?
<Yes> <No>
C R O L L TO TO P
What is recommended?
22 of 29
01/19/2017 03:32 PM
Man thanks,
Andrea
TenHourGu Novemer 28, 2014

1
I said "es" but if ou read m comment, I ran into some reall big problems with iptables so mabe ou
should tr "no" but I have no idea to be honest. :P
TenHourGu Novemer 28, 2014

0
I'm stuck on the "Establish a Base Firewall" part. Whenever I enter anthing to do with iptables, I get the
following message:
modprobe: ERROR: ../libkmod/libkmod.c:556 kmod_search_moddep() could not open moddep file

iptables v1.4.21: can't initialize iptables table `filter': Table does not exist (do you
Perhaps iptables or your kernel needs to be upgraded.
If I tr apt-get install insmod then it sas the package cannot be found. I'm on Ubuntu 14.04, just to clarif.
mateuslopes Novemer 30, 2014

0
I am stucked with the same problem too! :(

I also answered YE to both ipv4 and ipv6 rules on iptables-persistent installation.
I don't reall know what to do.
mateuslopes Novemer 30, 2014

0
Now I solved m problem with the link below!

https://www.digitalocean.com/communit/questions/error-while-allowing-ssh-connections-on-ufw
rbgokso Decemer 11, 2014

0
Hello,
I hope someone is looking there. I have got some problems.
I configured m banning polic and H section like this:
# "bantime" is the number of seconds that a host is banned.
23 of 29
C R O L L TO TO P
01/19/2017 03:32 PM
bantime
= 60
# A host is banned if it has generated "maxretry" during the last "findtime"

# seconds.
findtime = 15
maxretry = 2
[ssh]
enabled
= true
port
= ssh-4444
filter
= sshd
logpath
= /var/log/auth.log
maxretry = 2
But when i tr to test it, fail2ban does not banning login attempt. Here is m fail2ban log:
2014-12-11 21:56:25,182 fail2ban.server : INFO
Changed logging target to /var/log/fail2ban.
2014-12-11 21:56:25,183 fail2ban.jail
: INFO
Creating new jail 'ssh'
2014-12-11 21:56:25,199 fail2ban.jail
: INFO
Jail 'ssh' uses pyinotify
2014-12-11 21:56:25,219 fail2ban.jail
: INFO
Initiated 'pyinotify' backend
2014-12-11 21:56:25,221 fail2ban.filter : INFO
Added logfile = /var/log/auth.log
Set maxRetry = 2
Set findtime = 15
2014-12-11 21:56:25,223 fail2ban.actions: INFO
Set banTime = 60
2014-12-11 21:56:25,253 fail2ban.jail
: INFO
Creating new jail 'ssh-ddos'
2014-12-11 21:56:25,253 fail2ban.jail
: INFO
Jail 'ssh-ddos' uses pyinotify
2014-12-11 21:56:25,256 fail2ban.jail
: INFO
Set maxRetry = 2
Set findtime = 15
Set banTime = 60
2014-12-11 21:56:25,265 fail2ban.jail
: INFO
Jail 'ssh' started
2014-12-11 21:56:25,268 fail2ban.jail
: INFO
Jail 'ssh-ddos' started
2014-12-11 21:56:25,289 fail2ban.actions.action: ERROR
iptables -N fail2ban-ssh
iptables -A fail2ban-ssh -j RETURN

iptables -I INPUT -p tcp -m multiport --dports ssh-4444 -j fail2ban-ssh returned 200
2014-12-11 22:14:51,679 fail2ban.actions: WARNING [ssh] Ban 217.131.215.136
24 of 29
iptables -n -L INPUT | grep -q 'fail2
Invariant check failed. Trying to res
C R O L L TO TO P
01/19/2017 03:32 PM

2014-12-11 22:14:51,696 fail2ban.actions.action: CRITICAL Unable to restore environment

2014-12-11 22:15:51,765 fail2ban.actions: WARNING [ssh] Unban 217.131.215.136


2014-12-11 22:25:34,472 fail2ban.actions: WARNING [ssh] Ban 217.131.215.136


Stopping all jails
2014-12-11 22:25:45,513 fail2ban.actions: WARNING [ssh] Unban 217.131.215.136



2014-12-11 22:25:45,530 fail2ban.jail
: INFO
Jail 'ssh' stopped
2014-12-11 22:25:46,491 fail2ban.jail
: INFO
Jail 'ssh-ddos' stopped
Exiting Fail2ban
Changed logging target to /var/log/fail2ban.
2014-12-11 22:25:47,018 fail2ban.jail
: INFO
Creating new jail 'ssh'
2014-12-11 22:25:47,036 fail2ban.jail
: INFO
Jail 'ssh' uses pyinotify
2014-12-11 22:25:47,053 fail2ban.jail
: INFO
Set maxRetry = 2
Set findtime = 15
Set banTime = 60
2014-12-11 22:25:47,086 fail2ban.jail
: INFO
Creating new jail 'ssh-ddos'
2014-12-11 22:25:47,086 fail2ban.jail
: INFO
Jail 'ssh-ddos' uses pyinotify
2014-12-11 22:25:47,089 fail2ban.jail
: INFO
25 of 29
C R O L L TO TO P
01/19/2017 03:32 PM
Set maxRetry = 2
Set findtime = 15
Set banTime = 60
2014-12-11 22:25:47,098 fail2ban.jail
: INFO
Jail 'ssh' started
2014-12-11 22:25:47,101 fail2ban.jail
: INFO
Jail 'ssh-ddos' started

Here iptables - :
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-N fail2ban-ssh
-N fail2ban-ssh-ddos
-N ufw-after-forward
-N ufw-after-input
-N ufw-after-logging-forward
-N ufw-after-logging-input
-N ufw-after-logging-output
-N ufw-after-output
-N ufw-before-forward
-N ufw-before-input
-N ufw-before-logging-forward
-N ufw-before-logging-input
-N ufw-before-logging-output
-N ufw-before-output
-N ufw-logging-allow
-N ufw-logging-deny
-N ufw-not-local
-N ufw-reject-forward
-N ufw-reject-input
-N ufw-reject-output
-N ufw-skip-to-policy-forward
-N ufw-skip-to-policy-input
-N ufw-skip-to-policy-output
-N ufw-track-forward
-N ufw-track-input
-N ufw-track-output
-N ufw-user-forward
-N ufw-user-input
26 of 29
C R O L L TO TO P
01/19/2017 03:32 PM
-N ufw-user-limit
-N ufw-user-limit-accept
-N ufw-user-logging-forward
-N ufw-user-logging-input
-N ufw-user-logging-output
-N ufw-user-output
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh-ddos
-A INPUT -j ufw-before-logging-input
-A INPUT -j ufw-before-input
-A INPUT -j ufw-after-input
-A INPUT -j ufw-after-logging-input
-A INPUT -j ufw-reject-input
-A INPUT -j ufw-track-input
-A FORWARD -j ufw-before-logging-forward
-A FORWARD -j ufw-before-forward
-A FORWARD -j ufw-after-forward
-A FORWARD -j ufw-after-logging-forward
-A FORWARD -j ufw-reject-forward
-A FORWARD -j ufw-track-forward
-A OUTPUT -j ufw-before-logging-output
-A OUTPUT -j ufw-before-output
-A OUTPUT -j ufw-after-output
-A OUTPUT -j ufw-after-logging-output
-A OUTPUT -j ufw-reject-output
-A OUTPUT -j ufw-track-output
-A fail2ban-ssh-ddos -j RETURN
-A ufw-after-input -p udp -m udp --dport 137 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 139 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 445 -j ufw-skip-to-policy-input
-A ufw-after-input -m addrtype --dst-type BROADCAST -j ufw-skip-to-policy-input
-A ufw-after-logging-forward -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UF

-A ufw-after-logging-input -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW
-A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-forward -j ufw-user-forward
-A ufw-before-input -i lo -j ACCEPT
27 of 29
C R O L L TO TO P
01/19/2017 03:32 PM
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

-A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny
-A ufw-before-input -m conntrack --ctstate INVALID -j DROP
-A ufw-before-input -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-input -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A ufw-before-input -j ufw-not-local
-A ufw-before-input -d 224.0.0.251/32 -p udp -m udp --dport 5353 -j ACCEPT
-A ufw-before-input -d 239.255.255.250/32 -p udp -m udp --dport 1900 -j ACCEPT
-A ufw-before-input -j ufw-user-input
-A ufw-before-output -o lo -j ACCEPT
-A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-output -j ufw-user-output
-A ufw-logging-allow -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW ALLOW]
-A ufw-logging-deny -m conntrack --ctstate INVALID -m limit --limit 3/min --limit-burst 10 -j

-A ufw-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK]
-A ufw-not-local -m addrtype --dst-type LOCAL -j RETURN
-A ufw-not-local -m addrtype --dst-type MULTICAST -j RETURN
-A ufw-not-local -m addrtype --dst-type BROADCAST -j RETURN
-A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny
-A ufw-not-local -j DROP
-A ufw-skip-to-policy-forward -j DROP
-A ufw-skip-to-policy-input -j DROP
-A ufw-skip-to-policy-output -j ACCEPT
-A ufw-track-output -p tcp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-track-output -p udp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 4444 -j ACCEPT
-A ufw-user-limit -m limit --limit 3/min -j LOG --log-prefix "[UFW LIMIT BLOCK] "
-A ufw-user-limit -j REJECT --reject-with icmp-port-unreachable
-A ufw-user-limit-accept -j ACCEPT
shannond June 3, 2015

0
28 of 29
It's been a long time since ou wrote, and I'm a noob, but on the off chance this is still helpful, I think our
problem is here:
C R O L L TO TO P
01/19/2017 03:32 PM
[ssh]
enabled
= true
port
= ssh-4444
filter
= sshd
logpath
= /var/log/auth.log
maxretry = 2
I don't think fail2ban knows what to do with ssh-4444. The iptables seems to reflect an ssh port of 22 from
fail2ban. I suspect that changing ssh-4444 to 4444 will start to fix our problem.
Load More Comments
This work is licensed under a Creative

Commons Attribution-NonCommercialhareAlike 4.0 International License.
Copright 2017 DigitalOcean Inc.

Communit Tutorials Questions Projects Tags Newsletter R
Distros & One-Click Apps Terms, Privac, & Copright ecurit Report a Bug Get Paid to Write hop
C R O L L TO TO P
29 of 29
01/19/2017 03:32 PM

Fail 2 Ban

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Fail 2 Ban

Uploaded by

Copyright:

Available Formats

How To Protect SSH with Fail2Ban on Ubuntu 14....

How To Protect H with Fail2Ban

Install Fail2Ban on Ubuntu 14.04

How To Protect SSH with Fail2Ban on Ubuntu 14....

$ sudo apt-get update

Configure Fail2Ban with our ervice ettings

$ sudo nano /etc/fail2ban/jail.conf

How To Protect SSH with Fail2Ban on Ubuntu 14....

How To Protect SSH with Fail2Ban on Ubuntu 14....

Individual Jail ettings

How To Protect SSH with Fail2Ban on Ubuntu 14....

B default, the H service is enabled and all others are disabled.

This is actuall alread set up in a section called [nginx-http-auth] in our /etc/fail2ban

How To Protect SSH with Fail2Ban on Ubuntu 14....

Putting It All Together

$ sudo apt-get update

$ sudo service fail2ban stop

Establish a Base Firewall

How To Protect SSH with Fail2Ban on Ubuntu 14....

$ sudo iptables -A INPUT -i lo -j ACCEPT

$ sudo dpkg-reconfigure iptables-persistent

Afterwards, ou can restart fail2ban to implement the wrapping rules:

$ sudo service fail2ban start

We can see our current firewall rules b tping:

How To Protect SSH with Fail2Ban on Ubuntu 14....

Adjusting the Fail2ban Configuration

$ sudo nano /etc/fail2ban/jail.local

How To Protect SSH with Fail2Ban on Ubuntu 14....

How To Protect SSH with Fail2Ban on Ubuntu 14....

Restarting the Fail2ban ervice

$ sudo service fail2ban stop

Now we can restart it b tping:

$ sudo service fail2ban start

How To Protect SSH with Fail2Ban on Ubuntu 14....

Testing the Banning Policies

local$ ssh blah@fail2ban_server_IP

How To Protect SSH with Fail2Ban on Ubuntu 14....

-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

How To Protect SSH with Fail2Ban on Ubuntu 14....

What's on our server securit check list?

How To Protect SSH with Fail2Ban on Ubuntu 14....

brandon- May 9, 2014

How To Protect SSH with Fail2Ban on Ubuntu 14....

brandon- May 9, 2014

How To Protect SSH with Fail2Ban on Ubuntu 14....

luciano.longo May 15, 2014

Great tutorial, as alwas!

How To Protect SSH with Fail2Ban on Ubuntu 14....

Here are m iptable rules:

dconn6 May 18, 2014

May 19, 2014

garsoltero May 22, 2014

How To Protect SSH with Fail2Ban on Ubuntu 14....

May 22, 2014

hello646431 July 7, 2014

How To Protect SSH with Fail2Ban on Ubuntu 14....

rbgokso July 31, 2014

Thanks for this article!

JonPohlner April 1, 2015

fideloper August 1, 2014

mattnz Septemer 19, 2014

How To Protect SSH with Fail2Ban on Ubuntu 14....

r.l.lopez66 Octoer 9, 2014