Inferring the Deployment of Inbound Source Address Validation Using DNS Resolvers

Background

IP address spoofing consists of modifying the source IP address of a packet, which prevents all the outgoing traffic to be traced to its origin. It has been widely used to launch amplification DDoS attacks: certain Internet services (such as DNS or NTP) can generate replies of a much larger size than the requests they receive. An attacker changes the source address of the generated packets to the IP address of a victim, sends a carefully-crafted request to such a service, and the victim receives a large reply. This scenario is possible if the network of the attacker does not filter its outbound traffic based on the source IP addresses. An SAV-compliant network drops spoofed packets because the source IP address does not belong to the network prefix.

Evaluating outbound SAV compliance has already received considerable attention from the scientific community. The problem of implementing outbound SAV comes from misaligned economic incentives - the network applying SAV protects the rest of the Internet from the actions of its hosts but it is not protected itself. Little attention has been paid to inbound SAV that filters incoming traffic by the source IP address, which directly protects the deploying network. The absence of inbound SAV can also amplify other attack vectors, such as NXNSAttack, DNS cache poisoning, and others.

In this article, we present a method for evaluating the deployment of inbound SAV: we test if networks filter incoming traffic by the source IP address. Using the method, we enumerate vulnerable networks in the IPv4 and IPv6 address spaces.

Methodology

We rely on the DNS protocol to evaluate the vulnerability to inbound spoofing. We have developed an efficient scanner that sends handcrafted DNS A request packets with spoofed source addresses. The DNS query concerns domain names that we set up: v4.drakkardnsv4.com and v6.drakkardnsv6.com for IPv4 and IPv6 scans, respectively.

The figure below shows the operation of the method that scans an example IPv4 network with prefix 1.2.3.0/24. The scanner sends a DNS A query for the name we control to each host with a spoofed source IP address: it is the next one to the destination address. We encode the destination address in the query domain name to identify the true originator in case a host forwards the query. When such packets arrive at the network edge (step 1), there are three possible scenarios:

• Inbound SAV is deployed and spoofed packets are dropped,
• Inbound SAV is not deployed and spoofed packets reach their destinations (step 2),
• Regardless of the presence/absence of SAV, we may experience packet losses or SAV in transit networks.

If the packet reaches any host that is not a local DNS resolver, the packet is just dropped. However, if there is a local DNS resolver configured to accept requests from its internal network, it accepts the query and starts resolving our domain name by contacting the root (step 3) and the .com TLD (step 4) nameservers. Then, it reaches the authoritative nameservers under our control (steps 5 and 6) so we can find out that we have reached a closed resolver. Finally, the response is returned to the host holding the IP address that we spoofed (step 7), rather than our scanner machine, so we do not receive the DNS reply. To distinguish open vulnerable resolvers from the closed ones, the scanner sends a non-spoofed query just after the spoofed one: if the target host is an open resolver, it will reply to the query.

Scan targets

• IPv4 RouteViews BGP prefixes - we scan all the IPv4 addresses from the BGP routing table.
• IPv6 Hitlist Service - as scanning the whole address space is not feasible in IPv6, we use a target list of responsive IPv6 addresses.

Results

In IPv4, almost half of all the routable autonomous systems (32,755 out of 66,978) were originators of spoofed requests. They correspond to 197,608 prefixes or 938,472 /24 IPv4 networks. The IPv6 scan reveals 4,766 ASes, 6,873 BGP prefixes, and 7,698 /40 IPv6 networks, vulnerable to inbound spoofing. In addition, we identified 4,251,189 IPv4 and 103,012 IPv6 closed resolvers.

Partially Vulnerable Networks

When open DNS resolvers do not resolve spoofed queries, we infer the presence of SAV for inbound traffic either at the tested network edge or in transit. However, there are cases when a single network has multiple DNS resolvers each showing the absence or presence of inbound SAV. We call such networks partially vulnerable. The highest proportion of partial deployment is for autonomous systems (34.60 % in IPv4 and 2.17 % in IPv6). The smaller the network size, the more consistent results we obtain. 

Discussion

The proposed method of evaluating inbound SAV compliance is the first one to operate completely remotely - it does not require a vantage point inside tested networks. We have scanned the whole routable IPv4 address space and found that nearly half of all the autonomous systems are at least to some extent vulnerable to inbound spoofing. While we have not covered the whole IPv6 space, we have still obtained a significant amount of information about filtering policies in IPv6 networks. We plan to perform a longitudinal analysis to study the persistence of this vulnerability as well as a notification campaign to draw attention to the problem.

The Closed Resolver Project

We described our findings in greater detail in the following publications (if you refer to this work, please cite):

• Maciej Korczyński, Yevheniya Nosyk, Qasim Lone, Marcin Skwarek, Baptiste Jonglez, and Andrzej Duda. March 2020. Don’t Forget to Lock the Front Door! Inferring the Deployment of Source Address Validation of Inbound Traffic. In Passive and Active Measurement Conference. Springer, 107–121.
• Maciej Korczyński, Yevheniya Nosyk, Qasim Lone, Marcin Skwarek, Baptiste Jonglez, and Andrzej Duda. May 2020. The Closed Resolver Project: Measuring the Deployment of Source Address Validation of Inbound Traffic. arXiv:2006.05277 [cs.NI]

Visit our project website to check whether the network you are connecting from is vulnerable to inbound spoofing:

https://closedresolver.korlabs.io

If you want to find out more about the filtering policies of your network, please write to us: maciej.korczynski@univ-grenoble-alpes.fr and/or yevheniya.nosyk@etu.univ-grenoble-alpes.fr.