The adage: ‘On the Internet, nobody knows you’re a dog‘ has been popularized by the Internet community, for obvious reasons. The saying hints at the anonymous nature of the Internet and the many ways in which people can pretend to be something that they’re not.
One of the most popular ways of doing that is by spoofing packets. Today, we’re going to dive into exactly what spoofing packets involves and why it’s a tough problem to resolve on a large scale.
What are all these spoofing reports?
If you hang around with network operations people long enough, you end up on a lot of Network Operator Group (NOG) lists. APNIC has an internal contact database which lists 23 NOG groups in the region. These NOG lists attract reminder posts like light attracts moths. Some of the reminders are about routing and addressing and contain language that may look strange to newcomers.
Here is a spoofer report. So what’s CAIDA and what’s a spoofer?
CAIDA, or the Center for Applied Internet Data Analysis, is an independent, US-based research data collection, collation, and distribution project. Figure 1 shows a practical service they provide to inform the community when they see spoofed-source packet flows.
Spoofing happens when a bad actor gains control of a computer system on the Internet and starts sending out IP packets which don’t have the source address field marked with the actual address of the computer they are using. They ‘spoof’ (trick) the system into believing they are the sender.
Wait. You can send a packet with a forged ‘from’ address?
Yes. Much like ordinary mail, the sender address usually doesn’t actually affect how it is sent to the receiver. It is typically only used when you want to send something back.
This has implications for routing. It can affect the path because you might have a policy about how you forward traffic depending on who is sending it. But most of the time, this is, at best, a secondary consideration.
Spoofing is like calling up the local farm and asking for a package of chicken manure to be delivered to your home, but giving the address of your school’s headmaster. The idea is to make the recipient of the spoofed packet try to send a reply back to somebody else (before you get carried away, I googled sending chicken manure to somebody online. Trust me, you don’t want to, it’s illegal and akin to swatting, which has led to death in the US).
In an IP spoof, you send a packet to somebody important who has a lot of reach, so they reply ‘huh? why did I get this?’ In doing so, they send a packet back to the apparent sender, basically telling them to go away.
This can take several forms. It could be an Internet Control Message Protocol (ICMP) unreachable message (part of the ping family), it could be a Transmission Control Protocol (TCP) RST (reset) packet, or it could be something else like a large DNS response packet (10 or 20 times bigger than the small request packet received), this is called ‘amplification’ and is how the attacker can make a lot more traffic come to the victim than they have to send.
Why do people do this?
Because it’s one of the fundamental mechanisms used to drive a Distributed Denial of Service (DDoS) attack.
Sending a packet with somebody else’s source address is usually aimed at getting a lot of traffic to go back to the source address you used. If I send an email to a third party, faking your email address as my own, then you could expect to receive a little bit of traffic. So rather than send to just one third party, I send the email to a lot of third parties, and they all send the responses back to you.
This is what’s known as a DDoS attack. It’s flooding one server with traffic in an effort to damage their ability to distinguish between real traffic and the flood of fake material. Sometimes the deluge is so bad that the servers can buckle and crash under the strain.
If you want to see what a DDoS attack looks like, here’s a video that APNIC Labs produced when it was checking the old network blocks that were part of the final /8 rundown. The clip shows a single IP network being flooded, briefly, with traffic from a huge range of apparent source addresses. The distributed sources (on the left) are real. Each one represents somebody who was infected and ran malware that sent out packets pretending to come from the destination (right hand side).
The many recipients all sent their ‘who are you and why did you send me this’ protocol responses back to the one address on the right.
Bang.
So… ISPs should stop this, right?
Ideally, yes. It would be ideal if ISPs had some kind of process in their network to make this either impossible or harder. This has been a bone of contention in the ISP community for a long time and is the fundamental motivator behind BCP-38 and related activity such as MANRS and those spoofer reports from CAIDA.
CAIDA monitors worldwide networks to find origin-ASes that are visibly able to send spoofed-source packets. They then send regular reports to the NOG lists, to help people understand the visibility of spoofed sources in their regional network community, and to apply some social pressure that encourages ISPs to apply the various fixes recommended.
Is that where the buck stops? No, it’s never that simple.
It’s important to note that even inside the ISP’s own network, spoofed sources can be a risk. Like it or not, deploying anti-spoofing technology represents a cost: It is complexity added to the routing and switching fabric that requires maintenance. That complexity could also resemble denying your customers the ability to send traffic, which would be a net-negative to revenue, if based on volume of traffic sent.
These counter-arguments are not complete or compelling, but the current reality is that BCP-38 is not yet completely deployed, and MANRS has continuing burdens (as do APNIC trainers) to help advise people how to construct robust, defensible, and well-behaved networks for the common good.
Of course, the underlying problem here is the amount of malware out there in the community, and how easily it can intrude systems and hosts. The CERT community works to identify attacks and risks, and helps with upgrades, but it’s a non-stop battle between limited defence and mitigation resources, and technically-savvy people with something to gain, or an axe to grind.
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.