Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I run a CentOS 5.7 64bit server which has a strange issue.

While I was watching my logs at /var/log/secure I noticed that one strange IP was trying to connect to ssh with a lot of strange usernames.

Output of the log: http://pastebin.com/raw.php?i=3uYjPrLL

I run fail2ban which had already blocked this IP, and I also blocked this IP again manually via iptables.

Running iptables -n -L I got this output:

Chain fail2ban-SSH (1 references)
target     prot opt source               destination
DROP       all  --  50.115.166.129       0.0.0.0/0
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

So the block is in place. Iptables is also running, and I have blocked many IP's via iptables already, and those blocks are all working fine.

But somehow this IP is able to get to my machine. Any idea how this is possible?

share|improve this question
    
Perhaps the fail2ban-SSH chain is never being invoked, or is invoked at the wrong stage of processing. We'll need to see the output of iptables -L -n -v to say anything useful. –  MadHatter Feb 15 '12 at 9:58
    
This is the output: pastebin.com/raw.php?i=kxYGc6Gs –  Mr.Boon Feb 15 '12 at 10:07
1  
The top of the output is missing, so we can't be sure that it starts with rule 1. Could you ensure that all the output of the iptables command makes it into your pastebin? And can you confirm what port you're running sshd on? –  MadHatter Feb 15 '12 at 10:10
    
I have updated the pastebin file, now shows full output. pastebin.com/raw.php?i=kxYGc6Gs its a couple thousand lines as I recently had to block a whole bot network that was flooding my site. –  Mr.Boon Feb 15 '12 at 10:16
    
ssh is running on port 2222 –  Mr.Boon Feb 15 '12 at 10:27

1 Answer 1

up vote 4 down vote accepted

The issue is that your fail2ban-SSH chain is being applied to traffic to port 22, which isn't where your sshd is listening. So fail2ban picks up the failures from the auth logs, and correctly updates the refusal chain. But ssh traffic is never sent to that chain, so your malfeasor, who is now blocked from talking to port 22, is still able to talk to sshd on 2222.

Assuming you're using standard CentOS /etc/sysconfig/iptables, you need to change the line in the filter section that currently says something like

-A INPUT -p tcp --dport 22 -j fail2ban-SSH

to say

-A INPUT -p tcp --dport 2222 -j fail2ban-SSH

As for your manual drop, you have added it after the lines that say

 689M  126G ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED

and

 0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:2222 state NEW

so it will simply never get invoked to limit new traffic to port 2222, or subsequent packets in any such connection, as those have already been permitted. The order of rules is vital in iptables, because first dispositive match wins.

share|improve this answer
    
Thank you, I have changed the default ssh port in the jail.conf file, that worked. –  Mr.Boon Feb 15 '12 at 10:44

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.