DDoS Attack Simulation Report

These attacks target web applications and services directly, aiming to exhaust server resources like CPU, memory, or application logic.

• GET/GET Flood:Overwhelms the target with a high volume of standard HTTP GET requests, often targeting large files or dynamic pages to consume bandwidth and server resources.
• POST/POST Flood:Sends a high volume of HTTP POST requests, typically with data payloads, stressing the application's data processing capabilities, database connections, and backend logic. Often more resource-intensive per request than GET floods.
• STOMP:Specialized attack potentially targeting WebSocket or message queue protocols (like STOMP over WebSockets) if used by the application. Aims to bypass specific defenses like CAPTCHAs by attacking underlying protocols.
• STRESS:Sends HTTP packets designed to maximize server load, potentially using large headers, unusual methods, or high byte counts per packet.
• DYN:Dynamic flood using randomized or rapidly changing subdomains (e.g.,random1.BStest.local,random2.BStest.local) to bypass simple caching or DNS-based defenses.
• SLOW:Classic Slowloris attack. Opens multiple connections and keeps them alive by sending partial HTTP requests very slowly, exhausting the server's concurrent connection limit.
• HEAD:Similar to GET flood but uses the HTTP HEAD method (requests only headers, not the body), potentially bypassing some content-based WAF rules while still consuming connection resources.

These attacks target the network infrastructure and transport protocols, aiming to saturate bandwidth or exhaust state tables in firewalls and load balancers.

• TCP/TCP Flood:Generic TCP flood sending a high volume of TCP packets (could be SYN, ACK, FIN, RST, or combinations) to overwhelm state tables or consume processing power. May include bypass techniques.
• UDP/UDP Flood:Floods the target with UDP packets, typically targeting specific ports or sending large packets to saturate network bandwidth. Often used in amplification attacks. Includes bypass techniques.
• SYN/SYN Flood:Sends a high volume of TCP SYN packets (connection initiation requests) with spoofed source IPs. The server keeps allocating resources for half-open connections, eventually exhausting its capacity.
• DNS/DNS Amplification:A reflection/amplification attack. Sends DNS lookup requests to open DNS resolvers with a spoofed source IP (the victim's). The much larger DNS responses are sent back to the victim, overwhelming their network.

• Attack showedextreme traffic volatility(high Std Dev), indicating aggressive mitigation (rate limiting) triggered by sharp peaks (max 77 PPS), followed by near-zero troughs.
• Peak load (77 PPS / 53.9 kBps) occurred ~60s in. Subsequent peaks suggest mitigation thresholds were repeatedly breached or attack sources rotated.
• Despite mitigation,99% impact was reached rapidly and persisted. Allowed GET volume still overwhelmed resources (web server connections, ephemeral ports, CPU/TLS).
• Large delta between Peak (77) and Avg (~25.3) PPS shows mitigation reduced sustained load, but the average throughput was still too high.
• High traffic influx moments: [19:16:35] (peak), [19:17:37], [19:18:10].

• POST flood also showedsignificant traffic volatility(Std Dev PPS: ~14.2), indicating mitigation activity.
• Peak PPS (55) and BPS (45.9 kBps) weremarkedly lower (~15-30%)than GET peaks, expected due to higher server-side processing for POSTs.
• Peak BPS ([19:16:20]) occurred earlier than peak PPS ([19:18:22]), possibly due to initial larger payloads or later mitigation focusing on packet rate.
• Critically, despite lower traffic volume, 99% impact was still reached.This strongly suggests ahigher per-request resource cost for POSTs. Bottleneck likely shifted from network/connection handling toCPU, memory, or database resourcesconsumed by application logic.
• Notable Spikes: [19:16:20] (Peak BPS), [19:17:56], [19:18:22] (Peak PPS).

• Repeat POST flood largely replicated the first test, confirming consistent vulnerability. Showedhigh traffic inconsistency(Std Dev PPS: ~13.1) indicative of mitigation.
• Peak PPS (50) and BPS (41.1 kB/s) were lowest observed, occurring ~75s in ([19:16:49]).
• Crucially, this lowest peak volume still drove the system to 99% impact.Reinforces that POST requests are highly resource-intensive for this application. Bottleneck is almost certainly server-side (CPU, memory, DB, app logic).
• Consistency across POST tests validates the finding: POSTs represent a disproportionately high resource cost compared to GETs.
• Notable Spikes: Main peak at [19:16:49], smaller resurgences near [19:18:25].

• STRESS attack generated moderate peak PPS (65) but notably higher peak BPS (75.2 kB/s), suggesting larger, more complex packets designed to maximize processing load.
• Extreme BPS variability(Std Dev ~20.1) alongside high PPS variability indicates mitigation struggled with both packet rate and packet size/complexity.
• 99% impact achieved rapidly, confirming effectiveness in overwhelming server resources (likely CPU/memory due to packet processing) even without extreme packet rates.
• This attack type effectively targets server processing capacity rather than just connection handling or simple application logic.
• High load moments: [19:21:15] (Peak PPS), [19:21:40] (Peak BPS), [19:22:30].

• SLOW attack operated withextremely low PPS and negligible BPS, consistent with its goal of holding connections open, not flooding traffic.
• Low variability (Std Dev) indicates a steady, persistent attempt to maintain open connections by slowly sending partial data.
• Despite minimal traffic, 99% impact was reached, strongly indicating successfulconnection table exhaustionon the web server or load balancer.
• This type of attack bypasses typical volume-based rate limiting and highlights vulnerability to resource exhaustion through connection handling. Standard flood defenses are ineffective here.
• Impact likely built gradually as connection slots filled up, potentially leading to timeouts for legitimate users trying to establish new connections.

• BOT simulation generated traffic patterns resembling a high-volume GET flood (Peak PPS 70), but potentially with headers/behavior mimicking legitimate crawlers.
• Moderate variabilityinitially might suggest the attack partially bypassed simple signature-based bot detection, behaving more like legitimate traffic before potential rate limiting kicked in.
• 99% impact was still achieved, indicating that even if the traffic appeared 'legitimate' to basic filters, the sheer volume overwhelmed resources similar to the GET flood.
• This highlights the need for advanced bot detection (behavioral analysis, fingerprinting, challenges) beyond simple User-Agent checks or IP reputation.
• Peak activity around [19:31:05], with sustained high load until mitigation likely became more effective later in the test.