bug in iptables-restore and "recent" module

bug in iptables-restore and "recent" module

[richard lucassen]

When using the "recent" module and when the hitcount max (defaults to
20) is violated, "iptables-restore" is testing the file OK, but fails
on loading the filter table:

The file "iptables.save" contains the rule (note: "--hitcount 21"
exceeds the default max of 20):

-A INPUT  -m state --state NEW -p tcp --dport 443 -m recent --update
--name https --seconds 50 --hitcount 21 -j REJECT

The -t option (test file) shows an OK:

# iptables-restore -t < iptables.save
# echo $?
0

But:

# iptables-restore < iptables.save
iptables-restore: line 180 failed

On line 180 there is the "COMMIT" of the filter table.

Distro: Debian testing
# iptables --version
iptables v1.4.21

R.

-- 
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht                                        |
+------------------------------------------------------------------+

Re: bug in iptables-restore and "recent" module

[Pascal Hambourg]

richard lucassen a écrit :
> When using the "recent" module and when the hitcount max (defaults to
> 20) is violated, "iptables-restore" is testing the file OK, but fails
> on loading the filter table:
> 
> The file "iptables.save" contains the rule (note: "--hitcount 21"
> exceeds the default max of 20):
> 
> -A INPUT  -m state --state NEW -p tcp --dport 443 -m recent --update
> --name https --seconds 50 --hitcount 21 -j REJECT
> 
> The -t option (test file) shows an OK:
> But:
> 
> # iptables-restore < iptables.save
> iptables-restore: line 180 failed
> 
> On line 180 there is the "COMMIT" of the filter table.

That sounds like expected behaviour. Where's the bug ?

Re: bug in iptables-restore and "recent" module

[richard lucassen]

On Mon, 16 Feb 2015 00:08:41 +0100
Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:

> > On line 180 there is the "COMMIT" of the filter table.
> 
> That sounds like expected behaviour. Where's the bug ?

I'd say in iptables-restore. Apparently the -t (test) does not notice
that there is a problem while the real iptables-restore does.

-- 
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht                                        |
+------------------------------------------------------------------+

Re: bug in iptables-restore and "recent" module

[Pascal Hambourg]

richard lucassen a écrit :
> On Mon, 16 Feb 2015 00:08:41 +0100
> Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
> 
>>> On line 180 there is the "COMMIT" of the filter table.
>> That sounds like expected behaviour. Where's the bug ?
> 
> I'd say in iptables-restore. Apparently the -t (test) does not notice
> that there is a problem while the real iptables-restore does.

Sorry, my question was not clear enough. Let me rephrase.

As -t does not commit the tables to the kernel, I do not expect it to
detect errors related to the kernel configuration. So I do not see any
bug in your description, it sounds like expected behaviour to me. Where
do you see a bug in that behaviour ?

Re: bug in iptables-restore and "recent" module

[Dennis Jacobfeuerborn]

On 17.02.2015 09:52, Pascal Hambourg wrote:
> richard lucassen a écrit :
>> On Mon, 16 Feb 2015 00:08:41 +0100
>> Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
>>
>>>> On line 180 there is the "COMMIT" of the filter table.
>>> That sounds like expected behaviour. Where's the bug ?
>>
>> I'd say in iptables-restore. Apparently the -t (test) does not notice
>> that there is a problem while the real iptables-restore does.
> 
> Sorry, my question was not clear enough. Let me rephrase.
> 
> As -t does not commit the tables to the kernel, I do not expect it to
> detect errors related to the kernel configuration. So I do not see any
> bug in your description, it sounds like expected behaviour to me. Where
> do you see a bug in that behaviour ?

This should probably be mentioned in the man page. Most people would
think that if the ruleset passes a test with -t this means the ruleset
can be activated. Which part specifically of the mentioned rule is it
that cannot be tested without being committed the rule in the kernel?

Regards,
  Dennis

Re: bug in iptables-restore and "recent" module

[richard lucassen]

On Tue, 17 Feb 2015 12:12:30 +0100
Dennis Jacobfeuerborn <dennisml@conversis.de> wrote:

> > As -t does not commit the tables to the kernel, I do not expect it
> > to detect errors related to the kernel configuration. So I do not
> > see any bug in your description, it sounds like expected behaviour
> > to me. Where do you see a bug in that behaviour ?
> 
> This should probably be mentioned in the man page. Most people would
> think that if the ruleset passes a test with -t this means the ruleset
> can be activated. Which part specifically of the mentioned rule is it
> that cannot be tested without being committed the rule in the kernel?

--hitcount

Default is 20 and when --hitcount exceeds this value, "iptables-restore
-t" approves the syntax but the kernel does not accept this value.

R.

-- 
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht                                        |
+------------------------------------------------------------------+

Re: bug in iptables-restore and "recent" module

[richard lucassen]

On Tue, 17 Feb 2015 09:52:54 +0100
Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:

> > I'd say in iptables-restore. Apparently the -t (test) does not
> > notice that there is a problem while the real iptables-restore does.
> 
> Sorry, my question was not clear enough. Let me rephrase.
> 
> As -t does not commit the tables to the kernel, I do not expect it to
> detect errors related to the kernel configuration. So I do not see any
> bug in your description, it sounds like expected behaviour to me.
> Where do you see a bug in that behaviour ?

You have a point :) And I agree with Dennis to add it to the
manpage.

R.

-- 
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht                                        |
+------------------------------------------------------------------+

Re: bug in iptables-restore and "recent" module

[Neal Murphy]

On Friday, February 20, 2015 04:05:44 PM richard lucassen wrote:
> On Tue, 17 Feb 2015 09:52:54 +0100
> 
> Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
> > > I'd say in iptables-restore. Apparently the -t (test) does not
> > > notice that there is a problem while the real iptables-restore does.
> > 
> > Sorry, my question was not clear enough. Let me rephrase.
> > 
> > As -t does not commit the tables to the kernel, I do not expect it to
> > detect errors related to the kernel configuration. So I do not see any
> > bug in your description, it sounds like expected behaviour to me.
> > Where do you see a bug in that behaviour ?
> 
> You have a point :) And I agree with Dennis to add it to the
> manpage.

To state it a little more explicitly:
  o '-t' can only validate the syntax; it cannot check the data
  o 'the kernel' validates the data