From: "Vasilii.Alferov" <Vasilii.Alferov@gmail.com>
To: netfilter@lists.netfilter.org
Subject: Re: philosophical question regarding NAT
Date: Tue, 10 May 2005 17:25:19 +0600 [thread overview]
Message-ID: <d5q590$fsv$1@sea.gmane.org> (raw)
In-Reply-To: 1115723584l.29661l.0l@server.moose.blogdns.org
Ian Laurie wrote:
> I've got a philosophical question regarding NAT as follows.
>
> Imagine the following unrealistic gateway firewall:
>
> ## eth0 = WAN, eth1 = LAN
> *nat
> :PREROUTING ACCEPT [0:0]
> :POSTROUTING ACCEPT [0:0]
> :OUTPUT ACCEPT [0:0]
> -A POSTROUTING -o eth0 -j MASQUERADE
> COMMIT
>
> *filter
> :INPUT ACCEPT [0:0]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [0:0]
> COMMIT
>
> Although NAT is enabled and LAN side systems will be NATed to the
> gateway's WAN side IP address, WAN side systems can still access
> systems on the inside of the firewall if they know what the LAN
> side addresses are (and have a route to the gateway somehow).
>
> In other words, even though NAT is active the bridging function
> provided by ip_forward is still happening as well.
>
> It seems you can disable the bridging function with the following
> PREROUTING rule:
>
> -A PREROUTING -i eth0 -d <private_lan_block> -j DROP
>
> which enforces NAT, ie, only NATed things can get through. While
> you can achieve the same thing by setting policy of FORWARD to DROP
> and allowing only RELATED and ESTABLISHED stuff through (which I do)
> I am surprised I have not seen this PREROUTING rule used more
> often as a safety measure.
>
> It doesn't seem to break anything, does anyone know why this
> technique isn't seen more often?
>
> Ian
More effective solution is to enable rp_filter in kernel using proc
filesystem or sysctl. It prevents anyone from spoofing IP addresses.
Vasilii.
next prev parent reply other threads:[~2005-05-10 11:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-10 11:13 philosophical question regarding NAT Ian Laurie
2005-05-10 11:25 ` Vasilii.Alferov [this message]
2005-05-11 9:12 ` Ian Laurie
2005-05-10 11:26 ` Problem adding connlimit rule Ruben Cardenal
2005-05-10 13:11 ` philosophical question regarding NAT Francesco Ciocchetti
[not found] ` <20050510112649.07D4458F@mail.817west.com>
2005-05-10 13:45 ` Problem adding connlimit rule Jason Opperisano
2005-05-10 22:11 ` philosophical question regarding NAT Taylor, Grant
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='d5q590$fsv$1@sea.gmane.org' \
--to=vasilii.alferov@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox