4 ms·

I'm not sure about `tcptraceroute` but `traceroute -T` seems to be using SYN packets with tweaked TTL value [1]. There is an even more interesting technique -

by majke 14y ago

I'm not sure about `tcptraceroute` but `traceroute -T` seems to be using SYN packets with tweaked TTL value [1]. There is an even more interesting technique - injecting packets with modified TTL into a currently running and valid TCP/IP connection. This often can be used to detect network setup behind NAT on the server side. I think the most famous attempt was 0trace by Michal Zalewski [2] but there are many implementations. Oh boy, one day I even created an Nmap script to do this [3], those were the days :) [1] http://linux.die.net/man/8/traceroute http://linux.die.net/man/8/traceroute [2] http://seclists.org/fulldisclosure/2007/Jan/145 http://seclists.org/fulldisclosure/2007/Jan/145 [3] http://seclists.org/nmap-dev/2007/q3/186 http://seclists.org/nmap-dev/2007/q3/186

X-Istence 14y ago
And that is why you should scrub all incoming packets and make sure that they don't have a TTL that is too low ... PF's scrub reassemble tcp for example will make sure that the TTL can't be lowered in an already existing connection ... [1] http://www.openbsd.gr/faq/pf/scrub.html http://www.openbsd.gr/faq/pf/scrub.html
- chrisbolt 14y ago
  If you scrub packets where the TTL changes, what happens to a connection where the route changes and the TTL has a valid reason for changing?
- majke 14y ago
  Alternatively - watch out what ICMP errors are outgoing from your servers. (But don't block all ICMP or you'll screw up MTU discovery [1]) If you're worried about exposing your internal setup you also need to filter packets with unusual IP flags such as "Record Route" [2] or "Internet Timestamp" [3]. Fortunately scrub should notice that. [1] http://en.wikipedia.org/wiki/Path_MTU_Discovery http://en.wikipedia.org/wiki/Path_MTU_Discovery [2] http://tools.ietf.org/html/rfc791#page-18 http://tools.ietf.org/html/rfc791#page-18 [3] http://tools.ietf.org/html/rfc791#page-22 http://tools.ietf.org/html/rfc791#page-22 If you have a source NAT on your servers, it's likely that an attacker can easily detect that, no matter ICMP / TTL / IP options setting. Running p0f on established connections will show your setup, for example: http://seclists.org/nmap-dev/2007/q1/175 http://seclists.org/nmap-dev/2007/q1/175
  - X-Istence 14y ago
    It becomes much harder to identify NAT when you also scrub out going packets, and change the packet IP identification field with a random-id. Other things that help as well is to not load balance the TCP/IP connection, but rather terminate on the first machine, then pass the connection through using something like varnish/haproxy.

by majke 14y ago

X-Istence 14y ago

And that is why you should scrub all incoming packets and make sure that they don't have a TTL that is too low ... PF's scrub reassemble tcp for example will make sure that the TTL can't be lowered in an already existing connection ... [1] http://www.openbsd.gr/faq/pf/scrub.html http://www.openbsd.gr/faq/pf/scrub.html

chrisbolt 14y ago
If you scrub packets where the TTL changes, what happens to a connection where the route changes and the TTL has a valid reason for changing?
majke 14y ago
Alternatively - watch out what ICMP errors are outgoing from your servers. (But don't block all ICMP or you'll screw up MTU discovery [1]) If you're worried about exposing your internal setup you also need to filter packets with unusual IP flags such as "Record Route" [2] or "Internet Timestamp" [3]. Fortunately scrub should notice that. [1] http://en.wikipedia.org/wiki/Path_MTU_Discovery http://en.wikipedia.org/wiki/Path_MTU_Discovery [2] http://tools.ietf.org/html/rfc791#page-18 http://tools.ietf.org/html/rfc791#page-18 [3] http://tools.ietf.org/html/rfc791#page-22 http://tools.ietf.org/html/rfc791#page-22 If you have a source NAT on your servers, it's likely that an attacker can easily detect that, no matter ICMP / TTL / IP options setting. Running p0f on established connections will show your setup, for example: http://seclists.org/nmap-dev/2007/q1/175 http://seclists.org/nmap-dev/2007/q1/175
- X-Istence 14y ago
  It becomes much harder to identify NAT when you also scrub out going packets, and change the packet IP identification field with a random-id. Other things that help as well is to not load balance the TCP/IP connection, but rather terminate on the first machine, then pass the connection through using something like varnish/haproxy.