From owner-freebsd-current@FreeBSD.ORG Sun Aug 20 23:28:32 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BDD7D16A4DD for ; Sun, 20 Aug 2006 23:28:32 +0000 (UTC) (envelope-from dwoolworth@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id A040143D49 for ; Sun, 20 Aug 2006 23:28:27 +0000 (GMT) (envelope-from dwoolworth@gmail.com) Received: by nf-out-0910.google.com with SMTP id n29so1956012nfc for ; Sun, 20 Aug 2006 16:28:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=kOdL3ymyiwIpB4z6rIxhrCc52ahZWxyYsJZt3EZKMFJmDyiY1uKnUh6E18oNHbQstkhBggM+i2aGKg6dbwY4mU20MaayJ61+7zoY17I5F0XKtST0249ofUIefTV0CD09Jilb5fIzjgZ22A3F04HfkZbcIxDWimrSAJ+Htt3K524= Received: by 10.49.29.3 with SMTP id g3mr7020462nfj; Sun, 20 Aug 2006 16:28:26 -0700 (PDT) Received: by 10.48.207.16 with HTTP; Sun, 20 Aug 2006 16:28:26 -0700 (PDT) Message-ID: <10fd06c60608201628o51d6a5beof512e907b4d53872@mail.gmail.com> Date: Sun, 20 Aug 2006 18:28:26 -0500 From: "Derrick T. Woolworth" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: SYN Flood X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2006 23:28:32 -0000 I forwarded a message to the security officer about this issue, but I still haven't been able to narrow down whats happening enough to guarantee its just not a bug. I'm running -CURRENT on one server. Our Internet router/firewall is a 6.1-STABLE system running PF, routing two class C's or a /23 subnet actually. I didn't have any trouble until I put the -CURRENT system on our LAN and attempted to make it a router/firewall system. The route is 64.199.142.240/28 => 64.199.142.60, so I'm merely routing a few IP's at the -CURRENT system uname -a FreeBSD mbfw.mb.rndkc.com 7.0-CURRENT FreeBSD 7.0-CURRENT #1: Sun Aug 20 15:29:02 CDT 2006 root@mbfw.mb.rndkc.com:/usr/src/sys/amd64/compile/MBFW amd64 router's ethernet addr: 00:0d:87:e9:c0:40 'vr' driver new -current system's public interface eth addr: 00:16:e6:52:cd:47 'nve' driver After leaving tcpdump running until this happens (which, things run away for 2 to 3 minutes and then stop), I've captured this: 17:42:33.829685 00:0d:87:e9:c0:40 > 00:08:54:b1:45:18, ethertype IPv4 (0x0800), length 60: 81.176.69.92.80 > 64.199.142.47.1490: S 3842711808:3842711808(0) ack 2054160385 win 16384 0x0000: 4500 0028 0100 4000 5b06 b8cd 51b0 455c E..(..@.[...Q.E\ 0x0010: 40c7 8e2f 0050 05d2 e50b 2100 7a70 0001 @../.P....!.zp.. 0x0020: 5012 4000 8330 0000 0715 9e32 ef00 P.@..0.....2.. 17:42:33.831281 00:16:e6:52:cd:47 > 00:08:54:b1:45:18, ethertype IPv4 (0x0800), length 54: 81.176.69.92.80 > 64.199.142.47.1490: S 3842711808:3842711808(0) ack 2054160385 win 16384 0x0000: 4500 0028 0100 4000 5906 bacd 51b0 455c E..(..@.Y...Q.E\ 0x0010: 40c7 8e2f 0050 05d2 e50b 2100 7a70 0001 @../.P....!.zp.. 0x0020: 5012 4000 8330 0000 P.@..0.. 17:42:33.832700 00:0d:87:e9:c0:40 > 00:0e:0c:b1:b4:0c, ethertype IPv4 (0x0800), length 60: 81.176.69.92.80 > 64.199.142.88.1527: S 199865344:199865344(0) ack 1390346241 win 16384 0x0000: 4500 0028 0100 4000 5b06 b8a4 51b0 455c E..(..@.[...Q.E\ 0x0010: 40c7 8e58 0050 05f7 0be9 b400 52df 0001 @..X.P......R... 0x0020: 5012 4000 f095 0000 d443 0000 69d9 P.@......C..i. 17:42:33.833752 00:16:e6:52:cd:47 > 00:0e:0c:b1:b4:0c, ethertype IPv4 (0x0800), length 54: 81.176.69.92.80 > 64.199.142.88.1527: S 199865344:199865344(0) ack 1390346241 win 16384 0x0000: 4500 0028 0100 4000 5906 baa4 51b0 455c E..(..@.Y...Q.E\ 0x0010: 40c7 8e58 0050 05f7 0be9 b400 52df 0001 @..X.P......R... 0x0020: 5012 4000 f095 0000 P.@..... 17:42:33.851227 00:0d:87:e9:c0:40 > 00:50:04:60:34:fd, ethertype IPv4 (0x0800), length 60: 81.176.69.92.80 > 64.199.142.148.1918: S 1499637248:1499637248(0) ack 830603265 win 16384 0x0000: 4500 0028 0100 4000 5b06 b868 51b0 455c E..(..@.[..hQ.E\ 0x0010: 40c7 8e94 0050 077e 5962 a600 3182 0001 @....P.~Yb..1... 0x0020: 5012 4000 d0b6 0000 0050 4f20 0001 P.@......PO... 17:42:33.852111 00:16:e6:52:cd:47 > 00:50:04:60:34:fd, ethertype IPv4 (0x0800), length 54: 81.176.69.92.80 > 64.199.142.148.1918: S 1499637248:1499637248(0) ack 830603265 win 16384 0x0000: 4500 0028 0100 4000 5906 ba68 51b0 455c E..(..@.Y..hQ.E\ 0x0010: 40c7 8e94 0050 077e 5962 a600 3182 0001 @....P.~Yb..1... 0x0020: 5012 4000 d0b6 0000 P.@..... 17:42:33.854137 00:0d:87:e9:c0:40 > 00:04:5f:40:0d:2b, ethertype IPv4 (0x0800), length 60: 81.176.69.92.80 > 64.199.143.232.1656: S 3817299712:3817299712(0) ack 1325531137 win 16384 0x0000: 4500 0028 0100 4000 5b06 b714 51b0 455c E..(..@.[...Q.E\ 0x0010: 40c7 8fe8 0050 0678 e387 5f00 4f02 0001 @....P.x.._.O... 0x0020: 5012 4000 6fc3 0000 0000 0000 0000 P.@.o......... 17:42:33.854177 00:16:e6:52:cd:47 > 00:0d:87:e9:c0:40, ethertype IPv4 (0x0800), length 54: 81.176.69.92.80 > 64.199.143.232.1656: S 3817299712:3817299712(0) ack 1325531137 win 16384 0x0000: 4500 0028 0100 4000 5906 b914 51b0 455c E..(..@.Y...Q.E\ 0x0010: 40c7 8fe8 0050 0678 e387 5f00 4f02 0001 @....P.x.._.O... 0x0020: 5012 4000 6fc3 0000 P.@.o... 17:42:33.854338 00:0d:87:e9:c0:40 > 00:04:5f:40:0d:2b, ethertype IPv4 (0x0800), length 60: 81.176.69.92.80 > 64.199.143.232.1656: S 3817299712:3817299712(0) ack 1325531137 win 16384 0x0000: 4500 0028 0cb6 0000 5806 ee5e 51b0 455c E..(....X..^Q.E\ 0x0010: 40c7 8fe8 0050 0678 e387 5f00 4f02 0001 @....P.x.._.O... 0x0020: 5012 4000 6fc3 0000 03f3 e59a 3200 P.@.o.......2. 17:42:33.854365 00:16:e6:52:cd:47 > 00:0d:87:e9:c0:40, ethertype IPv4 (0x0800), length 54: 81.176.69.92.80 > 64.199.143.232.1656: S 3817299712:3817299712(0) ack 1325531137 win 16384 0x0000: 4500 0028 0cb6 0000 5606 f05e 51b0 455c E..(....V..^Q.E\ 0x0010: 40c7 8fe8 0050 0678 e387 5f00 4f02 0001 @....P.x.._.O... 0x0020: 5012 4000 6fc3 0000 P.@.o... I'm watching this on the -current system's public interface and on the router's LAN facing interface. I suppose the first odd thing is why or how is my switch is showing the -current system's public/LAN facing interface this SYN packet that isn't destined for it. Even worse, however, is the -current's nve interface duplicates these packets - and where is the 81.176.69.92 IP address coming from? The packets occur often and from different IP addresses. I can't tell if the first SYN packet in is actually valid or not, but since these max out a 100mb connection, you can imagine that our main firewall/router's LAN interface is maxing out the CPU (swi1: net has used 545 hours of CPU time and irq23: vr0 588 hours). The -current system is similar with the nve driver. Has anyone seen this kind of behavior? Do I have some kind of weird viral thing happening or a switch problem? The switch has been really stable for us - a Cisco 4003 with 68 ports... I just haven't seen anything like this before - getting a SYN flood from all kinds of addresses and yet if I watch the public router/firewall interface, I only have outbound packets from the network. Sorry if I'm posting to the wrong list, but this only started occuring when we added this -current server to our network... I'm just wondering if there could be some odd behavior with the updates to the nve driver? Thanks, D -- Derrick T. Woolworth R&D Technology, LLC. http://www.rndtechnology.com