IP source address spoofing is regularly leveraged in amplification and reflection attacks. Even though we have the technical means to prevent IP spoofing through strict ingress filtering, as detailed in BCP38, we still get reports of spoofing-based attacks on a daily basis.
Filtering for spoofing is not as easy as it seems
Fundamentally, the lack of consistent BCP38 deployment is due to the incentive structure. When deploying strict network ingress filtering, a network will stop transporting potential malicious traffic through the Internet but it will not gain any direct benefit from it. Not sending out spoofed traffic benefits the networks peers, but not directly the network deploying the filters.
In order to understand how this scenario manifests itself on the real-world Internet, we conducted a survey amongst network operators through Network Operator Group (NOG) mailing lists.
We found that more than 70% of the participants suffered from spoofing related attacks and many are active in spoofing prevention and mitigation. Despite that, only 20% of the participating networks are deploying BCP38-based filtering. This does seem contradictory, but when asked why they do not deploy strict filtering, most non-filtering Autonomous System (AS) holders listed fear of dropping legitimate customer traffic as the main hindrance.
This problem is quite understandable, especially for transit providers, whose main task is to transport customer traffic. In order to do that job reliably, and additionally deploying clean network filtering, the network engineers would need time, skills, and money.
Many participating ASes actually stated they would prefer to drop spoofed traffic, but their management does not deem the problem important enough to assign the required resources. The MANRS Project tries to remedy the situation by providing easily accessible documentation and information for ASes interested in BCP38 deployment.
Read 14,000 incidents — routing security in 2017
Identifying spoofed traffic in the wild
In our research, which we presented at IMC 2017, we wanted to shed light on three different factors:
- How many ASes on the public Internet do deploy network filtering?
- How is network filtering realized?
- What spoofed traffic actually does look like in the wild
For the sake of real-world understanding, we analyzed four weeks of traffic at a large European Internet Exchange Point (IXP) from the beginning of 2017.
As the term ‘spoofed traffic’ can have very different meanings for different groups of people, we were relying on the broadest definition available: A packet is spoofed if the source IP address does not match the IP address of the host that originated the packet.
As we cannot decide from afar if the source address is indeed of the originating host or not, we needed to decide on a prefix basis if an AS is allowed to send traffic with the observed source IP address.
Figure 1: Classifying packets based on the source IP address.
We leveraged the available routing data of RIPE/RIS and the RouteViews project to build a database of address space that can be associated with an AS.
Note: we decided to count all the announcements we encountered during our study period. This means we will most certainly have taken invalid announcements (hijacking, misconfiguration) into account, but we tried to filter these out later in the traffic analysis. Another option was to only consider announcements that have a matching valid route object in the RIR databases. While this is a best practice for routing security, it is not suitable for our research question because it is well known that not all networks filter their routes based on route objects or even maintain their route objects in the database properly. As such, we decided to take a broader view of the valid IP address space per AS.
At the IXP, traffic was categorized as follows:
- Bogon: RFC1918, Multicast, IANA reserved
- Unrouted: Source IP is routable, but we did not find any announcement covering the corresponding prefix
- Invalid: Source IP is covered by an announcement, but we see the traffic coming from an AS that is not responsible for the prefix
Spoofed traffic: Who? How Much? What?
Overall we found that the amount of spoofed traffic is small (Table 1). However, the important notion when considering spoofed traffic is that it is mostly used to trigger amplification attacks. Keeping that in mind, the amount of amplified traffic that can be triggered by spoofed traffic can be orders of magnitude larger.
| Bogon | 0.003% |
| Unrouted | 0.004% |
| Invalid | 0.12% |
The picture changes slightly when regarding the filtering strategies of the different ASes. Figure 2 shows a breakdown of which fraction of ASes contribute traffic to which class.
We see that 72% emit Bogon (green circle), 52% Unrouted (red circle) and 57% Invalid (blue circle) traffic. When considering the intersection of all three classes, we see that 28% of the IXP member ASes contributed to all of them. This leads us to conclude that they have only minimal filtering deployed at their border. When we take a closer look at these ASes we find them to be mostly hosters and end-user ISPs.
Now, let’s zoom into the actual spoofed traffic. The traffic breakdown into TCP and UDP source and destination traffic by port looks vastly different from the regular traffic mix otherwise found at the IXP. Especially in the case of UDP destination traffic in class ‘Invalid’. This class is heavily dominated by NTP traffic with very small packets (not shown).
Compared to the regular distribution, where NTP is almost negligible, this shows a clear indication of NTP amplification attacks. Another interesting case is TCP destination of class ‘Invalid’ of which 80% is HTTP traffic, while the regular traffic mix at the IXP for TCP destination shows less than 15%.
Similar to the NTP traffic case before, the packet size is, on average, smaller than usual. As such, we are likely seeing HTTP flooding attacks.
Figure 3: Traffic mix for regular, Bogon, Unrouted and Invalid traffic.
The victims of reflection and amplification attacks range from well-known security experts and ISPs to secure email providers. Usually, we learn who gets targeted by such attacks via the vast amount of traffic the victim receives.
Reflection attacks first use regular packets, for example NTP or DNS, to spoof the IP source address of the victim, which triggers the much larger responses towards the victim. Inspecting the NTP traffic found to be spoofed, will show who is being targeted by NTP amplification attacks.
Grouping the IPv4 address space by /8 and counting the amount of spoofed packets with source addresses from the respective address block paints the picture shown in Figure 4. The spikes indicate the most spoofed victims within our study.
Figure 4: Traffic distribution across address space for source addresses of class Invalid.
Let’s take the distinctive peak at /183, which is mostly allocated to Chinese ISPs, as an example. From inspecting this ASes traffic, that we identified as spoofed, we found that it is mostly NTP traffic with many small packets. This strongly suggests we observed a NTP amplification attack against Chinese ISPs.
Figure 5: Contribution to class Invalid per AS (Bytes).
Figure 5 shows the contribution by each AS peering at the IXP to all of the spoofed traffic we found. The important fact here is that five ASes contribute more than 80% of all the spoofed traffic we see. As such, even if we are only able to convince and educate a small number of ASes to deploy strict filtering at their network borders we could reduce the amount of spoofed traffic drastically.
Spoofing: What next?
In summary, we can confirm that spoofing is still a big issue based on the amount of traffic and the number of involved ASes we saw when investigating spoofed traffic at a large European IXP.
While we cannot draw any definitive conclusions on the reasons for the spoofed traffic we see, it is there and it does impact dedicated victims. Feedback from the network operator survey suggests that operators would like to deploy spoofing prevention, but have various reasons why they do not.
Combining these two observations leads to the conclusion that we urgently need to address the obstacles network operators face when deploying BCP38, even if we are only able to convince and educate a fraction of the ASes to deploy strict filtering at their network borders.
Franziska Lichtblau is a PhD student in the field of Internet Measurement at TU Berlin. Her main focus is on inter-domain traffic measurements, IXPs, security and Internet infrastructure.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.