[Nelug] Re: [general] iptables doing unwanted logging

[Richard Mortimer - Volume Systems Products]

On Tue, 2003-08-12 at 14:31, James Barton wrote:
> Chris Burton said:
> >> Now I think they should have been caught by this rule (the variables for
> >> the name and the IP address do have the right values):
> >>
> >> $IPTABLES -A INPUT -i $EXTERNAL_IF_1 -p TCP -s $ANYWHERE -d
> >> $EXTERNAL_IP_1
> >> --dport 20:24 -j ACCEPT
> >>
> >> and hence not logged. What have I missed?
> >>
> >
> > You have these lines ..
> > #echo -e "Denying UDP, except DNS."
> > $IPTABLES -A INPUT -i $EXTERNAL_IF_1 -j LOG
> >
> > Which might be catching it, I havnt looked too close but thats a first
> > guess.
> 
> Dead right, thanks Chris. Might have worked it out if I'd grepped for
> 'LOG' instead of 'log', or thought that SSH might be over UDP. Silly me.

Ok so you found the problem but note that whilst the echo may say about
Denying UDP the LOG rule does nothing to log only UDP. ssh is done over
tcp.


A few other comments - hope you don't mind...

Disclaimer - I'm no expert and am willing to learn if you (or others)
think that that I'm talking bull***t.


why do you set the default of FORWARD to ACCEPT by default? That sounds
like it opens up the possibility of allowing all sorts through if you
get a rule wrong.

Using -d $ANYWHERE and -s $ANYWHERE aren't necessary because iptables
defaults to these if you don't provide them. Having them there just
makes the rule harder to read. i.e. allow loopback  could be specified
as

$IPTABLES -A INPUT -i lo -j ACCEPT


Not sure on the answer to this but on the 
#echo -e "Dropping other traffic to ports < 1024, monitor worm"
rules you explictly state -i and -d. Doesn't that create a potential
loophole because something targetted to a different -d which ends up on
your input chain could cause trouble. i.e. your config doesn't
explicitly say whether you've configured your IP stack to accept input
on a different interface i.e. if I create an IP packet to your internal
address but send it via the external address (I know that you've caught
that earlier) then this rule wouldn't apply. Surely it is better to be
more general and deny more unless you have a specific reason for not
doing so.

You have a rule

# allow all else
$IPTABLES -A INPUT -i $EXTERNAL_IF_1 -s $ANYWHERE -d $EXTERNAL_IP_1 -j
ACCEPT

which *totally* makes the next established connections rule totally
pointless. I'm not sure that this is what you meant.


Forward chain - you explicitly state both external and internal
interfaces on the forward rules. If anyone manages to spoof routes this
would end up being explicitly allowed by the global  FORWARD accept
rule. I think that you would be better off with something like

$IPTABLES -A FORWARD -i $EXTERNAL_IF_1 -o $INTERNAL_IF_1 -d
$INTERNAL_NET_1 -m state --state ESTABLISHED,RELATED -j ACCEPT

Side note that the next rule undoes all of the work that you have done
in the rule above 'cos it allows everything else through!



Finally being totally paranoid I would probably configure the adbust and
worry chains prior to putting them onto a chain to stop race conditions
of people trying to circumvent them whilst the rest of the rules are
being processed.


Hope this helps.

Richard

-- 
Richard Mortimer               |  Email: Richard.Mortimer at sun.com
Sun Microsystems Inc.          |  Phone: +44 (0)1207 585514 (x10614)
Medomsley Road, Consett,       |  Fax:   +44 (0)1207 585592
Co. Durham, DH8 6TJ, UK.       |