At 14:17 20/10/2001 -0500, Mike Silbersack wrote: > > I've read some explanations about the SYN flood DoS attack. > > I understand that when the attacker fills the listening queue of the > > attacked host with incomplete connections, the attacked host will not > > reply to any SYN it receives after that. >That's an old explanation; basically any OS released in the last few years >will throw old/random connections out of the queue when it fills up.
Anyway, I wonder how the old implementations behaved, and why they behaved like that. >What you actually describe here is more "spoofing" than a syn flood; a >syn flood just involves blasting large numbers of syn packets at someone, >with no intent of actually spoofing a connection. >When Mitnick / anyone else did spoofing, it was through weaknesses in the >algorithm used to generate initial sequence numbers, not through simple >brute force. The attack was a trust relationship exploit, that means, one host trusted the other by its IP address. For exploiting that trust relationship, Mitnick spoofed the trusted-host IP address. But he had to silence the trusted host in some way, and that's why he SYN-flooded it. My point is that he shouldn't have been able to silence the host in that way. I don't see any reason for the old TCP/IP stacks droping a SYN/ACK segment they received just because the listening queue was full. Under normal conditions (i.e., listening queue NOT full), they replied the SYN/ACK with an RST (as they had never sent a SYN). So why should this behavior change when the listening queue is full? >(I'm assuming that's how Mitnick did it; I'm not aware that >he has revealed exactly how he did anything, He didn't do it. It was the owner of the attacked host that revealed it, in a post to comp.security.misc. >and I doubt I'd trust him even if he did explain.) Why? > > However, I don't understand why it will not even reply with an RST > > when it receives a SYN-ACK from other machine. >In the general case of spoofing, you could ensure that a syn-ack does not >elicit a rst by spoofing the IP of a nonexistant host. But in the case I'm talking about, the host did exist. >I've also read that older tcp stacks could be caused to stop emitting >packets by filling their SYN queue; I'm not sure when that stopped applying. Well, that's the point of my question: is there any reason for the stacks to behave like that? Kind regards, Fernando Gont e-mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
