Date: Mon, 27 Oct 2003 00:57:46 -0800
To: Brett Glass <brett@lariat.org>
On 2003-10-27 00:31 -0700, Brett Glass <brett@lariat.org> wrote:
> We're being ping-flooded by the Nachi worm, which probes subnets for
> systems to attack by sending 92-byte ping packets. Unfortunately,
> IPFW doesn't seem to have the ability to filter packets by length.
> Assuming that I stick with IPFW, what's the best way to stem the
> tide?
You could filter by icmptype, with the result that no ICMP ECHO
packets would transit your firewall (i.e. ping stops working).
Here is what I use on one of my hosts. Comments welcome.
# icmp
# echo reply, dest unreach, redirect, echo request, ttl exceeded
$fwcmd add 07000 allow icmp from me to any out xmit $eth icmptypes 0,3,5,8,11
# echo reply, dest unreach, echo request, ttl exceeded
$fwcmd add 07010 allow icmp from any to me in recv $eth icmptypes 0,3,8,11
(The remainder are denied by default.)
Greg
--
Gregory S. Sutter It is no measure of health to be
mailto:gsutter@zer0.org well adjusted to a profoundly
http://zer0.org/~gsutter/ sick society. --Krishamurti
Re: [PATCH] ng_tag - new netgraph node, please test (L7 filtering possibility) ... For simple using, however, you don't need to bother all that details - just remember magic number and where to place it, and it is now simple for use with ipfw tags.... Currently the only analyzing node in FreeBSD src tree is ng_bpf, but it merely splits incoming packets in two streams, matched and not. ... There are reasons to this, as netgraph needs to be modular, and each node does a small thing, but does it well. ... For long time ng_bpf was used for another purposes in the kernel, and now, as new ipfw features appeared, ng_tag came up for easy integration. ... (freebsd-current)
Re: [PATCH] ng_tag - new netgraph node, please test (L7 filtering possibility) ... For simple using, however, you don't need to bother all that details - just remember magic number and where to place it, and it is now simple for use with ipfw tags.... Currently the only analyzing node in FreeBSD src tree is ng_bpf, but it merely splits incoming packets in two streams, matched and not. ... There are reasons to this, as netgraph needs to be modular, and each node does a small thing, but does it well. ... For long time ng_bpf was used for another purposes in the kernel, and now, as new ipfw features appeared, ng_tag came up for easy integration. ... (freebsd-isp)
Re: [PATCH] ng_tag - new netgraph node, please test (L7 filtering possibility) ... For simple using, however, you don't need to bother all that details - just remember magic number and where to place it, and it is now simple for use with ipfw tags.... Currently the only analyzing node in FreeBSD src tree is ng_bpf, but it merely splits incoming packets in two streams, matched and not. ... There are reasons to this, as netgraph needs to be modular, and each node does a small thing, but does it well. ... For long time ng_bpf was used for another purposes in the kernel, and now, as new ipfw features appeared, ng_tag came up for easy integration. ... (freebsd-net)
FreeBSD Security Advisory: FreeBSD-SA-01:08.ipfw [REVISED] ... included in FreeBSD 4.0 and above. ... based on an old version of ipfw and does not contain as many features. ... Due to overloading of the TCP reserved flags field,... incorrectly treat all TCP packets with the ECE flag set as being part ... (FreeBSD-Security)
Re: [PATCH] ng_tag - new netgraph node, please test (L7 filtering possibility) ... The problem with pf is that pf compiles all the rules at the time, so exact tags representation can change each time (for this reason ipfw tags were made incompatible with pf), and you must that values to supply them to. ... Also, as it seems non-trivial on current ipfw dynamic rules implementation, I don't know if shaping will work at all. ... But you can try to test such ruleset (it supposes that dynamic rules are checked twice, on incoming packets and on outgoing also, as with all other rules as ipfw manpage says): ... (freebsd-isp)
