|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
RE: How should NAT terminate ?
Subject: RE: How should NAT terminate ?
From: Johnny Shelley (syntax
nations.net)
Date: Mon Jan 10 2000 - 18:46:03 CST
- Next message: Rick Smith: "RE: VPN Glossary On Line!"
- Previous message: James R Grinter: "RE: How should NAT terminate ?"
- In reply to: Ben Nagy: "RE: How should NAT terminate ?"
- Next in thread: Darren Reed: "Re: How should NAT terminate ?"
- Next in thread: TC Wolsey: "Re: How should NAT terminate ?"
- Reply: Johnny Shelley: "RE: How should NAT terminate ?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Mon, 10 Jan 2000, Ben Nagy wrote:
A few minor bones to pick here.
> a) a sequence number guessing genius (assuming you run a sane OS)and
Ok, this would probably actually take some sniffing assuming a decent
sequencing implementation.
> b) lucky enough to get your IP address when they dial up, and
This isn't terribly hard, even without any access, someone attack your
machine with something like ath0 during peak hours and call in before
someone else grabs the session.
> 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).
This assumes your ISP will remove routes and is often not the case,
especially in small mom and pop shops where the network is not much more
complicated than a few servers, a switch, dial-ins and a router. In a
case like that, the server is just going to keep trying to send assuming
the packet got lost along the way
> If you're worried about the new owner of your IP address being EVIL and
> running sniffers and stuff, then you need to make sure that anything that
> you're doing which is sensitive is encrypted. But you do that anyway, right?
> I thought so.
Sadly, this can't always be the case, but it damn well should be.
> 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.
Well..
> 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.
This is the cute part.. the far end may very well still have the
connection in an open state. I bumped into this playing around with ircd
(I know its an ugly habit). It was actually fairly simple to send a
sequence of commands to the server for up to the ping timeout limit the
server/client had set.
By tearing down the connection without killing the session, I could dial
in from a totally different ip address and have a (one sided) session. My
machine seemed happy to 'spoof' packets from the old ip as it had never
torn down the connection. Of course it never recieved any responses, but
you know what you want to do, right?
johnny
---
"They called me mad, and I called them mad, and damn them, they outvoted me."
-- Nathaniel Lee, on being consigned to a mental
institution, circa 17th century.
- Next message: Rick Smith: "RE: VPN Glossary On Line!"
- Previous message: James R Grinter: "RE: How should NAT terminate ?"
- In reply to: Ben Nagy: "RE: How should NAT terminate ?"
- Next in thread: Darren Reed: "Re: How should NAT terminate ?"
- Next in thread: TC Wolsey: "Re: How should NAT terminate ?"
- Reply: Johnny Shelley: "RE: How should NAT terminate ?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
This archive was generated by hypermail 2b27 : Wed Jan 12 2000 - 22:13:11 CST