Are IP addresses "trivial to forge"?

Question

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?

Answer 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:

1. Gain control of a botnet.
2. Configure all your nodes to use the same source IP address for malicious packets. This IP address will be your eventual victim.
3. 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:

1. 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.)

2. 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...

Answer 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.

Answer 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.

Answer 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.

Answer 5

The GOOG article was explicitly discussing DNS. DNS uses both UDP and TCP packets. The UDP ones can be forged, but not the TCP. TCP requires a 3 way handshake. If the IP address for a TCP packet is forged then the forging computer will not receive the response and the connection will fail. UDP, as mentioned in other answers, is 'fire and forget' and requires no response communication. DoS attacks come almost exclusively in the form of UDP packets for this reason.

In the context of Stack Overflow and family sites, the issue raised by Takaun Daikon is very valid. There are many ways to get a new IP address from one's ISP. Changing a MAC address is clearly the easiest and works for many ISPs. In addition, many folks who are up to silliness may be using a public proxy or TOR. Clearly blocking the origination IP for those packets would just block the proxy or TOR termination node.

So is blocking IP addresses valid? Hell yes it is. But you will end up with errors. You will block some IPs which really are not the source of the problem (i.e proxies) and you will also have people avoiding your blocks by changing IPs. The person who is unlucky enough to get the banned IP later will not be able to access the SO family of sites. But the error rate should be small. Unless you are blocking huge sets of IPs. But if you are blocking one or two a day, you should be fine.

You may want to introduce a slightly more sophisticated scheme where you block, but only for a period, like a year. If your network is capable of bandwidth throttling or connection limiting, you might also consider a scheme where douche bags who run Apache Benchmarks on your site just get put in a cage with very limited bandwidth.

Answer 6

IP spoofing will continue because ISPs are lazy.

My ISP damned well knows that I am on a specific address, or at least the subnet I'm on. Yet I can use any source address. Why is that? Simply, cost.

If I fake a few addresses here and there, it costs my ISP nothing. If every user of my ISP faked one packet between 1:00 and 2:00, it would still be hardly a blip on the radar. However, when a botnet sends many spoofed packets from many hosts on many ISPs, the target machine or network falls over.

The financial reality is that unless you are the one attacked, spoofing costs nothing. It costs money to implement filtering near the customer, and the one spending the money realizes very little return other than knowing they are good network citizens.

UDP and ICMP are easiest to fake, but TCP is also possible. It requires an insecure remote OS, which uses predictable sequence numbers to exploit. Sometimes it's the load balancing machines that alter sequence numbers and make them predictable. So, TCP is possible -- but harder.

DNS anti-spoofing focuses mostly on the security side of preventing someone from submitting a false answer to a recursive resolver. The flooding aspects of UDP are not DNS specific other than a single small query (say, for '.') will cause a rather large response. Thus, it makes a nice amplification vector. There are many other UDP protocols out there that work, but DNS is in use everywhere, and it's easy to find machines to use to amplify attacks.

DNSSEC makes this even worse, with UDP packets that can reach 4k in size.

Answer 7

IP addresses are trivial to forge as far as DNS-based (D)DOS attacks are concerned, as they’re typically a case of fire-and-forget UDP packets. For HTTP traffic, that’s not the case, so you’d need to either be on the same local network as the web server (entirely possible, of course, depending upon where your site is hosted), or control the intermediate routers.

Answer 8

You can send a letter to anyone, and if you don't put a return address on the envelope (or put the wrong one), they can hire all the junk mail filterers in the world and not filter your message out without opening (processing) it.

However, if the sender wants a response, the return address better be correct, or there would have to be an application layer mechanism for getting the correct address. So I can make you think you're opening a letter from Nana, but even if I fool you with the letter's content, you're not going to send Nana a check made out to CASH to some address in Nigeria (unless Nana is Nigerian). So challenge/response is an effective defense as long as you aren't also being Man in the Middled.

Answer 9

I can set whatever source IP address I want in a datagram.
Whether my ISP would let such a packet out into the wild is another question.

Answer 10

While this is certainly a reality that needs to be dealt with, the underlying problem is really non-technical: People with malicious intent trying to do malicious things. The real solution therefore must be non-technical as well.

I think what Stackoverflow has done is EXACTLY the right solution for handling the second line of defense: The techniques for restricting potential spam users through the different ways of limiting their abilities to interact with the platform prior to achieving some level of 'credibility'.

Not only do these techniques help to improve the overall quality of the site, they actually incentivize users to get more involved and provide more credible / reliable answers.

From the technical standpoint, the best thing to do then would be to do as Google suggests: just be efficient in absorbing / dealing with the additional load.

Great job and keep improving!

Answer 11

UDP is the main part of why this is easy - in fact, Skype and Slingbox exploit the ability to forge IP addresses easily in UDP to 'punch' through NAT and allow for easy peer-to-peer.

TCP is harder since it requires a full SYN/ACK cycle, but you could still flood the server with hanging SYN packets which go to IP addresses many-hops away and essentially tie up a huge number of routers in the process.

Answer 12

As mentioned above, using proxies is trivial, and there are a very large number of open anonymous proxies available.

Even without using a proxy, I can set the MAC address on my firewall to any new arbitrary value, reset my cable modem, and my ISP will assign me a brand new shiny IP address.

And that's just for starters. There are many many other ways to get around IP bans.

Answer 13

If so, what mitigations are possible?

Not much you can do on the receiving side.

The ISP of the forger should be filtering their outbound traffic so that its customers can't spoof IPs from different networks.

It is only a few lines in the router config so there isn't a good excuse for not doing it.

There is a way to track the attacker, but it requires coperation of your upstream providers: http://www.cymru.com/Documents/dos-and-vip.html

Answer 14

As others have pointed out, UDP is pretty trivial to forge, TCP not so much.

The preferred defence, but unfortunately not universally deployed, is egress filters.

For ISPs running DSL etc services, each virtual line should be configured with ip verify unicast reverse-path (or whatever the non-Cisco equivalent is) which blocks any packet whose source IP address isn't in the ranges known to be routed down that line.

Answer 15

I can remember doing sockets programming in the late 90's with what was probably Visual Basic, and we could set the source IP on our connection. I remember vaguely that when we tried it, netstat -an showed the actual source IP, but the Apache logs showed the spoofed IP; and I think Apache was handing the spoofed IP to the perl modules and so on as well.