Re: Blocked incoming ICMP, getting outgoing ICMP  Destination Unreachable
- From: ibuprofin@xxxxxxxxxxxxxxxxxxxxxx (Moe Trin)
- Date: Sun, 26 Feb 2006 13:36:32 -0600
On Sat, 25 Feb 2006, in the Usenet newsgroup comp.security.firewalls, in article
<44011981$0$46421$892e7fe2@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>, Dom wrote:
windoze imitation version of traceroute
The real LBL traceroute
How 'bout clearing up this distinction between real and imitation
traceroute. I just don't understand the contention surrounding
Microsoft's traceroute. Do they both not accomplish the same thing?
As you demonstrate in the following post, no. In (roughly) 1987, Van
Jacobson (then at Lawrence Berkeley National Lab) created traceroute to
debug networking problems based on a suggestion from Prof. Steve Deering
(then at Stanford). Since then, there have been several other versions
inspired by the LBL version, and several other tools that use the same
concept for different ends.
I would argue that ICMP echo is the proper protocol for a traceroute
because a firewalled target host is most likely to reply to an echo
Watch the line wrap here:
The original ip spec (rfc791) said that you should never send an
icmp error in reponse to an icmp packet. Several years later
this was amended to "... in response to an icmp *error* packet" but,
at the time that traceroute was written, most router vendors had
implemented according to the original spec & wouldn't send an
icmp time exceeded in response to an icmp echo or echo reply.
I would place hping above all other traceroute utilities. Hping
can perform traceroutes with many protocols and ports.
Yes, but hping is not primarily a traceroute tool. I also have... I was
going to say some number, but realize I don't know how many different
tools on this system can do a traceroute type function - it's at least
On Sun, 26 Feb 2006, in the Usenet newsgroup comp.security.firewalls, in article
<44016b8b$0$49311$892e7fe2@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>, Dom wrote:
Dur, that's how they all work regardless of the protocol used. However,
I think it's important that the target host respond to the protocol
used, else you end up with something like the following.
And there you hit the nail squarely. ICMP (and indeed several protocols
and services) have been abused quite badly over the years, resulting in
firewalls that block many helpful tools. In the late 1990s, the skript
kiddiez discovered that microsoft's usual incompetent programming skills
had created a b0rken network stack that could be kicked over by sending
one of a number of different specially crafted packets - I'll mention only
the "ping-of-death" so fondly enjoyed by wankers everywhere. The result
was that a lot of networks suddenly got firewall rules that dropped ICMP
echo (silently, as per RFC0792).
People seem to forget that the (big I) Internet is a _cooperative_
network, and members of that network are under no compulsion to accept
_any_ traffic from _anywhere_ or anyone. If I decide not to allow traffic
from hosts that have the digit '2' in their IP address - that's my business,
and if that prevents you from connecting - tough nuggies. The statement
is more commonly seen on posting is news.admin.net-abuse.blocklisting as
"my servers, my rules", but it applies to networking just as much.
$ traceroute6 chia.arin.net
And of course none of the original traceroute versions supported the then
traceroute6 to chia.arin.net (2001:440:2000:1::21) from
2001:5c0:8ec3:0:211:11ff:fe33:e364, 64 hops max, 12 byte packets
4 if-5-0-1.6bb1.mtt-montreal.ipv6.teleglobe.net 299.767 ms * 92.365 ms
10 hitachi1.otemachi.wide.ad.jp 296.599 ms 299.514 ms 301.235 ms
17 sl-bb1v6-rly-t-1002.sprintv6.net 335.771 ms 327.331 ms 330.071 ms
Reminds me of the original traceroute - half way around the world to get
to a place a few hundred miles away. For people who aren't aware, Dom seems
to be in Quebec, Canada, and the trace to ARIN (in the Washington, DC metro
area) has wandered all over h*ll and gone (otemachi.wide.ad.jp is near Tokyo)
because this is an IPv6 trace.
[compton ~/IP.ADDR/stats]$ zwc -l [ALR]* | column
1002 AFRINIC.gz 36528 ARIN.gz 20431 RIPE.gz
12127 APNIC.gz 1619 LACNIC.gz 71707 total
[compton ~/IP.ADDR/stats]$ zwc -l IPv6.current.data.gz
71707 IPv4 assignments world wide verses 1410 IPv6. It's the coming thing,
but "it ain't here yet".
I'd like to see that you're right. But ICMP echo filtering is a
widespread disease in the days of "Personal Firewalls" and "stealthing".
Which would you consider more likely: A firewall that blocks echo
requests without stealthing udp 34000-35000 (or whatever the hell ports
33434 + 1 for each hop - call it 33434 -33500, chosen because there was
little likelihood of the port being in use.
or a firewall that stealths udp and allows echo requests.
And the answer is "that depends". A web page at the NSA (National Security
deny icmp any any echo
deny icmp any any redirect
deny icmp any any mask-request
permit icmp any
The web page now 404's, but that seems to have been derived from page 89 of
the Cisco Security Guide. Translated, that is block Type 8, 5, 17. I
disagree, suggesting that you allow types 0, 3, 4 and 11 INBOUND, 3, 4, and
8 OUTBOUND, while denying all else (remember that statement above - "my
servers, my rules"). Some may consider type 4 (Source Quench) as undesirable
(possible DOS). YMMV. ICMP type 3 code 4 is necessary to support Path MTU.
See RFC2923. As regards blocking UDP - at home I ignore 1025-1100 inbound
unsolicited - as a result of microsoft's incompetent re-invention of the
talk daemon being used as a spamming tool. At work, the perimeter firewalls
port translate outbound 1025-1050ish to a higher range, so there is never
any legitimate inbound traffic on that range. This allows our upstream to
silently drop that traffic. At a half Meg of crap per day per IP address,
this adds up to a substantial number with a /16 or greater.
Mind that I'm not accusing anyone of getting overzealous in this thread,
but I've seen some fierce debate in the past on this subject and I fail
to perceive the superiority of udp trace over icmp.
I haven't seen that much in debate, although google seems to indicate
otherwise, but it's starting to become a moot point. As a WAG, about 20%
of my UDP traces die before or at the destination, compared to maybe 33% for
ICMP. I have much better luck using "other" protocols, and only run into
problems where there is a block of ICMP 3 or 11. I suppose if I were
tracing to "home" IP ranges, that 20% or 33% figure would be much higher,
but I rarely have the need to make such a trace.
- Prev by Date: Re: Reliability of Networking Hardware?
- Next by Date: Re: nmap inconsistent results - via intermedite router?
- Previous by thread: Re: Blocked incoming ICMP, getting outgoing ICMP  Destination Unreachable
- Next by thread: Re: Blocked incoming ICMP, getting outgoing ICMP  Destination Unreachable