Re: [iptables] Zone based rules

* [Tue, Apr 09, 2013 at 05:41:39PM +0200] Jimmy Thrasibule:
>In can change the rules order but this will not solve the problem.
>Another solution would be to mark the packet and then check the mark at
>the end to decide on whether to accept or reject. But how about
>performances on a large set of rules as the firewall will have to go
>through all of them before taking a decision?

Have you considered using RETURN instead of ACCEPT ?
Something like:

   # Traffic coming from the zones.
   -A FORWARD -i eth0 ZONE_MRKT_OUT
   -A FORWARD -i eth1 ZONE_SRV_OUT

   # Traffic to the zones.
   -A FORWARD -o eth0 ZONE_MRKT_IN
   -A FORWARD -o eth1 ZONE_SRV_IN

   -A FORWARD -j ACCEPT

   # Let's look at marketing.
   -A ZONE_MKRT_OUT -j RETURN
   -A ZONE_MKRT_OUT -j DROP # catch-all, useless here

   # Servers
   -A ZONE_SRV_IN -s mar.ket.ing.net/mask -p tcp --dport 22 -j DROP
   -A ZONE_SRV_IN -j DROP # catch-all

>How would you manage such a case?

I'm not sure if I've got the context right, here.
If the fw will be managed by a single person/team, I'd surely go for a 
classic set of rules. I normally group the forward rules by the output 
interface and use a reject catch-all chain (explicitly dropping "unfair" 
packets), so i.e.:

   -A FORWARD -o eth0 -j fwd_eth0
   -A FORWARD -o eth1 -j fwd_eth1
   -A FORWARD -o eth2 -j fwd_eth2 # internet nic ?

   -A fwd_eth1 -i eth0 -p tcp --dport 22 -j DROP
   -A fwd_eth1 -j reject-chain

   -A fwd_eth2 -i eth0 -j ACCEPT
   -A fwd_eth2 -j reject-chain

On the other hand, if the filtering rules should be managed autonomously 
by the two departments (and I suspect this is the case), I'd probably go 
for a multi-context/"virtual" system. Putting something together using 
lxc and a virtual switch shouldn't be difficult.

Ciao,
Gian Piero.