News for hackers. Stuff that matters.
Re:TCP Traceroute by X-Istence on Sunday February 24, 2013 @10:11PM (#5277121)
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

Re:TCP Traceroute by majke on Sunday February 24, 2013 @10:42PM (#5277203)
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

[2] http://tools.ietf.org/html/rfc791#page-18

[3] 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

Re:TCP Traceroute by X-Istence on Monday February 25, 2013 @08:42AM (#5278919)
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.

Re:TCP Traceroute by chrisbolt on Friday March 01, 2013 @01:57AM (#5303190)
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?