Linux Netfilter discussions
 help / color / mirror / Atom feed
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.



  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