OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
NFR Wizards Archives: RE: How should NAT terminate ?

RE: How should NAT terminate ?

Subject: RE: How should NAT terminate ?
From: Ben Nagy (bnagycpms.com.au)
Date: Tue Jan 11 2000 - 19:05:22 CST

So, I take it that I did shoot my mouth off. ;)

> -----Original Message-----
> From: Darren Reed [mailto:darrenrreed.wattle.id.au]
> Sent: None
> To: bnagycpms.com.au
> Cc: firewall-wizardsnfr.net
> Subject: Re: How should NAT terminate ?
>
>
> In some email I received from Ben Nagy, sie wrote:
> [...]
> Don't mean to spoil your party, but...
>
> > So, that part is all covered. Nobody can resume your old
> sessions unless
> > they are:
> > a) a sequence number guessing genius (assuming you run a
> sane OS)and
>
> Not needed. The packet received has both sequence numbers in
> it

Oh yeah. Duh. Back to RFC 793 for me. I was thinking of the "normal" session
hijacking attack where you're spoofing IP addresses.

> > b) lucky enough to get your IP address when they dial up, and
>
> This isn't necessarily a personal problem.

OK, leaving aside how likely / unlikely this is, we'll just assume that it
happens.

>
> > c) fast enough so that the packets you're worried about
> don't get bounced in
> > the meantime by the ISP who has just removed the routes to
> that IP address
> > (since you disconnected).
>
> In most cases, the "routes" will be a CIDR block that all terminate on
> the same router, so no special "routes" will have been removed (unless
> you've got your own IS and do stupid things - i.e. dialup). The worst
> that can happen is for ICMP unreachables to be returned by the router,
> which some TCP stacks will suppress for a period of time, hoping that
> the network will fix itself and the unreachable problem will
> disappear.

Well, _somewhere_ there was a directly connected route for your single IP
address, which has now gone away since your connection died, neh? So the
ICMP stuff is almost certainly going to happen. It just depends how long it
takes for the new IP address to get reassigned, and how long the remote
stack ignores them for. I guess that there is no real way for getting from
ESTABLISHED to one of the closing states without getting a RST or FIN, so I
suppose the connection at the remote end hangs around and waits for packets
until it is cleaned up by its own garbage collector.

>

 The only way your pre-emptive strike could
> work is if it were
> > performed before the link dropped - this is likely to be impossible.
>
> You're forgetting that the firewall will more than likely still have a
> record of all the old state information for filters and NAT sessions,
> so generating things with the old IP# is not exactly a problem.

I actually wasn't, I was just simplifying. You can try and forge your old IP
address, but you need to have an ISP that doesn't filter spoofed IP traffic
and you also need to beat your attacker to the punch, otherwise the sequence
number you remebered will have advanced (which you mentioned yourself). This
could suck.

SOOOOOO, I guess to get back to the original question:

It looks to me like the exposure is pretty small. Your IP needs to get
assigned to an attacker with a modified TCP stack within the time that the
remote server is still retransmitting its last packet.

The potential risk is pretty large, if you're using simple protocols like
Telnet or HTTP to do sensitive things. An attacker can jump in on a session
_after_ you've authenticated as you. But then again, there is always the
risk of a blind (or not) hijacking attack, so we shouldn't be doing this
anyway. The attacker will find it much MUCH harder to resume an SSL web
connection, for example.

The sensible behaviour is probably:
If the link is about to be dropped from this end, maybe the firewall could
close() all TCP sessions. This bit is easy. However, this only saves you if
it's the firewall process that calls all the closes and then drops the PPP
(or whatever) connection. So _that_ means that you need to give the control
of your PPP dialer process thingy to the firewall, which makes
implementation klunky.

If the link drops, I don't see much benefit to trying to nuke all your old
connections - you've still got to wait for the modem dialup and
authentication etc etc. By the time that's all done the retransmission has
probably almost finished anyway. In any case, you're quite a ways behind the
attacker who could have gotten your IP address in the time it takes for the
interface to be reset - 3 seconds?

That's ignoring the fact that you need to spoof IP addresses to do it which
may violate your terms of service with some ISPs, get blocked by filters or
otherwise Just Not Work.

>
> Darren

Overall, my general philosohpy remains that IP is Not Secure so if you're
using it to do sensitive stuff without some better protection then you
shouldn't rely on your firewall to save you from yourself. You already know
that there are dozens of points in your packet's path where it could be
sniffed and MitM'ed - why worry about a similar situation which has a very
small time / opportunity window?

And thanks for flaming gently. ;)

Cheers, 

--
Ben Nagy
Network Consultant, CPM&S Group of Companies
PGP Key ID: 0x1A86E304  Mobile: +61 414 411 520

This archive was generated by hypermail 2b27 : Fri Jan 14 2000 - 04:14:55 CST