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: >=20 > Please read the rest of the thread before criticizing. Let me clarify. Na=EFvely 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. --=20 I FIGHT FOR THE USERS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BABF8C57A778F04791343E5601659908236D59>