[Firehol-support] SQUID_USERS, 'time' and overlapping sources/destinations

[Jack Olszewski]

From: "Costa Tsaousis" <costa at tsaousis.gr>
Subject: Re: [Firehol-support] SQUID_USERS, 'time' and overlapping sources/destinations
Date: Wed, 29 Oct 2003 22:32:02 +0200 (EET)

costa> Hi Jack,
costa> 
costa> Problem 1: OWNER match fails with "invalid argument".
costa> Answer:
costa> 
costa> I can guess of two reasons for this to happen:
costa> 
costa> a. The running kernel was not having the OWNER netfilter module compiled
costa> in (or as module)
costa> 
costa> b. The iptables user-space tools were not compiled with the running kernel
costa> (this can still happen even on RH systems if you update your kernel but
costa> don't update the iptables user-space tools.
costa> 
costa> If none of the above is the case, then it might be a FireHOL bug (although
costa> I don't see any errors in the produced iptables command that fails).
costa> 

You are right about iptables compiled with a kernel other than
actually running. Iptables have been built and packaged into an rpm on
daffy.perf.redhat.com on 4 Mar 2002, and kernel-bigmem - on
porky.devel.redhat.com on 19 Aug 2003. 

costa> Problem 2: time service fails.
costa> Answer:
costa> There have been reported problems with some versions of BASH, producing
costa> errors when BASH reserved keywords are used as array values. Time is a
costa> reserved BASH keyword that produces such errors on these versions of BASH.
costa> Note that such errors are not produced by the service names (FireHOL never
costa> places service names in BASH arrays). They are produced by the port names
costa> defined within the services. All these mean that:
costa> 
costa> server_time_ports="udp/time tcp/time"
costa> 
costa> produces errors when used by FireHOL on a few BASH versions, but
costa> 
costa> server_time_ports="udp/37 tcp/37"
costa> 
costa> runs without any problems.
costa> I have changed the time definition to use numeric ports in version 1.164
costa> (currently in the CVS).
costa> 
costa> Problem 3: Overlapping interfaces.
costa> Answer:
costa> I have chosen the default policy on interfaces to be DROP, meaning that
costa> all traffic that is matched by an interface statement but is not matched
costa> by the server and client statements within that interface will be dropped
costa> at the end of the interface with a log-prefix of "IN-name" or "OUT-name"
costa> where name is the name given to the interface.
costa> Of course, I could give the default policy RETURN to interfaces (like the
costa> routers) in which case everything would be the same except that
costa> overlapping interfaces would work by default (like the routers) and all
costa> logs should appear as "IN-unknown" and "OUT-unknown" (like the routers:
costa> PASS-unknown).
costa> 
costa> I decided that for interfaces I should choose the first option (policy
costa> DROP) since this would make debugging clear (you know which interface did
costa> not match the traffic) and for routers the second options (policy RETURN)
costa> to allow you to build routing zones any way you like them, even
costa> overlapping.
costa> 
costa> So, to use overlapping interfaces you have to define:
costa> 
costa> policy return
costa> 
costa> within all but the last interface of the overlapping. Even if you give
costa> this policy to all the interfaces in your firewall, traffic not explicitly
costa> matched by server and client statements will be dropped at the end of the
costa> firewall with "IN-unknown" or "OUT-unknown" - so this is not a security
costa> problem.
costa> 
costa> Kind regards,
costa> 
costa> Costa
costa> 
costa> -- 
costa> Costa Tsaousis
costa> 

Yes, you've explained all 3 problems. Many thanks and regards.
--
Jack