SYN Flood Attack Analysis.

In this guided lab, a travel agency's sales webpage started returning connection timeout errors. The scenario provides a Wireshark TCP/HTTP log showing a large number of TCP SYN requests from an unfamiliar IP address. My part was to review the provided log, identify the attack, and write up the incident report.

1. ReviewRead the scenario and the provided log
2. BaselineFollowed normal visits through the three-way handshake and HTTP 200 OK
3. SpotIsolated the flood of SYN requests from 203.0.113.0
4. ImpactTraced 504 Gateway Time-out and [RST, ACK] errors to real visitors
5. ReportWrote the incident report and mitigations

• 140 of the 173 packets came from 203.0.113.0, and 139 of those were SYN requests to the web server on port 443.
• The flood started at packet 52, about 3.39 seconds into the capture.
• Legitimate visitors began getting [RST, ACK] and HTTP 504 Gateway Time-out responses around 6 to 7 seconds in.
• The server stopped responding entirely after packet 124 (20.81 seconds).
• All malicious traffic came from one IP address, so this was a DoS rather than a DDoS attack.

• Block the attacking IP with a firewall rule as an immediate fix, knowing attackers can spoof other addresses.
• Use a firewall or IPS to detect and drop abnormal SYN floods.
• Rate limit incoming connection requests.
• Enable SYN cookies so the server does not reserve resources for half-open connections.

• Wireshark Packet Analysis
• TCP Three-Way Handshake
• HTTP Status Codes
• DoS Detection
• Network Mitigations
• Incident Documentation

• A normal visit is SYN, SYN-ACK, ACK, then a request and a response. A flood of SYNs with no requests is a red flag.
• 504 Gateway Time-out and [RST, ACK] responses to legitimate users show a server that is overwhelmed.
• Blocking one IP helps in the moment, but layered defenses are needed because attackers can spoof addresses.