From owner-freebsd-pf@FreeBSD.ORG Thu Aug 7 16:02:39 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9998A1065672 for ; Thu, 7 Aug 2008 16:02:39 +0000 (UTC) (envelope-from freebsd@optiksecurite.com) Received: from tomts18-srv.bellnexxia.net (tomts18.bellnexxia.net [209.226.175.72]) by mx1.freebsd.org (Postfix) with ESMTP id 491A28FC28 for ; Thu, 7 Aug 2008 16:02:39 +0000 (UTC) (envelope-from freebsd@optiksecurite.com) Received: from toip40-bus.srvr.bell.ca ([67.69.240.41]) by tomts45-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20080807151100.HMEH13316.tomts45-srv.bellnexxia.net@toip40-bus.srvr.bell.ca>; Thu, 7 Aug 2008 11:11:00 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEynmkhKD7BS/2dsb2JhbACtA0M Received: from mtrlpq02-1242542162.sdsl.bell.ca (HELO [69.69.69.183]) ([74.15.176.82]) by toip40-bus.srvr.bell.ca with ESMTP; 07 Aug 2008 11:10:59 -0400 Message-ID: <489B1049.9000002@optiksecurite.com> Date: Thu, 07 Aug 2008 11:10:01 -0400 From: FreeBSD User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Tom Huppi References: <20080807101825.GC10818@huppi.com> In-Reply-To: <20080807101825.GC10818@huppi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-pf@freebsd.org Subject: Re: syn flood, tcpdump readings X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2008 16:02:39 -0000 Tom Huppi a écrit : > I have been using 'pf' for about 8 months now, and it has been > rock solid and a real pleasure to use. I built it into: FreeBSD > 6.3-PRERELEASE (PEO2) #2: Mon Dec 10 19:45:05 PST 2007. I've > not wished to re-start PF for 7 months since it is doing live > traffic and I didn't do a pfsync implementation (won't make that > mistake again and am working on such a solution now.) > > I am makeing high use of the load balancer and it is extreamly > useful to us. > > My gateway host acts as a simple router with three physical > interfaces, but I only filter on the interface connected to my > provider (set skip on { lo0 em0 bce1 }). > > Anyway, I am getting what I believe to be syn floods > periodically. They dwarf my production traffic and sometimes > get close to producing as much bandwith as we are paying for. A > representative sample looks like so when viewed with tcpdump on > my outward interface ('em1'): > > 21:36:53.870312 IP 125.21.176.19.x11 > 74.123.192.195.domain: S 27394048:27394048(0) win 16384 > 21:36:53.870319 IP 125.21.176.19.x11 > 74.123.192.204.domain: S 1793916928:1793916928(0) win 16384 > 21:36:53.870325 IP 125.21.176.19.x11 > 74.123.192.190.domain: S 1669070848:1669070848(0) win 16384 > 21:36:53.870369 IP 125.21.176.19.x11 > 74.123.192.185.domain: S 601948160:601948160(0) win 16384 > 21:36:53.870371 IP 125.21.176.19.x11 > 74.123.192.166.domain: S 1129906176:1129906176(0) win 16384 > 21:36:53.870373 IP 125.21.176.19.x11 > 74.123.192.179.domain: S 1231945728:1231945728(0) win 16384 > 21:36:53.870375 IP 125.21.176.19.x11 > 74.123.192.171.domain: S 1524105216:1524105216(0) win 16384 > 21:36:53.870377 IP 125.21.176.19.x11 > 74.123.192.26.domain: S 1212678144:1212678144(0) win 16384 > 21:36:53.870381 IP 125.21.176.19.x11 > 74.123.192.195.domain: S 27394048:27394048(0) win 16384 > 21:36:53.870383 IP 125.21.176.19.x11 > 74.123.192.204.domain: S 1793916928:1793916928(0) win 16384 > 21:36:53.870385 IP 125.21.176.19.x11 > 74.123.192.190.domain: S 1669070848:1669070848(0) win 16384 > 21:36:53.870396 IP 125.21.176.19.x11 > 74.123.192.185.domain: S 601948160:601948160(0) win 16384 > 21:36:53.870403 IP 125.21.176.19.x11 > 74.123.192.166.domain: S 1129906176:1129906176(0) win 16384 > 21:36:53.870409 IP 125.21.176.19.x11 > 74.123.192.179.domain: S 1231945728:1231945728(0) win 16384 > 21:36:53.870416 IP 125.21.176.19.x11 > 74.123.192.171.domain: S 1524105216:1524105216(0) win 16384 > 21:36:53.870422 IP 125.21.176.19.x11 > 74.123.192.26.domain: S 1212678144:1212678144(0) win 16384 > > > I run 'pfstat' and here is a representative chart showing > bandwidth. The chart of packets almost completely obscures real > traffic since the syn packets are small: > > http://www.huppi.com/t/tmp/pfstat_2days.png > > > My confusion is that my charts show outgoing traffic matching > incomming traffic, but I see no outgoing with tcpdump. My > uplink is Gig ethernet rate-limited by my network provider. I > think perhaps the outgoing traffic is something other than TCP, > but I wanted to ask on this list since I couldn't spot an answer > in surfing around and network stuff is really not my area of > expertise. > > My fear is that I actually am responding in some manner to these > packets and either inviting more of these attacks, or worse, > allowing my service to attack other people (say if the incomming > IP was spoofed to an attack target.) > > --- > > A slightly less important question is whether attacks like this > are 'par for the course' and expected, and how bad they can > get. I do fear that at an inopertune time I will recieve an > attack which consumes all of my bandwith and causes performance > issues for my real traffic. (I'm developing more faith in > PF's ability to handle things...so far I see no degradation > whatsoever durring these attacks.) > > > My typical rules look like so: > > pass proto tcp from any to port $tase_int_ports flags S/SA synproxy state > > and I really only notice attacks after I started using > 'synproxy'. Whether I had them prior and just didn't notice, I > am not sure. I've not used any of the 'max-*' stuff because I > don't fully understand the problem and issues, and I am using a > somewhat dated codebase. > > --- > > Thanks for any thoughts, hints, pointers, etc. > > - Tom > Hi, I think that you should look at the 'scrub' directive in pf.conf. I think that a 'scrub in all' should block that kind of malformed packets. Martin