IBM Support

SYN Flood attack - Detection and Prevention

Troubleshooting


Problem

A SYN flood is a form of denial-of-service attack in which an attacker sends a succession of SYN requests from random or spoofed source IP addresses to a target in an attempt to consume enough server resources to make the system unresponsive to legitimate traffic.  
A standard TCP connection is established by sending a SYN packet to the destination host. If the destination host is waiting for a connection on the specified port, it will respond with a SYN/ACK packet. The source host (the initial sender) then replies to the SYN/ACK with an ACK packet, and the connection is established.  
When the SYN/ACK packet is sent back to the source host, a block of memory on the destination host is allocated to hold information about the state of the connection that is currently being established. Until the final ACK is received from the source host, or a timeout is reached, this block of memory remains unused, waiting for more information to be received from the source host.

Cause

By sending numerous SYN packets to a host, the destination host will exhaust the portion of memory used to manage opening connections. When this memory is exhausted, legitimate connections will no longer be able to connect to the destination host.  The OS allocates resources (such as memory and connection slots) to each incoming SYN request. Since the attacker doesn't complete the handshake, these resources are not released. The rapid accumulation of half-open connections can exhaust the victim's resources. In a SYN Flood attack, backlog of half-open connections can grow significantly, consuming available resources.

Diagnosing The Problem

This situation can be detected by a flood of SYN packets that do not have accompanying responses.    To illustrate, it is useful to simulate a SYN Flood attack, search the internet for “Kali Linux hping3 syn flood” for such methods to implement.  Once you have simulated the attack, you can run `tcpdump` directly on the VSI terminal to selectively capture only SYN-ACK packets sent by the VSI.

sudo timeout 15 tcpdump -i ifXXXXXXXX -nnq 'tcp[13] = 0x12'

image-20240130083532-1

Or use below to only filter the connections to the public IP addresses.

tcpdump -i eth0 -nnq 'tcp[13] = 0x12 and not (net 10.0.0.0/8 or net 172.16.0.0/12 or net 192.168.0.0/16 or net 169.254.0.0/16 or net 127.0.0.0/8)'

Wireshark can then be used to help detect the simulated SYN Flood attacks:

image-20240130083730-2

As you can see attack has reaching 2500 packets/sec.  
In network captures, you may notice numerous packets with identical sizes, often registering as 0-byte packets:

image-20240130083944-3

Another option is to use ss/netstat command within the VSI to check whether the VSI is transmitting a significant number of SYN-ACK messages to unknown IPs:
watch -n 2 ss -an4 state syn-recv
image-20240130084111-4
IBM Flow Logs might also be used to check for historical attacks in a VPC. Use these steps to create Flow Logs.  Following are sample screenshots showing some required steps:
image-20240130084313-6
Create Object Storage

image-20240130084407-7

Authorize resources of type Flow Logs for VPC to use the Object Storage instance created

image-20240130084439-8

Creating a flow log collector

There are various ways to process flow logs for specific use cases, and all have specific advantages e.g.:

Following is a sample screenshot using LogDNA:

image-20240130084611-9

The following are alternative methods can also be used:

Following is sample output using Data Engine:

image-20240130084738-10

You can check the “was_terminated” field to know the connection status. Additional fields of interest might include:

bytes_from_initiator, packets_from_initiator to know data sent from initiator to target

bytes_from_target, packets_from_target to know data sent from target to initiator.

Resolving The Problem

How do I help prevent a Syn Flood attack? Review and implement the following

Best Practice Guidelines:

  • Network Access Control Lists (NACL) and Security Group (SG) Rules: Customers can use NACL rules to block at the subnet level or SG rules to block at the VSI level.
  • Harden the VSI: Customers can enhance VSI security by implementing rate limiting, SYN cookies, IP tables, max connection counts, etc., at the OS or application level.

Several options are available to address this:

  • Direct Link (Most Expensive): IBM provides private connectivity where traffic never touches the public internet. This can be achieved through direct peering with IBM or via any exchange provider that has colocation with IBM.
  • VPN Connectivity (Less Expensive): IBM offers VPN connectivity for customers who prefer a less management-intensive solution. This includes site-to-site or client-server VPN options, with IBM managing the VPN and providing a High Availability (HA) option.
  • Cloud Flare CIS: Another option that includes built-in DDOS protection, WAF, DNS LB, etc. However, it's essential to note that customer will only be opening ports between CIS and VSI on their FIP.
  • VPC NLB Option: In VPC, an option is available for Network LB. NLB sits in front with static FIP per zone and customer VSI acts as a backend member pool with private IP. NLB forwards everything to VSI(s) and also protects it.
  • Classic Environment with Floating IP: If the VSI has a floating IP and the Classic environment is considered more secure than VPC, customers can place their JUMP VSI in classic and connect seamlessly with their VPC side. This scenario is commonly used for migrating customers from classic to VPC.
  • Virtual Firewall Appliance in Classic: Customers with workloads in Classic can deploy virtual firewall appliances by Juniper, PaloAlto, Fortinet, etc. This ensures they are fully protected by an industry-based security solution, and they can also run VPNs and create site-to-site tunnels. They can route all their traffic from firewall to VPC.
  • VPC NFV Firewall Option: In VPC, an option is available for Network Function Virtualization (NFV) firewall. Customers can deploy their NFV firewall, which will be licensed and managed by the customer.
  • Edge VPC with Transit Gateway (TGW) Option: Customers can opt for Transit Gateway where a separate EDGE VPC is created along with their ServerFarm VPC, and all traffic is routed via EDGE VPC to the SERVER FARM VPC. Edge VPC has all the security appliances/NFV firewalls.
  • Custom Ingress Routing Table: Customers can add drop rules against IPs or network ranges at VPC routing level by creating a custom ingress routing table, acting as a NULL route scenario similar to Classic.

For better visibility

  • Flow Logs: To gain better visibility and monitoring of VPC traffic, customers can add flow logs to observe network traffic connection logs.

By thoughtfully considering and implementing these options, you can strengthen the security of your infrastructure and safeguard against threats.

Document Location

Worldwide

[{"Type":"MASTER","Line of Business":{"code":"LOB21","label":"Public Cloud Platform"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEK1X","label":"IBM Cloud Virtual Servers for VPC"},"ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]

Document Information

Modified date:
30 January 2024

UID

ibm17112468

Page Feedback