I recently purchased a server with "DDoS protection" and a 1gbps uplink.
What I can't figure out, is that I'm suffering from SYN floods. Isn't the large amount of bandwidth available to me supposed to be able to nullify these attacks? Is there anything I can do to block them? I have CSF and have set up appropriate rules although I know software firewalls don't do much.
Simple DoS-attacks use up the bandwidth.
But more sophisticated attacks use up other resources such as CPU time and memory. A SYN flood is targeted at using up memory, (and in some cases CPU-time on hardware firewalls).
For an attacker, however, it is easier to flood a victim with SYN-packets, if the victim has a huge bandwidth.
TCP uses a three way hand shake:
Client --------- SYN -------> Server
Client <------ SYN,ACK ------ Server
Client ------- ACK,... -----> Server
The traditional way to handle the creation of a connection is this:
After the Server received a SYN packet, it has to allocate some memory to store the information about the connection (e. g. client IP, client port, server IP, server port). It acknowledges the SYN packet by sending a SYN ACK back to the source IP-address specified in the initial packet.
A SYN flood consists of lots of SYN packet for which the server has to allocate memory. The client can just send and forget about them. Furthermore the source IP-address can be set to anything (unless the ISP of the attacker has filters).
The server needs to verify that the sender of the ACK-packet in step 3 is the one who sent the SYN-packet and received the SYN-ACK packet. This is the way TCP tried to protect against forged IP-addresses and packet injections.
(The protection does not work against an attacker who has access to a router through which the packets travel).
Instead of allocation memory and store the information about the half opened connection, the server sends the required information back in the TCP-sequence number field in a cryptographic save way.
So when the final ACK-packet is received, it can extract the required information, verify it and establish the connection.
Wikipedia has a good article on SYN cookies.
Typical signs of a syn-flood attack include copious ammounts of half-open syn-recieved (SYN_RECV) connections. Also note, most IPS's will detect and stop syn-flooding.
Read the CSF documentation before blindly enabling this! I have seen to many people using CSF that didn't know what they were actually doing.
It always depends on the setup, but personally I would not enable much more than SYN cookies (any maybe a well-thought SYN filter on firewall level) unless the machine is under attack. It's always good to be prepared but don't throw out your defense before the battle .
CSF http://www.configserver.com/cp/csf.html has good SYN Flood protection. Its worth trying out.
Config is simple as editing these settings.
DDoS protection is a pitch with a lot of marketing spin rather than technical merit. Most service providers and product vendors will offer some level of DDoS protection. However, its effectiveness may be quite limited depending on the implementation. For example, WAF vendors offer DDoS protection but the protection is aimed more at preventing server lockups than service availability.
Consider than DoS is fundamentally a condition where a service becomes or is unavailable to users. DoS can be caused by something as simple as the service not running (i.e. say Apache was configured incorrectly so it didn't start up automatically upon reboot) or perhaps a disconnected network cable. Security practitioners often joke about self DoS situations where administrators inadvertently cause a denial of service by changing service passwords or creating any condition where the service becomes unavailable.
A distributed denial of service generally refers to situations where the cause is distributed (i.e. traffic floods of all sorts). SYN floods are a type of DDoS. With that said, DDoS protection may be anything as simple as a service aimed at offloading the network stack such that an application/service/server doesn't fail under high load or after receiving an anomalous packet or other similar situations. For example, a 1Gbps pipe could be just a network pipe capped at 1Gbps. DDoS protection may be an additional service that identifies and blocks excessive traffic packets at the network layer. For example, if 10 hosts from Eastern Europe start sending a non=normal traffic, then the network may have the ability to drop those packets before they reach your server. However, there are situations where such protection may not be sufficient.
Simple terms, a 1Gbps pipe is just that. If an attacker is able to overwhelm the network (say by sending 2 or 5 Gbps of sustained traffic), then such an attack would easily overwhelm the 1Gbps limit. It's similar to a traffic jam where a 10 lane highway becomes a 5 lane highway (or any physics experiment where p=FA). The squelch point becomes the bottleneck and traffic tends to slow down.
There are service providers that provide DDoS protection (regardless of what the service is called (DDoS protection has become more of a marketing term than any practical technology)) where the bandwidth limitations are less strict (a sudden spike of anomalous traffic may not count against quota). Such services aren't technically a product (or security) implementation but rather a service in the form of lax business rules. Such services usually include a CDN (or anycast routing) but the implementation of the protection is transparent to the service owner. Alternatively, many companies offer DDoS protection where the technical implementation doesn't really provide useful protection against sophisticated attacks.
Long story short, 1Gbps isn't a large amount of traffic and DDoS attacks may leverage 2-10 Gbps of sustained throughput, which would easily overwhelm your SLA. Without clever protection, firewalls (or any security product) alone won't help. I'd recommend asking companies that offer DDoS protection the "hard questions" including the "how" of their implementation. I say this because not all DDoS protection is made the same. Many DDoS protections available today rely on assumptions of architecture and it makes sense to understand what those assumptions that PM used in developing the services are and how applicable they are to your situation. I'd also recommend expand the budgeting constraints and look at service providers that are able to absorb DDoS attacks through clever architecture. Such services are more costly but are more effective at ensuring continued service availability to end users.
HTH
