Fail2ban block with IPtables doesn't work on Debian Lenny. [moved ssh port]

Question

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

Versions:

• 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?

Solution 1

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!

Solution 2

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 

into

port = 12345

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

Comments

[antivirtel]

Question edited! Any ideas?

[antivirtel]

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.

[enedene]

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.

[antivirtel]

No, I have the right package. packages.debian.org/search?suite=lenny&keywords=fail2ban

[James Sumners]

In that case, I recommend doing a dist-upgrade.

[antivirtel]

okok, it is not too easy, but I will manage to do it somehow... - maybe a clean reinstall

[James Sumners]

sed -i 's/lenny/squeeze/' /etc/apt/sources.list && apt-get update && apt-get dist-upgrade. It's quite simple.

[antivirtel]

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?

[James Sumners]

I've been upgrading Debian in this manner since at least Potato, if not Slink. This is the Debian way. Clearly, you should be prepared for disaster (i.e. do proper backups). But you would have to do that with a clean install anyway, so what's the difference? Other than not having to waste time with a clean install.

[antivirtel]

Yeah, you are right. Thanks your advices. Otherwise, I want to remove LVM(it is not recommended) so I have to repartition. I'm strongly thinking about ext4 instead of ext3. What is your opinion about ext4?

[James Sumners]

That's a different question and is likely already answered.

[antivirtel]

Ok, thanks. Otherwise, I found the solution! :)

[Adrian Lopez]

Also note that your iptable name must have less than 32 characters in order to be added successfuly.