'recent' matching when less than hitcount hits

'recent' matching when less than hitcount hits

[Msquared]

Hi people!

I seem to be having a problem where a rule with --hitcount is matching
when there are fewer hits than is listed in the hitcount parameter.

I have the following two rules in a chain called service-ssh:

  -m recent --update --seconds 40 --hitcount 5 --name SSH --rsource -j DROP
  -m recent --set --name SSH --rsource -j ACCEPT

The rules are in a chain that is only hit for incoming SSH connections.
EG: I have this rule in the INPUT chain:

  -m tcp --dport 22 -j service-ssh

The problem is that while the first attempt to connect to SSH on the
server succeeds, the second one fails.

The match counts after restarting iptables:


[root@server ~]# iptables -vnL service-ssh
Chain service-ssh (1 references)
 pkts bytes target     prot opt in     out     source      destination
    0     0 DROP       all  --  *      *       0.0.0.0/0   0.0.0.0/0           recent: UPDATE seconds: 40 hit_count: 5 name: SSH side: source
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0   0.0.0.0/0           recent: SET name: SSH side: source


After one connection to SSH:

[root@server ~]# iptables -vnL service-ssh
Chain service-ssh (1 references)
 pkts bytes target     prot opt in     out     source      destination
    0     0 DROP       all  --  *      *       0.0.0.0/0   0.0.0.0/0           recent: UPDATE seconds: 40 hit_count: 5 name: SSH side: source
    1    48 ACCEPT     all  --  *      *       0.0.0.0/0   0.0.0.0/0           recent: SET name: SSH side: source

[root@server ~]# cat /proc/net/ipt_recent/SSH
src=202.89.183.219 ttl: 122 last_seen: 3951144554 oldest_pkt: 1 last_pkts:
3951144554 


After the second connection to SSH (which times out):

[root@server ~]# iptables -vnL service-ssh
Chain service-ssh (1 references)
 pkts bytes target     prot opt in     out     source       destination
    2    96 DROP       all  --  *      *       0.0.0.0/0    0.0.0.0/0           recent: UPDATE seconds: 40 hit_count: 5 name: SSH side: source
    1    48 ACCEPT     all  --  *      *       0.0.0.0/0    0.0.0.0/0           recent: SET name: SSH side: source

[root@server ~]# cat /proc/net/ipt_recent/SSH
src=202.89.183.219 ttl: 122 last_seen: 3951159153 oldest_pkt: 4 last_pkts: 3951144554, 3951158254, 3951158551, 3951159153



Note that there are only four hits listed, yet the DROP rule still
matched.

As I understand it, my rules mean the following:

  -m recent --update --seconds 40 --hitcount 5 --name SSH --rsource -j DROP

              If this IP address has been seen five times or more, and the
              last time was in the last 40 seconds mark it as seen again,
              and drop the connection.
    
  -m recent --set --name SSH --rsource -j ACCEPT

              Mark this IP address as seen, and accept the connection.

Is this correct?  Am I missing something about how --seconds and
--hitcount interact?

Also, all of this (plus the contents of /proc/net/ipt_recent/SSH) makes me
wonder how entries in the IP list are aged and removed.  Can I control
that, or is that up to the ipt_recent module itself only?


Regards, Msquared...

Re: 'recent' matching when less than hitcount hits

[Patrick McHardy]

Msquared wrote:
> I seem to be having a problem where a rule with --hitcount is matching
> when there are fewer hits than is listed in the hitcount parameter.


Which kernel version are you using?

Re: 'recent' matching when less than hitcount hits

[hdemir]

On Wed, Jun 27, 2007 at 05:00:43PM +0800, Msquared wrote:
> Hi people!
> 
> I seem to be having a problem where a rule with --hitcount is matching
> when there are fewer hits than is listed in the hitcount parameter.
> 
> I have the following two rules in a chain called service-ssh:
> 
>   -m recent --update --seconds 40 --hitcount 5 --name SSH --rsource -j DROP
>   -m recent --set --name SSH --rsource -j ACCEPT
> 
> The rules are in a chain that is only hit for incoming SSH connections.
> EG: I have this rule in the INPUT chain:
> 
>   -m tcp --dport 22 -j service-ssh
> 
You are sending all the traffic to the port 22. Use -m state --state NEW, so that only new ssh connections can be updated. 


hdemir.

Re: 'recent' matching when less than hitcount hits

[Msquared]

On Wed, Jun 27, 2007 at 11:07:38AM +0200, Patrick McHardy wrote:

> > I seem to be having a problem where a rule with --hitcount is matching
> > when there are fewer hits than is listed in the hitcount parameter.
> 
> Which kernel version are you using?

2.4.22-1.2199.8.legacy.nptl


On Wed, Jun 27, 2007 at 12:41:46PM +0300, hdemir@metu.edu.tr wrote:

> > The rules are in a chain that is only hit for incoming SSH connections.
> > EG: I have this rule in the INPUT chain:
> > 
> >   -m tcp --dport 22 -j service-ssh
> 
> You are sending all the traffic to the port 22. Use -m state --state
> NEW, so that only new ssh connections can be updated. 

I already tried that, but it made no difference (perhaps because -m state
--state ESTABLISHED,RELATED -j ACCEPT higher in the INPUT chain).

Note from the iptables -vnL output that I showed that it only counted one
hit on the --set rule and a number of hits on the --update rule.

Regards, Msquared...

Re: 'recent' matching when less than hitcount hits

[Patrick McHardy]

Msquared wrote:
> On Wed, Jun 27, 2007 at 11:07:38AM +0200, Patrick McHardy wrote:
> 
> 
>>>I seem to be having a problem where a rule with --hitcount is matching
>>>when there are fewer hits than is listed in the hitcount parameter.
>>
>>Which kernel version are you using?
> 
> 
> 2.4.22-1.2199.8.legacy.nptl
> 
> 
> On Wed, Jun 27, 2007 at 12:41:46PM +0300, hdemir@metu.edu.tr wrote:
> 
> 
>>>The rules are in a chain that is only hit for incoming SSH connections.
>>>EG: I have this rule in the INPUT chain:
>>>
>>>  -m tcp --dport 22 -j service-ssh
>>
>>You are sending all the traffic to the port 22. Use -m state --state
>>NEW, so that only new ssh connections can be updated. 
> 
> 
> I already tried that, but it made no difference (perhaps because -m state
> --state ESTABLISHED,RELATED -j ACCEPT higher in the INPUT chain).
> 
> Note from the iptables -vnL output that I showed that it only counted one
> hit on the --set rule and a number of hits on the --update rule.


I think I know what the reason is. My rewritten version of the recent
match matches if the current packet is the nth hit and in that case
doesn't note the entry. So you're only seeing n-1 entries in /proc.

Did the old version behave differently here?

Re: 'recent' matching when less than hitcount hits

[Msquared]

On Fri, Jun 29, 2007 at 02:23:35PM +0200, Patrick McHardy wrote:

> >>>The rules are in a chain that is only hit for incoming SSH connections.
> >>>EG: I have this rule in the INPUT chain:
> >>>
> >>>  -m tcp --dport 22 -j service-ssh
> >>
> >>You are sending all the traffic to the port 22. Use -m state --state
> >>NEW, so that only new ssh connections can be updated. 
> > 
> > 
> > I already tried that, but it made no difference (perhaps because -m state
> > --state ESTABLISHED,RELATED -j ACCEPT higher in the INPUT chain).
> > 
> > Note from the iptables -vnL output that I showed that it only counted one
> > hit on the --set rule and a number of hits on the --update rule.
> 
> 
> I think I know what the reason is. My rewritten version of the recent
> match matches if the current packet is the nth hit and in that case
> doesn't note the entry. So you're only seeing n-1 entries in /proc.

I'm not sure if that's relevant or not.  Are you basing that on there
being 4 hits listed in my /proc output, whereas I have the hitcount at 5?

The problem persists even with the hitcount at 10.  Actually, it seems to
continue to misbehave up until 20, but seems to behave at 21 or higher
(with --seconds 40).

If my second attempt to connect is more than 40 seconds after the first,
it connects OK, but if it's less than 40 seconds after the first, it won't
let me connect.  It's as if it's ignoring the hitcount unless it's higher
than 20.

I tried with --seconds 30 and could find no correlation to the duration of
time between first and second attempts and whether the second attempt was
successful or not.

It's as if I just don't understand the interaction between --seconds and
--hitcount.  I believe they interact like so:

  If there have been [hitcount] packets from the source IP in the last
  [seconds] seconds, then the rule will match

Is this correct?

> Did the old version behave differently here?

I'm not sure, I've only ever had this version set up.

Regards, Msquared...