Date: Wed, 13 Feb 2013 12:51:44 -0500 From: "xenophon\\+freebsd" <xenophon+freebsd@irtnog.org> To: <freebsd-isp@freebsd.org>, <freebsd-security@freebsd.org> Subject: RE: FreeBSD DDoS protection Message-ID: <BABF8C57A778F04791343E5601659908236D59@cinip100ntsbs.irtnog.net> In-Reply-To: <2107458022.140210.1360773865635@d94655abdbc041fe9f54c404b6b4e89c.nuevasync.com> References: <SNT002-W152BF18F12BD59F112A1CBAE5040@phx.gbl> <321927899.767139.1360461430134@89b1b4b66ec741cb85480c78b68b8dce.nuevasync.com> <BABF8C57A778F04791343E5601659908236D58@cinip100ntsbs.irtnog.net> <2107458022.140210.1360773865635@d94655abdbc041fe9f54c404b6b4e89c.nuevasync.com>
next in thread | previous in thread | raw e-mail | index | archive | help
khatfield@... writes: > > Please read the rest of the thread before criticizing. Let me clarify. Naïvely blocking ICMP isn't the only thing firewall admins should avoid doing. I think that one should construct firewalls in such a manner that for all prohibited classes of traffic, the firewall should return the correct destination-unreachable messages (TCP RST or ICMP UNREACHABLE) to the traffic source. For one, this makes the presence of a firewall less obvious to attackers, but more importantly, end users don't have to wait for their connections to mysteriously time out when they do something prohibited. Black holes and null routes have their place, such as in response to an active denial of service attack, but not in the primary traffic control policy. -- I FIGHT FOR THE USERS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BABF8C57A778F04791343E5601659908236D59>