With kernel 3.19.0, the following iptables rule, where SSH_TRIES is set
to 4:
iptables -D SSH_CHAIN -m conntrack --ctstate NEW \
-m recent --update --seconds $SSH_LOGIN_PERIOD --hitcount $SSH_TRIES -j DROP
generates this error message in syslog:
kernel: xt_recent: hitcount (4) is larger than packets to be
remembered (4) for table DEFAULT
and the rule fails to install in the table. No error is generated with
kernel 3.18.6.
Chris
On Wed, 11 Feb 2015 09:28:34 +0000
Chris Vine <[email protected]> wrote:
> With kernel 3.19.0, the following iptables rule, where SSH_TRIES is
> set to 4:
>
> iptables -D SSH_CHAIN -m conntrack --ctstate NEW \
> -m recent --update --seconds $SSH_LOGIN_PERIOD --hitcount
> $SSH_TRIES -j DROP
>
> generates this error message in syslog:
>
> kernel: xt_recent: hitcount (4) is larger than packets to be
> remembered (4) for table DEFAULT
>
> and the rule fails to install in the table. No error is generated
> with kernel 3.18.6.
The rule provoking this should of course have been the one appending
the rule, which is:
iptables -A SSH_CHAIN -m conntrack --ctstate NEW \
-m recent --update --seconds $SSH_LOGIN_PERIOD --hitcount $SSH_TRIES -j DROP
On looking at the code, the changes in the 3.19 kernel seem not to have
been tested and there is an off-by-one error. The patch below restores
behaviour to be identical to that found in the 3.18 kernel.
Chris
--- linux-3.19.0/net/netfilter/xt_recent.c~ 2015-02-10 09:18:44.657376355 +0000
+++ linux-3.19.0/net/netfilter/xt_recent.c 2015-02-11 17:58:33.311608835 +0000
@@ -378,7 +378,7 @@
mutex_lock(&recent_mutex);
t = recent_table_lookup(recent_net, info->name);
if (t != NULL) {
- if (info->hit_count > t->nstamps_max_mask) {
+ if (info->hit_count > t->nstamps_max_mask + 1) {
pr_info("hitcount (%u) is larger than packets to be remembered (%u) for table %s\n",
info->hit_count, t->nstamps_max_mask + 1,
info->name);
(Cc'ing netdev and netfilter-devel lists)
On Wed, Feb 11, 2015 at 10:31 AM, Chris Vine
<[email protected]> wrote:
> On Wed, 11 Feb 2015 09:28:34 +0000
> Chris Vine <[email protected]> wrote:
>> With kernel 3.19.0, the following iptables rule, where SSH_TRIES is
>> set to 4:
>>
>> iptables -D SSH_CHAIN -m conntrack --ctstate NEW \
>> -m recent --update --seconds $SSH_LOGIN_PERIOD --hitcount
>> $SSH_TRIES -j DROP
>>
>> generates this error message in syslog:
>>
>> kernel: xt_recent: hitcount (4) is larger than packets to be
>> remembered (4) for table DEFAULT
>>
>> and the rule fails to install in the table. No error is generated
>> with kernel 3.18.6.
>
> The rule provoking this should of course have been the one appending
> the rule, which is:
>
> iptables -A SSH_CHAIN -m conntrack --ctstate NEW \
> -m recent --update --seconds $SSH_LOGIN_PERIOD --hitcount $SSH_TRIES -j DROP
>
> On looking at the code, the changes in the 3.19 kernel seem not to have
> been tested and there is an off-by-one error. The patch below restores
> behaviour to be identical to that found in the 3.18 kernel.
>
> Chris
>
> --- linux-3.19.0/net/netfilter/xt_recent.c~ 2015-02-10 09:18:44.657376355 +0000
> +++ linux-3.19.0/net/netfilter/xt_recent.c 2015-02-11 17:58:33.311608835 +0000
> @@ -378,7 +378,7 @@
> mutex_lock(&recent_mutex);
> t = recent_table_lookup(recent_net, info->name);
> if (t != NULL) {
> - if (info->hit_count > t->nstamps_max_mask) {
> + if (info->hit_count > t->nstamps_max_mask + 1) {
> pr_info("hitcount (%u) is larger than packets to be remembered (%u) for table %s\n",
> info->hit_count, t->nstamps_max_mask + 1,
> info->name);
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Cong Wang <[email protected]> wrote:
> (Cc'ing netdev and netfilter-devel lists)
Thanks for forwarding.
> > Chris Vine <[email protected]> wrote:
> >> iptables -D SSH_CHAIN -m conntrack --ctstate NEW \
> >> -m recent --update --seconds $SSH_LOGIN_PERIOD --hitcount
> >> $SSH_TRIES -j DROP
> > --- linux-3.19.0/net/netfilter/xt_recent.c~ 2015-02-10 09:18:44.657376355 +0000
> > +++ linux-3.19.0/net/netfilter/xt_recent.c 2015-02-11 17:58:33.311608835 +0000
> > @@ -378,7 +378,7 @@
> > mutex_lock(&recent_mutex);
> > t = recent_table_lookup(recent_net, info->name);
> > if (t != NULL) {
> > - if (info->hit_count > t->nstamps_max_mask) {
> > + if (info->hit_count > t->nstamps_max_mask + 1) {
Looks good. Chris, could you formally submit this patch to
[email protected]?
Thanks!
On Thu, 12 Feb 2015 09:35:33 +0100
Florian Westphal <[email protected]> wrote:
> Cong Wang <[email protected]> wrote:
> > (Cc'ing netdev and netfilter-devel lists)
>
> Thanks for forwarding.
>
> > > Chris Vine <[email protected]> wrote:
> > >> iptables -D SSH_CHAIN -m conntrack --ctstate NEW \
> > >> -m recent --update --seconds $SSH_LOGIN_PERIOD --hitcount
> > >> $SSH_TRIES -j DROP
> > > --- linux-3.19.0/net/netfilter/xt_recent.c~ 2015-02-10
> > > 09:18:44.657376355 +0000 +++
> > > linux-3.19.0/net/netfilter/xt_recent.c 2015-02-11
> > > 17:58:33.311608835 +0000 @@ -378,7 +378,7 @@
> > > mutex_lock(&recent_mutex); t = recent_table_lookup(recent_net,
> > > info->name); if (t != NULL) {
> > > - if (info->hit_count > t->nstamps_max_mask) {
> > > + if (info->hit_count > t->nstamps_max_mask + 1) {
>
> Looks good. Chris, could you formally submit this patch to
> [email protected]?
>
> Thanks!
Done.
Chris
On Thu, 12 Feb 2015 10:26:16 +0000
Chris Vine <[email protected]> wrote:
> On Thu, 12 Feb 2015 09:35:33 +0100
> Florian Westphal <[email protected]> wrote:
> > Cong Wang <[email protected]> wrote:
> > > (Cc'ing netdev and netfilter-devel lists)
> >
> > Thanks for forwarding.
> >
> > > > Chris Vine <[email protected]> wrote:
> > > >> iptables -D SSH_CHAIN -m conntrack --ctstate NEW \
> > > >> -m recent --update --seconds $SSH_LOGIN_PERIOD --hitcount
> > > >> $SSH_TRIES -j DROP
> > > > --- linux-3.19.0/net/netfilter/xt_recent.c~ 2015-02-10
> > > > 09:18:44.657376355 +0000 +++
> > > > linux-3.19.0/net/netfilter/xt_recent.c 2015-02-11
> > > > 17:58:33.311608835 +0000 @@ -378,7 +378,7 @@
> > > > mutex_lock(&recent_mutex); t = recent_table_lookup(recent_net,
> > > > info->name); if (t != NULL) {
> > > > - if (info->hit_count > t->nstamps_max_mask) {
> > > > + if (info->hit_count > t->nstamps_max_mask + 1) {
> >
> > Looks good. Chris, could you formally submit this patch to
> > [email protected]?
> >
> > Thanks!
>
> Done.
On further testing I see that that patch only solves the problem if
SSH_TRIES is set to a power of two boundary. You still get an error
loading the rule if it is anything else. I think there is something
wrong with the nstamp_mask heuristic which is used here.
Chris
On Thu, 12 Feb 2015 10:54:17 +0000
Chris Vine <[email protected]> wrote:
[snip]
> On further testing I see that that patch only solves the problem if
> SSH_TRIES is set to a power of two boundary. You still get an error
> loading the rule if it is anything else. I think there is something
> wrong with the nstamp_mask heuristic which is used here.
I now find that that is not right either. I had to rmmod xt_recent to
get it to drop its previous setting. With that done, the patch does
indeed seem to work for all values of SSH_TRIES.
Chris