Possible dangerous flaw in the NAT howto

Possible dangerous flaw in the NAT howto

[Elver Loho]

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

Re: Possible dangerous flaw in the NAT howto

[Cedric Blancher]

Le dim 22/06/2003 à 04:44, Elver Loho a écrit : 
> <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?

Yes, this kind of rule is not imho strict enough, but I quite disagree
with you on the flaw you describe.

> <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?

As long as C and D are on a locally attached network (i.e. to external
interface) they surely can. Otherwise, I don't think so.

> <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)

Problem is gateway must support IP-IP tunnels, and an appropriate tunnel
as to be configured. If not, packets will probably get dropped. The only
way to realize this I can think of is source routing use, but is barely
not applicable as most routers drop source routed IP.

[...]
> <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.

Providing gateway supports IP-IP tunnel, and is properly configured so B
can use it (see http://lartc.org/howto/lartc.tunnel.ip-ip.html for IP-IP
tunnels configuration), yes, packets can be delivered. Otherwise, you
can't.

1. Gateway does not support IP-IP tunneling

	Gateway receive a packet with protocol filed set to 4 (payload
	is IP). As the gateway has no layer 4 extension to support this
	protocol number, packet gets dropped

	Note that most (not to say all) distribution kernels are build
	with IP-IP tunnel support as module. So, if the box is not
	intentionnaly configured to support them, it won't be likely to.
	Moreover, stock kernel defautl configuration does not include
	IP tunneling support, and so does not include IP-IP.

2. Gateway does support IP-IP tunneling

	2.1 No tunnel is configured with B

		It is likely that packet will be droped as packet cannot
		get associated to an existing interface

	2.2 A tunnel is configured with B

		Then B is likely to be allowed to behave like this ;)


I have not verified this by experience, I do not have the proper setup
right now, but I will.

Therefore, your remark still apply to locally attached external
stations, such as this kind of case :

	A -------- B -------- Internet
			|
			|---- C
			`---- D

C and D are able to get masqueraded though B to the Internet with rule
you describe. To a wider point of vue, allowing routing of packets
through their incoming interface can often lead to flaws. As an example,
it is a basic technic to overcome private VLAN or MAC level ACLs
restrictions. In this cas, it can lead to gateway impersonation.

So, if I agree the fact this rule is weak, I don't think it can be used
by arbitrary hosts on the Internet for impersonation (but can be wrong).


-- 
Cédric Blancher  <blancher@cartel-securite.fr>
IT systems and networks security - Cartel Sécurité
Phone : +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99
PGP KeyID:157E98EE  FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE

Re: Possible dangerous flaw in the NAT howto

[Ramin Dousti]

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
> 

Re: Possible dangerous flaw in the NAT howto

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1310 bytes --]

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?
> [...]

Well, using nat doens't mean that you don't want to use packet filtering
anymore, does it? 

I mean, apart from your MASQUERADE rule you would still have a packet
filtering ruleset in the 'filter' table, just like on any normal non-NAT 
firewall. 

> Elver Loho
> kernelpenguin@hot.ee

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]