From: Luis Santos (luis_santos@xxxxxxx)
Date: Mon Feb 26 2001 - 05:53:11 GMT-3
Just a few additional comments as to why Cisco even has this option on the
ACLs for ICMP traceroute.
1. The traceroute we use today uses a combination of UDP packets where the
TTL field in the IP header is gradually incremented starting with the value
1. The host doing the traceroute sends a UDP packet destined to ports that
are not likely to have any applications running - this point is important
for the success of the whole thing as it allows traceroute to know when the
trace is over. At the first the TTL is set to one which means that upon
crossing the first router it will be decremented to 0 at which point that
router will send an ICMP "Host unreachable - TTL expired in transit" message
where the source address of that message is that of the router. This way we
know who the first router is. The traceroute host then sends another message
with a TTL of 2 which passes the first router but upon hitting the second
the same thing will occur and we will know who the 2nd router is and so on,
and so on. When it finally hits the destination host and since more than
likely there are no processes running on the UDP ports being used the end
host will send an ICMP "destination unreachable - port unreachable message."
At this point the trace is over. As it has been stated, blocking the UDP
ports used is an effective way of blocking such traces, although some
traceroute apps allow you to manipulate which ports are used. You can even
run it against a well known port as long as no process is running on it.
Solution: Do not allow UDP at all except for the specific UDP based services
that you absolutely must have (DNS, NTP, etc).
2. There is however another option and that is the ICMP Record Route
function. It is a specific ICMP packet type in which the routers along a
given path write their IP address on the RR ICMP header field. This however
has severe limitations, because the maximum size an IP header can have is 60
bytes (15 times 32 bits - header length field is 4-bits and is counted in
32-bit words) this means that the maximum number of hops you can record is
limited to 9 entries. Because of this ICMP RR is not used very much if at
all. However it is a valid ICMP packet type and that is why you can filter
it specifically by means of an access list. However doing so will not block
the traditional traceroute widely used today.
HTH,
-Luis
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
JZ
Sent: Sunday, February 25, 2001 10:48 PM
To: ccielab@groupstudy.com
Subject: How to block "traceroute" output but allow "ping" ?
Hi, here is an issue regarding "traceroute" of ICMP:
rL:s0 ------------- s0:rM:S1 --------------s0:rR
| |
tr <rR:s0 ip > "ip acc-grp 100 out"
ping <rR:s0 ip>
Q: apply acl on rM:S1 (out) to block the output of
traceroute from rL to rR, but allow rL ping rR.
All routers have full IP connectivity.
My cfg. on rM: (omitting unrelated part)
!
int rM:S1
ip acc-grp 100 out
!
acl# 100 deny ICMP any any EQ Traceroute
acl# 100 perit ip any any
!
While verify, from rL using "tr <rR:s0 IP> ", the
traceroute output from both routers -- rM and rR, show up.
Ping works well.
Was anything wrong in cfg. that fails to block the output
from rR ?
Thanks in advance ,
JZ
Sunday
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:29:01 GMT-3