From: Ramin Dousti <ramin@cannon.eng.us.uu.net>
To: Elver Loho <kernelpenguin@hot.ee>
Cc: netfilter@lists.netfilter.org
Subject: Re: Possible dangerous flaw in the NAT howto
Date: Sun, 22 Jun 2003 16:12:43 -0400 [thread overview]
Message-ID: <20030622201243.GB25892@cannon.eng.us.uu.net> (raw)
In-Reply-To: <20030622024450.19E60105939@hot.ee>
Doesn't the whole story here imply IP-IP tunneling from two "well"-defined
interfaces? Even if my MASQing firewall had IP-to-IP capability, if I had
received such a packet from an arbitrary host, it would have been dropped.
Or maybe I didn't read this email correctly?
Ramin
On Sun, Jun 22, 2003 at 05:44:49AM +0300, Elver Loho wrote:
> I was on #netfilter (irc.freenode.net) earlier and asked about a possible flaw in the NAT howto, but got no reply (people sleeping?) so I'm just going to paste what I said here and go to sleep. (nearing 6am currently)
>
>
> <elver> I have a question about masquerading. The NAT howto gives an example like this: "iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE", but since it masks the packets that are outgoing on ppp0 (by the destination IP, interface IP and netmask) then could that rule also be exploited by outside hosts tunneling?
> <elver> For example, we have host A on subnet where the gateway to the internet is B (running that same rule) and then there are external hosts on the internet C and D. A's packets to C and D are masq'ed by B, but can't C and D also use B as a IP-level proxy to communicate to eachother?
> <elver> Over LAN the routing is done on the ethernet level usually, but over the internet this could possibly done by IP encapsulation (RFC 2003 and RFC 1853)
> <elver> Coming back to the example, C tunneling through B to D would look something like [ IP layer: from C to B [ IP layer: from C to D [ TCP layer [ Data ] ] ] ]
> <elver> RFC 2003 does however define that if the source IP is the same as any interface on itself, then it should drop it. So therefore, C can't fake the address part to be B. However, with masquerading, it would NAT the connection and thus to D it would appear as if the data was coming from B.
> <elver> Since Netfilter does NAT in the POSTROUTING table, then it only cares about the outgoing interface, which would be ppp0 or whatever your internet link might be.
> <elver> The problem would be delivering the packet to B so that B would think that it is outgoing on it's internet link.
> <elver> Since routing is done at a higher layer (Ethernet layer above the IP layer for example) then IP encapsulation could possibly used to deliver it to host B.
> <elver> The quick and dirty masquerading part of the NAT howto at netfilter.org (http://www.netfilter.org/documentation/HOWTO//NAT-HOWTO-4.html#ss4.1) does not build any safeguards against this.
> <elver> Sensible way would be denying all forwarding requests coming in over the internet link.
> <elver> Potentially this could mean that there are hundreds of Linux gateways out there that could be used as anonymous proxies.
> <elver> Funny. The Masquerading Simple Howto (http://www.linuxdocs.org/HOWTOs/Masquerading-Simple-HOWTO/summary.html) DOES address that specific security hole by adding "iptables -A FORWARD -i eth0 -o eth0 -j REJECT".
> <elver> So I would say that anyone using just netfilter.org howto could be vulnerable. (http://www.netfilter.org/documentation/HOWTO//NAT-HOWTO-4.html#ss4.1)
>
>
> This inconsistency between howtos was pointed out by Peter Johansson (x-g@gamleby.net) when he was looking for docs while setting up his Linux gateway. I did the additional research into the subject.
>
>
> Elver Loho
> kernelpenguin@hot.ee
>
> -----------------------------------------
> Hot Mobiil - helinad, logod ja piltsõnumid!
> http://portal.hot.ee
>
next prev parent reply other threads:[~2003-06-22 20:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-22 2:44 Possible dangerous flaw in the NAT howto Elver Loho
2003-06-22 10:49 ` Cedric Blancher
2003-06-22 20:12 ` Ramin Dousti [this message]
2003-06-24 17:10 ` Harald Welte
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=20030622201243.GB25892@cannon.eng.us.uu.net \
--to=ramin@cannon.eng.us.uu.net \
--cc=kernelpenguin@hot.ee \
--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