At least half of all Autonomous Systems (ASes) on the Internet are vulnerable to Denial of Service (DoS) attacks because they are not deploying a 20-year-old filtering mechanism.
That mechanism, Source Address Validation (SAV), was first proposed in 2000 (BCP 38/RFC 2827) and has since been the best current practice for network ingress filtering, an important method to mitigate against DoS attacks. Networks that deploy SAV drop spoofed packets because the source IP address does not belong to the network prefix.
As part of the Closed Revolver Project, my colleagues and I have been working to measure and identify the number of networks that do not deploy SAV for incoming traffic, a practice that can amplify other attack vectors, such as an NXNSAttack and DNS cache poisoning. In doing so, we hope to shine a light on why networks are not complying with this best current practice and encourage networks to check for themselves using our newly developed method.
There have been many studies into the deployment of outbound SAV, most of which point to the misaligned economic incentives of deploying it — a network applying SAV protects the rest of the Internet from the actions of its hosts but it is not protected itself.
However, there has been little attention paid to understanding the use of inbound SAV, which filters incoming traffic by the source IP address, which directly protects the deploying network.
Our method for measuring inbound SAV relies 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.
Figure 1 shows the operation of the method that scans an example IPv4 network with prefix 18.104.22.168/24.
The scanner sends a DNS A query for the name we control to each host with a spoofed source IP 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 in the network edge (step 1), there are three possible scenarios:
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.
It then reaches the authoritative nameservers under our control (steps 5 and 6) so we can find out if 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.
Using the above method, we used IPv4 RouteViews BGP prefixes to scan all the IPv4 addresses from the BGP routing table, and the IPv6 hitlist service to scan a target list of responsive IPv6 addresses.
From this we found that almost half of all routable ASes (32,755 out of 66,978) were originators of spoofed requests, corresponding to 197,608 prefixes or 938,472 /24 IPv4 networks.
We also found similar figures in our IPv6 scan, where 4,766 ASes, 6,873 BGP prefixes, and 7,698 /40 IPv6 networks, were vulnerable to inbound spoofing.
In addition, we identified 4,251,189 IPv4 and 103,012 IPv6 closed resolvers.
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 ASes (34.60% in IPv4 and 2.17% in IPv6). The smaller the network size, the more consistent results we obtain.
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.
Visit our project website to check whether the network you are connecting from is vulnerable to inbound spoofing.
If you want to find out more about the filtering policies of your network, please contact us or leave a comment below.
Contributors: Maciej Korczyński, Yevheniya Nosyk, Qasim Lone, Marcin Skwarek, Baptiste Jonglez and Andrzej