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