For lack of better wording, how do I make a router invisible?
I see the carriers do it all the time. When a tracert happens, I want no IP to show up but continue on so that it will eventually get to its destination.
I know you can use an access list on a router to control the types of icmp messgaes that are allowed. For example:
access-list 110 deny icmp any any echo-reply
I hope this helps.
Hmmm... so this would be assigned to the T1 or ATM interface?
That seems to easy... thats it? I guess I was under the impression that a trace route kind of worked a little differently than a ping. I know it pings back, but its got to figure out the hops. I thought there was a way to some how disable that so that a tracert couldnt find the hop, but normal traffic would still go through it.
If this is all thats needed, thats a very simple fix for me!
Here are some further examples:
access-list 110 deny icmp any any echo
access-list 110 deny icmp any any echo-reply
access-list 110 deny icmp any any packet-too-big
access-list 110 deny icmp any any source-quench
access-list 110 deny icmp any any time-exceeded
I hope this helps.
If this helps you please rate my post, thanks.
trace route uses ping or icmp packets to work. basicly it pings each hop in the routing path. So the access lists will work by not allowing the router to accept or respond to ping requests. One word of caution, it also means you can not ping the routers in question unless you specificly allow ping from your location.
I dont want to block them all together. I just dont want the router to respond to PINGS. If I apply this access list then all pings will get blocked then. I need to specifically write an access-list to not allow pings from that interface correct sourcing from itself right?
Yes, you need to create a custom access list for your environment that prevents the router itself from processing icmp messages. For example:
access-list 110 deny icmp any host x.x.x.x
where x.x.x.x is your router's interface
Then apply the acl to the interface.
If this post helps please rate my post, thanks.
I think the command you're looking for is 'no icmp unreachables". I believe that will supress the ttl exceeded icmp message used by traceroute.
Traceroute works by sending some packet (some use udp, other use icmp) with an initial ttl of 1. Each subsequent packet goes out with the ttl incremented by one. The effect of this is that at each router hop where the ttl is decremented by one, an icmp ttl exceeded error is sourced by that router back to the sender. Thus a record is created of each hop traversed between a source and destination.
Obviously asymetric routing is another issue.
Well I have the no icmp unreachables on the interface. Thats always been part of my config for my routers. So I built an access list to deny the pings. Weird thing is if you do a ping to the router interface it comes back as unreachable. But if you do a tracert it sees the IP. There has to be something that disables this.
Tracing route to server [10.200.148.11]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 10.200.81.251
2 1 ms 1 ms <1 ms 10.200.100.1
3 6 ms 5 ms 9 ms 10.200.90.34
4 6 ms 9 ms 9 ms 10.200.91.6
5 5 ms 9 ms 5 ms 10.200.148.11
Pinging 10.200.91.6 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
access-list 110 deny icmp host 10.200.91.6 any
access-list 110 deny icmp any host 10.200.91.6
access-list 110 permit ip any any
ip address 10.200.91.6 255.255.255.252
no ip redirects
no ip unreachables
no ip proxy-arp
ip route-cache flow
no cdp enable
no mop enabled
I have 2 corrections to things that have been said in this discussion.
- the statement that traceroute uses ping may be true and may be not true, depending on what is issuing the traceroute. If a Windows system uses the tracert command then the traceroute will use ping. But if a Cisco router or Unix system issue the traceroute command then it will use UDP packets for the traceroute. So trying to solve this with access lists is problematic (how do you know what UDP port number would be used for a particular traceroute - since the port number increments for each hop along the path).
- Mike was on the right track about how to make the router not respond to traceroute, but got the syntax slightly off. It is not no icmp unreachable but is no ip reachable (which gets configured on the interface).
Rick is correct in the way that traceroute works. It sends udp or icmp packet which are set to expire. However the no ip unreachables command stops the router from sending unreachable messages, however I at least on the IOS we are running, it stop icmp host unreachable, icmp network unreachable, and icmp administratively prohibited, and probably a few others. The icmp message sent by the trace back to the destination is an icmp time-exceeded message. If you put in your access-list deny icmp time-exceeded, it should stop the replies to the traceroute probes, effectively making your router "invisible."
Regarding the comment that you see carriers do it all the time, most of the time that is because they are running an MPLS core, and have the customer routes only on the edge routers. This means that the packet will go into an MPLS tunnel through there network until it exits on the other side of their network. Their core routers use the mpls tag to determine where to forward the packet, rather than the destination ip address. Therefore when a packet's TTL expires in mid transit, it does not have a route back to the source, and the router drops the packet.
But there is a flaw in that approach. An outbound access list will not filter pacekts originated by the router. So you could put statements in the outbound access list to deny icmp time-exceeded, but it would not stop the router from generating and sending the responses. It can stop packets going through the router but not packets originated by the router.
I believe that if you want the router to be invisible it must be really invisible (no host unreachable, no network unreachable, not just no time-exceeded).
The router on the edge of your network will still send the icmp time-exceeded message because outbound access-lists do not apply to traffic generated by the router as you said, but that is as far into your network as they will get. Setting no ip unreachables on every interface is a good thing, in that it stops the router from generating the various unreachable message, however, it does not stop the time exceeded message. We have no ip unreachables turned on every interface in our network, but you can still run a traceroute through our network.
And as you can see in the poster's config, he already has it set on his interface, but traceroute still responds.
I dont see a command for the commands you guys were talking about unless its a sub command somewhere...
What commands to do I need to enable?
In the access-list applied to your interface, you need to block icmp time-exceeded. This will not stop your router from responding to a trace probe, but it will revent further replies. So if you create and access-list with the following entry:
access-list 110 deny icmp any any eq time-exceeded
and apply that access-group to your interface it will block traceroutes. To test this put it as an outbound access-list facing the windows PC you are running the traceroute from. The last response you should get is the one from that router. Any responses beyond that will get blocked.
In practice, you need to apply the access-list outbound on your external facing interface, which will prevent anyone from tracing into your network any further than your external router. The last reachable hop on the traceroute from the outside should be the router. None of your internal infrastucture will be revealed. This will also still allow you to do traceroutes out of your network, but keep people on the outside from tracing in.
My mistake. It doesn't look like TTL exceeded is one of the ICMP type 3 unreachable messages.
Apparently it's an ICMP type 11 message.
As i understand you just want to decrease the number of hops in traceroute. It can be done by opennig a GRE tunnel end-to-end or on the path you want to hide. And than just do necessary routing and the user will see only tunnel ip addresses nothing more.
Hope this is what you are looking for.
I setup the GRE tunnel. However when its assigned to my core router, Pings stop.
ip address 126.96.36.199 255.255.255.252
tunnel source x.x.x.x (my core)
tunnel destination x.x.x.x (my public outside)
access-list 111 deny icmp 10.200.78.0 0.0.0.255 any
access-list 111 deny icmp any 10.200.78.0 0.0.0.255
access-list 111 deny icmp 10.200.81.0 0.0.0.255 any
access-list 111 deny icmp any 10.200.81.0 0.0.0.255
access-list 111 permit icmp any any
access-list 111 permit udp any any gt 33434
route-map GRE permit 20
match ip address 111
set ip next-hop 188.8.131.52
show route GRE
route-map GRE, permit, sequence 20
ip address (access-lists): 111
ip next-hop 184.108.40.206
Policy routing matches: 10555 packets, 996642 bytes
I have on my firewall permitting GRE and it shows tons of hits. The outside router shows this:
ip address 220.127.116.11 255.255.255.252
tunnel source x.x.x.x (my public outside)
tunnel destination x.x.x.x (internal core)
I dont have anything else assigned to this router other than this command. I was told that this was all that needs to be done. But Im assuming at this point that I have to build an access-list and assign it to the tunnel too right? This access-list is going to be more complicated if thats the case..
Well this got extremely complicated with my NAT/PAT I do on some firewalls. So scrapped that with the GRE tunnel and was able to do this:
access-list 110 permit icmp any any time-exceeded
route-map NULL permit 10
match ip address 110
set interface Null0
ip local policy route-map NULL
All I need to do now is just add a deny to the access list on the networks that need to see trace routes...
Your best bet to deny traceroute and pings into your network would be to put and access-list outbound on your external router which blocks outbound icmp echo-reply and time-exceeded messages. That will prevent people from pinging in or tracing into your network, but will still allow you to ping out and trace out.
The other thing, I would like to say be very careful running a GRE tunnel through a firewall. You pretty much defeat the purpose of the firewall since the traffic matching the GRE rule is passed through the firewall, preventing any kind of filtering that is normally done by the firewall. It provides another backdoor into your network.
Try this, it will stop your router responding to traceroute requests.
ip local policy route-map NO_TRACEROUTE
ip access-list extended no_traceroute
permit icmp any any time-exceeded
permit icmp any any port-unreachable
route-map NO_TRACEROUTE permit 10
match ip address no_traceroute
set interface Null0
But the problem with that approach is it does not allow you to perform a traceroute out of your network as it applies to your traces as well. I still think the best option is to block outgoing time-execeeded messages and outgoing echo replies. Additionally, you could block incoming icmp echo requests, and incoming udp packets with ports above 33000
Actually it does work. What I listed was just for everything. I have gone back and added denies before the permit on the access list for the networks I do not want to be affected by this policy map.
Outside of using MPLS, and using the MPLS propagate ttl feature, I think Ekiriakos suggestion is the best.
Like you mentioned, applying the access-list to the interface implies that all icmp ttl exceeded packets are dropped. Hence, the traceroutes can not proceed beyond the router.
However, by creating a local policy, which applies to packets originating from the router, you can deny icmp ttl exceeded messages from being originated by the router, while the router will start route the icmp packets. Hence, in your traceroute, you get asterisks, rather than the ip address and the trace continues.
As said before, the MPLS will be the best, and I think a number of service provider are using this. It hides the entire core, because you do not even see the asterisks. Hence you do not even know the number of hops along the service provider.