It shouldn't. The TCP sequence number *should* be cryptographically strong. (As opposed to the IP ID number which is usually incremental). It is "strong" in the sense that, even if I make 100 connections to a host, and watch which sequence numbers it uses (and even of those are 100 consecutive connections), I SHOULD NOT be able to predict the next sequence number it uses. nmap -O -v is a good guage of this. Early Windows kernel are apparently really bad ... something like incremental TCP Seq numbers ...
Justin On Thu, Jul 24, 2003 at 09:14:03PM +0000, Stuart wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Thanks for clearing that up, > I remember reading an article a while back about sending frequent > spoofed ARP packets to receive packets but have been unable to locate > the article. You can specify your own Mac address on some network > cards in windows now, if this was set wouldn't this prevent proper > communications between hosts? > Such as A sending a SYN packet > B replying with SYN/ACK > And C (change MAC) replying with FIN > Will this cause the connection to close preventing connectivity? > > Thanks > > Stu > > > - -----Original Message----- > From: David Gillett [mailto:[EMAIL PROTECTED] > Sent: 24 July 2003 17:39 > To: 'Stuart'; [EMAIL PROTECTED] > Subject: RE: ARP Spoof Question > > A switch should *always* be learning. A destination MAC > address should always fall into one of two categories: > > 1. I have it in my switch table (NOT *ARP*, per se), because > I saw traffic from it on interface X within the last N time-units. > > 2. It's not in my tables -- send this packet to every port and > assume we'll see a packet from it soon so it will get added to > my switch table. > > Switch table entries could get created when ARP response packets > are seen -- or ARP requests, or DHCP broadcasts, or .... > > David Gillett > > > > -----Original Message----- > > From: Stuart [mailto:[EMAIL PROTECTED] > > Sent: July 23, 2003 16:13 > > To: [EMAIL PROTECTED] > > Subject: RE: ARP Spoof Question > > > > > > If we use a Cisco switch for example, don't they have a > > learning period? > > I would presume that the switch would go through the process > > of building > > its ARP tables again. > > > > Stu > > > > -----Original Message----- > > From: Simon Gray [mailto:[EMAIL PROTECTED] > > Sent: 23 July 2003 17:10 > > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Subject: Re: ARP Spoof Question > > > > >Q1.My Question is, Node C will also reply to that request of > > Node A. SO > > >now Node A has 2 different MAC for the same IP. How is Node > > A handling > > >this situation??? > > >Q2.The switch also updates its table of IP/MAC address > > bindings, so how > > >is switch handling this situation??? > > >Is it 'first-come-first-serve' methodology which Node > > A/Switch takes??? > > > > I don't know how correct this is, but I would of thought the Node > > A/Switch > > would update whatever stored record of IP/MAC it has with the new > > details. > > > > Simon > > > > > > -------------------------------------------------------------- > > ---------- > > --- > > -------------------------------------------------------------- > > ---------- > > ---- > > > > > > > > -------------------------------------------------------------- > > ------------- > > -------------------------------------------------------------- > > -------------- > > > > -----BEGIN PGP SIGNATURE----- > Version: PGP 8.0.2 > > iQIVAwUBPyARjZMRMj30dWmZAQIQVw//Z/h3UPG4X3eg29UGr9OChIXHQj+bc90j > 5WLIXXZ9ec5yBHCkqqz6wjbY1foUmqzAsVakjnSLjidy7LyRbJhTLTJsopp9s92B > L/hMh4HxLEBuHe7L5hMh5KKAsldeorycF0S/Sgfjm/5DRkL2xpSfqtJQttSqPMrL > jxWn2EF5vbaRKUX/CsGPWKPKSnwZ85zaYxWUIatM3uyiotaeDsYdzgupKOHdqaHm > FxUT4qKINE5z2kXuUBUyOiypwd/FgabPmy6bg5IV9wLthfQCSUpnjqe2ObwWmaCT > JkWFtBpn3lWBy2qwNahFrzSdPVTDJ6Mo+Hjb6ZAfGvGqVoz99VdR+7zpJaoMC9mD > 6aQRWkgZrxJKYzgXLxhxAdliOa/ovTGaz1y0bv1hfjuuvRPuwjdpT7DcpOwscQNY > kBlCfkhuzJ1gD2A0PE62iDdUdnJeBPWVUVAKRkPQfV1d9k2J5k6UxYxfQPbO4ZfM > NVnR1RszjLl38eTeQpq3uD0K2BK0vjquOvBh/fZF92W+ctrkfecrubCIl0MC1S9q > RReJqjGxxj7qZs/sCtrKZt+3T7ahSkuMuvlYwcEw4UBnPpDtl0iacabVZjHuu+lE > 3uD+UAxbRaNxG+fX7IOQNQy0LvJgx9Zg2G2pTsrNLUawpNOAT6Y/z4Zb00Fgu9xU > 8UgW8toGn20= > =/E3X > -----END PGP SIGNATURE----- > > > --------------------------------------------------------------------------- > ---------------------------------------------------------------------------- > --------------------------------------------------------------------------- ----------------------------------------------------------------------------
