iptables extension idea

[Patrick Schaaf]

> For me it would be useful to be able to write a rule to match a class of
> packets.  It wouldn't add extra functionality, but it would clean up my
> firewall quite a bit.  This appears to be the same reasoning behind the
> ippool match, but extended to match more than just IP addresses.

The idea behind the ippool match was operation in an environment where
the individual IP addresses a "logical" rule should match, would vary
a lot, decided by a user level process (e.g. a RADIUS server). Instead
of modifying the ruleset, one adds or deletes addresses from the pool.

> I would like to be able to just classify my interfaces as being either
> "internal", "dmz", or "external".  Then I could write my firewall without
> being concerned about the actual names of the interfaces, just their type.

You can do this right now. Have a look at the "ip" command from the
iproute2 package. Using that, you can rename the real network interfaces.
Then, use the wildcard feature of iptables to match the base part of
the renamed interface names. This would look something like this:

	ip link set eth0 name dmz0
	ip link set eth1 name dmz1
	ip link set eth2 name internal0
	ip link set eth3 name internal1
	ip link set eth4 name internal2
	ip link set eth4 name external0

	iptables -A FORWARD -i internal+ -o external+ -j ACCEPT

> If a PPP interface came up because of pptp, I could just add it to my class
> of internal interfaces.

	ip link set ppp0 name internal3

Here you see the one problem: how to select the number behind the prefix.
This would be the job for a daemon, or for a program with proper locking
against multiple concurrent calls.

That said:

> Implementation
> ~~~~~~~~~~~~~~
> Create a new table "class".  There would be no default chains in this table.
> Any new chain in the class table would create a new class name.
> Add a new match to iptables, -m class, which would take the --classname
> <classname> option.  The rule would match if the rule <classname> in the
> class table ACCEPTed the packet.
> It would be really nice if you could use "and", "or", and "not" inside
> the -m class matching rule, so that you could make compound statements
> (useful on the FORWARD chain).

This is similar to something I thought to propose for some time. Forget
about the "new table". Why would one need it? What I'd want, is just
a generic '-m chain', with options '--table X' and '--name Y'.
This would call chain Y in table X, with X defaulting to the table
the rule is found in. As with your proposal, only an NF_ACCEPT would
result in the '-m chain' matching.

Why did I not propose that? Well, for one, we are on our way to build
a packet filtering programming language, but we do it by inventing ad hoc
semantics pressed into the iptables command line syntax. This feels wrong.
Also, various matches and targets are dependant on the tables they sit in,
and/or the hooks they are used from, so any mechanism as described above,
wouldn't be usable in the suggestive generality it seems to have.

In other words: the resulting filters become more and more unmaintainable,
and nonunderstandable.

Hope this makes sense to somebody...

best regards
  Patrick