4 ms·
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 ab
by 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 agoIt 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.