From: Alistair Tonner <Alistair@nerdnet.ca>
To: netfilter@lists.netfilter.org
Subject: Re: Policy Misunderstanding: RTFM Guidance Requested.
Date: Wed, 1 Sep 2004 12:53:52 -0400 [thread overview]
Message-ID: <200409011253.52931.Alistair@nerdnet.ca> (raw)
In-Reply-To: <8ca4228204090109202271a1da@mail.gmail.com>
On September 1, 2004 12:20 pm, Mike wrote:
> Hi Alistair,
>
<SNIPPAGE>
>
> This comment pricks up my ears/eyes. Why is this so, and do you have
> links to discussions on this topic.
Prowl back through the lists -- there are several discussions on the issue.
In the case of large scale firewalls there may be some call for using
mangle and nat to do filtering but its not really a good idea, since you then
need to build rules to let things through mangle and nat.
>
> > 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
> > > $IPTABLES -t filter -P FORWARD 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
> lockdown.
>
> > > $IPTABLES -t nat -P PREROUTING DROP
> > > $IPTABLES -t nat -P POSTROUTING DROP
> > > $IPTABLES -t nat -P OUTPUT DROP
> > > $IPTABLES -t mangle -P INPUT DROP
> > > $IPTABLES -t mangle -P OUTPUT DROP
> > > $IPTABLES -t mangle -P FORWARD DROP
> > > $IPTABLES -t mangle -P PREROUTING DROP
> > > $IPTABLES -t mangle -P POSTROUTING 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.
You now have to put in ACCEPT rules to get things through. This gets
complicated by the fact that functionality changes in mangle and nat.
Better to let things through the mangle and nat tables, and do filtering in
the filter table. There have been folks who like to drop things in the
mangle and nat tables, but setting actual DROP policies makes life very
difficult.
> > > 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
> > > ESTABLISHED,RELATED -j ACCEPT
> >
> > 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
> > > ACCEPT
> >
> > 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.
There is no definition of the SOURCE that you want to drop ICMP echorequests
from. Thus this rule drops all ping echorequests.
iptables -t filter -A INPUT -p icmp -i [internet pipe device] -icmp-type \
echo-request -j DROP
will allow your LAN users to ping the box, but prevent pings from the
internet from getting in.
Really and truely -- Oskar's tutorials are great and easy to read... and even
the sample firewalls there are decent enough to start with for a newbie.
Alistair Tonner
>
> Thanks again for your thoughtful response.
> I'd hope you can spare some further time to respond.
>
> Mike
next prev parent reply other threads:[~2004-09-01 16:53 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-01 1:01 Mail Server Behind IPTABLES Ajen Diwakar
2004-09-01 4:22 ` George Alexandru Dragoi
2004-09-01 11:54 ` Policy Misunderstanding: RTFM Guidance Requested Mike
2004-09-01 13:27 ` Deepak Seshadri
2004-09-01 15:46 ` Mike
2004-09-01 16:50 ` Jason Opperisano
2004-09-01 17:53 ` Mike
2004-09-01 17:38 ` Deepak Seshadri
2004-09-01 16:40 ` Mike
2004-09-01 14:44 ` Alistair Tonner
2004-09-01 16:20 ` Mike
2004-09-01 16:53 ` Alistair Tonner [this message]
2004-09-01 18:12 ` Mike
2004-09-01 16:43 ` Jason Opperisano
2004-09-01 14:50 ` Mail Server Behind IPTABLES Alistair Tonner
[not found] ` <1094054540.5456.16.camel@matevz.net>
2004-09-01 16:27 ` Alistair Tonner
2004-09-01 18:12 ` Matevz
2004-09-01 18:19 ` Jason Opperisano
2004-09-01 18:25 ` Jason Opperisano
2004-09-01 18:23 ` Alistair Tonner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200409011253.52931.Alistair@nerdnet.ca \
--to=alistair@nerdnet.ca \
--cc=netfilter@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.