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