I've recently decided to do some security maintenance. I saw my logs, and there were some tries against my SSH server. At first, I moved away the SSH port from the default 22. After it, I read something about Fail2ban, BlockHosts and DenyHosts.

I took a look at the first: it is simple to configure, everything is understandable; but when I tried to "probe its protection", the tests are failed. Everything seems to be good, but I can still access the server.

I also tested the IPtables: # iptables -I INPUT -j DROP - after that my SSH connection was lost (so, what I wanted). Then # iptables -I INPUT -s 84.x.y.z -j DROP, which worked too.

But, what rules did the Fail2ban do, that doesn't work: ($ sudo iptables -L)

Chain INPUT (policy ACCEPT)
target     prot opt source               destination        
fail2ban-apache  tcp  --  anywhere             anywhere            multiport dports www,https
fail2ban-ssh  tcp  --  anywhere             anywhere            multiport dports ssh
fail2ban-ssh-ddos  tcp  --  anywhere             anywhere            multiport dports ssh

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination        

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination        

Chain fail2ban-apache (1 references)
target     prot opt source               destination        
RETURN     all  --  anywhere             anywhere            

Chain fail2ban-ssh (1 references)
target     prot opt source               destination        
DROP       all  --  84.x.y.z           anywhere            
RETURN     all  --  anywhere             anywhere            

Chain fail2ban-ssh-ddos (1 references)
target     prot opt source               destination        
RETURN     all  --  anywhere             anywhere

Kernel modules loaded: ($ lsmod | grep ip)

iptable_nat             4680  0
nf_nat                 15576  1 iptable_nat
nf_conntrack_ipv4      12268  3 iptable_nat,nf_nat
nf_conntrack           55540  4 xt_state,iptable_nat,nf_nat,nf_conntrack_ipv4
xt_multiport            2816  2
iptable_filter          2624  1
ip_tables              10160  2 iptable_nat,iptable_filter
x_tables               13284  5 xt_state,xt_tcpudp,iptable_nat,xt_multiport,ip_tables
ipv6                  235396  24


  • Debian Lenny 5.06, kernel 2.6.26-2-686
  • IPtables 1.4.2-6
  • Fail2ban 0.8.3-2sid1
  • openssh-server 1:5.1p1-5

Test #1 step by step:

  1. Configure Fail2ban to low bantime. 60 secs. Then reload.
  2. Attempt to login (with SSH), directly with wrong passwd.
  3. For the 6th time enter the correct passwd (max tries is only 4 here). I logged in. I can also access the web page hosted by that server.
  4. iptables -L shown me as its mentioned above. So the ban was active, when I connected, commanded my server.

Test #2 step by step:

  1. Stop Fail2ban. Create an at script, to remove the below wrote ban rule in the future. (iptables -D INPUT 1)
  2. Create a ban rule: iptables -I INPUT 1 -s 84.x.y.z -j DROP
  3. I couldn't type in anything else, the SSH connection is unuseable. I couldn't access the web page. So, what I wanted from iptables.
  4. After the at script, I can access my server.

I don't see the solution, what should I do to make my IPtables ban (made by Fail2ban) work?

  • Question edited! Any ideas?
    – antivirtel
    Commented Jun 12, 2011 at 21:49

4 Answers 4


I found the problem, what I did, before installing fail2ban. Sorry for your time.

For security reason, I moved away my sshd from port 22 to an other. The reference in iptables refers to port 22 only. I thought, that it is a variable, what always refers to the current sshd port. But NOT.

The exact solution (if you moved away your daemon from its original port):

  1. Open jail.local (or .conf).
  2. Find your service (in braces).
  3. Fix the port section to all. Example: port = all
  4. Add or edit an existing banaction line after the port line, with value iptables-allports. Example: banaction = iptables-allports.
  5. Restart the daemon. Example: # service fail2ban restart.

I couldn't find solution for change the port ssh directive, or write there a number. If you have a non-all-ports solution, I'll listen it!

  • 1
    All you need to do is to provide the port number instead of name. Commented Oct 15, 2012 at 12:09
  • Also note that your iptable name must have less than 32 characters in order to be added successfuly. Commented Feb 2, 2015 at 21:08

I had the same problem with fail2ban not banning after I had moved my ssh server to non standard port 12345 (let's say).

To make fail2ban produce the right rules after a number of failed authentication attempts, I edited /etc/fail2ban/jail.conf.

port = ssh 


port = 12345

I assume a similar approach would work for other services on non standard ports.


The settings for fail2ban is in /etc/fail2ban/jail.local. On a default install I'm not sure if it's there. Then what you do is copy jail.conf to jail.local, so you have both files in /etc/fail2ban/. Edit jail.local, go to the line containing [ssh] and enable it like this:

enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 6

After that, restart fail2ban:

sudo /etc/init.d/fail2ban restart

It's possible that it will work now, I have set it up like that and it works.

  • I think, you didn't understand my question! Fail2ban does, what I want: watch logs, and place ban on attackers. But that ban, what should IPtables have to do, doen't work. I can STILL ACCESS the server, with the above mentioned rule setup.
    – antivirtel
    Commented Jun 12, 2011 at 18:28
  • Sorry, I was in a hurry, so I misunderstood and since I had the same problem, which I solved with adding jail.local, I thought it would help. Unfortunately, if you have everything set correctly than I don't know what is the problem but hope someone else does.
    – enedene
    Commented Jun 13, 2011 at 0:44

You listed "Fail2ban 0.8.3-2sid1" as being installed. This is an unsupported configuration. Sid packages should not be installed into a stable environment.

I run Debian 6 (Squeeze), which was upgraded from Lenny, in a VM specifically as an SSH server for my home. I also use fail2ban. I performed your Test #1 and everything worked as it should. I failed to login for the max number of attempts, and then my requests to login were dropped for 60 seconds.

My version list:

  • /etc/debian_version = 6.0.1
  • fail2ban = 08..4-3
  • iptables = 1.4.8
  • openssh-server = 1:5.5p1-6
  • No, I have the right package. packages.debian.org/search?suite=lenny&keywords=fail2ban
    – antivirtel
    Commented Jul 17, 2011 at 19:14
  • In that case, I recommend doing a dist-upgrade. Commented Jul 17, 2011 at 19:39
  • okok, it is not too easy, but I will manage to do it somehow... - maybe a clean reinstall
    – antivirtel
    Commented Jul 17, 2011 at 20:39
  • sed -i 's/lenny/squeeze/' /etc/apt/sources.list && apt-get update && apt-get dist-upgrade. It's quite simple. Commented Jul 17, 2011 at 21:29
  • yes, but is there any chance to not boots next time... the release notes wrote, that new kenel+new udev system... - was it successful with your machine?
    – antivirtel
    Commented Jul 17, 2011 at 21:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .