1: number of session
2: port reuse
3: tcp-half-open
4: tcp-new session attempts
etc....
So sending 3000k session from a single ip address is easy to defend by setting sessions profiles limits. It's also easy to review from a firewall log analysis.
But a HTTP GE via a single session is much harder. Here' I will use httperf to send a HTTP request that contains 100 GETs
httperf --max-connections 1 --num-calls 100 --print-request header --server www.example.com
So as seen by the tcptrace tool it looks like one single tcp session between client and server.
408 packets seen, 408 TCP packets traced
elapsed wallclock time: 0:00:00.023934, 17046 pkts/sec analyzed
trace file elapsed time: 0:00:01.328067
TCP connection info:
1: kenthehackerLinx:47746 - 93.184.216.34:80 (a2b) 205> 203< (complete)
but if we analyze the actual pcap we will see 100 GETs where contained within the single tcp session
dodflooder@kenthehacker:~$ tcptrace -n -xhttp http.pcap | grep GET | wc
100 300 1900
We will use tshark also to validate the numbers
dodflooder@kenthehacker:~$
dodflooder@kenthehacker:~$ tshark -r http.pcap -z http,stat | tail -n 12
405 1.316035 10.92.89.2 → 93.184.216.34 TCP 66 47746 → 80 [ACK] Seq=6801 Ack=159871 Win=14612 Len=0 TSval=5657385 TSecr=3211221224
406 1.316061 10.92.89.2 → 93.184.216.34 TCP 66 47746 → 80 [FIN, ACK] Seq=6801 Ack=159871 Win=14612 Len=0 TSval=5657385 TSecr=3211221224
407 1.328047 93.184.216.34 → 10.92.89.2 TCP 66 80 → 47746 [FIN, ACK] Seq=159871 Ack=6802 Win=144896 Len=0 TSval=3211221236 TSecr=5657385
408 1.328067 10.92.89.2 → 93.184.216.34 TCP 66 47746 → 80 [ACK] Seq=6802 Ack=159872 Win=14612 Len=0 TSval=5657388 TSecr=3211221236
===================================================================
HTTP Statistics
* HTTP Status Codes in reply packets
HTTP 200 OK
* List of HTTP Request methods
GET 100
===================================================================
and http,tree shows
===========================
HTTP/Packet Counter:
Topic / Item Count Average Min val Max val Rate (ms) Percent Burst rate Burst start
--------------------------------------------------------------------------------------------------------------------------
Total HTTP Packets 200 0.1534 100% 0.1600 0.025
HTTP Response Packets 100 0.0767 50.00% 0.0800 0.025
2xx: Success 100 0.0767 100.00% 0.0800 0.025
200 OK 100 0.0767 100.00% 0.0800 0.025
???: broken 0 0.0000 0.00% - -
5xx: Server Error 0 0.0000 0.00% - -
4xx: Client Error 0 0.0000 0.00% - -
3xx: Redirection 0 0.0000 0.00% - -
1xx: Informational 0 0.0000 0.00% - -
HTTP Request Packets 100 0.0767 50.00% 0.0800 0.012
GET 100 0.0767 100.00% 0.0800 0.012
Other HTTP Packets 0 0.0000 0.00% - -
---------------------------------------------------------------------------------------------------------------------------
HTTP was used here so we could review data with out any decryption concerns. Typically most sites are HTTPS so the same would hold true, a single https-session with multiple HTTP-GET
So DoS protection profiles will not work on a layer7 application flooding and with HTTP protocol. You will need to deploy a SLB or ADC in front of the server to limit the http GETs.
A F5-LTM , Netscaler, FortiWeb or A10 would be able to control this type of flooding or better yet a WAF.
By rate limiting the web site, you can prevent flooding from impacting the servers within the pool.
Other cool tools for web stressing and flooding nc, ab, bombardment or locust.
Enjoy
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com
^ ^
=( @ @ )=
o
/ \
No comments:
Post a Comment