From: "Michael H. Warfield" <mhw(_at_)wittsend(_dot_)com>
...
But some of us turn off ICMP except for ICMP_FRAG_NEEDED and keep
MTU discovery alive while cutting off the ICMP food fights and script
kiddie probes that seem to be endemic in our current mess.
Why couldn't you do as has been frequently suggested and only throttle
ICMP Echo-Request/Reply?
You betcha traceroute and ping are broken (figuratively and
literally). Just as broken as I can make them. You don't need to be
tracerouting or pinging into my network and that's my choice to make.
As we all agree, what you do with your own network is only your business.
However, rest assured that if you're an ISP that breaks traceroute,
then you also break arbitrary UDP applications, and that means you
don't get any business from anyone with any sense.
I can break them without breaking MTU discovery. You want to diagnose
routing or other technical problems, why aren't you contacting me?
(Hypothetically, of course) Because I do not know where the problem
is. Without traceroute, how should I figure out to call you? How
do I discover that you're running a transit network between here
and the other and that is trashing my packets)?
Nonsense about calling arround is exactly why traceroute was invented,
and that was back when there were a lot fewer usual suspects messing with
things. Before traceroute, the only way to figure out what was wrong
was to call the far end and the first hop...well, besides intelligent
and laborous use of `ping` and other manual, hop-by-hop probing.
Since you turn off ICMP Echo-Requests, no one can tell.
You probably also turn of Record-Route, lest someone discover that your
routers are in the path.
You cut off ICMP_ECHOREPLY and all but a tightly restricted set
of UDP and you have just starved these DDoS zombies of the vast majority
of their communications facility. TCP is much easier to trace, if they
fall back to that (I don't see how TFN2K could - it utilizes a blind
No, TCP is not more traceable because has no more IP source addresses
than UDP. Yes, unidirectional TCP is not terribly useful for
legitimate traffic, but that also applies to UDP.
You have a such narrow view of the possibilities for a DDoS attack
that it is dangerously wrong. If you accept any packets that cause
your systems to do any work, then I can write a distributed program
that can trash your systems, your network, or both. All you can
do is force me increase the size of my army of zombie proxies.
If you do not accept any packets that cause your system to do any work
(including merely sending "puzzles" or checking answers), then your system
is useless. Who would send any packets to a system that does nothing?
Blocking spoofed packets won't
do nearly as good a job since a lot of the packets aren't spoofed.
Yes, as has been repeatedly pointed out.
RFC 2267 filtering is good even if it is not a pancea. The reasons
advanced for bogus IP source addresses are not compelling.
...
They broke it's back by blocking ICMP_ECHO and ICMP_ECHOREPLY
(fortunately, this attack was not using one of the UDP options).
It is also fortunate that it was not based on TCP packets to port 80
or UDP to or from port 53.
I'd wonder why they didn't use a distributed, very low rate per zombie
SYN attack, except I know such people are fundamentally stupid.
...
The attackers are gaining in sophistication. We are begining to
see effort at "covert channels" for communications. The tricks of
communicating via ICMP_ECHOREPLY packets with commands in the payload
and sending blobs of forward only commands with no reverse channel
responses are just examples. How long before they start sneaking past
those defenses by sending ICMP_UNREACHABLE/ICMP_FRAG_NEEDED with
a command data payload?
Also think about putting commands in packets to port 53 or 80. Yes,
including TCP port 80. If you've broken into a system, you may as well
listen to all raw packets and not just what the local TCP state machine
thinks are kosher and not only what `ping` and `traceroute` use.
Given all of that, could you remind me of why it is rational to filter
ICMP-Echo's when by your own words the bad guys don't need to use them?
As in the spam war, filtering ICMP-Echo's only advances the day whey
they use other schemes that are harder to filter. Unlike the spam
war, it is technically easy to make bad traffic that cannot be filtered
(press releases from security outfits notwithstanding).
Vernon Schryver vjs(_at_)rhyolite(_dot_)com