What prevents me from launching an SYN-ACK flood using HTTP servers?

Question

I've been studying networks lately and this issue came across my mind.

What prevents me from sending a lot of SYN requests with source address of my (attack's) target and flooding the target's internet line with SYN-ACK packets?

This gives me advantage over simple SYN flood (or UDP flood) against my attack target -- anonymity, I can hide my real IP this way and make my attack pretty hard to mitigate by blackholing, because I can force any HTTP server on the internet to send the traffic.

Another advantage is that I can send the SYNs to the HTTP servers from almost any computer in a botnet - including those behind a firewall.

My question is: Why can't I do this? Why hasn't this been exploited in the wild?

Answer 1

This is a long known-about attack called a "reflected DoS". The reason it mostly doesn't cause much of a problem for defenders is that receiving an unexpected SYN+ACK doesn't take up any state on the target server; at most it may send back a packet to say "uh, sorry, wasn't expecting that" which may cause some saturation of their network connection in a scenario where the attacker has a lot of bandwidth at their disposal, but mostly this isn't very useful to attackers. Most of the time, the firewall in front of the service will see that there's no open connection and just drop the packet silently. In general, SYN and SYN+ACK packets are very small, so you need a huge number of them to cause any problems for a defender in terms of flooding.

By contrast, the reason SYN flooding is sometimes effective is not that the network link becomes saturated, but that the server's TCP stack is expecting the new clients to send an ACK and must maintain state until that wait period times out, causing the half-open connection limit to be reached and new connections from legitimate users to be denied. This is, however, mostly mitigated in most sensible scenarios by use of modern TCP/IP stack implementations and defensive measures such as TCP cookies and firewall / IPS rules.

The type of flooding reflection attacks more commonly seen are those which amplify the attack in the process, whereby small packets sent by an attacker generate large response packets from the server, allowing the attacker to amplify the volume of traffic significantly. This was mostly initially exploited against DNS servers, but more recently attackers have identified many other services which produce even greater amplification coefficients, particularly NTP.

Answer 2

In most ISPes or organisations your attack may not work for the outside, simply because it is considered a best practice of the industry and good etiquete to do what Cisco parlance call egress filtering.

With some firewall brands, namely CheckPoint, if anti-spoofing measures are enabled, you will be only to attach machines on the same network with spoofed packets.

Simply any organisation, and in practice, many ISPs, filter out in their firewall or border gateways, any package going to the Internet that has not as source an IP address of their own.

In the ISPs and big organisations I have managed I always have implemented ingress and egress filtering.

The in/egress filters have been standard practice since the late 90s, to mitigate forged packets and DDOS attacks. Many do not still implement the measures.

Tech Tip: Use Ingress and Egress Filtering to Protect the Edge of Your Network

As a anecdotal tale: I managed the IP/communication/systems in one of the biggest ISPs of a 3rd-world country; we were still pretty much satellite bound, and specially upstream bandwidth was at premium and scarce. I was once forwarded a ticket by the helpdesk where a competitor had bought a modem of ours and they complained our service was not forwarding their IP address space.

As a more serious tale: I once disabled for a couple of minutes my ingress filtering for testing, and was pretty fast in my knees due to my upstream provider mistake of not filtering properly their multicast video traffic.

Answer 3

It might work, but it seems painful.

If I got you right, the naked SYNs on your "reflector" machine would eventually be identified by any IPS or modern firewall as an attempt to flood and would be dropped.

An unsolicited SYN-ACK on the victim would be dropped at the firewall. It wouldn't even be going to a service port.

[source] -ephermal:TCP(SYN):80-> [reflector] -80:TCP(SYN-ACK):ephermal-> [victim]

It would take a lot of webservers without synflood protection sending SYN-ACKs to saturate a 1Gbps pipe.