I was reading through some of the notes on Google's new public DNS service:
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?
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:
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...
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.
Little Proof of Concept for Zordeche's Answer (with ubuntu):
Then in another console:
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.
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.
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.
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.
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.
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!