Courseiva
Malware, Social Engineering and Network AttacksmediumMultiple ChoiceObjective-mapped

CEH Practice Question: Malware, Social Engineering and Network Attacks

Which of the following is the BEST defense against a TCP SYN flood attack?

⚠ Common exam trap

The CEH exam often tests the misconception that rate limiting or ingress filtering alone can stop a SYN flood, but the key is that SYN cookies directly prevent the resource exhaustion of the TCP backlog queue, which is the core vulnerability exploited in this attack.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

SYN cookies

SYN cookies are the best defense against TCP SYN flood attacks because they allow the server to avoid allocating resources for half-open connections until the handshake is completed. When a SYN cookie is used, the server encodes connection state information into the initial sequence number (ISN) sent in the SYN-ACK, and only commits memory upon receiving a valid ACK from the client. This prevents the exhaustion of the SYN backlog queue, which is the primary target of a SYN flood.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • Ingress filtering

    Why it's wrong here

    Ingress filtering primarily operates at network borders, inspecting outgoing packets to ensure their source IP addresses originate from within the network's assigned address space. While effective at preventing IP spoofing, which can be a component of some DDoS attacks, it does not directly mitigate a TCP SYN flood. A SYN flood overwhelms a server by exhausting its connection table with half-open connections, regardless of whether the source IPs are legitimate or spoofed, as ingress filtering doesn't prevent the initial SYN packet from reaching the target.

  • Intrusion detection system

    Why it's wrong here

    An Intrusion Detection System (IDS) is designed to monitor network traffic for malicious activity or policy violations, alerting administrators when suspicious patterns are identified. While an IDS can effectively detect the characteristic high volume of SYN packets indicative of a SYN flood, it is a passive monitoring tool. It does not possess the inherent capability to actively block or mitigate the attack traffic itself, requiring integration with an Intrusion Prevention System (IPS) or firewall to take preventive action, making it an indirect defense at best.

  • Rate limiting

    Why it's wrong here

    Rate limiting involves configuring network devices to restrict the number of incoming packets or connections from a specific source or to a particular destination within a given timeframe. While it can help reduce the overall volume of attack traffic during a SYN flood, potentially mitigating some resource exhaustion, it is a blunt instrument. Aggressive rate limiting might inadvertently drop legitimate SYN requests, impacting service availability, and it doesn't specifically address the server's state table exhaustion issue as efficiently or elegantly as SYN cookies, which validate the client before allocating resources.

  • SYN cookies

    Why this is correct

    SYN cookies are a robust defense mechanism against TCP SYN floods, operating by enabling a server to respond to SYN requests without allocating resources for a half-open connection immediately. Instead, the server crafts an initial sequence number (ISN) for the SYN-ACK packet that encodes information about the connection, including the client's IP, port, and the server's ISN. Only when the client responds with a valid ACK packet, using the derived sequence number, does the server then reconstruct the connection state, effectively deferring resource allocation until the three-way handshake is complete and verified. This stateless approach prevents the server's connection table from being overwhelmed.

Visual reference

Client Server SYN (seq=100) SYN-ACK (seq=200, ack=101) ACK (ack=201) Connection established — data transfer begins

About these practice questions

This CEH question is part of Courseiva's 870-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This CEH practice question is part of Courseiva's free EC-Council certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CEH exam.