Are IP addresses "trivial to forge"?
I was reading through some of the notes on Google's new public DNS service:
- Performance Benefits
- Security Benefits
I noticed under the security section this paragraph:
Until a standard system-wide solution to DNS vulnerabilities is universally implemented, such as the DNSSEC2 protocol, open DNS resolvers need to independently take some measures to mitigate against known threats. Many techniques have been proposed; see IETF RFC 4542: Measures for making DNS more resilient against forged answers for an overview of most of them. In Google Public DNS, we have implemented, and we recommend, the following approaches:
- Overprovisioning machine resources to protect against direct DoS attacks on the resolvers themselves. Since IP addresses are trivial for attackers to forge, it's impossible to block queries based on IP address or subnet; the only effective way to handle such attacks is to simply absorb the load.
That is a depressing realization; even on Stack Overflow / Server Fault / Super User, we frequently use IP addresses as the basis for bans and blocks of all kinds.
To think that a "talented" attacker could trivially use whatever IP address they want, and synthesize as many unique fake IP addresses as they want, is really scary!
So my question(s):
- Is it really that easy for an attacker to forge an IP address in the wild?
- If so, what mitigations are possible?
Solution 1:
As stated by many others, IP headers are trivial to forge, as long as one doesn't care about receiving a response. This is why it is mostly seen with UDP, as TCP requires a 3-way handshake. One notable exception is the SYN flood, which uses TCP and attempts to tie up resources on a receiving host; again, as the replies are discarded, the source address does not matter.
A particularly nasty side-effect of the ability of attackers to spoof source addresses is a backscatter attack. There is an excellent description here, but briefly, it is the inverse of a traditional DDoS attack:
- Gain control of a botnet.
- Configure all your nodes to use the same source IP address for malicious packets. This IP address will be your eventual victim.
- Send packets from all of your controlled nodes to various addresses across the internet, targeting ports that generally are not open, or connecting to valid ports (TCP/80) claiming to be part of an already existing transaction.
In either of the cases mentioned in (3), many hosts will respond with an ICMP unreachable or a TCP reset, targeted at the source address of the malicious packet. The attacker now has potentially thousands of uncompromised machines on the network performing a DDoS attack on his/her chosen victim, all through the use of a spoofed source IP address.
In terms of mitigation, this risk is really one that only ISPs (and particularly ISPs providing customer access, rather than transit) can address. There are two main methods of doing this:
Ingress filtering - ensuring packets coming in to your network are sourced from address ranges that live on the far side of the incoming interface. Many router vendors implement features such as unicast reverse path forwarding, which use the router's routing and forwarding tables to verify that the next hop of the source address of an incoming packet is the incoming interface. This is best performed at the first layer 3 hop in the network (i.e. your default gateway.)
Egress filtering - ensuring that packets leaving your network only source from address ranges you own. This is the natural complement to ingress filtering, and is essentially part of being a 'good neighbor'; ensuring that even if your network is compromised by malicious traffic, that traffic is not forwarded to networks you peer with.
Both of these techniques are most effective and easily implemented when done so in 'edge' or 'access' networks, where clients interface with the provider. Implementing ingress/egress filtering above the access layer becomes more difficult, due to the complexities of multiple paths and asymmetric routing.
I have seen these techniques (particularly ingress filtering) used to great effect within an enterprise network. Perhaps someone with more service provider experience can give more insight into the challenges of deploying ingress/egress filtering on the internet at large. I imagine hardware/firmware support to be a big challenge, as well as being unable to force upstream providers in other countries to implement similar policies...
Solution 2:
Is it really that easy for an attacker to forge an IP address in the wild?
Sure, if I don't care about actually receiving any responses, I can very easily send out packets using any source address I like. Since many ISPs don't really have good egress rules, anything I forge generally will be delivered.
If the attacker actually needs two way communication it becomes very difficult. If they need two way communication it tends to be easier to simply use a proxy of some sort. Which is very easy to set up if you know what you are doing.
Banning people by IP address is moderately effective on SF/SO/SU since the site uses http/https which requires two way communication.
Solution 3:
Little Proof of Concept for Zordeche's Answer (with ubuntu):
$ sudo apt-get install hping3
$ sudo hping3 -1 --spoof 11.10.10.20 www.google.com
HPING www.google.com (eth0 64.233.169.105): icmp mode set, 28 headers + 0 data bytes
Then in another console:
$ sudo tcpdump -i eth0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
13:30:19.439737 IP 11.10.10.20 > yo-in-f105.1e100.net: ICMP echo request, id 31297, seq 0, length 8
So yes, trivial, but then you don't get the replies as previously mentioned unless you have access to 11.10.10.20 or have a sniffer somewhere between www.google.com and 11.10.10.20 (And it would need to be right in front of either end, since you can't predict the route of packets). Also, the spoofer's gateway (ISP) might not let that packet out the door if they have some sort of ip inspection going on and see that the source smells bad.
Solution 4:
IP addresses are easy to forge for one-directional UDP traffic. For TCP packets, you can only forge to get a half-open TCP connections with SYN packets. This is the basis of a kind of DOS attack as well. But you can't forge an HTTP connection with a spoofed address (for instance, if you are filtering sessions to use the same IP address). While yes, you can spoof an IP address in the packets, it's only useful for certain kinds of denial of service attacks.