Internet-wide scanning (or probing) has emerged as a key measurement technique to study a diverse set of the Internet’s properties, including address space utilization, host reachability, topology, service availability, vulnerabilities, and service discrimination. But despite its widespread use and critical importance for Internet measurement, we still lack a clear understanding of IP liveness—whether a target IP address responds to a probe packet. What type of probe packets should we send if we, for example, want to maximize the responding host population? What type of responses can we expect and which factors determine such responses? What degree of consistency can we expect when probing the same host with different probe packets?
In our recent paper Scanning the Internet for Liveness, we presented a systematic analysis of liveness and how it shows up in active scanning campaigns. We developed a taxonomy of liveness which we employed to develop a method to perform concurrent IPv4 scans using ICMP, five TCP-based, and two UDP-based protocols, capturing all responses to our probes. Our key findings are:
- Responsive host populations are highly sensitive to the choice of probe. While ICMP discovers the highest number of raw IPs, our TCP and UDP measurements exclusively contribute a fifth to the total population of responsive hosts.
- Collecting ICMP Error messages for TCP and UDP scans increases the responsive population by more than 13%, and provides new opportunities to interpret scan results.
- At the transport layer, our concurrent measurements reveal that the majority of hosts exhibit inconsistent behaviour when probed on different ports, and that capturing negative responses significantly improves scanning completeness.
- Our concurrent scans allow us to identify nearly 2M tarpits (IPs masquerading as fake hosts) that would bias measurements that do not take them into account.
- Our study of cross-protocol liveness shows that responsiveness for some protocols is correlated, suggesting that the same seed set of responsive IP addresses can be potentially used to bootstrap multiple highly-correlated target populations to reduce scan traffic.
This work recently appeared in the April 2018 issue of ACM SIGCOMM Computer Communication Review (CCR), and was conducted in collaboration with Philipp Richter (MIT), Mobin Javed (LUMS Pakistan, ICSI Berkeley), Srikanth Sundaresan (Princeton University), Zakir Durumeric (Stanford University), Steven J. Murdoch (University College London), Richard Mortier (University of Cambridge) and Vern Paxson (UC Berkeley, ICSI Berkeley). Overall, this study yields practical insights and methodological improvements for the design and the execution of active Internet measurement studies. We released the code and data of this work as open source to allow for reproducibility of the results, and to enable further research.
In simple terms, active scanning involves sending one or more probe packets to a target IP address, and observing a response (or its absence) from the targeted host. If a host replies to a probe packet, we refer to it as alive. Liveness—whether or not a target IP address responds to a probe packet—is a nuanced concept, and depends on the probe type, the configuration of the targeted host, as well as on firewalling and filtering behaviours at the edge or within networks. The interpretation of responses (positive, negative, absent) in turn allows for drawing conclusions about liveness on different network layers.
A Taxonomy of Liveness
To systematically understand these issues, we presented a taxonomy of liveness (see the figure above), which depends both on the probe type and the reply. Key concepts include:
- Network-layer liveness. An IP address is network-layer alive if it responds to a probe with an IP packet. This is the most basic liveness criterion.
- Transport-layer liveness. An IP address is considered transport-layer active if it is capable of sending TCP packets (whether SYN-ACK or RST) from at least one port. That is, the transport protocol stack of the IP address is operational, sending packets with transport layer semantics. An IP address is transport-layer alive if it accepts TCP connections on a specific port number, indicated by a SYN-ACK response to a probe.
- Application-layer liveness. Application-layer active means that the IP address sends a payload, valid or invalid, for at least one application protocol. An IP address is application-layer alive if it speaks the probed application protocol.
Experimental Setup
We collected data from simultaneous scans of the entire IPv4 address space covering 8 protocols, conducted with ZMap. To minimize the effect of temporal churn (for example caused by hosts going up and down and dynamic IP address assignment), we probed each IP address for all of our protocols within a short time window. We selected ports that run well-documented applications, and cover both the server as well as (at least partially) the client space: one network layer ICMP Echo scan, five transport layer TCP SYN scans covering popular ports 22 (SSH), 23 (Telnet), 80 (HTTP), 443 (HTTPS), and 7547 (CPE WAN Management Protocol, CWMP) and two popular UDP-based applications, DNS and NTP. We customized ZMap so as to capture any reply to our probes including negative responses such as ICMP errors and TCP RSTs. By taking these steps, we captured what we believe is the most comprehensive and least noisy picture of the state of Internet liveness available to date. Overall, our scans recorded 487M network-alive IPs out of 3.6B probed. We discuss our key findings below.
What is the effect of different probe types on the measured network-alive population?
Recall that an IP address is network-layer alive if it responds to a probe with any IP packet. We found that as expected ICMP Echo probes are most effective in discovering network-alive IPs, followed by TCP and UDP probes. Interestingly, 16% of network-alive IPs can only exclusively be discovered via TCP, suggesting widespread filtering/firewalling of ICMP traffic within networks and at target hosts.
Reachability, performance, and topology measurements often employ ICMP Echo to study /24 IP address blocks. At the granularity of /24, surprisingly TCP scans show the highest coverage, discovering some 5M active /24 blocks, slightly more (3%) than ICMP Echo.
What is the effect of different probe responses on the measured network-alive population?
A probe can trigger multiple types of responses, for example TCP SYN can trigger TCP SYN-ACK, TCP RST, or ICMP Error responses. Interpretation of network-aliveness depends on what responses are captured. Surprisingly, ICMP Error responses comprise a sizable portion of TCP, and are the dominant means of inferring network aliveness via UDP. This might be due to routers and middleboxes that are configured to ignore direct probes but indirectly reveal activity via ICMP Error packets, as well as due to filtering and firewalling in networks and end hosts.
What is the effect of the probed port on the measured transport-active population?
An IP address is considered transport-active if it is capable of sending TCP packets (whether SYN-ACK or RST) from at least one port. If hosts responded consistently across TCP ports, we would expect to see the same number of transport-active IPs across all five TCP scans since an IP would respond with either TCP SYN-ACK or TCP RST for each probe, in accordance with RFC standards. We found, however, that the number of active hosts varies vastly when probed on different port numbers. Only 24% of active hosts responded to probe packets on all five ports. This, in turn, shows that the vast majority of hosts selectively suppress responses for particular application protocols, due to firewalling and/or filtering. Their visibility or non-visibility in active scanning campaigns heavily depends on the choice of the probed port numbers.
What is the effect of different probe responses on the measured transport-active population?
TCP stacks should respond to TCP SYN probes with a TCP SYN-ACK if a service is listening on the probed port, or TCP RST otherwise. We call the subset of the transport-active population that responds with a TCP SYN-ACK as TCP alive, indicating a service is running on that port. We found that except for HTTP, for a given protocol, the TCP alive population is vastly smaller than the TCP active population on that port. Hence, negative replies (TCP RST) are crucial for capturing the population of TCP active hosts comprehensively. We also find surprising results regarding the TCP alive (i.e., replying with a TCP SYN-ACK) population: the size of the of CWMP alive population is surprisingly large (greater than the SSH alive population!). CWMP provides means for remote management of end-user devices such as modems, routers, gateways, set-top boxes, and VoIP-phones. A possible explanation could be related to widespread distribution of CWMP-speaking CPE devices by ISPs.
How do fabricated responses affect the measured population?
One consideration in enumerating the TCP alive population of any given protocol are network tarpits: IPs masquerading as fake hosts, responding positively with a TCP SYN-ACK to all TCP SYN probes. We discovered 1.9M TCP alive IPs that oddly appear in all five TCP scans. To confirm that these are tarpits, we scanned these IPs on a random high port six days after the original scan—89% responded positively, strengthening our belief that these are tarpits. If, as is common practice, transport alive IPs are taken as a proxy for the service population (e.g., IPs that respond to TCP SYN probe on port 80 with SYN-ACK represent Web servers), then the 1.9M tarpit IPs inflate HTTP, HTTPS, and CWMP footprints by 3–4% of their original size, SSH by 10% and Telnet as high as 23%. To mitigate bias due to tarpits in studies conducting transport-layer measurements from which to make application-layer inferences, simultaneously probing a high random port number for liveness can aid in identifying such instances.
What fraction of the host population that responds to a certain probe/protocol can also be captured when probed for different protocols?
The figure above shows the conditional probabilities for activity (which includes both positive and negative responses) of our probed TCP- and UDP-based protocols. For ICMP, we considered network-layer aliveness (i.e., IPs that respond with ICMP EchoReply). The bottom-most row shows that a significant fraction of transport active hosts (26% on average for TCP services and 12% for UDP) cannot be discovered via ICMP. This is an important consideration, given that it is common practice to use the subset of ICMP-alive IP addresses for further scans, e.g., to measure service availability. The TCP and UDP blocks indicate varying degrees of correlation in filtering behaviour across services, when seen pair-wise. Some protocols are highly-correlated: for example, a Telnet-active host is very likely to elicit a response from both SSH and HTTPS. This suggests that the same seed set of IP addresses can be potentially used to bootstrap multiple highly-correlated target populations to reduce scan traffic.
Summary
Internet-wide scanning depends on a notion of liveness: does a target IP address respond to a probe packet? However, the interpretation of such responses, or lack of them, is nuanced and depends on multiple factors, including: how we probed, how different protocols in the network stack interact, the presence of filtering policies near the target, and temporal churn in IP responsiveness. Although often neglected, these factors can significantly affect the results of active measurement studies. In our recent ACM SIGCOMM CCR paper Scanning the Internet for Liveness, we presented a systematic analysis of liveness and how it manifests in active scanning campaigns, yielding practical insights and methodological improvements for the design and the execution of active Internet measurement studies. We released the code and data of this work as open source to allow for reproducibility of the results, and to enable further research.
Going forward, we are keen to deepen our understanding of active scanning in multiple dimensions, looking at: (1) liveness at the application layer, (2) how liveness varies over time and IP space, and (3) the multivariate probability distributions of transport layer liveness, and exploring using existing results and their correlations to reduce scan traffic.