[c-nsp] Hiding a Cisco Router from a Traceroute

[Gordon Bezzina]

Hi,

I do not know if this is possible with an ACL, but I would like to hide my
network topology from the internet.

Eg. trace to c.c.c.c

1 a.a.a.a
2 b.b.b.b
3 c.c.c.c

Assume that c.c.c.c is final client whilst b.b.b.b is my border router and
a.a.a.a and before is from the Internet. Now I want to set up an ACL that
hides from b onwards. Excuse my ignorance, but I cannot find a clean way to
do it. Obviously, I still want my client to be able to perform pings and
tracroutes to the external world.

Thanks/Regards
Gordon Bezzina

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Saku Ytti]

Post by Gordon Bezzina
I do not know if this is possible with an ACL, but I would like to hide my
network topology from the internet.

With ACL people doing traceroute will notice that there is node there,
but they will not know it's IP.
With MPLS you can hide all your core routers (routers that only
have your routers as adjacent routers).

Post by Gordon Bezzina
Eg. trace to c.c.c.c
1 a.a.a.a
2 b.b.b.b
3 c.c.c.c
Assume that c.c.c.c is final client whilst b.b.b.b is my border router and
a.a.a.a and before is from the Internet. Now I want to set up an ACL that
hides from b onwards. Excuse my ignorance, but I cannot find a clean way to
do it. Obviously, I still want my client to be able to perform pings and
tracroutes to the external world.
Thanks/Regards
Gordon Bezzina
_______________________________________________
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Kristofer Sigurdsson]

Hi,

Post by Gordon Bezzina
Hi,
I do not know if this is possible with an ACL, but I would like to hide my
network topology from the internet.
Eg. trace to c.c.c.c
1 a.a.a.a
2 b.b.b.b
3 c.c.c.c
Assume that c.c.c.c is final client whilst b.b.b.b is my border router and
a.a.a.a and before is from the Internet. Now I want to set up an ACL that
hides from b onwards. Excuse my ignorance, but I cannot find a clean way to
do it. Obviously, I still want my client to be able to perform pings and
tracroutes to the external world.

See ramble at the end...

Here's how traceroute is done:

The host sends a UDP packet on port 33435 to the host he's
traceroute'ing to, with a TTL of 1.
The first router on the way decrements the TTL to 0, which means
the packet can't go any further. This router sends an ICMP time to
live exceeded packet back to the host to inform you of this, this
gives your traceroute tool the info it needs about the first router
on the way.

Traceroute now does the same thing, except the port number is now
33436, and TTL 2. The second router on the way sends the ICMP time
to live exceeded back...etc.

This is repeated with incrementing port numbers and TTL's, until the
end host responds.

To disable this, you could for example create an ACL on b.b.b.b banning
ICMP time to live exceeded from your routers to the end host, or banning
UDP ports 33435 - 33465 from the end host to your routers.

Ramble:

Disabling traceroute means disabling a very useful tool in all sorts of
debugging. This is something users should have, it both gives clued
individuals a way to find out if their system is broken or the service
provider's, thereby reducing the load on the service provider's help
desk and this command is something the help desk is likely to ask the
customer to use in diagnosing problems.

You really should ask yourself why you want to disable traceroute. If
it's for security reasons, maybe you should try and find out why your
network is so vulnerable it is dangerous for people to know the IP
addresses or basic scheme of your network.

End of ramble.

[Babak Farrokhi]

Hi,

I am not sure if it is possible in cisco routers, but you should ask
your router to do not modify (reduce) TTL value in packets. Once you
could do it, the hop won't show up in traceroute output.

Post by Kristofer Sigurdsson
Hi,

Post by Gordon Bezzina
Hi,
I do not know if this is possible with an ACL, but I would like to hide my
network topology from the internet.
Eg. trace to c.c.c.c
1 a.a.a.a
2 b.b.b.b
3 c.c.c.c
Assume that c.c.c.c is final client whilst b.b.b.b is my border router and
a.a.a.a and before is from the Internet. Now I want to set up an ACL that
hides from b onwards. Excuse my ignorance, but I cannot find a clean way to
do it. Obviously, I still want my client to be able to perform pings and
tracroutes to the external world.

See ramble at the end...
The host sends a UDP packet on port 33435 to the host he's
traceroute'ing to, with a TTL of 1.
The first router on the way decrements the TTL to 0, which means
the packet can't go any further. This router sends an ICMP time to
live exceeded packet back to the host to inform you of this, this
gives your traceroute tool the info it needs about the first router
on the way.
Traceroute now does the same thing, except the port number is now
33436, and TTL 2. The second router on the way sends the ICMP time
to live exceeded back...etc.
This is repeated with incrementing port numbers and TTL's, until the
end host responds.
To disable this, you could for example create an ACL on b.b.b.b banning
ICMP time to live exceeded from your routers to the end host, or banning
UDP ports 33435 - 33465 from the end host to your routers.
Disabling traceroute means disabling a very useful tool in all sorts of
debugging. This is something users should have, it both gives clued
individuals a way to find out if their system is broken or the service
provider's, thereby reducing the load on the service provider's help
desk and this command is something the help desk is likely to ask the
customer to use in diagnosing problems.
You really should ask yourself why you want to disable traceroute. If
it's for security reasons, maybe you should try and find out why your
network is so vulnerable it is dangerous for people to know the IP
addresses or basic scheme of your network.
End of ramble.
--
Kristófer Sigurðsson Tel: [phone]
Netrekstur/Network Operations IP Fjarskipti ehf.
_______________________________________________
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

--
Babak Farrokhi
email: ***@farrokhi.net
web: http://farrokhi.net/

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Jay Ford]

Post by Babak Farrokhi
I am not sure if it is possible in cisco routers, but you should ask
your router to do not modify (reduce) TTL value in packets. Once you
could do it, the hop won't show up in traceroute output.

Bad idea. The TTL exists to squash loops. Don't disable the basic TTL
mechanism, even if you can.

As was said, please leave traceroute enabled. You apparently find it useful
to be able to trace through other nets (based on your desire to have your
client continue to be able to use it), so please reciprocate by letting the
rest of us trace through your net.

________________________________________________________________________
Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-***@uiowa.edu, phone: [phone], fax: [phone]
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[John Kristoff]

On Thu, 20 Oct 2005 17:12:37 +0000

Post by Kristofer Sigurdsson
The host sends a UDP packet on port 33435 to the host he's
traceroute'ing to, with a TTL of 1.

You can effectively do a traceroute using any IP protocol and Windows
by default uses ICMP echoes.

I thought someone pointing out that MPLS can hide the topology was
interesting. That would have to be one of the most peculiar reasons
for implementing MPLS though. :-)

I agree with the sentiment expressed in the note I'm replying to that
blocking it is of dubious merit. Hoewver, if you insist, rather than
a router ACL you probably want to look at a more sophisticated firewall
solution.

John
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Adam Greene]

Following up on this discussion ... in effect, we "block" traceroutes by
implementing private IP addresses on router interfaces within our network.
We viewed the utilization of private IP addresses as a security enhancement
(i.e. the internal routers will never be victims of DoS attacks originating
from outside our network). However, it obviously has the major disadvantage
of disabling a useful (essential?) diagnostic tool. Has anyone else faced
this particular dilemma? It sounds like most of us would suggest utilizing
public IP addresses on router inerfaces throughout our networks.

----- Original Message -----
From: "John Kristoff" <***@northwestern.edu>
To: <cisco-***@puck.nether.net>
Sent: Friday, October 21, 2005 8:32 PM
Subject: Re: [c-nsp] Hiding a Cisco Router from a Traceroute

Post by John Kristoff
On Thu, 20 Oct 2005 17:12:37 +0000

Post by Kristofer Sigurdsson
The host sends a UDP packet on port 33435 to the host he's
traceroute'ing to, with a TTL of 1.

You can effectively do a traceroute using any IP protocol and Windows
by default uses ICMP echoes.
I thought someone pointing out that MPLS can hide the topology was
interesting. That would have to be one of the most peculiar reasons
for implementing MPLS though. :-)
I agree with the sentiment expressed in the note I'm replying to that
blocking it is of dubious merit. Hoewver, if you insist, rather than
a router ACL you probably want to look at a more sophisticated firewall
solution.
John
_______________________________________________
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
---
[This e-mail was scanned for viruses by Webjogger's AntiVirus Protection

System]
---
[This e-mail was scanned for viruses by Webjogger's AntiVirus Protection System]

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Robert Kiessling]

Post by Adam Greene
Following up on this discussion ... in effect, we "block" traceroutes by
implementing private IP addresses on router interfaces within our network.
We viewed the utilization of private IP addresses as a security enhancement
(i.e. the internal routers will never be victims of DoS attacks originating
from outside our network).

Implementing private IP addresses on links between your routers
violates RFC1918 unless you implement filters on your borders.
You still originate the ICMPs and they still reach the sources
(unless filtered). This is a very bad idea.

One solution to your problem is to use addresses for the links
which are assigned to you (eg. by ARIN or RIPE or an intermediary)
but which are not advertised in the DFZ. You can for example
getting PI addresses separate from your normal PA addresses.

This way users see the same traceroute results including reverse
DNS, but noone outside your AS can directly reach your routers.

There is a catch though. Some networks implement lose RPF filters
which in this case means your ICMP responses will be filtered by
those networks and not reach external users tracerouting to you.

There is a workaround though. You can advertise that netblock
from somewhere external to your network to "trick" the lose RPF
filters. If you do this you might also wish to add reverse DNS to
some interfaces on that way that say something like
do-not-traceroute-to-this-address.the-results-are-completely-meaningless.your.net

Robert

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Kristofer Sigurdsson]

Post by Robert Kiessling

Post by Adam Greene
Following up on this discussion ... in effect, we "block" traceroutes by
implementing private IP addresses on router interfaces within our network.
We viewed the utilization of private IP addresses as a security enhancement
(i.e. the internal routers will never be victims of DoS attacks originating
from outside our network).

Implementing private IP addresses on links between your routers
violates RFC1918 unless you implement filters on your borders.
You still originate the ICMPs and they still reach the sources
(unless filtered). This is a very bad idea.

Since these addresses are meant for use for networks not connected
to the Internet (see sec. 2 of RFC1918), this violates RFC1918, filters
or no filters.

Post by Robert Kiessling
One solution to your problem is to use addresses for the links
which are assigned to you (eg. by ARIN or RIPE or an intermediary)
but which are not advertised in the DFZ. You can for example
getting PI addresses separate from your normal PA addresses.
This way users see the same traceroute results including reverse
DNS, but noone outside your AS can directly reach your routers.
There is a catch though. Some networks implement lose RPF filters
which in this case means your ICMP responses will be filtered by
those networks and not reach external users tracerouting to you.
There is a workaround though. You can advertise that netblock
from somewhere external to your network to "trick" the lose RPF

If you use addresses for your router interfaces that cannot be reached
from the general user, or if you filter ICMP to/from the interfaces
somehow, you will break MTU path discovery, thereby making your users
unable to reach a significant part of the Internet, and possibly a large
number of users will be unable to reach your services (eg. www).

[Robert Kiessling]

Post by Kristofer Sigurdsson
If you use addresses for your router interfaces that cannot be reached
from the general user [...] you will break MTU path discovery,

That's an argument frequently heard, but nontheless invalid.
All pMTUd needs is that the ICMP response from the router goes
back to the user. The other direction, whether the user can
reach the router, is irrelevant for that purpose.

Post by Kristofer Sigurdsson
thereby making your users
unable to reach a significant part of the Internet, and possibly a large
number of users will be unable to reach your services (eg. www).

That's only true on a link with an MTU smaller than the packets
that should be sent over it.

In practice that means links with 1500 MTU never cause "fragmentation
needed" since packets will always traverse a network segment with an
MTU of 1500 or smaller before entering your backbone.

It typically causes issues (only) on DSL links, but I don't think
that's what the previous poster was asking about. And what I suggest
does not break pMTUd in any case.

Robert

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Kristofer Sigurdsson]

Post by Robert Kiessling

Post by Kristofer Sigurdsson
If you use addresses for your router interfaces that cannot be reached
from the general user [...] you will break MTU path discovery,

That's an argument frequently heard, but nontheless invalid.
All pMTUd needs is that the ICMP response from the router goes
back to the user. The other direction, whether the user can
reach the router, is irrelevant for that purpose.

This was an "ooops" on my part - that should have read "that cannot
reach the user". If you use RFC1918 addresses on your router
interfaces, this will be the case.

If you block ICMP to your users, however, they will not receive
fragmentation requests.

Post by Robert Kiessling

Post by Kristofer Sigurdsson
thereby making your users
unable to reach a significant part of the Internet, and possibly a large
number of users will be unable to reach your services (eg. www).

That's only true on a link with an MTU smaller than the packets
that should be sent over it.
In practice that means links with 1500 MTU never cause "fragmentation
needed" since packets will always traverse a network segment with an
MTU of 1500 or smaller before entering your backbone.

This is also true, but the thing is, a lot of connections "out there"
have an MTU under 1500, eg. various tunnels.

Post by Robert Kiessling
It typically causes issues (only) on DSL links, but I don't think
that's what the previous poster was asking about. And what I suggest
does not break pMTUd in any case.

DSL links are getting quite common. ;)

[Joe Maimon]

Post by Robert Kiessling

Post by Adam Greene
Following up on this discussion ... in effect, we "block" traceroutes by
implementing private IP addresses on router interfaces within our network.
We viewed the utilization of private IP addresses as a security enhancement
(i.e. the internal routers will never be victims of DoS attacks originating
from outside our network).

Implementing private IP addresses on links between your routers
violates RFC1918 unless you implement filters on your borders.
You still originate the ICMPs and they still reach the sources
(unless filtered). This is a very bad idea.
One solution to your problem is to use addresses for the links
which are assigned to you (eg. by ARIN or RIPE or an intermediary)
but which are not advertised in the DFZ. You can for example
getting PI addresses separate from your normal PA addresses.

The other solution involves nat. Which can become problematic quickly.

However, it sure would be nice to be able to have all otherwise
meaningless ip addresses for links in a router be rfc1918, with the
ability to lowprocesser intensive nat ICMP generated from the box itself
without involving any other traffic transitting any other interfaces.

Something similar to ip local policy-route would be nice for nat.

So you could sum up hundreds of rfc1918 interface addresses into one
loopback public address null routed in your AS, but part of a prefix
announced to to the world, with no leakage, no change of route direction
for the ICMP replies and without having to reveal specifics other than a
chosen address identifier for the box.




_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[james edwards]

If you block traceroute you will likely break path MTU discovery. This is a
bad idea all round.

James
Routing and Security Administrator
At the Santa Fe Office: Cyber Mesa Telecom
***@cybermesa.com ***@cybermesa.com
http://www.cybermesa.com/ContactCM
[phone]

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Kristofer Sigurdsson]

Post by james edwards
If you block traceroute you will likely break path MTU discovery. This is a
bad idea all round.

If you only block ICMP Time to live exceeded, ICMP packets requesting
fragmenting the packets will most likely survive.

However, I completely agree, it's a bad idea, that goes for disabling
traceroute and especially breaking the path MTU discovery mechanism.
Too many intellectually challenged sysadmins block ICMP to/from their
(www) servers, making the use of links with lower MTU than 1500 pretty
near impossible.

[Church, Chuck]

Post by Robert Kiessling
That's an argument frequently heard, but nontheless invalid.
All pMTUd needs is that the ICMP response from the router goes
back to the user. The other direction, whether the user can
reach the router, is irrelevant for that purpose.

But, if the router replying with a packet too big ICMP message is using
1918 address space, and on the way back to the end user, it crosses an
ISP doing (as they probably should) 1918 and other bogon source and
destination filtering, that PTB ICMP message with a 1918 source address
would get dropped. I guess if you are going to use 1918 addresses on
your network, then you should use at least a 1500 byte MTU...

Chuck Church
Lead Design Engineer
CCIE #8776, MCNE, MCSE
Netco Government Services - Design & Implementation
1210 N. Parker Rd.
Greenville, SC 29609
Home office: 864-335-9473
Cell: 703-819-3495
***@netcogov.com
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4371A48D



_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Adam Greene]

Thanks for the feedback. It's sounding like the best idea is to use
publically routable IP addresses on my router interfaces, and until I
accomplish that change, make sure filters are in place preventing any
packets from leaving my network with private source IP's. I guess I can set
up ACLs determining what type of traffic I will allow in from the Internet
to my router interface addresses.

The other alternative I understand that Robert is suggesting is utilizing a
block of PI addresses on the routers, and not advertising that block
upstream. However, this would still break traceroute for end-users of
providers implementing loose RPF.

From that p.o.v. the first option sounds better to me.

One more thing: just to clarify (to better understand the extent of my
error): perhaps the violation of RFC 1918 Kristofer states even with filters
in place is a matter of interpretation? Section 5 of the RFC states, "It is
strongly recommended that routers which connect enterprises to external
networks are set up with appropriate
packet and routing filters at both ends of the link in order to prevent
packet and routing information leakage."

Thanks for all your help.
Adam

---
[This e-mail was scanned for viruses by Webjogger's AntiVirus Protection System]

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/