0

According to this answer, it's possible to send a network packet with a forged source IP address.

So, what methods a server administrator can take to prevent/block a countless requests from faked IP addresses, assuming they have no known regularity (except that they are a lot), and he doesn't intend to prevent some legitimate clients from the service (for instance, a web server), even temporarily.

Community
  • 1
Reflection
  • 219
  • 2
  • 6
  • @lynks Well, I'd be happy if we create the issue again here, since I see the answers guideline in the laden link you suggested is the detecting of the attacker or the zombie computer retrospectively (e.g. after failing in a "CAPTCHA" validation image). However, the attack still exists: the zombie computer's request itself to the targeted server has been a network strain, even if the next time he enters the server he will be blocked (the truth is that it usually does not happen, but simply giving a second change to fill the Captcha) – Reflection Nov 05 '13 at 17:37
  • Read [this answer](http://security.stackexchange.com/a/30354/9377), particularly the things regarding `Proof of Work`. – lynks Nov 05 '13 at 17:51
  • I read it, as it is the basis for my comment above here. In fact, the comment of Pacerier to the answer you linked can explain (maybe demonstrate) my question better. Unfortunately, he did not receive a response. – Reflection Nov 05 '13 at 17:55
  • The answer in reality is that DDoS mitigation is extremely difficult, and any solution will only be of partial success. Companies exist solely to absorb huge DDoS attacks. – lynks Nov 05 '13 at 18:04
  • @lynks - Thank you. What are the partial solutions (the common ones, at least)? And, can you specify some companies that offer such absorption services? – Reflection Nov 05 '13 at 19:34

1 Answers1

2

For the quick answer: use synproxy (as offered by BSD's pf for instance), or a reverse proxy like Nginx if you have an Apache directly facing Internet.

Real DDoS issues would merely come from actual IP address owned by botnets than faked IP address. However, some application remains indeed sensible to fake SYN packet, but this is merely an application issue exploitable by a single host (aka DoS with a single 'D') than a DDoS

Why? Thank to TCP 3 way handshake:

  • The client sends a SYN packet,
  • The servers answer with a SYN-ACK packet,
  • The client answers back with a ACK packet,
  • Then at last the TCP connection is established and the HTTP request (for instance) can be sent from the client to the server.

What invalidates forged IP address is that each host selects a random sequence in this handshake, and for the connection to be established client's final ACK must show the two sequence number validly incremented.

When you use a forged IP address for your SYN request, by definition you will never receive the server's SYN-ACK, therefore you will never now the random sequence number he selected, so you will never be able to complete the TCP handshake.

So, when you use a forged IP address, the only "harm" you may do is send fake SYN requests to the server, which should require very low resources on server side, and which will indeed require negligible resource if the server or its firewall is using above mentioned synproxy (with this option enable, the connection will be forwarded to the listening service only when the 3-way handshake has been successfully executed).

If you do not use synproxy, depending on the way your service is implemented a SYN packet may involve more or less resource. The issue with Apache server is that it already forks to a new process upon SYN packet reception, so you need either to protect it using specific measures (adding Nginx which uses another implementation not sensible to such issue), or configure your firewall to mitigate the risk (reduce the number of ongoing TCP handshakes, reduce the handshake delay, etc., but unlike previous solutions this one may have an impact on legitimate clients).

WhiteWinterWolf
  • 19,082
  • 4
  • 58
  • 104
  • Thank you. First, is there a free or open-source "syn-proxy" software? Second, how is the syn-proxy faced with a large amount of unresolved connections? Does it kick them after a while? If so, what exactly is the difference between it and a correct configuration of a standard server? – Reflection Nov 05 '13 at 19:31
  • @Reflection: Most well known open-source software with synproxy capability are FreeBSD and OpenBSD systems (and firewall solution relying on them). The pending connections are indeed kicked after a while. Compared to a server, it depends upon its implementation and how much resource is allocated upon a SYN packet reception: Apache will fork to a new process, allocating memory, filling it up or reaching MaxClient limit in case of SYN flood, in case of syn-proxy few bytes will be needed to wait until TCP handshake completion or packet dropping. – WhiteWinterWolf Nov 05 '13 at 19:48
  • The 'syn flood' described by GZBK here works because your server has to keep a record of all unfinished TCP handshakes for a period of time. Sending a whole bunch of SYN packets fills up this record. [SYN Cookies](http://en.wikipedia.org/wiki/SYN_cookies) is a method of selecting special TCP sequence numbers in such a way that allows the server to *not* keep a record of unfinished TCP handshakes. See the wikipedia article for details. – lynks Nov 06 '13 at 12:21