There are times when network administrators may configure a single host to forward various ports to other hosts at different tiers within their internal network. A single Internet Protocol (IP) address may actually represent as many machines on an internal network as it has open ports. While it is somewhat elementary to detect this, surprisingly popular tools have yet to incorporate information related to the discovery of tiered networks in their respective output. This post will guide the reader through the process of monitoring Time-To-Live (TTL) values during routine activities to acquire information about port forwarding and intrusion response surrounding remote hosts.
Understanding TTL Responses
Each time a host sends data to another, the data travels in a packet, from one host along a series of routers, switches, and other hosts, until reaching its destination. The TTL header exists within this packet and specifies how many hops the packet can travel before no longer being forwarded. Each "hop" the packet encounters decrements the TTL value in the header.
TTL's Can Reveal Route Changes
Route changes can occur semi-frequently across the internet as internet service providers tighten their relationships with Tier1 Backbone Providers. When these changes occur, every response from a host on the other side of a changed route may change TTL values at once. A route change may occur due to normal internet expansion, a network appliance restricting traffic from a particular source into a honeypot, or a port redirect for load-balancing purposes.
TTL's In Scan Responses
During a port scan, SYN packets are sent to the target host on a variety of ports in order to evoke a response, revealing which ports have services listening behind them. While all of the packets sent by the scanner (unless the scanner is told otherwise) will have the same TTL to start with, there are times when the IP address being scanned will actually have different TTL values in its responses. The differing TTL's can indicate additional "tiers" of networking behind the public IP address being scanned. The higher the TTL, the closer the host running the service is to the scanning host; the lower the TTL, the further the host is from the scanning host.
In other words, if the host has a baseline response TTL of 47, but a response comes in with a TTL of 45, the port the response came from may be visibly forwarded. On the other hand, if a packet is received with a TTL of 48 from the same host, it may have actually originated from a device between the scanning host and the target host.
TTL's Could Betray Firewalls and Intrusion Responses
Port scanning isn't the only time it can be advantageous to monitor for TTL anomalies. Firewalls and Intrusion Prevention Systems (IPS's) between an attacker and their target can also respond with RST packets to terminate connections which are considered harmful. Because these appliances sit between the attacker and the target, the RST packet received by the attacker will have a TTL that is higher in value than that of the packets received from the target host's normal service on that port.
ttl_mon.py: A Passive Python2 TTL Monitor
In order to monitor for TTL anomalies, the team put together ttl_mon.py on github. It runs until the user exits using control+C, and prints detailed information on a host-by-host basis about the hosts it encountered during runtime. When TTL values for individual ports change during runtime, a red notification about route modification is printed to the screen. It has the ability to monitor all hosts on a given interface or a single target host while ignoring locally emitted traffic.
ttl_mon.py depends on the dpkt and pcapy packages for python2. They can be installed using the python pip module like so:
python2 -mpip install pcapy dpkt
Usage: ttl_mon.py [options] Options: -h, --help show this help message and exit -i INTERFACE, --interface=INTERFACE Interface to listen to -l LOCAL, --local=LOCAL Local address to ignore -t TARGET, --target=TARGET Only record changes for this ip