So, I take it that I did shoot my mouth off. ;) > -----Original Message----- > From: Darren Reed [mailto:darrenrat_private] > Sent: None > To: bnagyat_private > Cc: firewall-wizardsat_private > 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 2b30 : Fri Apr 13 2001 - 13:57:13 PDT