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?

Spoofed IP's shouldn't be a problem for IP based bans, since one's ultimate aim is to gain access, which needs legitimate replies. But some of the greater risks are: IP's shared by many people (schools, workplaces, internet cafes, ...) and IP's that can change to anything like after a modem reset on non-static DSLs.
–
Halil ÖzgürDec 18 '10 at 12:35

Gaining access is not the primary goal for many attacks using spoofed addresses. I suspect the various amplification attacks using DNS is more frequent. DNS is lovely (with DNSSEC worse) -- you can send a small, < 100 byte packet with a spoofed source address will cause the spoofed address to receive a 7x to 40x amplification as a reply.
–
Michael GraffJun 6 '12 at 17:38

15 Answers
15

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

Sounds nasty. So is there anything an administrator could do if he found his server to be targeted like this? Might it be possible to temporarily block the ICMP packets and the TCP reset messages from all IPs? Would you even be able to operate in some semi-normal way like this?
–
UpTheCreekFeb 10 '11 at 7:57

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.

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.

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.

Do you mean it's hard to forge an HTTP connection with a spoofed address, or that its not even possible to do so?
–
PacerierJun 21 '12 at 20:05

On the open internet, it's impossible. There are some tricks if you're on the same LAN that can trick the other computer into sending traffic to you (web.eecs.umich.edu/~zhiyunq/pub/…). You can think of it this way. UDP is like sending a postcard. You can write any name on the return address you want. TCP is like a conversation where if you don't put the right return address, you won't be able to continue the conversation. Some of the other answers here explain it much better.
–
FryGuyJun 26 '12 at 20:42

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.

Unless the attacker has access to the traffic stream to begin with, TCP sequencing attacks with modern operating systems are pretty impractical. If they're a man-in-the-middle anyway then they probably don't even need to do TCP connection hijacking anyway.
–
Evan AndersonDec 3 '09 at 19:02

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.

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.

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.

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.

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.

The routers only route packets. They don't maintain TCP state, so a packet is a packet is a packet to them.
–
Michael GraffDec 3 '09 at 23:50

good point. So it'll tie up servers (or whatever front-end device is doing SYN/ACK negotiation) waiting for their ACK :-) We've got our load balancers configured to fully negotiate SYN/ACK before handing it off to the servers on an already-open connection, so that helps bigtime in that case.
–
JustinDec 11 '09 at 21:57

this is not a problem. A real "problem" here is design of IP protocol, which has no provision to verify if IP address you creating your IP packet with belongs to you or not. So you are allowed to create a storm of packets with different source (destination) addresses and nothing will stop you from sending them out.
–
monomythDec 3 '09 at 18:14

3

Something could stop you. Your ISP could setup egress filters on their routers to not allow packets to be forwarded unless the source IP address is actually belongs to that network.
–
ZoredacheDec 3 '09 at 18:56

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.

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.