From owner-freebsd-pf@FreeBSD.ORG Sun Aug 19 08:48:50 2012 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 9ABD5106566C for ; Sun, 19 Aug 2012 08:48:50 +0000 (UTC) (envelope-from "") Received: from uksmtp6.uky.edu (uksmtp6.uky.edu [128.163.16.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5CDE68FC14 for ; Sun, 19 Aug 2012 08:48:47 +0000 (UTC) Received: from lsv (lsv.uky.edu [128.163.184.152]) by uksmtp6.uky.edu (Postfix) with ESMTP id D0B6AE02FB for ; Sun, 19 Aug 2012 04:42:15 -0400 (EDT) Date: Sun, 19 Aug 2012 04:42:15 -0400 From: "University of Kentucky LISTSERV Server (14.4)" To: freebsd-pf@FREEBSD.ORG Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="WcLOFSTBVYWBWHVAYSYQUJAEXYcFSA" Cc: Subject: Rejected posting to GARDENS@LSV.UKY.EDU 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: Sun, 19 Aug 2012 08:48:50 -0000 --WcLOFSTBVYWBWHVAYSYQUJAEXYcFSA You are not authorized to send mail to the GARDENS list from your freebsd-pf@FREEBSD.ORG account. You might be authorized to post to the list from another of your accounts, or perhaps when using another mail program configured to use a different e-mail address, but LISTSERV has no way to associate this other account or address with yours. If you need assistance or if you have any questions regarding the policy of the GARDENS list, please contact the list owners at GARDENS-request@LSV.UKY.EDU. --WcLOFSTBVYWBWHVAYSYQUJAEXYcFSA Content-Type: message/rfc822 Return-Path: Received: from 128.163.184.113 by LSV.UKY.EDU (SMTPL release 1.0m) with TCP; Sun, 19 Aug 2012 04:42:15 -0400 Received: from freebsd.org (219.219.124.183) by EX10ES03.ad.uky.edu (128.163.184.113) with Microsoft SMTP Server id 14.1.379.0; Sun, 19 Aug 2012 04:42:16 -0400 From: To: Subject: Returned mail: Data format error Date: Sun, 19 Aug 2012 16:42:11 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0008_282395D1.C41D9C28" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <991c5760-778e-4738-84e0-0a7edfd6ea12@EX10ES03.ad.uky.edu> Return-Path: freebsd-pf@freebsd.org Received-SPF: SoftFail (EX10ES03.ad.uky.edu: domain of transitioning freebsd-pf@freebsd.org discourages use of 219.219.124.183 as permitted sender) ------=_NextPart_000_0008_282395D1.C41D9C28 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ------=_NextPart_000_0008_282395D1.C41D9C28 Content-Type: text/plain; name="message.zip.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="message.zip.txt" Content-Description: message.zip.txt VGhpcyBhdHRhY2htZW50IHdhcyByZW1vdmVkLg== ------=_NextPart_000_0008_282395D1.C41D9C28-- --WcLOFSTBVYWBWHVAYSYQUJAEXYcFSA-- From owner-freebsd-pf@FreeBSD.ORG Mon Aug 20 11:07:58 2012 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 05A0E1065670 for ; Mon, 20 Aug 2012 11:07:58 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E2EB48FC1C for ; Mon, 20 Aug 2012 11:07:57 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q7KB7vwS047969 for ; Mon, 20 Aug 2012 11:07:57 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q7KB7uX8047964 for freebsd-pf@FreeBSD.org; Mon, 20 Aug 2012 11:07:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 20 Aug 2012 11:07:56 GMT Message-Id: <201208201107.q7KB7uX8047964@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-pf@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org 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: Mon, 20 Aug 2012 11:07:58 -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/169630 pf [pf] [patch] pf fragment reassembly of padded (undersi o kern/168952 pf [pf] direction scrub rules don't work o kern/168190 pf [pf] panic when using pf and route-to (maybe: bad frag s kern/167057 pf [pf] PF firewall version 4.5 in FreeBSD 9.0 & 8.2 nolo o kern/166336 pf [pf] kern.securelevel 3 +pf reload o kern/165315 pf [pf] States never cleared in PF with DEVICE_POLLING o kern/164402 pf [pf] pf crashes with a particular set of rules when fi o kern/164271 pf [pf] not working pf nat on FreeBSD 9.0 [regression] o kern/163208 pf [pf] PF state key linking mismatch o kern/160370 pf [pf] Incorrect pfctl check of pf.conf o kern/155736 pf [pf] [altq] borrow from parent queue does not work wit o kern/153307 pf [pf] Bug with PF firewall o kern/148290 pf [pf] "sticky-address" option of Packet Filter (PF) blo o kern/148260 pf [pf] [patch] pf rdr incompatible with dummynet o kern/147789 pf [pf] Firewall PF no longer drops connections by sendin o kern/143543 pf [pf] [panic] PF route-to causes kernel panic o bin/143504 pf [patch] outgoing states are not killed by authpf(8) o conf/142961 pf [pf] No way to adjust pidfile in pflogd o conf/142817 pf [patch] etc/rc.d/pf: silence pfctl o kern/141905 pf [pf] [panic] pf kernel panic on 7.2-RELEASE with empty o kern/140697 pf [pf] pf behaviour changes - must be documented o kern/137982 pf [pf] when pf can hit state limits, random IP failures o kern/136781 pf [pf] Packets appear to drop with pf scrub and if_bridg o kern/135948 pf [pf] [gre] pf not natting gre protocol o kern/135162 pf [pfsync] pfsync(4) not usable with GENERIC kernel o kern/134996 pf [pf] Anchor tables not included when pfctl(8) is run w o kern/133732 pf [pf] max-src-conn issue o kern/132769 pf [pf] [lor] 2 LOR's with pf task mtx / ifnet and rtent f kern/132176 pf [pf] pf stalls connection when using route-to [regress o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st o kern/129861 pf [pf] [patch] Argument names reversed in pf_table.c:_co o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o kern/127439 pf [pf] deadlock in pf o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/103283 pf pfsync fails to sucessfully transfer some sessions o kern/103281 pf pfsync reports bulk update failures o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf. o kern/82271 pf [pf] cbq scheduler cause bad latency 53 problems total. From owner-freebsd-pf@FreeBSD.ORG Mon Aug 20 15:53:11 2012 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 37DE3106566C for ; Mon, 20 Aug 2012 15:53:11 +0000 (UTC) (envelope-from jdavidlists@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id DD12D8FC1B for ; Mon, 20 Aug 2012 15:53:10 +0000 (UTC) Received: by vbmv11 with SMTP id v11so7191961vbm.13 for ; Mon, 20 Aug 2012 08:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=sXX3PGeNnqTuMZdhd9eehl6BoAWIh5wEVCzsQlwCXds=; b=sMAqNjZq5/4EBYU5TqIq9d74pOIX3XPZjI5WCfYKEsIz0fh++/y7EL//hJZGtJt77c npR3GW2jBCWMGyvbr6Eg6hJMTIhEfr20fBZo/tmgc7y36vXI9rt1an5VN4T0OEZVGOZt cdeEG42xCQP6ZuC0XfUeXAQdJERUE/IMxajqdRXfMG2MxwGP5YOZGeE0yIUc8TFpNr6H fFvMgKFKa9mktqUCxFRDyeIfCls5md7W8QjS5DnlJZ6w0u8rhQ7SImhT8nvgBRaBgQgP G4Sm66VRktON+Jk6V39eIIsEpvupEbLBMO2TP3TmUy7Q3I1lZmEA2VU0qQkJ39yAo2xZ uFKA== MIME-Version: 1.0 Received: by 10.52.74.6 with SMTP id p6mr8983779vdv.117.1345477989908; Mon, 20 Aug 2012 08:53:09 -0700 (PDT) Sender: jdavidlists@gmail.com Received: by 10.59.7.163 with HTTP; Mon, 20 Aug 2012 08:53:09 -0700 (PDT) Date: Mon, 20 Aug 2012 11:53:09 -0400 X-Google-Sender-Auth: 7-HaFaJT85VbC_uFwEo6aE5umac Message-ID: From: J David To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Fighting DDOS attacks with pf 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: Mon, 20 Aug 2012 15:53:11 -0000 Hello, We experience frequent DDOS attacks, and we're having a tough time mitigating them with pf. We have plenty of bandwidth and processing power, we just can't seem to get the rules right. If, for example, I have a single IP address on the outside attacking a range of IPs on the inside, it is very easy to write a max-src-states rule that will count the states for that IP and flush the attacker to a "drop quick" table if they exceed the limit. However, the nature of a DDOS attack is that there is not a single source IP. The source IP is either outright forged or one of a large number of compromised attacking hosts. So what I really want to do is have a "max-dst-states" rule that would at least temporarily blackhole an IP being attacked, but there's no such thing. Currently we have to run a script once per minute that parses "pfctl -s info" looking for large numbers of states to a common destination. But as we have our states set to 1000000, this is really inefficient and of course takes at least a minute to catch up to an attack. Is there a better way to do this? This is on FreeBSD 9.1-PRERELEASE #0 r238540. Thanks for any help! From owner-freebsd-pf@FreeBSD.ORG Mon Aug 20 16:07:36 2012 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 A98B11065672 for ; Mon, 20 Aug 2012 16:07:36 +0000 (UTC) (envelope-from kevin.wilcox@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7E7888FC12 for ; Mon, 20 Aug 2012 16:07:36 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp2so7553168pbb.13 for ; Mon, 20 Aug 2012 09:07:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ONiMTe2ovD61culNnLYyny5z0f7nio0qDR4y/d9/8k8=; b=e9dumVQ7nHsmjEHEWWN9gdLm6/DeSkM3E0FaXaUGTHlpO16XqThYjIu9GwjMy5Kjdh mz2AHku0H1AFqf+AIVUQqkWLh6ZBjZ+2369+hh4wBu1Im+gZomP2quIn4tmdhDnMyVcP jPhtE/ydnHnM0xOm7BBS3D9jKJGgIt1KVSNPMbV+yuONZv6Gppt2bwe67+Yui46R67Ob U+keRV/oa7EkjF41rwH8sLR0yjXs9qMi7AyuczoYjlKR/UIjoB7DRt85CPXdh5N3yUMY 0b4T7JIxi8vLaxTg7ko+Pu0YSKC9lLywK7Ue2LGtsyVm5BBFXwQymQAOg67ca6TDhWKH ++6g== MIME-Version: 1.0 Received: by 10.66.75.225 with SMTP id f1mr30644240paw.35.1345478856382; Mon, 20 Aug 2012 09:07:36 -0700 (PDT) Received: by 10.68.6.232 with HTTP; Mon, 20 Aug 2012 09:07:36 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Aug 2012 12:07:36 -0400 Message-ID: From: Kevin Wilcox To: J David Content-Type: text/plain; charset=UTF-8 Cc: freebsd-pf@freebsd.org Subject: Re: Fighting DDOS attacks with pf 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: Mon, 20 Aug 2012 16:07:36 -0000 On Mon, Aug 20, 2012 at 11:53 AM, J David wrote: > However, the nature of a DDOS attack is that there is not a single > source IP. The source IP is either outright forged or one of a large > number of compromised attacking hosts. So what I really want to do is > have a "max-dst-states" rule that would at least temporarily blackhole > an IP being attacked, but there's no such thing. Rather than block on the number of states, take a look at dropping based on the number of connections over some time delta. Specifically, max-src-conn and max-src-conn-rate. kmw From owner-freebsd-pf@FreeBSD.ORG Mon Aug 20 16:09:29 2012 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E4E51106564A for ; Mon, 20 Aug 2012 16:09:29 +0000 (UTC) (envelope-from victordetoni@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id A1BBC8FC16 for ; Mon, 20 Aug 2012 16:09:29 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so7556036pbb.13 for ; Mon, 20 Aug 2012 09:09:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KDkHUhWoDXANdSRv1c12RO/HRKvShGRUtxHnoen9lA4=; b=ZlXG8LSM1NRcCt4re6BI/JojaodfUp/SXlDqnLulqqgjNRU5Pey9TU+bOl/0iPqixT dMBEn4qAkZyrWl4j1mHT0V1dH4xoFl6FMzX9Zo39nU3yZSf9IxcPOBfh8RIvC1FMb8pI 0A3TtwB9TGgQckGCzaG7qVKz5wpk6Ala+j3tgjp69K1UJk25cQrzi5O/l9pu7YUa+j+S ZbVJ/KY43f88dLAGHIX+tB8dkRf7Ruh8d6PgOqDC4IuKCtBd24HO0JazWnOvUe+paoED mydgajR/FoEv4thvmBuhww5YxY1BO59I5f6FN/Vg8cHfXKxCPK/4PPAvQQzdk+vFPdOq P5pQ== MIME-Version: 1.0 Received: by 10.68.229.73 with SMTP id so9mr36224372pbc.66.1345478968993; Mon, 20 Aug 2012 09:09:28 -0700 (PDT) Received: by 10.66.50.35 with HTTP; Mon, 20 Aug 2012 09:09:28 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Aug 2012 13:09:28 -0300 Message-ID: From: Victor Detoni To: J David Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-pf@freebsd.org Subject: Re: Fighting DDOS attacks with pf 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: Mon, 20 Aug 2012 16:09:30 -0000 David, Have you looked *optimization* at link below? Maybe it helps you. http://www.openbsd.org/faq/pf/options.html On Mon, Aug 20, 2012 at 12:53 PM, J David wrote: > Hello, > > We experience frequent DDOS attacks, and we're having a tough time > mitigating them with pf. We have plenty of bandwidth and processing > power, we just can't seem to get the rules right. > > If, for example, I have a single IP address on the outside attacking a > range of IPs on the inside, it is very easy to write a max-src-states > rule that will count the states for that IP and flush the attacker to > a "drop quick" table if they exceed the limit. > > However, the nature of a DDOS attack is that there is not a single > source IP. The source IP is either outright forged or one of a large > number of compromised attacking hosts. So what I really want to do is > have a "max-dst-states" rule that would at least temporarily blackhole > an IP being attacked, but there's no such thing. > > Currently we have to run a script once per minute that parses "pfctl > -s info" looking for large numbers of states to a common destination. > But as we have our states set to 1000000, this is really inefficient > and of course takes at least a minute to catch up to an attack. > > Is there a better way to do this? > > This is on FreeBSD 9.1-PRERELEASE #0 r238540. > > Thanks for any help! > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" > From owner-freebsd-pf@FreeBSD.ORG Mon Aug 20 16:23:16 2012 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8B5EB1065670 for ; Mon, 20 Aug 2012 16:23:16 +0000 (UTC) (envelope-from jdavidlists@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3FC838FC15 for ; Mon, 20 Aug 2012 16:23:16 +0000 (UTC) Received: by vcbgb22 with SMTP id gb22so6645565vcb.13 for ; Mon, 20 Aug 2012 09:23:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=HGweACcslspYqq2bBQkyt6VEHyFgeqFvjlkhQ3pmzRk=; b=kn5lrJFQHAXALW01iAyqVlD2N8taR/yxAIAvSaKbXVsDuQrPa5u2sy04T7xl0YUXNn r0/W3ndXsOO8jXEs+TDmzaC8M2kA6rDG9mINnrUpjF0C2PQt2O9ouTOR3IeWVILlVd45 Uil/xp64QQyo0TymVkyYIqdbFEAdK//Y6SqmcouMjUbTlbpRlhQLVhrEOUVX9OYiicNK qF2PfbmP9islFF5tMw8qKdX0yn9vCyAuxxBrbMBJVv32RAVT2V/vCRSYAvpjse+8me18 mVA78mxXHKyezhv3w33MHCzsJfzQN/2QDZlKcSthFpjfsoi2gRLPpYKM38PzoFEE5vt6 baEA== MIME-Version: 1.0 Received: by 10.52.93.170 with SMTP id cv10mr2880939vdb.78.1345479795656; Mon, 20 Aug 2012 09:23:15 -0700 (PDT) Sender: jdavidlists@gmail.com Received: by 10.59.7.163 with HTTP; Mon, 20 Aug 2012 09:23:15 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Aug 2012 12:23:15 -0400 X-Google-Sender-Auth: LvapTu0XQj1b_rx3Zp_ZvF78yl4 Message-ID: From: J David To: Kevin Wilcox Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-pf@freebsd.org Subject: Re: Fighting DDOS attacks with pf 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: Mon, 20 Aug 2012 16:23:16 -0000 On Mon, Aug 20, 2012 at 12:07 PM, Kevin Wilcox wrote: > Rather than block on the number of states, take a look at dropping > based on the number of connections over some time delta. > > Specifically, max-src-conn and max-src-conn-rate. Anything based on the source address is ineffective as the number of attack packets from any given IP is very low (frequently 1 if they are forged). The goal for us is to clamp down on attacks directed at a given IP quickly and effectively enough that only that IP is affected. Thanks. From owner-freebsd-pf@FreeBSD.ORG Mon Aug 20 16:27:57 2012 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 552D4106564A for ; Mon, 20 Aug 2012 16:27:57 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id EEA628FC0C for ; Mon, 20 Aug 2012 16:27:56 +0000 (UTC) Received: by yenl7 with SMTP id l7so6298507yen.13 for ; Mon, 20 Aug 2012 09:27:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=6alNyDRLbH4asF+n0yJLCxCAEfuWq4iypZygF11ijaM=; b=PqenmP0X1pocf74d9aV2eIuxCzr1MMP7nl3GSsfNiFPQUXuSCy5TIURm53d2xRDZY3 VUnN+DAceDFpxUYzmAzWbxTZS9Vv+dSPDgnzIt0uJxCu7A+lxGo++/ytUx5PGt3Q0BUx kA7wZoq1VRH2Aqbz3F8B7CDBhndpm88pS5D4Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-gm-message-state; bh=6alNyDRLbH4asF+n0yJLCxCAEfuWq4iypZygF11ijaM=; b=hY7aSW13Iyw2me05Nx5ZKke7usfjqWan4eDk81yR3OojePNSDUTD+JE2TXujrdhKFX OmkYx5mGx/WovIvJQ7soJrBk3t+vQG3Eaf0lfEucpMetsLwh1aXIW2oQGFbtB3Kd6Qi/ dph5FWS+j5IEIRsG7i2HRIHUhv3gf07CQ6/n/vkh7yoDlFF1IpCNDL01AH1KQW2FK7LW K06yifMEX+Q8p026dkuopq/f7Z4qeyPDuX8k5fGLUfxMTlwkCiU8ctEoGvG751Ze0HsW KM/OwW0+kblhek0pOPRQnWi6f4PTvcsRlP28ETAlFPc8bRWmGxHyObKJ9wbldpML/XAz WlpQ== Received: by 10.50.154.225 with SMTP id vr1mr10334849igb.70.1345480075911; Mon, 20 Aug 2012 09:27:55 -0700 (PDT) Received: from DataIX.net (adsl-108-73-114-157.dsl.klmzmi.sbcglobal.net. [108.73.114.157]) by mx.google.com with ESMTPS id gy9sm13273293igc.1.2012.08.20.09.27.54 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Aug 2012 09:27:55 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q7KGRqJ5029134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Aug 2012 12:27:53 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jh@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q7KGRq6Y029133; Mon, 20 Aug 2012 12:27:52 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Mon, 20 Aug 2012 12:27:52 -0400 From: Jason Hellenthal To: J David Message-ID: <20120820162752.GA28945@DataIX.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k1lZvvs/B4yU6o8G" Content-Disposition: inline In-Reply-To: X-Gm-Message-State: ALoCoQmO9/ieE4eTOGLkzEq4plYceQGMkIdfKKj+iyCb/TNZWfaMxvl2/cqEW213KWq2GOYByl4D Cc: freebsd-pf@freebsd.org Subject: Re: Fighting DDOS attacks with pf 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: Mon, 20 Aug 2012 16:27:57 -0000 --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable All of the methods listed in more recent messages are just fine of methods to *somewhat* handle the DDoS on the hosts being attacked. - *But* - The only way you are going to take care of this is going to you're provider at the next level and asking them for assistance. Most of the addresses you will be seeing are probably spoofed or part of some amplification attack at which you will end up blocking out legitimate customers anyhow. So level up and go to your're Tier 2, Tier 1's. On Mon, Aug 20, 2012 at 11:53:09AM -0400, J David wrote: > Hello, >=20 > We experience frequent DDOS attacks, and we're having a tough time > mitigating them with pf. We have plenty of bandwidth and processing > power, we just can't seem to get the rules right. >=20 > If, for example, I have a single IP address on the outside attacking a > range of IPs on the inside, it is very easy to write a max-src-states > rule that will count the states for that IP and flush the attacker to > a "drop quick" table if they exceed the limit. >=20 > However, the nature of a DDOS attack is that there is not a single > source IP. The source IP is either outright forged or one of a large > number of compromised attacking hosts. So what I really want to do is > have a "max-dst-states" rule that would at least temporarily blackhole > an IP being attacked, but there's no such thing. >=20 > Currently we have to run a script once per minute that parses "pfctl > -s info" looking for large numbers of states to a common destination. > But as we have our states set to 1000000, this is really inefficient > and of course takes at least a minute to catch up to an attack. >=20 > Is there a better way to do this? >=20 > This is on FreeBSD 9.1-PRERELEASE #0 r238540. >=20 > Thanks for any help! > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" --=20 - (2^(N-1)) JJH48-ARIN --k1lZvvs/B4yU6o8G Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJQMmWHAAoJEBSh2Dr1DU7WtI8IAIeA19ZBUi/GPG/wiwosNpi1 l5W7FcURe3OQUFOoXdR2VrQ4kUhlrDKvLBbFQy+yoWE7klG9LyfKA0/lgRsKRoOr c38/TWoUZC5y3znJ0MfefQunTiT3RAV42c0oxP0V96j+mscOkCzLrJ11lNleYB+g 6J8qOzq+YXubaq5tYbpRviZY2qtZuKOU2EE+iPYguAREV+9RXiY+1/7D4VsB7swQ RL2u2nf9DsN+9fXhjkR8Hazze3W6ou8bVKfwWQFcYXHKGHClgGf2G6gAfMAe6LYD TMuJGfQbm59OysenF6jxy3aebPHheZnPOUZKpnF35I2OVBfs9v7hvsdMElp8R2g= =FgO7 -----END PGP SIGNATURE----- --k1lZvvs/B4yU6o8G-- From owner-freebsd-pf@FreeBSD.ORG Mon Aug 20 17:20:28 2012 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E240A1065670 for ; Mon, 20 Aug 2012 17:20:27 +0000 (UTC) (envelope-from mistrzipan@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 6F4FA8FC18 for ; Mon, 20 Aug 2012 17:20:27 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so5478402wgb.31 for ; Mon, 20 Aug 2012 10:20:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=8qyLrUK4049tUmBur2s5VQ10ZW2WN1o9Kqgnz2hSojU=; b=fajG92edXqowESheXW97MIDSPQ2e72j8nlRLoNT8tmQoauXVQMoSOeGXYY+l/wywBq io3EfxX5FzfSZligqqqwbKYOBXpHYShf2FTXjSfI4NTVGq40KhNjOOO6nqXm39EDah3Z sCOiPf7z6wVpkdihzLU+M7EOZodDMgw4u6eNdD5uzldxBedb/f7ky8esglu0WPsRUgzU rZichTOVBkfrsi274JE7L4JGgi8xFf1KuNMDWViUIezFHnS5jVHNLsWPpfRlXUaPOIWv GSS0/WhiEcJejkpVWRiznDqWQToo59YEQhGso9Rfb88G/9FYYbQJNXFBGMBT60Stdd6i PL+g== Received: by 10.180.78.4 with SMTP id x4mr29303526wiw.19.1345483226164; Mon, 20 Aug 2012 10:20:26 -0700 (PDT) Received: from [192.168.32.241] ([79.110.197.42]) by mx.google.com with ESMTPS id dc3sm28950763wib.7.2012.08.20.10.20.25 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Aug 2012 10:20:25 -0700 (PDT) Message-ID: <503271D8.1040707@gmail.com> Date: Mon, 20 Aug 2012 19:20:24 +0200 From: "Bartek W. aka Mastier" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-pf@freebsd.org References: <20120820162752.GA28945@DataIX.net> In-Reply-To: <20120820162752.GA28945@DataIX.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Fighting DDOS attacks with pf 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: Mon, 20 Aug 2012 17:20:28 -0000 W dniu 20.08.2012 18:27, Jason Hellenthal pisze: > All of the methods listed in more recent messages are just fine of > methods to *somewhat* handle the DDoS on the hosts being attacked. > > - *But* - > > The only way you are going to take care of this is going to you're > provider at the next level and asking them for assistance. Most of the > addresses you will be seeing are probably spoofed or part of some > amplification attack at which you will end up blocking out legitimate > customers anyhow. > > So level up and go to your're Tier 2, Tier 1's. Beside, I advise you check thoroughly from where the attacks are actually coming from. In our case a lot of ACK and SYN attack with IP addresses looking like PA or PI addresses outside our network eventually appeared to be our customers having those public addresses spoofed on their machines causing global chaos. I am not sure which malware was causing such behaviour, but make your research in that direction. Check if those massive SYN are actually coming from WAN. Use tcpdump or trafshow to review if this public address are really in WAN. > > On Mon, Aug 20, 2012 at 11:53:09AM -0400, J David wrote: >> Hello, >> >> We experience frequent DDOS attacks, and we're having a tough time >> mitigating them with pf. We have plenty of bandwidth and processing >> power, we just can't seem to get the rules right. >> >> If, for example, I have a single IP address on the outside attacking a >> range of IPs on the inside, it is very easy to write a max-src-states >> rule that will count the states for that IP and flush the attacker to >> a "drop quick" table if they exceed the limit. >> >> However, the nature of a DDOS attack is that there is not a single >> source IP. The source IP is either outright forged or one of a large >> number of compromised attacking hosts. So what I really want to do is >> have a "max-dst-states" rule that would at least temporarily blackhole >> an IP being attacked, but there's no such thing. >> >> Currently we have to run a script once per minute that parses "pfctl >> -s info" looking for large numbers of states to a common destination. >> But as we have our states set to 1000000, this is really inefficient >> and of course takes at least a minute to catch up to an attack. >> >> Is there a better way to do this? >> >> This is on FreeBSD 9.1-PRERELEASE #0 r238540. >> >> Thanks for any help! >> _______________________________________________ >> freebsd-pf@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-pf >> To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" From owner-freebsd-pf@FreeBSD.ORG Mon Aug 20 18:16:17 2012 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 A9087106566B for ; Mon, 20 Aug 2012 18:16:17 +0000 (UTC) (envelope-from jdavidlists@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 32AB88FC0C for ; Mon, 20 Aug 2012 18:16:16 +0000 (UTC) Received: by vcbgb22 with SMTP id gb22so6804402vcb.13 for ; Mon, 20 Aug 2012 11:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=bbp+BdTG/mxtRGNMcW3+vMBAOORlVNtH+CTtPiDTnDQ=; b=PRVd3PDhJ68BipdYXqXDKUgtfaCXZBKAlzqNSZI9w6w4frEaUvZelS8c7eSnMyKq2z Zdnj/+Wd6goUujtRJQU31HJ5ctitrh7SGaeZiTaheK27iofGggGzsyyheXYrwQ42c9L8 HVJikO4V8WFhDyQYBrSMBziHuHcHbK9vzEzAUZIR2OHnCiJqoYtdNRrmP886OSYsa1QW Zvc5iUYqzTOcwZIi36Vf/tc45XdKxZ+WaiOnIoX4PPJPAAfOsiKA0rQMQ+lCnQIuPGKz ocqYO4Y0lXSZBWnHybSu7SlfVMukCoNTQ3h3Kfujpmt9qn6NWufEQPE3W7XhG31eUF2n 2QfQ== MIME-Version: 1.0 Received: by 10.58.102.48 with SMTP id fl16mr12056078veb.41.1345486576133; Mon, 20 Aug 2012 11:16:16 -0700 (PDT) Sender: jdavidlists@gmail.com Received: by 10.59.7.163 with HTTP; Mon, 20 Aug 2012 11:16:16 -0700 (PDT) In-Reply-To: <20120820162752.GA28945@DataIX.net> References: <20120820162752.GA28945@DataIX.net> Date: Mon, 20 Aug 2012 14:16:16 -0400 X-Google-Sender-Auth: -Fae9NQ5QA_qeEGfEL4tGe-wmXA Message-ID: From: J David To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Fighting DDOS attacks with pf 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: Mon, 20 Aug 2012 18:16:17 -0000 Unfortunately, I think my reference to DDOS attacks has distracted from the underlying issue. PF allows a rule like this: pass in proto tcp from any to any port www keep state (max 100, source-track rule, max-src-states 3) (adapted from the man page) We want this rule: pass in proto tcp from any to any port www keep state (max 100, dest-track rule, max-dst-states 3) Obviously there is no such rule. I'm simply curious whether anyone has found a way to bend the PF syntax to create the same behavior. Perhaps I can offer a couple of examples that will clarify. If I do this: table { 10.0.0.0/30 } block drop pass in proto tcp from any to port 80 keep state ( max 4000 ) This will not work for us. If traffic to 10.0.0.2 creates all 4000 allowed states, packets to *all* of the protected IPs will stop matching the pass rule and all of the protected IPs are effectively knocked offline. If, however, I do this: ProtectedIPs = "{ 10.0.0.0, 10.0.0.1, 10.0.0.2, 10.0.0.3 }" block drop pass in proto tcp from any to $ProtectedIPs port 80 keep state ( max 1000 ) Then PF will create one rule for each destination IP, and will therefore limit the number of states on a per-destination-IP basis. Thus, when traffic to 10.0.0.2 creates 1000 states on its pass rule, further packets match "block drop" instead, but only for that IP; traffic for the other three IPs is unaffected. That is the effect we want to create. This works. The problem we have is that the scale is much larger. Listing four example IP's in the PF config is not difficult, hardcoding thousands of destination IPs into the config file individually would be unwieldy and difficult to maintain, as well as possibly creating performance problems within pf, as rule processing goes from O(1) to O(n). Since that doesn't seem practical, we use the script I mentioned earlier that scans the state table and adds targeted IPs to a pf table to be blocked. This is fine, except it introduces a period of up to a minute where spillover damage may occur. What I am hoping to find is a way of doing this entirely within pf, in order to cut the response time and to gracefully flow from overflow to non-overflow conditions. There are a couple of ways of doing this. One would be to find a couple of really clever rules that would create the effect we are looking for. This is what I was hoping to find by asking here. The other would be to find some manageable way to generate the individual rules for each IP -- shouldn't be tough to script if the pf.conf syntax isn't up to it -- if adding a few thousand "pass" rules won't crush performance. If anyone has worked with ridiculously large rulesets of that sort, I would love to hear about their experiences.. Thanks! From owner-freebsd-pf@FreeBSD.ORG Tue Aug 21 07:49:43 2012 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D2226106564A for ; Tue, 21 Aug 2012 07:49:43 +0000 (UTC) (envelope-from fbsdmail@dnswatch.com) Received: from udns.ultimateDNS.NET (96-26-47-11.war.clearwire-wmx.net [96.26.47.11]) by mx1.freebsd.org (Postfix) with ESMTP id 2917C8FC0C for ; Tue, 21 Aug 2012 07:49:40 +0000 (UTC) Received: from ultimatedns.net (localhost [IPv6:::1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with SMTP id q7L7Qj29025944; Tue, 21 Aug 2012 00:26:54 -0700 (PDT) (envelope-from fbsdmail@dnswatch.com) Received: from 96.26.47.11 (auth. user chrish@localhost) by ultimatedns.net with HTTP; Tue, 21 Aug 2012 01:26:40 -0600 To: "freebsd-pf" Date: Tue, 21 Aug 2012 01:26:40 -0600 X-Mailer: UDNS Messaging System/0.9.5 (On: ultimatedns.net) Message-ID: In-Reply-To: From: "Chris H" Bounce-To: "Chris H" Errors-To: "Chris H" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Subject: Re: Fighting DDOS attacks with pf 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: Tue, 21 Aug 2012 07:49:43 -0000 On 8/20/2012, "J David" wrote: >Unfortunately, I think my reference to DDOS attacks has distracted >from the underlying issue. > >PF allows a rule like this: > >pass in proto tcp from any to any port www keep state (max 100, >source-track rule, max-src-states 3) > >(adapted from the man page) > >We want this rule: > >pass in proto tcp from any to any port www keep state (max 100, >dest-track rule, max-dst-states 3) > >Obviously there is no such rule. I'm simply curious whether anyone >has found a way to bend the PF syntax to create the same behavior. > >Perhaps I can offer a couple of examples that will clarify. > >If I do this: > >table { 10.0.0.0/30 } >block drop >pass in proto tcp from any to port 80 keep state ( max 4000 ) > >This will not work for us. If traffic to 10.0.0.2 creates all 4000 >allowed states, packets to *all* of the protected IPs will stop >matching the pass rule and all of the protected IPs are effectively >knocked offline. > >If, however, I do this: > >ProtectedIPs = "{ 10.0.0.0, 10.0.0.1, 10.0.0.2, 10.0.0.3 }" >block drop >pass in proto tcp from any to $ProtectedIPs port 80 keep state ( max 1000 ) > >Then PF will create one rule for each destination IP, and will >therefore limit the number of states on a per-destination-IP basis. >Thus, when traffic to 10.0.0.2 creates 1000 states on its pass rule, >further packets match "block drop" instead, but only for that IP; >traffic for the other three IPs is unaffected. > >That is the effect we want to create. > >This works. The problem we have is that the scale is much larger. >Listing four example IP's in the PF config is not difficult, >hardcoding thousands of destination IPs into the config file >individually would be unwieldy and difficult to maintain, as well as >possibly creating performance problems within pf, as rule processing >goes from O(1) to O(n). > >Since that doesn't seem practical, we use the script I mentioned >earlier that scans the state table and adds targeted IPs to a pf table >to be blocked. This is fine, except it introduces a period of up to a >minute where spillover damage may occur. > >What I am hoping to find is a way of doing this entirely within pf, in >order to cut the response time and to gracefully flow from overflow to >non-overflow conditions. > >There are a couple of ways of doing this. > >One would be to find a couple of really clever rules that would create >the effect we are looking for. This is what I was hoping to find by >asking here. > >The other would be to find some manageable way to generate the >individual rules for each IP -- shouldn't be tough to script if the >pf.conf syntax isn't up to it -- if adding a few thousand "pass" rules >won't crush performance. If anyone has worked with ridiculously large >rulesets of that sort, I would love to hear about their experiences.. > >Thanks! Greetings, I'm coming into this thread a bit late, and while I haven't read the entire thread. I also ran into a few DDOS's and found the antispoof for inet rule to help quite a bit. It made it easier to track down the offending IP(s). So I could contact the RP's to complain. On one occasion, the actual offender was deflecting off a poor guy's IP. The pf && DNS logs I had provided the information he needed to get the actual offender. Not sure if this will help you in your case, but felt if worth a mention. Best wishes. >_______________________________________________ >freebsd-pf@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-pf >To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org From owner-freebsd-pf@FreeBSD.ORG Tue Aug 21 08:41:16 2012 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E2B11065672 for ; Tue, 21 Aug 2012 08:41:16 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (106-30.3-213.fix.bluewin.ch [213.3.30.106]) by mx1.freebsd.org (Postfix) with ESMTP id A754A8FC1C for ; Tue, 21 Aug 2012 08:41:15 +0000 (UTC) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id q7L8OjYZ030035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2012 10:24:45 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id q7L8OivY014532; Tue, 21 Aug 2012 10:24:44 +0200 (MEST) Date: Tue, 21 Aug 2012 10:24:44 +0200 From: Daniel Hartmeier To: J David Message-ID: <20120821082444.GC31376@insomnia.benzedrine.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-pf@freebsd.org Subject: Re: Fighting DDOS attacks with pf 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: Tue, 21 Aug 2012 08:41:16 -0000 On Mon, Aug 20, 2012 at 12:23:15PM -0400, J David wrote: > Anything based on the source address is ineffective as the number of > attack packets from any given IP is very low (frequently 1 if they are > forged). Why not use synproxy state? > The goal for us is to clamp down on attacks directed at a given IP > quickly and effectively enough that only that IP is affected. How does it improve the situation for another destination? The attacker will not immediately stop, the TCP SYNs will continue to flood in. You're saying your uplink's downstream isn't saturated by them? If so, what other resource are you trying to protect? Daniel From owner-freebsd-pf@FreeBSD.ORG Tue Aug 21 18:21:47 2012 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 C8C5F106566B for ; Tue, 21 Aug 2012 18:21:47 +0000 (UTC) (envelope-from jdavidlists@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 740EB8FC0A for ; Tue, 21 Aug 2012 18:21:47 +0000 (UTC) Received: by vbmv11 with SMTP id v11so153403vbm.13 for ; Tue, 21 Aug 2012 11:21:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=fTxKSMvp/ywlolSsN3Il8qQRVjokJzhgcWRB98hy/PI=; b=L5Jkiv9o+GoS9INaVE0HJn/QA6WBHyxRx7zg/n7cpcBDHzAiZiv+ShI7pY6Nnal0Mh FLwjWkV2FstWr42J2GTTUhmY7FCSbnnarmsh+A/qr55lXQgqPnuzNFrU26CBqadoAwM2 xASDgyLSf11Shtr/XBw6jHqZj+Pm1OZ1YoatI1pqC0kNTtMqHRw3kUAtepWiuW9AIk+2 qdC0+DQVTSwEg3XtZRWI1TRBqA020eEBGWiDei2vmOexucbE5SDEZ0jiPJEMQwDmC3Ec dQ6sRnkI1Ujefi84Yvk9bqOhFtduBkGpnBDRyN0Y/Gk3Zo00VlDwcgXZUDjpu6RC7POS GVrA== MIME-Version: 1.0 Received: by 10.52.37.233 with SMTP id b9mr11980084vdk.107.1345573306719; Tue, 21 Aug 2012 11:21:46 -0700 (PDT) Sender: jdavidlists@gmail.com Received: by 10.59.7.163 with HTTP; Tue, 21 Aug 2012 11:21:46 -0700 (PDT) In-Reply-To: <20120821082444.GC31376@insomnia.benzedrine.cx> References: <20120821082444.GC31376@insomnia.benzedrine.cx> Date: Tue, 21 Aug 2012 14:21:46 -0400 X-Google-Sender-Auth: YDo8gfAlfpQOhu2MsxrtmH1buyg Message-ID: From: J David To: Daniel Hartmeier Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-pf@freebsd.org Subject: Re: Fighting DDOS attacks with pf 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: Tue, 21 Aug 2012 18:21:47 -0000 On Tue, Aug 21, 2012 at 4:24 AM, Daniel Hartmeier wrote: > Why not use synproxy state? synproxy state does not help us limit simultaneous connections to a particular destination IP, which is all we are trying to accomplish, for a very large number of destination IPs. Thanks.