From owner-freebsd-hackers Fri Sep 13 02:58:45 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA09794 for hackers-outgoing; Fri, 13 Sep 1996 02:58:45 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA09786 for ; Fri, 13 Sep 1996 02:58:42 -0700 (PDT) Received: from whale.gu.kiev.ua (whale.gu.kiev.ua [193.124.51.77]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id CAA12599 for ; Fri, 13 Sep 1996 02:55:13 -0700 (PDT) Received: from creator.gu.kiev.ua (stesin@creator.gu.kiev.ua [193.124.51.73]) by whale.gu.kiev.ua (8.7.5/8.7.3) with SMTP id MAA44164; Fri, 13 Sep 1996 12:32:01 +0300 Date: Fri, 13 Sep 1996 12:32:26 +0300 (EET DST) From: Andrew Stesin X-Sender: stesin@creator.gu.kiev.ua To: Michael Dillon cc: firewalls@greatcircle.com, freebsd-hackers@freebsd.org Subject: Re: SYN floods - possible solution? (fwd) In-Reply-To: Message-ID: X-NCC-RegID: ua.gu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Date: Thu, 12 Sep 1996 23:33:39 -0700 (PDT) > From: Michael Dillon > > Now here is something that could be used by sites to protect against SYN > flood attacke assuming that they can build a special custom box with > enough RAM to buffer the sockets for 30 seconds or more. How high a rate > can SYN floods come in at? I think ICMP-based solutions won't work. But assume the following: we take a PC with a plenty of RAM and customized BSD kernel, which works as a packet filter. What we can do with it -- we T can teach it to do "spoofing+buffering" of TCP handshakes for i a whole network behind it. The following chain of events will m take place in time: e | ------------------- "Acting persons" -------------------------- | | Client "Spoofer" Protected V (attacker?) firewall server 1. Sends SYN to protected Queues SYN as it Knows nothing :) server. was destined to it (just to another queue?) Sends SYN/ACK to client claiming to be a server, sets a timeout to wait for responce. #if (client is valid) 2. Continues with TCP Sends SYN to server, Gets 1st SYN connection. claiming to be a client. sends SYN/ACK to client. 3. Waits Silently "eats" SYN/ACK Waits server sent, caches connection as "valid,established" for passing it through later on. Passed continuation packet to server. 4. Works as usual Passed valid connection Works as usual through. #else /* SYN/flood attack -- queue timeout expired */ 2'. ??? (who cares?) Drops bad SYN away Still knows nothing #endif How to implement this? I'm just starting to check out exactly this, but as far as I know, Darren Reed's latest IPfilter is able to do some really sophisticated filtering, and (!) is able today to pass packets to an external user-space program. Some time coding that external program for your pet FreeBSD box -- and you may even store all that nasty-SYNs to a disk queue file! 8-) (Berkeley DB comes to mind -- very suitable for the purpose!) > I've heard of 1,000 per sec which implies that > this box needs to hold open 30,000 to 75,000 potential sockets. Is there > any problem within IPv4 (seq #'s?) that would make this inherently > impossible? 200MHz P5, 2 PCI NICs, 256+ Mb RAM, fast SCSI disk subsystem, + intelligent OS with intelligent packet filter. That's a today's firewall of choice for many people, anyway. What do you people think? This should (might?) work... > > Michael Dillon - ISP & Internet Consulting > Memra Software Inc. - Fax: +1-604-546-3049 > http://www.memra.com - E-mail: michael@memra.com > Best, Andrew Stesin