[Ferm] Inaccuracy about subchain concept

Kiss Gabor (Bitman) kissg at ssg.ki.iif.hu
Fri Jul 26 21:01:40 CEST 2013


Hi folks,

I have version 2.1. Ferm(1) writes:

       @subchain ["CHAIN-NAME"] { ... }
               Works like the normal block operators (i.e. without the
               @subchain keyword), except that ferm moves rules within the
               curly braces into a new custom chain.
(statement 1)
[...]
               You can achieve the same by explicitly declaring a custom
               chain, but you may feel that using @subchain requires less
               typing.
(statement 2)

The both statements are in contradiction. (Actually the first one
is the true.)

Compare these constructions:

table filter {
    chain demo1 {
        proto tcp dport 5001 @subchain "common1" {
            DROP saddr (1.0.0.0 2.0.0.0 3.0.0.0);
        }
        proto udp dport 6001 jump common1;
        proto ipv6 jump common1;
    }

    chain demo2 {
        proto tcp dport 5002 jump common2;
        proto udp dport 6002 jump common2;
        proto ipv6 jump common2;
    }
    chain common2 {
        DROP saddr (1.0.0.1 2.0.0.2 3.0.0.3);
    }
}

I wanted to use the first one because I find handy not to declare a
subchain separately. (I really feel that using @subchain requires
less typing. :-) And I like to share subchains. (It is not forbidden
and it works in most cases.)

However ferm generated such rules that were refused by
iptables-restore because multiple -p options. (I do not understand
why even after I wrote this mail. :-)
Let's see with --lines option:

# Generated by ferm 2.1 on Fri Jul 26 20:44:51 2013
*filter
:common1 - [0:0]
:common2 - [0:0]
:demo1 - [0:0]
:demo2 - [0:0]
-A common1 --protocol tcp --jump DROP --source 1.0.0.0
-A common1 --protocol tcp --jump DROP --source 2.0.0.0
-A common1 --protocol tcp --jump DROP --source 3.0.0.0
-A common2 --jump DROP --source 1.0.0.1
-A common2 --jump DROP --source 2.0.0.2
-A common2 --jump DROP --source 3.0.0.3
-A demo1 --protocol tcp --dport 5001 --jump common1
-A demo1 --protocol udp --dport 6001 --jump common1
-A demo1 --protocol ipv6 --jump common1
-A demo2 --protocol tcp --dport 5002 --jump common2
-A demo2 --protocol udp --dport 6002 --jump common2
-A demo2 --protocol ipv6 --jump common2
COMMIT

Can you see the difference between common1 and common2 chains?
Common1 is like statement 1 promised. If it was a simple block
it would contain also "--protocol tcp" as usual.

And it is evident that statement 2 is not true under all circumstances.
Even if iptables-restore accepted common1 it would not
block 6001/udp and embedded ipv6 traffic due to explicit protocol
specification.
Using separate chain is a MUST in this case.

Man page needs to be corrected.

Cheers

Gabor
-- 
E-mail = m-mail * c-mail ^ 2


More information about the Ferm mailing list