[Nelug] Re: [general] iptables doing unwanted logging
Richard Mortimer - Volume Systems Products
Richard.Mortimer at sun.com
Thu Aug 14 13:16:01 UTC 2003
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
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
$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
You have a rule
# allow all else
$IPTABLES -A INPUT -i $EXTERNAL_IF_1 -s $ANYWHERE -d $EXTERNAL_IP_1 -j
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
Hope this helps.
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. |
More information about the Nelug