Multiple Targets

Multiple Targets

[Ben La Monica]

Hello,

I'm writing a firewall application for ISPs, and I'm realizing that my
tables could potentially get very long because there is no way to
perform multiple targets on a matched rule. I wanted to get the list's
feedback before I put too much effort into doing something like this.

Basically I have a long list of rules which I am matching mac
addresses against. If the mac is in the list, it is MARKed with a
group number. Based on this mark, the packets go through different
sets of rules and then on to the traffic shaper. Because I am limited
to one target per match, I have to either let the packet continue to
traverse through the entire chain, or put another, identical rule
following the first rule to have it RETURN to the previous chain to
continue processing. This is only an issue on non-terminating targets
(such as MARK, ULOG, LOG, etc)

Example (where n is the number of authorized macs):
iptables -N auth
iptables -A auth -i int+ -m mac --mac-source 00:00:00:00:00:00 -j MARK
--set-mark 1
iptables -A auth -i int+ -m mac --mac-source 00:00:00:00:00:00 -j RETURN
iptables -A auth -i int+ -m mac --mac-source 00:00:00:00:00:01 -j MARK
--set-mark 2
iptables -A auth -i int+ -m mac --mac-source 00:00:00:00:00:01 -j RETURN
... n ...
iptables -A auth -i int+ -m mac --mac-source FF:FF:FF:FF:FF:FF -j MARK
--set-mark n

I had the idea of allowing multiple targets, as long as the targets
before the last were non-terminating. Following on my example above,
it would look something like this:

iptables -N auth
iptables -A auth -i int+ -m mac --mac-source 00:00:00:00:00:00 -j
MARK,RETURN --set-mark 1
iptables -A auth -i int+ -m mac --mac-source 00:00:00:00:00:01 -j
MARK,RETURN --set-mark 2
... n ...
iptables -A auth -i int+ -m mac --mac-source FF:FF:FF:FF:FF:FF -j
MARK,RETURN --set-mark n

This way, you could chain several targets together, and it would
execute them all until it hit a target that would decide the fate of
the packet. You could mark, log, and accept a packet with a single
match if you wanted to. I know you can do this to a certain extent by
creating a user-defined chain and then matching once and sending
packets to that user-defined chain.

If this is too ambitious or will break too many things, perhaps I
could just modify the RETURN target to do what I want it to do
(perform two returns instead of just one).

Please respond, even if it is to say, "That's stupid. Do it another way." :)

Thanks for your time.

-Ben La Monica

Re: Multiple Targets

[Patrick Schaaf]

> I'm writing a firewall application for ISPs, and I'm realizing that my
> tables could potentially get very long because there is no way to
> perform multiple targets on a matched rule.

There is: it is called user-defined chains.

Of course, seeing your example, you would need one such user-defined
chain for each different MARK value you want to set. Oh, and RETURN
would need to return two levels, as you seem to allude to near the
end of your posting. (BTW, I think THAT would be a generally
useful extension, -j RETURN --up NR)

That approach is impractical. "user-defined chains" is an easy answer,
but not a complete solution, as your examples clearly illustrate.

Unfortunately your proposals also appear to be very ambitiuous.

> I had the idea of allowing multiple targets, as long as the targets
> before the last were non-terminating. Following on my example above,
> it would look something like this:
> 
> iptables -N auth
> iptables -A auth -i int+ -m mac --mac-source 00:00:00:00:00:00 -j
> MARK,RETURN --set-mark 1
> iptables -A auth -i int+ -m mac --mac-source 00:00:00:00:00:01 -j
> MARK,RETURN --set-mark 2
> ... n ...
> iptables -A auth -i int+ -m mac --mac-source FF:FF:FF:FF:FF:FF -j
> MARK,RETURN --set-mark n
> 
> This way, you could chain several targets together, and it would
> execute them all until it hit a target that would decide the fate of
> the packet. You could mark, log, and accept a packet with a single
> match if you wanted to.

Problem: target options. How would the commandline parser see that
--set-mark belongs to MARK, and --log-prefix belongs to LOG? What
about the hypothetical case of several targets having target options
with identical names?

Apart from that, the approach will certainly break binary compatibility
with the former iptables, and thus WILL NOT BE DONE in the iptables
framework, because binary compatibility is considered GOD.

Harald, what does pkttables bring to the table in this regard?

Generally, I think the reasoning behind wanting such a feature, is sound.

best regards
  Patrick

Re[2]: Multiple Targets

[Maciej Soltysiak]

Hello Patrick,

Saturday, February 19, 2005, 9:28:51 AM, you wrote:
> Problem: target options. How would the commandline parser see that
> --set-mark belongs to MARK, and --log-prefix belongs to LOG? What
> about the hypothetical case of several targets having target options
> with identical names?
This is all very interesting.
But do we want this because we want just better looking rulesets or
have it optimized in sense of matchinge the packets?

I think the latter. So how about leaving the iptables semantics left as
they are, but changing it so it does recognize rules with identical
matching rules and somehow compiling the two (or more) of them into
a single rule that kernel-space would understand.
Example:

We write these 3 rules:
iptables -A INPUT -p tcp --dport 53 -j LOG --log-prefix "foo: "
iptables -A INPUT -p tcp --dport 53 -j MARK --set-mark 1
iptables -A INPUT -p tcp --dport 53 -j ACCEPT

iptables reads these 3 rules but creates one complex rule for that in
kernel-space that would read:
match tcp dport 53 packets on INPUT and do
1) LOG --log-prefix "foo: "
2) MARK --set-mark 1
3) ACCEPT

Of course there can be only one rule that ends with a returning verdict:
ACCEPT,DROP,REJECT.

This way only the kernel core since some new version would do this,
others would do it the standard way. Binary compatibility retained.

-- 
Best regards,
Maciej

Re: Multiple Targets

[Jonas Berlin]

Maciej Soltysiak wrote:

>Hello Patrick,
>
>Saturday, February 19, 2005, 9:28:51 AM, you wrote:
>  
>
>>Problem: target options. How would the commandline parser see that
>>--set-mark belongs to MARK, and --log-prefix belongs to LOG? What
>>about the hypothetical case of several targets having target options
>>with identical names?
>>    
>>
Isn't it possible to have multiple matchers also? How are the arguments 
to them separated?

>This is all very interesting.
>But do we want this because we want just better looking rulesets or
>have it optimized in sense of matchinge the packets?
>  
>
If the latter, how about having a match target instead that matches if 
the previous one matched?

i.e.

>iptables -A INPUT -p tcp --dport 53 -j LOG --log-prefix "foo: "
>iptables -A INPUT -p tcp --dport 53 -j MARK --set-mark 1
>iptables -A INPUT -p tcp --dport 53 -j ACCEPT
>  
>
would instead be written:

iptables -A INPUT -p tcp --dport 53 -j LOG --log-prefix "foo: "
iptables -A INPUT -m previous -j MARK --set-mark 1
iptables -A INPUT -m previous -j ACCEPT

This would be quite easy to implement, not break any binary interface 
and my guess is it wouldn't be too slow either.

That said, I could maybe look into coding it if there is no better idea 
and nobody think it's an immensely stupid idea :)

>iptables reads these 3 rules but creates one complex rule for that in
>kernel-space that would read:
>match tcp dport 53 packets on INPUT and do
>1) LOG --log-prefix "foo: "
>2) MARK --set-mark 1
>3) ACCEPT
>  
>
Another idea I just got would be like

iptables -A INPUT -p tcp --dport 53 -j IF_NOT_MATCH_SKIP --skip 3
iptables -j LOG --log-prefix "foo: "
iptables -j MARK --set-mark 1
iptables -j ACCEPT

i.e. if it matches it didn't match, it would skip the following three 
rules. This might be a bit intrusive to implement though, I'm not sure. 
It would be a little less space-effective, maybe aesthetically or 
logically less pleasing, but faster to process, if my previous 
suggestion would be too slow :)

These might not be the best options, but at least they are options :)

-- 
- xkr47

Re: Multiple Targets

[Patrick Schaaf]

> >>Problem: target options. How would the commandline parser see that
> >>--set-mark belongs to MARK, and --log-prefix belongs to LOG? What
> >>about the hypothetical case of several targets having target options
> >>with identical names?
> >>   
> >>
> Isn't it possible to have multiple matchers also? How are the arguments 
> to them separated?

Very strangely, or so they said. As far as I remember, doing things
cleanly in this regard, was one of the main motivations for pkttables.
(Sorry, I never tried to understand this in more detail)

> If the latter, how about having a match target instead that matches if 
> the previous one matched?
> 
> This would be quite easy to implement, not break any binary interface 
> and my guess is it wouldn't be too slow either.

Heh. I've got the same idea, but you beat me. However, I'd simply name this
'and', instead of 'previous':

iptables -A INPUT -p tcp --dport 53 -j LOG --log-prefix "foo: "
iptables -A INPUT -m and -j MARK --set-mark 1
iptables -A INPUT -m and -j ACCEPT

I agree that implementing this would be rather easy: the main table
scanning can certainly know the result of the last match it did,
and it could specialcase recognition of 'and' (i.e. NOT call the
match function, which would then wonder how to get at its caller's
knowledge of the previous match result...)

best regards
  Patrick

Re: Re[2]: Multiple Targets

[Samuel Jean]

On Sat, February 19, 2005 4:23 am, Maciej Soltysiak said:

Hi Maciej

> We write these 3 rules:
> iptables -A INPUT -p tcp --dport 53 -j LOG --log-prefix "foo: "
> iptables -A INPUT -p tcp --dport 53 -j MARK --set-mark 1
> iptables -A INPUT -p tcp --dport 53 -j ACCEPT
>
> iptables reads these 3 rules but creates one complex rule for that in
> kernel-space that would read:
> match tcp dport 53 packets on INPUT and do
> 1) LOG --log-prefix "foo: "
> 2) MARK --set-mark 1
> 3) ACCEPT

Consider what will happen if someone tries to -D such rules..

>
> --
> Best regards,
> Maciej
>

Best regards,

Samuel

Re: Multiple Targets

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----


It seems to me that having a "RETURN" option for all targets might be
one way. (IPFilter has "quick", which can be overused...)

Or write a module called "MARKRETURN".

In general, I would, however, like to have a way to load tables of
various kinds and lookup things in them.  That would, for me, include
"the default routing table".

Actually, I'd like to replace all of the IP forwarding logic with
iptables :-)

- -- 
] Michael Richardson          Xelerance Corporation, Ottawa, ON |  firewalls  [
] mcr @ xelerance.com           Now doing IPsec training, see   |net architect[
] http://www.sandelman.ca/mcr/    www.xelerance.com/training/   |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQiY9gIqHRg3pndX9AQFLjAP/f1dHEUeGO/H15Ipwpy8uHqgl5uLqs5zd
UrCrA+yJY4+5GzeUtpg7dumFw22TEX721r7CbNJF32ozopLsoJvpCXI39MJkLFbT
AOwjGk7/cnlyAraQHLXNuHbbd24YsVNOdGu5ceRJMPKT3winZ6ShfQxyHGV5fkdD
P+i2rMrWUGw=
=gSJl
-----END PGP SIGNATURE-----

Re: Multiple Targets

[Don Cohen]

 > Example (where n is the number of authorized macs):
 > iptables -N auth
 > iptables -A auth -i int+ -m mac --mac-source 00:00:00:00:00:00 -j MARK
 > --set-mark 1
 > iptables -A auth -i int+ -m mac --mac-source 00:00:00:00:00:00 -j RETURN
 > iptables -A auth -i int+ -m mac --mac-source 00:00:00:00:00:01 -j MARK
 > --set-mark 2
 > iptables -A auth -i int+ -m mac --mac-source 00:00:00:00:00:01 -j RETURN
 > ... n ...
 > iptables -A auth -i int+ -m mac --mac-source FF:FF:FF:FF:FF:FF -j MARK
 > --set-mark n
 > 
 > I had the idea of allowing multiple targets, as long as the targets
 > before the last were non-terminating. Following on my example above,
 > it would look something like this:

I think it would be better to focus on a better way of matching
large sets.  You currently have n x m rules for n addresses and
m targets.  Since n is much more likely to be large than m I
want to get rid of the factor if n rather than m, especially in
the run time.

The example above suggests a module that supports a hash table.  
You load the module, fill it with a large number of (in this case) 
mac addresses, and then in one rule match any mac address in that 
set.  This module could be parameterized by the size of the data 
you want to match.  You could use /proc files to read/write the 
table.  The iptables rule would then need some way to specify what 
to extract from the packet to match.  I imagine something like the 
u32 match where instead of comparing the extracted values with 
constants in the rule, these are just collected into a byte sequence 
which is then used as a hash key.

I think it would be useful to have such a module as a pure match, to
recognize members of a given set, but in the example above (which I
find rather odd), that saves nothing because every address has its own
mark, and I end up with one rule per mark.  In practice I think that
the number of marks is much less likely to be large than the number of
keys, but one could remove the factor of the number of marks by
generalizating the table to include a value for each key, where the
value is used to mark the packet.  

Another possibility, perhaps a third alternative version of the
module, would be replacing the hash table with a binary search, in
order to support ranges.

 > If the latter, how about having a match target instead that matches if 
 > the previous one matched?
 > 
 > i.e.
 > 
 > >iptables -A INPUT -p tcp --dport 53 -j LOG --log-prefix "foo: "
 > >iptables -A INPUT -p tcp --dport 53 -j MARK --set-mark 1
 > >iptables -A INPUT -p tcp --dport 53 -j ACCEPT
 > >  
 > >
 > would instead be written:
 > 
 > iptables -A INPUT -p tcp --dport 53 -j LOG --log-prefix "foo: "
 > iptables -A INPUT -m previous -j MARK --set-mark 1
 > iptables -A INPUT -m previous -j ACCEPT

How about just using the first rule to set the mark, and using 
the mark to trigger the rest?  I assume that matching the mark
is about as cheap as any match can be.