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 (one is an acknowledgement number and one is the sequence number) so if your TCP stack was told to misbehave and not send out a TCP RST, you could quite happily resume the other connection by either using a user TCP program or hacking the kernel in such a way that you could take advantage of this situation. Someone replied with a reference to a phrack article about this subejct, so assume that hacks/programs exist on the Internet to do exactly this. In fact, depending on the timeline of events between you loosing the connection and an attacker trying to pick up the connection from a broken dialup session, it is possible that any attempts by the original NAT box to terminate sessions will be ignored due to incorrect TCP sequence numbers. > b) lucky enough to get your IP address when they dial up, and This isn't necessarily a personal problem. > 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. > Your NAT sessions will all die horribly and will need to be re-established. > You cannot pick up an old TCP session with a new IP address. This is a no brainer. However, whilst the firewall knows this, the PC which just made a web connection to wwww.idont.care doesn't and still thinks it has a TCP connection to it and will leave it open, incorrectly hoping for some action. > One final note: Once you get the new IP address there's nothing you can do > to close down those old sessions - the stack at the remote end won't accept > RSTs from you since you've now got a new IP address and aren't part of the > old session. 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. Darren
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:57:07 PDT