From: Church, Chuck (cchurch@wamnetgov.com)
Date: Fri Jun 11 2004 - 12:35:29 GMT-3
Yes, looks like Cisco traceroute starts at 33434, and increments by 1
every time:
Tracing the route to 192.168.120.1
21:28:02: IP: s=192.168.120.73 (local), d=192.168.120.1 (Ethernet0), len
28, sen
ding
21:28:02: UDP src=41021, dst=33434
21:28:05: IP: s=192.168.120.73 (local), d=192.168.120.1 (Ethernet0), len
28, sen
ding
21:28:05: UDP src=36833, dst=33435
21:28:08: IP: s=192.168.120.73 (local), d=192.168.120.1 (Ethernet0), len
28, sen
ding
21:28:08: UDP src=41466, dst=33436
21:28:11: IP: s=192.168.120.73 (local), d=192.168.120.1 (Ethernet0), len
28, sen
ding
21:28:11: UDP src=41913, dst=33437
21:28:14: IP: s=192.168.120.73 (local), d=192.168.120.1 (Ethernet0), len
28, sen
Ding
21:28:14: UDP src=35703, dst=33438
Of course other vendors (or even other Cisco IOS versions) could
differ from this. But if you wanted to block the traceroute probe (not
the TTL exceeded reply), then denying dest UDP 33434 up to say 33484
would probably suffice.
Chuck Church
Lead Design Engineer
CCIE #8776, MCNE, MCSE
Wam!Net Government Services - Design & Implementation Team
13665 Dulles Technology Dr. Ste 250
Herndon, VA 20171
Office: 703-480-2569
Cell: 703-819-3495
cchurch@wamnetgov.com
PGP key:
http://pgp.mit.edu:11371/pks/lookup?op=index&search=cchurch%40wamnetgov.
com
-----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