Date: Wed, 26 Jan 2000 20:25:12 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Brett Glass <brett@lariat.org> Cc: security@FreeBSD.ORG Subject: Re: Riddle me this Message-ID: <200001270425.UAA18744@apollo.backplane.com> References: <200001270355.UAA01355@lariat.lariat.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:A fellow here in town asked me to look at a machine which he thought had been
:attacked. Sure enough, when I checked the logs, I saw
:
:Jan 24 19:18:59 victim /kernel: icmp-response bandwidth limit 108/100 pps
:Jan 24 19:19:37 victim /kernel: icmp-response bandwidth limit 115/100 pps
:Jan 24 19:19:38 victim /kernel: icmp-response bandwidth limit 131/100 pps
:Jan 24 19:19:39 victim /kernel: icmp-response bandwidth limit 135/100 pps
:Jan 24 19:19:40 victim /kernel: icmp-response bandwidth limit 104/100 pps
:Jan 24 19:20:12 victim /kernel: icmp-response bandwidth limit 146/100 pps
:Jan 24 19:20:13 victim /kernel: icmp-response bandwidth limit 127/100 pps
:Jan 24 19:20:14 victim /kernel: icmp-response bandwidth limit 127/100 pps
:Jan 24 19:20:15 victim /kernel: icmp-response bandwidth limit 118/100 pps
:
:which means that ICMP bandwidth limiting had kicked in. Probably stream.c, I
:thought. While this seemed to be keeping the system alive, I noted that the
:machine was also acting as a router for a private subnet with some Windows
:machines on it. So, since multicast IP wasn't in use, I added IPFW rules that
:blocked multicast addresses on all interfaces:
:
:00049 deny ip from 224.0.0.0/4 to any via any
:00050 deny ip from any to 224.0.0.0/4 via any
:
:So far, so good. But a couple of days later, when I checked the logs, I saw:
:
:Jan 26 15:23:49 victim natd[125]: failed to write packet back (No route to host)
:
:Maybe I'm just dense this evening and the cause of the message is obvious, but
:I can't figure out what would have generated this message. The system has a
:static default route to the upstream ISP's router.
:
:Is this a side effect of the rules I added? Or of something else?
:
:--Brett Glass
Well, certainly the 'failed to write packet back' has nothing to do
with the icmp bandwidth limiting -- the bandwidth limiting drops packets,
the sender would not see an error. Also, the bandwidth limiting only
drops kernel-generated icmp response packets for certain specific cases
unrelated to NAT.
It's hard to say without doing a continuous tcpdump but the most likely
possibility is that someone was playing a game or doing something else
related to sending and receiving UDP packets, and then disconnected.
Either that or it was a really dumb hacker attacking the machine (at only
120 pps).
What likely occured in the Jan 24 logs was some sort of continuous
problem for the time range indicated (19:18:59 -> 19:20:15), but only
exceeding the 100 pps threshold at a couple of points during that
period.
It would be interesting to see if there is some sort of continuing problem
by reducing the limit from 100 to 50, 20, 10, and so forth, and seeing
if it catches anything. If you find a potential problem then raise the
limit back up again and capture a bunch of packets with tcpdump and see
if you can locate the problem (use the -l option to tcpdump and then
grep for icmp packets).
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001270425.UAA18744>