From owner-freebsd-ipfw@FreeBSD.ORG Mon Sep 23 11:06:46 2013 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CEBD0BFE for ; Mon, 23 Sep 2013 11:06:46 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BBC562138 for ; Mon, 23 Sep 2013 11:06:46 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r8NB6kHe069487 for ; Mon, 23 Sep 2013 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r8NB6kSs069485 for freebsd-ipfw@FreeBSD.org; Mon, 23 Sep 2013 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 23 Sep 2013 11:06:46 GMT Message-Id: <201309231106.r8NB6kSs069485@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 11:06:47 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/180731 ipfw [ipfw] problem with displaying 255.255.255.255 address o kern/180729 ipfw [ipfw] ipfw nat show empty output o kern/178482 ipfw [ipfw] logging problem from vnet jail o kern/178480 ipfw [ipfw] dynamically loaded ipfw with a vimage kernel do o kern/178317 ipfw [ipfw] ipfw options need to specifed in specific order o kern/177948 ipfw [ipfw] ipfw fails to parse port ranges (p1-p2) for udp o kern/176503 ipfw [ipfw] ipfw layer2 problem o kern/169206 ipfw [ipfw] ipfw does not flush entries in table o conf/167822 ipfw [ipfw] [patch] start script doesn't load firewall_type o kern/166406 ipfw [ipfw] ipfw does not set ALTQ identifier for ipv6 traf o kern/165939 ipfw [ipfw] bug: incomplete firewall rules loaded if tables o kern/165190 ipfw [ipfw] [lo] [patch] loopback interface is not marking o kern/158066 ipfw [ipfw] ipfw + netgraph + multicast = multicast packets o kern/157689 ipfw [ipfw] ipfw nat config does not accept nonexistent int f kern/155927 ipfw [ipfw] ipfw stops to check packets for compliance with o bin/153252 ipfw [ipfw][patch] ipfw lockdown system in subsequent call o kern/153161 ipfw [ipfw] does not support specifying rules with ICMP cod o kern/152113 ipfw [ipfw] page fault on 8.1-RELEASE caused by certain amo o kern/148827 ipfw [ipfw] divert broken with in-kernel ipfw o kern/148430 ipfw [ipfw] IPFW schedule delete broken. o kern/148091 ipfw [ipfw] ipfw ipv6 handling broken. f kern/143973 ipfw [ipfw] [panic] ipfw forward option causes kernel reboo o kern/143621 ipfw [ipfw] [dummynet] [patch] dummynet and vnet use result o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/135476 ipfw [ipfw] IPFW table breaks after adding a large number o o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l f kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o bin/83046 ipfw [ipfw] ipfw2 error: "setup" is allowed for icmp, but s o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes s kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 45 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Wed Sep 25 17:36:15 2013 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DDF0294F for ; Wed, 25 Sep 2013 17:36:14 +0000 (UTC) (envelope-from netops.admin@epsb.ca) Received: from mail-ob0-f194.google.com (mail-ob0-f194.google.com [209.85.214.194]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A91CB25D3 for ; Wed, 25 Sep 2013 17:36:14 +0000 (UTC) Received: by mail-ob0-f194.google.com with SMTP id gq1so1697705obb.1 for ; Wed, 25 Sep 2013 10:36:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:content-type; bh=nOu9zaQld1aiIDV7k/WgIxfirdnlgqg0T3ZmqI22zdk=; b=NapDVCsKyTTGrtCJuJtc6c9A55bgA25yghxx+Fj0x7/JNFC/P0XQ4okXZUFuKi1Is9 rWY4RumDsXJ+65OPjuqjUsQ/O0lF8tggOzEh44oAi+mc6AntNAGFV+CpCEaXfW4Y68P1 D+TOXZCsHiJ4BcN0WQ77O1fyqVUYTat/yScQ8yAp7vWapKh0QaFwFLmznq9VlVtGw3jL M3n98I00TMqeeU5vv2iOot0qJcoRLD/T38sMRFIrdYh+fZjxMy9XIbGO2pxFSsXlK3DF 8DX7SRN2Ekf8RiJxAbuUoEsJxt99FifDduC7xYa657Nd3t4uyDRweCO2WxmFAgf6770K v9lg== X-Gm-Message-State: ALoCoQlYwPBb6H4sB/Fqhcg1q2cZ0HNx/JfPEss+5nzT6mh7a2wJlEzBFztjNjIns1D3iFl5a+X79MUytaBZ/AhMmAwUTdUZBuGgS0/JIe5jHJC5jQ8Y5qqq0V6qQ16V0mQqjuCaF90E MIME-Version: 1.0 X-Received: by 10.60.60.71 with SMTP id f7mr1287841oer.82.1380129801292; Wed, 25 Sep 2013 10:23:21 -0700 (PDT) Sender: kirk.davis@epsb.ca X-Google-Sender-Delegation: kirk.davis@epsb.ca Received: by 10.60.26.2 with HTTP; Wed, 25 Sep 2013 10:23:21 -0700 (PDT) Date: Wed, 25 Sep 2013 11:23:21 -0600 X-Google-Sender-Auth: TakFFisSisLavmNMYcuWuQYz2kc Message-ID: Subject: stopping an attack (fraggle like) From: NetOps Admin To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 17:36:15 -0000 Hi, We are currently getting hit with a DoS attack that looks very similar to a Fraggle attack. We are seeing a large amount of UDP traffic coming at us from thousands of hosts. The source UDP port is 19 (chargen) and when it hits it consumes a 2Gb/s link. Our main router is a FreeBSD server with ipfw installed. I have tried blocking UDP port 19 incoming from the internet in a firewall rule but the UDP packets are very large and they are followed by a number of fragmented packets. I think that even though I am blocking port 19, the fragmented packets are getting though and eating up the bandwidth. I am a little hesitant of using a UDP deny rule with "keep-state" to try and block the following fragmented packets. I don't want to cause memory issues. Can I use keep-state with a deny rules? Will it have issues if I use keep-state to track thousands of hosts in a saturated 2 Gb/s link? Any ideas on how others are controlling this? Thanks ----- Kirk From owner-freebsd-ipfw@FreeBSD.ORG Wed Sep 25 18:44:26 2013 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 30057213 for ; Wed, 25 Sep 2013 18:44:26 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F02AE2AA9 for ; Wed, 25 Sep 2013 18:44:25 +0000 (UTC) Received: by mail-ob0-f171.google.com with SMTP id wm4so148050obc.30 for ; Wed, 25 Sep 2013 11:44:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=lyfB99ZTgs3c4aCSJ4jutnAGTY+TAfKf3L4k474rXjc=; b=akuqzqn8n4qRNVEBXwJ06svbiDUZTmfUciadWQk+1x6XERlZ34sAzsSqJNqOuOmEDk 0vRZFamuJsGox6eeUEhAizKKDXRGiHd+gDCEdO3onULls3PgpCzNzZpAgBgUynMOnniw m0r6tV/K9jfT8umlCFS5FTsmn8uWlyUEKpjesgxe5PxOSbUy0PzD7qygbZOVaKJi3Uvv OoVC/Du2SCDjD5T6KR60VnPHNOHmEDyD3tiOKEVg0q6IkiTgt33Q+TDsVek7U1ps2j0b jvrsxuARSR1SZvHDsiHvLrPUEA+EDAs++GUsCPEaZUccGwGszN+3hP+xjNOqNuGv540V rpBg== X-Gm-Message-State: ALoCoQn+yXMDc2eGgDSYpSwnF+XI0m5nSpiWUsEDCusqO3x4DuesHItw1upk4G6eyZdSqGn0VOBu MIME-Version: 1.0 X-Received: by 10.60.142.8 with SMTP id rs8mr14510119oeb.34.1380134659229; Wed, 25 Sep 2013 11:44:19 -0700 (PDT) Received: by 10.60.21.69 with HTTP; Wed, 25 Sep 2013 11:44:19 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 Sep 2013 11:44:19 -0700 Message-ID: Subject: Re: stopping an attack (fraggle like) From: Michael Sierchio To: "freebsd-ipfw@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 18:44:26 -0000 I would certainly not use stateful rules. If you can't influence the upstream pipes at all, then your best bet is to used GRED, which is implemented in dummynet. There is a good bit of literature about this, but the tuning of the drop will be empirically determined. Fragmented packets won't contain port numbers anyway, but you could do this ipfw add allow ip from any to any via lo0 ipfw add reass all from any to any in recv $IF_WAN ... don't pass link-local packets through dummynet. - M On Wed, Sep 25, 2013 at 10:23 AM, NetOps Admin wrote: > Hi, > We are currently getting hit with a DoS attack that looks very > similar to a Fraggle attack. We are seeing a large amount of UDP traffic > coming at us from thousands of hosts. The source UDP port is 19 (chargen) > and when it hits it consumes a 2Gb/s link. > > Our main router is a FreeBSD server with ipfw installed. I have > tried blocking UDP port 19 incoming from the internet in a firewall rule > but the UDP packets are very large and they are followed by a number of > fragmented packets. I think that even though I am blocking port 19, the > fragmented packets are getting though and eating up the bandwidth. > > I am a little hesitant of using a UDP deny rule with "keep-state" to > try and block the following fragmented packets. I don't want to cause > memory issues. > > Can I use keep-state with a deny rules? Will it have issues if I use > keep-state to track thousands of hosts in a saturated 2 Gb/s link? > > Any ideas on how others are controlling this? > > Thanks > > ----- Kirk > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Wed Sep 25 18:58:43 2013 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A6AD3672 for ; Wed, 25 Sep 2013 18:58:43 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from st11p05mm-asmtp002.mac.com (st11p05mm-asmtp005.mac.com [17.172.108.250]) by mx1.freebsd.org (Postfix) with ESMTP id 7EDFC2B72 for ; Wed, 25 Sep 2013 18:58:43 +0000 (UTC) Received: from [17.198.198.221] (unknown [17.198.198.221]) by st11p05mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0MTP00GRG0L0Z740@st11p05mm-asmtp002.mac.com> for freebsd-ipfw@freebsd.org; Wed, 25 Sep 2013 17:58:13 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794,1.0.431,0.0.0000 definitions=2013-09-25_08:2013-09-25,2013-09-25,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1308280000 definitions=main-1309250097 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: stopping an attack (fraggle like) From: Charles Swiger In-reply-to: Date: Wed, 25 Sep 2013 10:58:12 -0700 Content-transfer-encoding: quoted-printable Message-id: <68FFEAB0-055E-4BDF-85E5-F5C1EF26B3C1@mac.com> References: To: NetOps Admin X-Mailer: Apple Mail (2.1510) Cc: freebsd-ipfw@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 18:58:43 -0000 Hi-- On Sep 25, 2013, at 10:23 AM, NetOps Admin wrote: > Hi, > We are currently getting hit with a DoS attack that looks very > similar to a Fraggle attack. We are seeing a large amount of UDP = traffic > coming at us from thousands of hosts. The source UDP port is 19 = (chargen) > and when it hits it consumes a 2Gb/s link. OK. You should get your ISP or whatever upstream connectivity provider = to filter out the malicious traffic before it hits your 2Gb/s link. > Our main router is a FreeBSD server with ipfw installed. I have > tried blocking UDP port 19 incoming from the internet in a firewall = rule > but the UDP packets are very large and they are followed by a number = of > fragmented packets. I think that even though I am blocking port 19, = the > fragmented packets are getting though and eating up the bandwidth. Right...filtering this UDP traffic on your side is already too late, = because your bandwidth is already being chewed up. > I am a little hesitant of using a UDP deny rule with "keep-state" = to > try and block the following fragmented packets. I don't want to cause > memory issues. Assuming PMTUD is working, it's not normal to receive any significant # = of fragmented packets over the WAN. Normally you only get them for local = net traffic, ie, NFS using 64K UDP packet size or similar. You can likely drop fragmented UDP traffic entirely, although it won't = help much because your bandwidth is still being used. > Can I use keep-state with a deny rules? Will it have issues if I = use > keep-state to track thousands of hosts in a saturated 2 Gb/s link? I believe yes and no, respectively; on the other hand, doing stateful = tracking of DoS traffic which you want to discard doesn't strike me as very = useful, either. > Any ideas on how others are controlling this? You need to filter the malicious traffic before it hits your pipe, as = much as possible. Your ISP should be willing to help make that happen; on a good day, they = might even try to block ingress of the malicious traffic before it wastes their = resources, rather than just working to filter the last step before your pipe. Regards, --=20 -Chuck From owner-freebsd-ipfw@FreeBSD.ORG Wed Sep 25 21:52:01 2013 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3B765D7D for ; Wed, 25 Sep 2013 21:52:01 +0000 (UTC) (envelope-from netops.admin@epsb.ca) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EC39C2766 for ; Wed, 25 Sep 2013 21:52:00 +0000 (UTC) Received: by mail-vc0-f179.google.com with SMTP id ht10so247441vcb.10 for ; Wed, 25 Sep 2013 14:51:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UOtRBVZl+SciW82urKFGhtuliU9OTOQXNRx7t8zPf0E=; b=TJ5mLtiJtF39jpSOxbE3E1GJMbOefidPNNd5Vs2Ac2HL33LfF8e6oIg34DpTT0CIXW KcbciCWQTLE8SXQ8OKvIMrE9bzJRChLrE9yTAIrA+MPHPUiFk0uCe5PrF4IHtDHd09Q2 lCwC4QPoj/2Y6BvXj+G1XwAfhC2pIOy5oCR/xie4AtLdlnNcwHJAzwCUFfPbmEkdvOpF 5l8nA0dcQdTt4XMXBtmk4HXYMZ3e6+fUlDkvCX+wWl+KEcg9LkEAmzl4iuSwbhWg3LWn dPnnsMeD4Nmmo6bcfB5824Aem5oihoDNDZTduHLZGL+9EoJgExMeV1rX4cwNbQtYVKwv 6PWQ== X-Gm-Message-State: ALoCoQkMGrZ/55ZOh9OPwVyUcXkCOllF0CJmTDdk4D+5l19C138TfHA2PFxkQzy9fEb4n2oJIhlv+BE0JN9VQjbEKACQ8h32so62n+bSIS+LFnvwnc0BlC1U4JOvN/QTDswdNavjs/LX MIME-Version: 1.0 X-Received: by 10.52.118.73 with SMTP id kk9mr29286424vdb.13.1380145914089; Wed, 25 Sep 2013 14:51:54 -0700 (PDT) Sender: kirk.davis@epsb.ca X-Google-Sender-Delegation: kirk.davis@epsb.ca Received: by 10.58.136.164 with HTTP; Wed, 25 Sep 2013 14:51:54 -0700 (PDT) In-Reply-To: <68FFEAB0-055E-4BDF-85E5-F5C1EF26B3C1@mac.com> References: <68FFEAB0-055E-4BDF-85E5-F5C1EF26B3C1@mac.com> Date: Wed, 25 Sep 2013 15:51:54 -0600 X-Google-Sender-Auth: zI4gB5u5EjOX-K6oAooGkNn2Z7o Message-ID: Subject: Re: stopping an attack (fraggle like) From: NetOps Admin To: Charles Swiger Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-ipfw@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 21:52:01 -0000 On Wed, Sep 25, 2013 at 11:58 AM, Charles Swiger wrote: > Hi-- > > On Sep 25, 2013, at 10:23 AM, NetOps Admin wrote: > > Hi, > > We are currently getting hit with a DoS attack that looks very > > similar to a Fraggle attack. We are seeing a large amount of UDP traffic > > coming at us from thousands of hosts. The source UDP port is 19 > (chargen) > > and when it hits it consumes a 2Gb/s link. > > OK. You should get your ISP or whatever upstream connectivity provider to > filter out the malicious traffic before it hits your 2Gb/s link. > My ISP is only able to filter out based on the attacking IP address. They did offer to block the IP if I can identify who is attacking us. This doesn't help in the case of a Fraggle attack where I don't see the initial attacker and the attack is hitting me from a few thousand IP's. > > > Our main router is a FreeBSD server with ipfw installed. I have > > tried blocking UDP port 19 incoming from the internet in a firewall rule > > but the UDP packets are very large and they are followed by a number of > > fragmented packets. I think that even though I am blocking port 19, the > > fragmented packets are getting though and eating up the bandwidth. > > Right...filtering this UDP traffic on your side is already too late, > because > your bandwidth is already being chewed up. > That is the problem. I am trying to affect it from my end since my my ISP can;t help in this situation. I guess this is really not an option. ;( ---- Kirk From owner-freebsd-ipfw@FreeBSD.ORG Wed Sep 25 21:57:18 2013 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 26B14FF2 for ; Wed, 25 Sep 2013 21:57:18 +0000 (UTC) (envelope-from jt@dhtcolorado.com) Received: from mon1.dancinghorsetechnology.com (mon1.dancinghorsetechnology.com [64.111.21.158]) by mx1.freebsd.org (Postfix) with ESMTP id 0401727B2 for ; Wed, 25 Sep 2013 21:57:17 +0000 (UTC) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: stopping an attack (fraggle like) X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 25 Sep 2013 15:56:04 -0600 Message-ID: <9134141EFB6B1E4E96DE9D17DC6861FA146263@Tubastrea.cs.dancinghorsetechnology.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: stopping an attack (fraggle like) thread-index: Ac66OXu+n8oeyCRtSoWJAosms1j9awAACauQ References: <68FFEAB0-055E-4BDF-85E5-F5C1EF26B3C1@mac.com> From: "Joe Thompson" To: "Charles Swiger" Cc: freebsd-ipfw@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 21:57:18 -0000 You might give another call to the ISP and see if they can at least do a basic switch ACL to drop UDP to port 19, I typically have not had too many problems requesting this. You may also want to make sure any rules on your side use a drop verses a reject mechanism to avoid backscatter killing your uplink. In cases such as these it can often become an impossible task to deflect without ISP support, might be time to pull that service level agreement. ~J -----Original Message----- From: owner-freebsd-ipfw@freebsd.org [mailto:owner-freebsd-ipfw@freebsd.org] On Behalf Of NetOps Admin Sent: Wednesday, September 25, 2013 3:52 PM To: Charles Swiger Cc: freebsd-ipfw@freebsd.org Subject: Re: stopping an attack (fraggle like) On Wed, Sep 25, 2013 at 11:58 AM, Charles Swiger wrote: > Hi-- > > On Sep 25, 2013, at 10:23 AM, NetOps Admin wrote: > > Hi, > > We are currently getting hit with a DoS attack that looks very > > similar to a Fraggle attack. We are seeing a large amount of UDP=20 > > traffic coming at us from thousands of hosts. The source UDP port=20 > > is 19 > (chargen) > > and when it hits it consumes a 2Gb/s link. > > OK. You should get your ISP or whatever upstream connectivity=20 > provider to filter out the malicious traffic before it hits your 2Gb/s link. > My ISP is only able to filter out based on the attacking IP address. They did offer to block the IP if I can identify who is attacking us. This doesn't help in the case of a Fraggle attack where I don't see the initial attacker and the attack is hitting me from a few thousand IP's. > > > Our main router is a FreeBSD server with ipfw installed. I=20 > > have tried blocking UDP port 19 incoming from the internet in a=20 > > firewall rule but the UDP packets are very large and they are=20 > > followed by a number of fragmented packets. I think that even=20 > > though I am blocking port 19, the fragmented packets are getting though and eating up the bandwidth. > > Right...filtering this UDP traffic on your side is already too late,=20 > because your bandwidth is already being chewed up. > That is the problem. I am trying to affect it from my end since my my ISP can;t help in this situation. I guess this is really not an option. ;( ---- Kirk _______________________________________________ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org"