From: Brian Dennis (bdennis@internetworkexpert.com)
Date: Sat Jun 12 2004 - 02:19:16 GMT-3
Comments inline:
> 1) If I wanted to deny all UDP traffic out of the interface, I would
> also be blocking all traceroute "requests", correct?
For the Cisco IOS implementation of traceroute, yes. But
remember that you will still be able to traceroute off the router itself
if just denying UDP packets out.
> 2) If I want to block traceroutes from leaving an interface but leave
> all other UDP ports open, the UDP port used is a (pseudo)random port
> number, so it cannot be easily classified to be blocked, correct?
You will not be able to block UDP based traceroute other than
just filtering based on the default port numbers UDP based traceroute
uses and hope the users do not alter the default starting port number.
Technically if you wanted to stop UDP based traceroute altogether, you
would have to filter off all UDP ports outbound or filter inbound the
replies (time exceeded and port unreachable). As a side note, Linux, at
least RedHat 9, uses the same default UDP port number of 33434 as the
Cisco IOS.
> 3) When a traceroute packet arrives at the last hop where the
> "destination port unreachable" message is expected to be returned,
what
> happens if the UDP port is not "closed"? What if I happen to be
running
> a service on there, like PC Anywhere? Will no message be sent back to
> the source, thus causing a timeout (*) in the traceroute?
If the UDP port is actually reachable on the final destination,
then that device should not send an ICMP port unreachable message.
Example, when tracerouting to a DNS server and setting the traceroute
UDP port to 53*, the DNS server will normally send back a packet
notifying us that the DNS packet (actually traceroute probe) was
malformed.
> And furthermore, why was the standard set so loosely so that "echo
> requests" could be implemented differently by Cisco, Microsoft, etc?
Actually there is not a real standard for traceroute. As I
mentioned in an earlier e-mail, traceroute is a technique that is
implemented differently by different developers. As far as ICMP based
traceroute goes, it is a bad implementation of traceroute seeing as RFC
792 (Internet Control Message Protocol) states that an ICMP message
should not be sent about another ICMP message ;-)
<RFC 792>
The ICMP messages typically report errors in the processing of
datagrams. To avoid the infinite regress of messages about messages
etc., no ICMP messages are sent about ICMP messages.
</RFC 792>
* When testing this, remember that traceroute increments the UDP port
numbers. You will have to set the right starting UDP port number or TTL
value to test this.
Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
bdennis@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987
Direct: 775-745-6404 (Outside the US and Canada)
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Kenneth Wygand
Sent: Friday, June 11, 2004 11:01 AM
To: Andrew Caslow; ccielab@groupstudy.com
Subject: RE: icmp filtering
Bruce,
So essentially what you are saying is that the traceroute "request" is
UDP-based while the "reply" is ICMP-based. So basically the "reply"
needs to be explicitly allowed because the UDP-request cannot "reflect"
the ICMP-reply. If this is correct, a few questions come to mind:
1) If I wanted to deny all UDP traffic out of the interface, I would
also be blocking all traceroute "requests", correct?
2) If I want to block traceroutes from leaving an interface but leave
all other UDP ports open, the UDP port used is a (pseudo)random port
number, so it cannot be easily classified to be blocked, correct?
3) When a traceroute packet arrives at the last hop where the
"destination port unreachable" message is expected to be returned, what
happens if the UDP port is not "closed"? What if I happen to be running
a service on there, like PC Anywhere? Will no message be sent back to
the source, thus causing a timeout (*) in the traceroute?
And furthermore, why was the standard set so loosely so that "echo
requests" could be implemented differently by Cisco, Microsoft, etc?
Kenneth E. Wygand
Systems Engineer, Project Services
CISSP #37102, CCNP, CCDP, ACSP, Cisco IPT Design Specialist, MCP, CNA,
Network+, A+
Custom Computer Specialists, Inc.
"The only unattainable goal is the one not attempted."
-Anonymous
-----Original Message-----
From: Andrew Caslow [mailto:abcaslow@netmasterclass.net]
Sent: Friday, June 11, 2004 12:38 PM
To: Kenneth Wygand; ccielab@groupstudy.com
Subject: RE: icmp filtering
Ken,
As you mentioned, traceroute uses UDP packets when it generates the
traceroute probe packets. These UDP packets originate from the device
that executed the traceroute command. Yes, traceroute uses UDP; however
the whole purpose of traceroute is to generate ICMP messages from
transit IP devices between the source (transit devices such as routers)
and the ultimate target of the traceroute. These traceroute generated
ICMP messages allow you to see the specific path to a given destination.
Traceroute depends on the common router practice of sending an ICMP Time
Exceeded message to the source when a traceroute generated packet
attains the TTL value of 0. This is in conformance to RFC 1812 (The
Router Requirements RFC) Section 5.3.1 Time to Live (TTL). This section
states:
" If the TTL is reduced to zero (or less), the packet MUST be discarded,
and if the destination is not a multicast address the router MUST send
an ICMP Time Exceeded message to the source."
So, a traceroute traffic pattern consists of: outbound UDP traffic and
return path ICMP traffic. A traceroute traffic pattern does not consist
of outbound ICMP traffic and inbound UDP traffic.
Here is some sample output. For the following traceroute:
r1#traceroute 172.16.35.5
Type escape sequence to abort.
Tracing the route to 172.16.35.5
1 172.16.123.3 12 msec 12 msec 12 msec
2 172.16.35.5 12 msec * 12 msec
The following debug was generated:
IP: s=172.16.123.1 (local), d=172.16.35.5 (Serial0/0.123), len 28,
sending
UDP src=33377, dst=33434
IP: s=172.16.123.3 (Serial0/0.123), d=172.16.123.1 (Serial0/0.123), len
56, rcvd 3
ICMP type=11, code=0
IP: s=172.16.123.1 (local), d=172.16.35.5 (Serial0/0.123), len 28,
sending
UDP src=33251, dst=33436
IP: s=172.16.123.1 (local), d=172.16.35.5 (Serial0/0.123), len 28,
sending
UDP src=34293, dst=33437
IP: s=172.16.35.5 (Serial0/0.123), d=172.16.123.1 (Serial0/0.123), len
56, rcvd 3
ICMP type=3, code=3
Notice that all of the sent packets were UDP and all of the received
packets are ICMP. In particular, two types of ICMP messages were
received:
ICMP Type 11 Code 0 (Time Exceeded)
ICMP Type 3 Code 3 (Port Unreachable)
The ICMP "Time Exceeded" messages are generated by the routers in the
path taken by the traceroute probe.
The ICMP "Port Unreachable" message is generated by the target
traceroute device.
For Cisco access-lists, the ACL keyword to match on ICMP time exceeded
messages is "time-exceeded". For ICMP port unreachable messages, the IOS
gives you two options "port-unreachable" and "unreachable". The first
ACL keyword is for only ICMP "port-unreachable messages" the second
keyword is for all ICMP "unreachable" messages.
See the following site for all ICMP message types:
http://www.iana.org/assignments/icmp-parameters
Therefore, when you encounter a configuration requirement that instructs
you to block traceroute traffic, carefully consider whether the
requirement is for blocking outbound traceroute traffic, this is UDP
traffic only, or is it return-path traceroute traffic, this is ICMP
traffic only.
For more details on how traceroute works, take a look that the following
NetMasterClass Tech-Note at http://www.netmasterclass.net/site/lib.php
"Debugging Techniques with Traceroute"
HTH,
-Bruce Caslow CCIE #3139
NetMasterClass, LLC
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Kenneth Wygand
Sent: Friday, June 11, 2004 10:31 AM
To: Brian McGahan; ccie2be; Group Study
Subject: RE: icmp filtering
Figure that out. Cisco traceroute uses UDP, yet it's matched in an ACL
as "permit _icmp_ any any time-exceeded" and "permit _icmp_ any any
unreachable".
Is it even possible to match traceroutes with a "permit udp" command?
Kenneth E. Wygand
Systems Engineer, Project Services
CISSP #37102, CCNP, CCDP, ACSP, Cisco IPT Design Specialist, MCP, CNA,
Network+, A+
Custom Computer Specialists, Inc.
"The only unattainable goal is the one not attempted."
-Anonymous
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Brian McGahan
Sent: Tuesday, June 08, 2004 7:18 PM
To: ccie2be; Group Study
Subject: RE: icmp filtering
> ***************
> Since a traceroute uses ping, and the icmp message type isn't
considered
> since all messages types are allowed, wouldn't any type of icmp
message
> type
> be allowed back in by virtue of the "permit icmp any any reflect ICMP"
and
> therefore negate the need for explicitly allowing
> the icmp time-exceeded and unreachable message types?
>
> **********************
Cisco traceroute doesn't use ICMP, it uses UDP. Read Lab 3 task 10.1 -
10.3 breakdown for more info.
HTH,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
> -----Original Message-----
> From: ccie2be [mailto:ccie2be@nyc.rr.com]
> Sent: Tuesday, June 08, 2004 6:07 PM
> To: Brian McGahan; Group Study
> Subject: Re: icmp filtering
>
> Thanks for getting back to me.
>
> See comments in-line.
> ----- Original Message -----
> From: "Brian McGahan" <bmcgahan@internetworkexpert.com>
> To: "ccie2be" <ccie2be@nyc.rr.com>; "Group Study"
<ccielab@groupstudy.com>
> Sent: Tuesday, June 08, 2004 6:02 PM
> Subject: RE: icmp filtering
>
>
> Tim,
>
> What about the question and solution implies this? The question
> says:
>
> "Configure your network so that ICMP traffic is only allowed into your
> network if the traffic was initiated from behind R5. For diagnostic
and
> troubleshooting purposes, ensure that users throughout your network
are
> still able to traceroute from behind R5."
>
> The solution is:
>
> R5:
> interface Ethernet0/1
> ip access-group DENY_SNMP in
> ip access-group EVALUATE_ICMP out
> !
> ip access-list extended DENY_SNMP
> deny udp any any eq snmp
> permit icmp any any time-exceeded
> permit icmp any any unreachable
> evaluate ICMP
> deny icmp any any
> permit ip any any
> !
> ip access-list extended EVALUATE_ICMP
> permit icmp any any reflect ICMP
> permit ip any any
>
> Essentially you are watching ICMP traffic that is exiting:
>
> permit icmp any any reflect ICMP
>
> and you are allowing it back in only if was initiated from the
> inside:
>
> evaluate ICMP
> deny icmp any any
>
> ***************
> Since a traceroute uses ping, and the icmp message type isn't
considered
> since all messages types are allowed, wouldn't any type of icmp
message
> type
> be allowed back in by virtue of the "permit icmp any any reflect ICMP"
and
> therefore negate the need for explicitly allowing
> the icmp time-exceeded and unreachable message types?
>
> **********************
>
> but you are allowing trace replies back:
>
> permit icmp any any time-exceeded
> permit icmp any any unreachable
>
> How does this relate to echo or echo-reply?
>
> HTH,
>
> Brian McGahan, CCIE #8593
> bmcgahan@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987 x 705
> Outside US: 775-826-4344 x 705
>
>
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > ccie2be
> > Sent: Tuesday, June 08, 2004 4:40 PM
> > To: Group Study
> > Subject: icmp filtering
> >
> > Hi guys,
> >
> > I hope this isn't too dumb a question, but...
> >
> > Can someone confirm what this acl entry does?
> >
> > ip access-list ext ping
> > permit (or deny) icmp any any <-----
> >
> > In particular, does this allow all icmp message types or just
> echo-request
> > and
> > echo-reply?
> >
> > I've search the Doc Cd and the whole of cisco.com but couldn't find
> > anything
> > definative.
> >
> > I would think it would allow ( or deny) all icmp message types but,
> I'm
> > doing
> > practice IE lab 2, task 10.8 - 10.10 and the solution seems to
> indicate
> > that
> > it only permits message types echo-request and echo-reply.
> >
> > Any feedback would be appreciated. Also, if someone knows of any
> links
> > which
> > discusses in detail, please let me know.
> >
> > TIA, Tim
> >
> >
>
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:38 GMT-3