The discussion about protection against SYN Flood cannot be one-sided. On one end is the host with its Linux kernel, sysctl settings, and iptables; on the other – the provider’s backbone, BGP, high-speed channels, and scrubbing centers. Considering the problem only “on the server” or only “in the network” will not lead to the desired level of resilience. In this article, we will maintain technical depth while explaining why and which actions fall to the provider, and which to the server administrator.
Who is Responsible for Protection: Areas of Responsibility and Why a One-Sided Approach Doesn’t Work
It sometimes seems logical to rely only on OS settings: enable SYN Cookies, increase the backlog, add a couple of iptables rules – and everything will be fine. This works against small, “local” attacks. But in real modern scenarios, attacks measure in tens and hundreds of gigabits per second. This is no longer a problem for an individual server, but a problem of the channel and the provider’s infrastructure.
When an attack flow reaches 100+ Gbps, no sysctl or iptables on the server will help – the client’s channel will be completely saturated even before the packets reach the host. Therefore, the responsibility is naturally divided: the provider is responsible for the backbone, routing, spoofing prevention, and filtering malicious traffic at the external network borders; the client (server administrator) – for the local service resilience, correct TCP/IP stack settings, and initial incident detection. Effective protection is a coordinated chain of measures: from validating source addresses in the provider’s network to pinpoint filters in the server OS.
What is a SYN Flood Attack (Technical Breakdown)
TCP establishes a connection in three steps: the client sends a SYN, the server responds with SYN-ACK, the client confirms with ACK. In a SYN flood, the attacker generates a huge number of SYN packets and does not complete the handshake, causing the server to accumulate “half-open” connections in a queue (SYN backlog) and spend memory and processing power on them. The negative effects manifest as increased latency, dropped availability of ports (typically 80/443), and, in critical cases, complete service failure.
Attacks vary: direct (flow from real IPs), with spoofed addresses (IP-spoofing, reflected/DRDoS), mass attacks across ranges, and targeted attacks on specific services. Reflected scenarios are especially dangerous: the attacker forges the victim’s source IP, and thousands/hundreds of thousands of third-party servers send responses towards the victim – ultimately, the load multiplies and exceeds the capabilities of a single host.
Why Classic Server Methods Are Sometimes Useless (The 100+ Gbps Case)
Local tools (SYN Cookies, increasing tcp_max_syn_backlog, iptables rate limits) are effective under moderate load, when the attack is within the client’s channel capacity. But when the attack exceeds the external channel’s bandwidth, the “excess” traffic is cut off at the uplink. Only the portion of packets that fits into the channel reaches the provider’s network. This is precisely why the provider’s role is critical: they must either absorb/filter the malicious traffic on the backbone or redirect the flow to a scrubbing center (a specialized node for cleaning DDoS traffic) – otherwise, the server will be disconnected regardless of its local configuration level.
How a Provider Detects Anomalies and What Tools They Have
Foundation: Preventing IP Spoofing
The first rule in fighting reflected attacks is to prevent packets with “foreign” source addresses from leaving the network. Implementing BCP 38 / RFC 2827 (Source Address Validation) means blocking egress packets whose source IP does not belong to the subscriber’s network. Practice: ACLs on edge routers and filters on the perimeter. This is not a panacea, but it blocks the most dangerous component of DRDoS (Distributed Reflection Denial of Service).
Flow-based Monitoring
Provider detection is based on flow analysis: NetFlow, sFlow, IPFIX provide a picture of the SYN/ACK ratio, traffic spikes to specific addresses and ports, and traffic asymmetry. Solutions from InMon, SolarWinds, or custom pipelines on ELK/ClickHouse allow for retrospective analysis and anomaly detection before clients start complaining.
Besides flow monitoring, other telemetries are useful: BGP Monitoring Protocol (BMP) helps control route stability and notice anomalies in BGP sessions, SNMP provides interface load metrics – a sharp increase in incoming traffic on a client’s port is often a primary indicator of an attack.
Filtration and Mitigation Methods
The provider operates tools of different “calibers” – from fast and radical to pinpoint and intelligent:
- RTBH (Remote Triggered Black Hole) – the simplest and fastest method: using BGP to tag a prefix leads to the dropping of all traffic to it. This saves the infrastructure but “kills” the client’s service entirely.
- BGP Flowspec – a tool with greater surgical precision: rules distributed via Flowspec create ACLs on network devices and allow dropping specific TCP packets (e.g., SYN to IP:port). Advantage – precision and minimal impact on legitimate traffic; disadvantage – requires equipment support and careful rule creation.
- Scrubbing centers (scrubbers) — the “big guns” in fighting DDoS. Client traffic is redirected (via BGP or DNS) to a cleaning center, where specialized systems analyze the flow, discard malicious traffic, and return “clean” data to the client via tunnels (GRE or VxLAN). Such centers can be either integrated on-premise solutions (e.g., Arbor TMS, Juniper DDoS Guard) or external cloud services. This is usually a paid add-on service for clients for whom downtime is critical.
Multi-Layered DDoS Protection Architecture: How Providers Build It
An effective protection system is a stack of levels, where each covers a specific area of responsibility:
- Core Network Level: BCP 38 + continuous flow monitoring + ready Flowspec mechanisms.
- Network Perimeter: fast RTBH mechanisms for emergencies.
- Service Level: scrubbing centers, DDoS services for clients, integration with CDN.
- Automation: linking “detector → rule” reduces TTR (time to respond) from hours to seconds: monitoring generates an alert – the system automatically publishes a Flowspec rule or initiates redirection to a scrubbing center.
Case Study: Provider’s Step-by-Step Actions Upon Detecting a SYN Flood
- Detection. A system based on NetFlow/IPFIX detects a spike in SYN packets to the client’s IP; SNMP shows a sharp increase in incoming traffic on the subscriber’s port; BMP signals degradation of the BGP session.
- Verification. Quick check via CLI: show flow monitor, show ip traffic, pcap analysis if necessary.
- Response.
- Option A (Precise): A BGP Flowspec rule is published, dropping the malicious flow while leaving legitimate traffic.
- Option B (Emergency): If the attack threatens the entire infrastructure – RTBH is applied to protect the backbone; the client’s service is temporarily unavailable, but the network remains stable.
- Option C (Service-based): The client is offered to redirect traffic to a scrubbing center for cleaning and return of a safe flow.
The key point is automation and experience: a well-configured monitoring chain + a playbook of actions minimizes human delay and prevents the incident from spreading.
AntiDDoS from VAS Experts – Briefly About the Solution
Stingray AntiDDoS is an example of an integrated provider-oriented solution: the system detects anomalies in real-time, can operate at speeds of hundreds of Gbps, automates the publication of Flowspec rules, and also functions as a scrubbing center itself, capable of cleaning traffic if the provider’s channel has sufficient bandwidth. For providers, this is a way to reduce response time and offer clients a “clean” traffic service without manual fine-tuning of each situation.
How a Server Administrator Detects an Attack in Their Environment
The service itself will indicate that something is wrong: visible symptoms include an increase in connections in the SYN_RECV state (checked via netstat -an | grep SYN_RECV), slowing page response times, increased CPU and memory consumption, and dropped TCP port availability. For confirmation, tools like tcpdump/Wireshark (many SYNs without subsequent ACKs) and monitoring systems (Zabbix, Prometheus, ELK) are used to visualize anomalies and correlate them with time.
Protection Methods on the Server Side
Even with provider protection, a reinforced local configuration reduces the likelihood of failure in borderline cases and helps correctly filter “noise” from useful traffic.
Key measures include:
- Linux Kernel Settings (sysctl)
- Increase the connection backlog queue so the server can handle more half-open connections.
- Reduce the number of SYN-ACK retransmission attempts to free up resources faster.
- Enable SYN Cookies to correctly handle half-open connections without memory overload.
- Connection Rate Limiting (iptables):
Example rule limiting the number of SYNs/sec for port 80:iptables -A INPUT -p tcp --syn --dport 80 -m limit --limit 10/s --limit-burst 20 -j ACCEPT
This helps mitigate the effects of small attacks or bursts but is powerless against very large flows that “jam” the entire channel.
- Hardware and Network Filters
Hardware Firewalls (Juniper, Cisco, Fortinet) can effectively block L3-L4 floods at the data center perimeter level. They have hardware accelerators for processing large numbers of sessions. - CDN / Hosting / DDoS Services
Using cloud CDNs or DDoS providers (Cloudflare, Selectel, VK Cloud, DDoS-Guard, etc.) allows discarding malicious traffic before it reaches the client. For websites, this is often the fastest path to restoring functionality. - Combined Approach
Optimal protection is a combination: proper sysctl settings, SYN Cookies, iptables on the host + filtration from the hoster/provider and the availability of a redirection option to a scrubbing center. Such a multi-layered approach provides the best chance of surviving and restoring critical services.
Conclusion
SYN Flood remains simple in mechanics but flexible and dangerous in its consequences. Relying only on server settings, a serious attack that “clogs” a channel of hundreds of gigabits will still lead to downtime. Relying only on the provider, without proper server configuration and monitoring, also carries a high risk of false positives and prolonged loss of availability.
Looking Ahead: Machine learning and integration with Whitebox equipment promise to make the detection of complex patterns and automatic response even more precise. But even the most advanced algorithms are only effective where the process is automated and delineated: monitoring, detection, publishing mitigation rules, and returning to normal mode.
