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.


--
To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20130409185435.GA30495@caimano.fdc.rm-rf.it