In article , Brad wrote: :There are two types of traceroutes. Windows products use ICMP/ICMP :while many UNIX flavors use UDP/ICMP. With the ICMP/ICMP no ports are :used since ICMP rides inside of IP. With UDP/ICMP, UDP uses a RANDOM :high port number as the destination port so there's no way to know what :port to keep open. Feel free to do some research on the way traceroute :actually functions.
Your information is incomplete. Most Unix traceroutes use port numbers that increment off of a constant (to the program) base, with the increment being one port per hop (e.g., TTL++, port++). The port number is NOT random: it is confined to small ranges near the common base ports. There are two common base ports, the most common of which (by far) starts at 33434. A quick peak at the OpenBSD source for traceroute shows that that port number breaks down in the source as 32768+666 .
formatting link
:If I can traceroute to your systems then I can map your network which :is quite revealing
All you can "map" is the existance of the few machines to which we allow traceroute -- machines whose identities are fairly easy to discover for anyone who takes the time to do a bit of research.
:...If your letting in UDP than I can use inverse :scans to find out what services are running on your hosts.
All you can find is the 'port unreachable' to the narrow range of ports we allow. As I indicated in my previous posting, on those servers no process ever uses the port ranges in question. As I indicated earlier, we do not allow general UDP, we only allow a very confined port range.
:I have no problem with being able to traceroute within a network but no :one should be able to traceroute from outside your network to inside :your network.
The justifications you gave for this do not hold up if one manages the port range appropriately.
Meanwhile, we have telecommuters and remote offices. Of course we have VPNs to the remote offices, but if the remote firewall is not responding, we need a way to check to find out whether the problem is with the VPN or with the firewall in general, so it is not rare for me to log in from work to my home system so as to get a reachability opinion from another viewpoint.
:Most routers on the Internet will block ICMP TTL expired messages :anyways (that's why you get asterisks in the traceroute output) so the :value of a traceroute used on the Internet is quite negligible.
"Most routers" ? You have studies to back that up?
Starting from one of my machines at work, I find the following:
formatting link
15 of 17 hops respond, including endpoint response
formatting link
14 of ?? hops respond
formatting link
18 of 18 hops respond, including endpoint response
formatting link
16 of 17 hops respond, including endpoint response
formatting link
15 of 15 hops respond, including endpoint response
formatting link
20 of ?? hops respond
formatting link
12 of ?? hops respond
formatting link
19+ of ?? hops respond (router loop)
formatting link
19 of 19 hops respond, including endpoint response
formatting link
21 of 21 hops respond, including endpoint response
The above is not "selective editing" -- those are the systems I tried, and those are the results I got.
:> I don't see how one could validly say that it is "more of a paperweight :> than a firewall".
:I hope that makes it clearer.
Sorry, no it doesn't -- what it seems to indicate is that you have not read the traceroute source, nor even the traceroute man page of common traceroute implimentations such as for Linux or Solaris or Mac OSX or IRIX. Experimentally, your statistics also appear to be unjustified. Perhaps you would care to re-examine your arguments.
formatting link
formatting link
formatting link
formatting link