Policy Misunderstanding: RTFM Guidance Requested.

Mike 1100100 at gmail.com
Wed Sep 1 18:20:54 CEST 2004

Hi Alistair,

Thanks for the reply.  I appreciate you taking a look and providing comments.
I want to ask you about some of these "Really Bad Thing"(s)

> > It runs Gentoo Linux, kernel 2.4.26 and iptables 1.2.10.
>         Yumm ...Gentoo -- good stuff

Definitely yes.  I switched from Slackware which I will always be fond
of, but Gentoo has so much to offer.  I'll leave it there because one
could write for days about portage and optimizations.

> > I thought I had seen others on this list discuss starting with a
> > completely closed router that denies all traffic - INPUT, OUTPUT, and
> > FORWARD; filter, nat, and mangle.

>         Set POLICY for INPUT OUTPUT and FORWARD to DROP in filter only.
>         If you start setting the POLICY for nat and mangle tables to DROP, things
>         will misbehave badly.  And be hard to debug. -- there are those that
>         disagree, and have success doing things like this but in general and
>         for a home router, it is in many folks eyes a (tm) Really Bad Thing (tm).

This comment pricks up my ears/eyes.  Why is this so, and do you have
links to discussions on this topic.

>         There is a wonderful fellow named Oskar Andreasson who has written a
> wonderful set of tutorials, and even provides some elemental scripts as
> guidelines
>         http://iptables-tutorial.frozentux.net/
>         Read and enjoy

Thanks for pointer.  I've got a Firefox tab open to it right now. 
Looks very good.  Now let's see if I can absorb it.

> >
> > echo "   Enabling forwarding.."
> > echo "1" > /proc/sys/net/ipv4/ip_forward
>         Urk
>           Do this at the *end* of the script. -- just a good habit to NOT turn on
> forwarding until all the rules are loaded to handle it.

That sounds like a very good idea to me.  Noted for edit this evening.

> >
> > echo "   Set the filter/nat/mangle packet Matching Table Policy."
> > $IPTABLES -t filter -P INPUT DROP
> > $IPTABLES -t filter -P OUTPUT DROP
> The above are a (tm) Good Thing (tm)

Yes, this is the kind of thing that I want - start from complete
lockdown, and then open only one thing at a time until I can do
everything that I want on the network and maintain everything else in

> > $IPTABLES -t mangle -P INPUT DROP
> > $IPTABLES -t mangle -P OUTPUT DROP
> In general the above are a (tm) Really Bad Thing (tm)

As previously requested above, why are these policies bad/unworkable?
Any info. and links discussing these iptables fundamentals would be
greatly valued.

> >
> > echo "   INPUT/OUTPUT Rules for Routerbox."
> > $IPTABLES -t filter -A INPUT -j ACCEPT
> > $IPTABLES -t filter -A OUTPUT -j ACCEPT
> Uhhh ... I hope these are only here because yer having problems --
>    These above two rules are a (tm) Really Bad Thing (tm)
>         (they basically allow everything in and out -- *ouch*)

You got it.  This is the rule of a man willing to submit his machines
to a world of hostility in a desperate attempt to get
some-packet/any-packet  through the routerbox.

> >
> > echo "   FORWARD Rules for data allowed IN and OUT of the LAN."
> > $IPTABLES -t filter -A FORWARD -i eth0 -o eth1 -m state --state
> Repeat the above rule for filter INPUT

Ahh, I see what you are getting at.  Will do.

> > $IPTABLES -t filter -A FORWARD -i eth0 -o eth1 -m state --state NEW -j
> The above rule is a (tm) Really Bad Thing (tm)
>         (basically allows everything into yer lan *ouch*)

Indeed, you are witnessing further desperation after hours of
scratching my head and muttering to myself.  :-)

> >
> > echo "   Do not respond to remote Pings."
> > $IPTABLES -t filter -A INPUT -p icmp --icmp-type echo-request -j DROP
> Umm .. You *might* want to set this to deny ping requests from the outside,
> rather than dropping them all .. .unless you don't trust users on the inside.
> *grin*

I'm not quite sure I follow here.  How does this affect users behind
the firewall on the home LAN.

Thanks again for your thoughtful response.
I'd hope you can spare some further time to respond.


More information about the netfilter mailing list