From owner-freebsd-security@FreeBSD.ORG Wed Feb 13 08:28:03 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DF869538; Wed, 13 Feb 2013 08:28:03 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 7E7E321E; Wed, 13 Feb 2013 08:28:03 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 580E66899; Wed, 13 Feb 2013 08:28:02 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 081A4A33F; Wed, 13 Feb 2013 09:28:01 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ian Smith Subject: Re: FreeBSD DDoS protection References: <321927899.767139.1360461430134@89b1b4b66ec741cb85480c78b68b8dce.nuevasync.com> <51179708.2030206@epipe.com> <86zjz9f31u.fsf@ds4.des.no> <20130213175449.O71572@sola.nimnet.asn.au> Date: Wed, 13 Feb 2013 09:28:00 +0100 In-Reply-To: <20130213175449.O71572@sola.nimnet.asn.au> (Ian Smith's message of "Wed, 13 Feb 2013 18:04:33 +1100 (EST)") Message-ID: <86halg4nzj.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Janne Snabb , khatfield@socllc.net, Mark Felder , freebsd-isp@freebsd.org, freebsd-security@freebsd.org, James Howlett X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 08:28:03 -0000 Ian Smith writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Slight correction: dropping *all* ICMP is a bad idea. You can get by= =20 > > with just unreach. Add timex, echoreq and echorep for troubleshooting. > rc.firewall, phk@? has long recommended 3,4,11 as "essential" icmptypes.= =20=20 > Are there any negative security implications to including source quench? See RFC 6633 (http://tools.ietf.org/html/rfc6633) and the literature it references, particularly RFC 5927 (http://tools.ietf.org/html/rfc5927). TL;DR: they were a bad idea to begin with, and nobody implements them anyway. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no