[SOLVED] iptables recent match . What am I doing wrong ?

bhaslinux · 09-16-2009, 01:23 PM

I want to stop brute-force attacks in ssh port.
I tried to google and found working examples but here in this question I am trying to learn how to write the rule by myself.

This is what I wrote. It does not work. It keeps logging all the packets which comes even after 5 seconds whereas it is supposed to log it only if the packets come within 5 seconds.

iptables -A INPUT -p tcp --dport ssh -m state --state NEW -m recent --name SSH --set

iptables -A INPUT -m recent --name SSH --update --seconds 5 --hitcount 1 -j LOG --log-prefix 'ssh_attack'

Whereas it is supposed to log _only_ if there are >=2 connections of ssh coming to this server within an interval of 5 seconds, it logs and gives me a lot of packets (atleast 11 packets per try to ssh).

Where am I going wrong ?

anomie · 09-16-2009, 02:16 PM

Do you have any other LOG targets in your ruleset? (Please post it in code tags.)

bhaslinux · 09-16-2009, 02:41 PM

No
I did a iptables -F before putting these commands

bhaslinux · 09-16-2009, 02:44 PM

the total rules as per iptables-save is

Quote:

Originally Posted by rules

# Generated by iptables-save v1.4.1.1 on Wed Sep 16 20:43:14 2009
*filter
:INPUT ACCEPT [32199:5340058]
:FORWARD ACCEPT [17509:1932511]
:OUTPUT ACCEPT [28248:6945578]
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH --rsource
-A INPUT -m recent --update --seconds 5 --hitcount 1 --name SSH --rsource -j LOG --log-prefix "ssh_attack"
COMMIT
# Completed on Wed Sep 16 20:43:14 2009
# Generated by iptables-save v1.4.1.1 on Wed Sep 16 20:43:14 2009
*mangle
:PREROUTING ACCEPT [50239:7339024]
:INPUT ACCEPT [32730:5406513]
:FORWARD ACCEPT [17509:1932511]
:OUTPUT ACCEPT [28670:7072990]
:POSTROUTING ACCEPT [46179:9005501]
COMMIT
# Completed on Wed Sep 16 20:43:14 2009
# Generated by iptables-save v1.4.1.1 on Wed Sep 16 20:43:14 2009
*nat
:PREROUTING ACCEPT [2907:233452]
:POSTROUTING ACCEPT [1254:74698]
:OUTPUT ACCEPT [2237:141117]
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Wed Sep 16 20:43:14 2009

salasi · 09-16-2009, 03:16 PM

Quote:

Originally Posted by bhaslinux

(atleast 11 packets per try to ssh)

I suspect that means that you are getting re-tries (and logging all of those). I don't see any sign of a drop or reject target (or policy, for that matter), and to quote http://www.linuxtopia.org/Linux_Fire...les/x4164.html

Quote:

The DROP target does just what it says, it drops packets dead... Note that this action might in certain cases have an unwanted effect, since it could leave dead sockets around on either host. A better solution in cases where this is likely would be to use the REJECT target, especially when you want to block port scanners from getting too much information, such as on filtered ports and so on.

This may be a case in which you want to reject, because, although it does give away the info that there is a 'sentient' box there and listening, it does give the other end an opportunity to give up early, when it knows it isn't going to get anywhere. Possibly.

Quote:

I want to stop brute-force attacks in ssh port.

And while that sounds like a worthwhile intention, the 'best' solution surely depends on whether you still need ssh to work. If you don't just block the port AND don't have anything to listen (belt 'n braces). Beyond that, whether to log anything is an interesting question. If no one is ever going to look at the logs, there may not be any point.

If you do there are a number of measures that you can take, of various degrees of 'paranoic-ness' and difficulty.

Move ssh to a non-standard port
Use port knocking
Use something like fail2ban

Can't say which, or which combination, you would like best, but the simplicity of the first does have an appeal.

bhaslinux · 09-16-2009, 03:22 PM

I dont think there is any retry. I moved the port to http and tried wget from some other server too. That is also logging too many inputs. The main issue is that I cannot achieve a DROP if log does not work. Also, after some 2hrs why is the packet in the
/proc/net/ipt_recent/SSH entries not cleared ? I am just trying to understand this. I can circumvent this issue with other methods (like I use hosts.allow/deny). But I want to learn this method too.

anomie · 09-16-2009, 04:24 PM

I'm not precisely sure about what is wrong with your ruleset; but, if it helps any, here's the iptables invocation for working rules (which I use):

Code:

-A INPUT -m state --state NEW -p tcp --dport 22 -m recent --set --name BRUTE
-A INPUT -m recent --rcheck --name BRUTE --hitcount 6 --seconds 60 -j DROP

There is also some good feedback on said rules in this thread.

Finally, using the LOG target instead of DROP may be having some unintended consequences. (i.e. I wouldn't assume that you will see the same behavior when using DROP -- try it out if you have a testing environment.)

Good luck.

evilted · 09-16-2009, 04:55 PM

Quote:

Originally Posted by bhaslinux

I want to stop brute-force attacks in ssh port.

why not just stop ssh listening on your wan interface? Do you really need it? or you can put an acl to allow certain hosts..

bhaslinux · 09-17-2009, 04:14 AM

Quote:

Originally Posted by anomie

Finally, using the LOG target instead of DROP may be having some unintended consequences. (i.e. I wouldn't assume that you will see the same behavior when using DROP -- try it out if you have a testing environment.)

That was the answer. The LOG target does not work with this 'kind-of' filtering using iptables. The DROP target if used however works fine. So there was nothing wrong
with the rules, but using the right TARGET.

Thanks all.

bhaslinux · 09-17-2009, 11:01 AM

Hi,

After some research found that the possible way to use the log method would be to have a seperate chain for the attack check
something like this works

iptables -N SSH
iptables -A INPUT -p tcp --dport ssh -m state --state NEW -m recent --name SSH --set -j SSH
iptables -A SSH -m recent --name SSH --rcheck --seconds 5 --hitcount 2 -j LOG
iptables -A SSH -m recent --name SSH --rcheck --seconds 5 --hitcount 2 -j DROP

this way you get the log information and also get the connections qunched to only 1 ssh per 5 seconds !
thanks all for your inputs.