Date: Sun, 21 Oct 2001 06:26:32 -0300 From: Fernando Gont <fernando@gont.com.ar> To: Mike Silbersack <silby@silby.com> Cc: freebsd-net@freebsd.org Subject: Re: SYN flood and IP spoofing Message-ID: <4.3.2.7.2.20011021061340.00d8bc80@mail.sitanium.com> In-Reply-To: <20011020140704.R63640-100000@achilles.silby.com> References: <4.3.2.7.2.20011020101858.00d984e0@mail.sitanium.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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: fernando@gont.com.ar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.3.2.7.2.20011021061340.00d8bc80>