From owner-freebsd-net Sun Oct 21 14: 9:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from ns1.via-net-works.net.ar (ns1.via-net-works.net.ar [200.10.100.10]) by hub.freebsd.org (Postfix) with ESMTP id F415837B401 for ; Sun, 21 Oct 2001 14:09:10 -0700 (PDT) Received: from gont.gont.com.ar (ppp238-r5300-cap3.via-net-works.net.ar [200.16.145.31]) by ns1.via-net-works.net.ar (8.9.3/8.9.3) with ESMTP id SAA89208; Sun, 21 Oct 2001 18:09:29 -0300 (ART) Message-Id: <4.3.2.7.2.20011021061340.00d8bc80@mail.sitanium.com> X-Sender: ingroupcomar-fgont@mail.sitanium.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 21 Oct 2001 06:26:32 -0300 To: Mike Silbersack From: Fernando Gont Subject: Re: SYN flood and IP spoofing Cc: freebsd-net@freebsd.org In-Reply-To: <20011020140704.R63640-100000@achilles.silby.com> References: <4.3.2.7.2.20011020101858.00d984e0@mail.sitanium.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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