The document discusses different types of denial of service (DoS) attacks against web servers, focusing on Slowloris, Slow Post, and Slow Read attacks. Slowloris keeps connections open by sending partial HTTP requests and headers. Slow Post sends complete headers but an incomplete message body. Slow Read maliciously throttles the receipt of large HTTP responses to tie up server resources. These low-bandwidth attacks can be effective at consuming connection pools and overloading servers. The document provides details on how each attack works and recommendations for detection and mitigation techniques.

1. DOS ATTACKS
USING
SLOWLORIS
V RAMAN TEJA
DOS ATTACKS
USING
SLOWLORIS
V RAMAN TEJA

2. About me!
 Security Enthusiast
 Graphic & Web Designer
 Entrepreneur
 Engineering in the making
 CISE v 2.0
 Security Enthusiast
 Graphic & Web Designer
 Entrepreneur
 Engineering in the making
 CISE v 2.0

3. Topics
 Dos Attacks – A general description
 Slowloris – Denial of Service – Stops Apache Web
servers
 Other Dos Attacks
 Dos Attacks – A general description
 Slowloris – Denial of Service – Stops Apache Web
servers
 Other Dos Attacks

4. Denial Of Service Attacks

5. Types of Dos Attacks
 There is a variety of forms aiming at a variety of services:
 Traffic consuming attacks or Network Layer Attacks(DNS,
firewall, router, load balancer, OS, etc.)
 Application Layer attacks (web server, media server,
mail server)
 There is a variety of forms aiming at a variety of services:
 Traffic consuming attacks or Network Layer Attacks(DNS,
firewall, router, load balancer, OS, etc.)
 Application Layer attacks (web server, media server,
mail server)

6. Network Layer attacks

7. HTTP GET

8. Application Layer attacks

9. Application Layer DoS attacks
Slow HTTP headers attack (a.k.a. Slowloris)
Slow HTTP message body attack (a.k.a Slow Post)
Slow read HTTP attack (a.k.a. TCP Persist Timer exploit)
Slow HTTP headers attack (a.k.a. Slowloris)
Slow HTTP message body attack (a.k.a Slow Post)
Slow read HTTP attack (a.k.a. TCP Persist Timer exploit)

10. What is low-bandwidth attack?
Mbps/secMbps/sec
Seconds

11. What is common?
 All mentioned attacks aim at draining the pool
of concurrent connections (usually relatively
small)

12. HyperText Transfer Protocol (HTTP)
Message syntax
Per RFC 2616
 generic-message = start-line
 *(message-header CRLF)
 CRLF
 [ message-body ]
 start-line = Request-Line | Status-Line
Per RFC 2616
 generic-message = start-line
 *(message-header CRLF)
 CRLF
 [ message-body ]
 start-line = Request-Line | Status-Line

13. HyperText Transfer Protocol (HTTP)
Message example
 GET /page.htm HTTP/1.1CRLF
 Host: www.example.com:8080CRLF
 Content-Length: 25CRLF
 CRLF
 Optional Message Body
 GET /page.htm HTTP/1.1CRLF
 Host: www.example.com:8080CRLF
 Content-Length: 25CRLF
 CRLF
 Optional Message Body

14. SEND INCOMPLETE HTTP REQUESTS
 Apache has a queue of approx. 256 requests
 Each one waits approx. 400 seconds by default for
the request to complete
 So less than one packet per second is enough to
occupy them all
 Which means Low-bandwidth DoS and no collateral
damage!
 Apache has a queue of approx. 256 requests
 Each one waits approx. 400 seconds by default for
the request to complete
 So less than one packet per second is enough to
occupy them all
 Which means Low-bandwidth DoS and no collateral
damage!

15. Slowloris

16. Slowloris
 Low bandwidth attack that sends HTTP requests with
incomplete headers. It continues to send headers at
regular intervals to keep the sockets active
 First mentioned by Adrian Ilarion Ciobanu in 2007
and implemeted by Robert Hansen in 2009
 Low bandwidth attack that sends HTTP requests with
incomplete headers. It continues to send headers at
regular intervals to keep the sockets active
 First mentioned by Adrian Ilarion Ciobanu in 2007
and implemeted by Robert Hansen in 2009

17. How slowloris works
GET / HTTP/1.1rn
Host: vulnerable-server.com:80rn
X-sadwqeq: dfg4t3rn
X-4rete: fdsgvryrn
59 seconds later
X-4rete: fdsgvryrn
X-4rete: fdsgvryrn
X-egyr7j: 8ihrn
59 seconds later
59 seconds later
Client Server

18. Demonstration

19. Slow POST
 Attack that sends HTTP requests with complete
headers but incomplete message body. There will
be no delay in HTTP header. Continues to send
data at regular intervals to keep the sockets
active
 Nullifies IIS internal defence.
 Discovered by Wong Onn Chee and popularized
by Tom Brennan in 2009
 Attack that sends HTTP requests with complete
headers but incomplete message body. There will
be no delay in HTTP header. Continues to send
data at regular intervals to keep the sockets
active
 Nullifies IIS internal defence.
 Discovered by Wong Onn Chee and popularized
by Tom Brennan in 2009

20. How Slow POST works
POST / HTTP/1.1rnHost: vulnerable-server.com:80rn
Content-Length: 4096rn
Content-Type: application/x-www-form-urlencodedrn
59 seconds later
rn
foo=barrn
&Owkuvj5=POaLLIrn
&uWat9wGqrP4SxV=SN3qrn
59 seconds later
59 seconds later
59 seconds later
...
Client Server

21. Slow Read
 Attack that keeps server sockets busy by maliciously
throttling down the receipt of large HTTP responses
 Uses known Network Layer flaws to aim Application Layer
 First mentioned by Outpost24 in sockstress. Implemented
as part of nkiller2 by Fotis Hantzis, a.k.a. ithilgore in
2009
 Attack that keeps server sockets busy by maliciously
throttling down the receipt of large HTTP responses
 Uses known Network Layer flaws to aim Application Layer
 First mentioned by Outpost24 in sockstress. Implemented
as part of nkiller2 by Fotis Hantzis, a.k.a. ithilgore in
2009

22. Related TCP details
“Window size (16 bits) – the size of the receive
window, which specifies the number of bytes (beyond
the sequence number in the acknowledgment field)
that the sender of this segment is currently willing to
receive” – Wikipedia
“Window size (16 bits) – the size of the receive
window, which specifies the number of bytes (beyond
the sequence number in the acknowledgment field)
that the sender of this segment is currently willing to
receive” – Wikipedia

23. How Slow Read works
bigpage.html
Client ServerGET bigpage.html HTTP/1.1rn
Host: vulnerable-server.com:80rnrn
BTW, my recv window is only 32 bytes
HTTP/1.1 200 OKrn
Content-Length: 131072rn
Content-type: text/htmlrnrn message
Recvbuffer
Sendbuffer
bigpage.html
HTTP/1.1 200 OKrn
Content-Length: 131072rn
Content-type: text/htmlrnrn messageKernel to app: I can send only 32 bytes now
Got it, wait for now (ACK window 0)
9090
Are you ready to receive more bytes?
OK, give me another 32 bytes

24. Prerequisites for successful Slow
Read attack
 The larger server response is - increasing the chances of
prolonging the connection
 make server generate a data stream that doesn't fully fit
into socket's send buffer (65536 bytes is default on most
Linux systems /proc/sys/net/ipv4/tcp_wmem, if server
doesn't set its own value)
 Request large resource by naturally finding it and/or
amplifying the response size by using HTTP pipelining.
 The larger server response is - increasing the chances of
prolonging the connection
 make server generate a data stream that doesn't fully fit
into socket's send buffer (65536 bytes is default on most
Linux systems /proc/sys/net/ipv4/tcp_wmem, if server
doesn't set its own value)
 Request large resource by naturally finding it and/or
amplifying the response size by using HTTP pipelining.
time

25. Why is Slow Read different?
Traditional (slowloris/slowpost) DoS
 Customer stuck deciding
what he wants
 Makes an order
 Pays
 Takes the order
 Next!
It is possible to identify and isolate
slow client in his request state
 Customer stuck deciding
what he wants
 Makes an order
 Pays
 Takes the order
 Next!
It is possible to identify and isolate
slow client in his request state

26. Why Slow Read is different?
Slow Read DoS
 Makes an order for
party of 50
 Pays
 Cannot take the
entire order with him,
makes several trips
to the car.
 Next!
it is quite late to do anything, as
the request was already accepted
and processed
 Makes an order for
party of 50
 Pays
 Cannot take the
entire order with him,
makes several trips
to the car.
 Next!

27. Why is Slow Read different?
 Makes an order for
party of 50
 Pays
 Cannot take the
entire order with him,
makes several trips to
the car
 Next!
Customer stuck deciding
what he wants Makes an
order & Pays Takes the
order Next!
 Makes an order for
party of 50
 Pays
 Cannot take the
entire order with him,
makes several trips to
the car
 Next!

28. Why is Slow Read different? (contd..)
 Defense mechanisms expect the crushing fist of malice to
appear in the request
 Instead, the entire transaction should be monitored
 Defense mechanisms expect the crushing fist of malice to
appear in the request
 Instead, the entire transaction should be monitored

29.  There is a good chance that you are. Default
configurations of nginx, lighttpd, IIS, Apache, Varnish
cache proxy, Shoutcast streaming server - are vulnerable
to at least one of the mentioned attacks
Am I vulnerable?
 There is a good chance that you are. Default
configurations of nginx, lighttpd, IIS, Apache, Varnish
cache proxy, Shoutcast streaming server - are vulnerable
to at least one of the mentioned attacks

30.  Use available tools to simulate attacks. SlowHTTPTest
covers all mentioned attacks and some more at
http://slowhttptest.googlecode.com
 Check out http://slowhammer.me to get access to your
own whitehat botnet in the cloud
 Use Qualys WAF or other firewalls that are supposed to
protect, but test before you pay!
What should I do?
 Use available tools to simulate attacks. SlowHTTPTest
covers all mentioned attacks and some more at
http://slowhttptest.googlecode.com
 Check out http://slowhammer.me to get access to your
own whitehat botnet in the cloud
 Use Qualys WAF or other firewalls that are supposed to
protect, but test before you pay!

31. Detection and Mitigation
 Drop connections with abnormally small TCP advertised
window(s) (i.e. <<16bits)
 Set an absolute connection timeout, if possible
 Limit length, number of headers to accept
 Limit max size of message body to accept
 Drop connections with HTTP methods (verbs) not supported
by the URL
 Limit accepted header and message body to a minimal
reasonable length
 Define the minimum data rate, and drop connections that
are slower than that rate
 Drop connections with abnormally small TCP advertised
window(s) (i.e. <<16bits)
 Set an absolute connection timeout, if possible
 Limit length, number of headers to accept
 Limit max size of message body to accept
 Drop connections with HTTP methods (verbs) not supported
by the URL
 Limit accepted header and message body to a minimal
reasonable length
 Define the minimum data rate, and drop connections that
are slower than that rate

32. Detection and Mitigation
 Qualys Web Application Scanner passively detects the
slow attack vulnerabilities
 ModSecurity v2.6 introduced a directive called
SecWriteStateLimit that places a time limit on the
concurrent number of threads (per IP address)
 Snort is working on detecting connections with small TCP
advertised window(s)
 Christian Folini introduced Flying Frog script at
https://www.netnea.com
 Qualys Web Application Scanner passively detects the
slow attack vulnerabilities
 ModSecurity v2.6 introduced a directive called
SecWriteStateLimit that places a time limit on the
concurrent number of threads (per IP address)
 Snort is working on detecting connections with small TCP
advertised window(s)
 Christian Folini introduced Flying Frog script at
https://www.netnea.com

33. Example of misconfiguration

34. OSI Model- a new approach
OSI Model DoS Attack
7 Application Slowloris – Incomplete HTTP Requests
6 Presentation
5 Session5 Session
4 Transport SYN Flood – Incomplete TCP Handshakes
3 Network HTTP GET/POST Flood
2 Data Link
1 Physical Cut a cable

35. A few more Attacks!A few more Attacks!

36. “the sky is falling.... but we cannot tell you why”
The new TCP DoS attacks
Source: news.softpedia.com

37. The “new” TCP DoS attacks
 During 2008, the discovery of some (supposedly)
new vulnerabilities received their share of press.
 They were “announced” by Outpost24, but no
details were provided – thus resulting in speculation
by the community.
 No counter-measures were proposed to vendors,
either.
 While not publicly credited for our work, we
provided advice to vendors on these issues.
 During 2008, the discovery of some (supposedly)
new vulnerabilities received their share of press.
 They were “announced” by Outpost24, but no
details were provided – thus resulting in speculation
by the community.
 No counter-measures were proposed to vendors,
either.
 While not publicly credited for our work, we
provided advice to vendors on these issues.

38. The “new” TCP DoS attacks
 For the most part, the vulnerabilities are:
 Connection-flooding attacks (Naphta and FIN-WAIT-2
flooding attacks)
 Socket send buffer attacks (Netkill and closed windows)
 TCP reassembly buffer attacks
 For the most part, the vulnerabilities are:
 Connection-flooding attacks (Naphta and FIN-WAIT-2
flooding attacks)
 Socket send buffer attacks (Netkill and closed windows)
 TCP reassembly buffer attacks

39. Some insights on the recent TCP DoS
vulnerabilities
Some insights on the recent TCP DoS
vulnerabilities

40. Connection-flooding attacks
(Naphta and FIN-WAIT-2)
Connection-flooding attacks
(Naphta and FIN-WAIT-2)

41. Naphta (connection-flooding
attack)
 TCP connections require end-points to keep state (in
system memory) for the connections.
 Memory is a limited resource, and thus can be
targeted for exhaustion: simply establish lots of
connections with the target system.
 This attack vector was known as “Naphta” -- see
CERT Advisory CA-2000-21.
 To avoid exhausting his own resources simply crafts
the required packets to establish TCP connections
with the target system, thus bypassing its kernel
implementation of TCP.
 TCP connections require end-points to keep state (in
system memory) for the connections.
 Memory is a limited resource, and thus can be
targeted for exhaustion: simply establish lots of
connections with the target system.
 This attack vector was known as “Naphta” -- see
CERT Advisory CA-2000-21.
 To avoid exhausting his own resources simply crafts
the required packets to establish TCP connections
with the target system, thus bypassing its kernel
implementation of TCP.

42. Naptha attack (example)

43. Countermeasures for Naphta
 Key problem: an actual attack does not necessarily
differ from a high-load scenario
 Possible counter-measures:
 Enforce per-user and pre-process limits
 Enforce limits on the number of ongoing connections
from a single system/prefix at the application-layer
 Enforce limits on the number of ongoing connections
from a single system/prefix at a firewall
 Key problem: an actual attack does not necessarily
differ from a high-load scenario
 Possible counter-measures:
 Enforce per-user and pre-process limits
 Enforce limits on the number of ongoing connections
from a single system/prefix at the application-layer
 Enforce limits on the number of ongoing connections
from a single system/prefix at a firewall

44.  A typical connection-termination scenario:
FIN-WAIT-2 flooding attack
 A typical connection-termination scenario:

45. FIN-WAIT-2 flooding attack
 Problems that may arise due to the FIN-WAIT-2
state
 There’s no limit on the amount of time a connection can
stay in the FIN-WAIT-2 state – connections could stay
forever in FIN-WAIT-2.
 When TCP gets into the FIN-WAIT-2 state there’s no
user-space controlling process (i.e., it’s hard to enforce
application-layer limits)
 Problems that may arise due to the FIN-WAIT-2
state
 There’s no limit on the amount of time a connection can
stay in the FIN-WAIT-2 state – connections could stay
forever in FIN-WAIT-2.
 When TCP gets into the FIN-WAIT-2 state there’s no
user-space controlling process (i.e., it’s hard to enforce
application-layer limits)

46. FIN-WAIT-2 attack (example)

47. Counter-measures for FIN-WAIT-2
flooding
 Enforce a limit on the duration of the FIN-WAIT-2
state. E.g., Linux 2.4 enforces a limit of 60 seconds.
Once that limit is reached, the connection is
aborted.
 Enforce on the number of ongoing connections with
no controlling process.
 The counter-measures for the Naptha attack still
apply. However, it is difficult for applications to
enforce limits (remember: no controlling process for
the connections).
 Enforce a limit on the duration of the FIN-WAIT-2
state. E.g., Linux 2.4 enforces a limit of 60 seconds.
Once that limit is reached, the connection is
aborted.
 Enforce on the number of ongoing connections with
no controlling process.
 The counter-measures for the Naptha attack still
apply. However, it is difficult for applications to
enforce limits (remember: no controlling process for
the connections).

48. Counter-measures for FIN-WAIT-2
flooding
 Applications should be modified so that they retain
control of the connection for most states. This can be
achieved with a conbination of the shutdown(),
setsockopt(), and close().
 Applications should be modified so that they retain
control of the connection for most states. This can be
achieved with a conbination of the shutdown(),
setsockopt(), and close().

49. Socket send buffer vulnerabilities
 The socket send buffer keeps a copy of those data
that have been accepted by TCP for delivery to the
remote TCP end-point.
 It is possible to exploit the Socket send buffer for a
memory exhaustion attack:
 Send an application request to the target system, but
never acknowledge the response (Netkill).
 Send an application request, but immediately close the
receive window, so that the target TCP refrains from
actually sending the response.
 The socket send buffer keeps a copy of those data
that have been accepted by TCP for delivery to the
remote TCP end-point.
 It is possible to exploit the Socket send buffer for a
memory exhaustion attack:
 Send an application request to the target system, but
never acknowledge the response (Netkill).
 Send an application request, but immediately close the
receive window, so that the target TCP refrains from
actually sending the response.

50. Netkill
 Data that have been sent but not yet acknowledged
are kept in the socket send buffer for their possible
retransmission.
 TCP will retransmit those data until they either get
acknowledged or the connection times out. In the
mean time, system memory is tied to those data.
 Easy to exploit for memory exhaustion: establish lots
of TCP connections, send an applicattion-request on
each of them, and never acknowledge the received
data.
 Data that have been sent but not yet acknowledged
are kept in the socket send buffer for their possible
retransmission.
 TCP will retransmit those data until they either get
acknowledged or the connection times out. In the
mean time, system memory is tied to those data.
 Easy to exploit for memory exhaustion: establish lots
of TCP connections, send an applicattion-request on
each of them, and never acknowledge the received
data.

51. Netkill (example)

52. Netkill (countermeasures)
 Problem: it’s very hard to infer attack from the
behavior of a single connection.
 Possible counter-measures:
 Measure connection progress at the application-
layer
 Do not use an unnecessarily large socket send
buffer
 Enforce per-user and pre-process limits
 Enforce limits on the number of ongoing connections
from a single system/prefix at the application-
layer
 Problem: it’s very hard to infer attack from the
behavior of a single connection.
 Possible counter-measures:
 Measure connection progress at the application-
layer
 Do not use an unnecessarily large socket send
buffer
 Enforce per-user and pre-process limits
 Enforce limits on the number of ongoing connections
from a single system/prefix at the application-
layer

53. Netkill(countermeasures)
 Enforce limits on the number of on-going connections
from a single system/prefix at a firewall
 When dropping connection, these are possible parameters
that may provide hints for selecting the target connection:
 Large amount of data queued in the TCP retransmission
buffer
 Small amount of data successfully transferred to the
remote endpoint
 Enforce limits on the number of on-going connections
from a single system/prefix at a firewall
 When dropping connection, these are possible parameters
that may provide hints for selecting the target connection:
 Large amount of data queued in the TCP retransmission
buffer
 Small amount of data successfully transferred to the
remote endpoint

54. Closed windows
 The TCP sliding-window mechanism prevents a fast
sender from overwhelming a slow consumer
application.
 When the advertised window is zero, the window is
said to be closed.
 The TCP sender polls the receiver from time to time
to find out if the window has opened (persist timer).
However, there’s no limit on the amount of time that
the window can be closed.
 The TCP sliding-window mechanism prevents a fast
sender from overwhelming a slow consumer
application.
 When the advertised window is zero, the window is
said to be closed.
 The TCP sender polls the receiver from time to time
to find out if the window has opened (persist timer).
However, there’s no limit on the amount of time that
the window can be closed.

55. Closed windows
 Easy to exploit for memory exhaustion: just send an
applicattion-request to the remote end-point, and
close the receive window.
 Easy to exploit for memory exhaustion: just send an
applicattion-request to the remote end-point, and
close the receive window.

56. Closed windows (example)

57. Closed windows (countermeasures)
 Problem: it’s very hard to infer attack from the
behavior of a single connection.
 It has been proposed that TCP should impose a limit
on the amount of time that the window can be
closed. However, this counter-measure is trivial to
circumvent: just open the window a bit from time to
time.
 Problem: it’s very hard to infer attack from the
behavior of a single connection.
 It has been proposed that TCP should impose a limit
on the amount of time that the window can be
closed. However, this counter-measure is trivial to
circumvent: just open the window a bit from time to
time.

58. Closed windows (countermeasures)
 Measure connection progress at the application-layer
 Do not use an unnecessarily large socket send buffer
 Enforce per-user and pre-process limits
 Enforce limits on the number of ongoing connections
from a single system/prefix at the application-layer
 Enforce limits on the number of ongoing connections
from a single system/prefix at a firewall
 Measure connection progress at the application-layer
 Do not use an unnecessarily large socket send buffer
 Enforce per-user and pre-process limits
 Enforce limits on the number of ongoing connections
from a single system/prefix at the application-layer
 Enforce limits on the number of ongoing connections
from a single system/prefix at a firewall

59. Summary
 Even though the simplest distributed DoS
attacks are enough to knock down most web
sites today, the nature of the attack will be
sure to improve, and it’s better to be ready
or, at least be aware of upcoming problems.
 Even though the simplest distributed DoS
attacks are enough to knock down most web
sites today, the nature of the attack will be
sure to improve, and it’s better to be ready
or, at least be aware of upcoming problems.

60. References
 ModSecurity Advanced Topic of the Week: Mitigation of 'Slow Read" Denial of
Service Attack
 http://blog.spiderlabs.com/2012/01/modsecurity-advanced-topic-of-the-week-
mitigation-of-slow-read-denial-of-service-attack.html
 DDoS attacks in H2 2011
http://www.securelist.com/en/analysis/204792221/DDoS_attacks_in_H2_2011
 The State of the Internet
 http://www.akamai.com/stateoftheinternet/
 Evaluation of slowhttptest against servers protected by CloudFlare
 http://samsclass.info/123/proj10/slow-read.html
 Blog posts on hardening web servers
 https://community.qualys.com/blogs/securitylabs/
 ModSecurity Advanced Topic of the Week: Mitigation of 'Slow Read" Denial of
Service Attack
 http://blog.spiderlabs.com/2012/01/modsecurity-advanced-topic-of-the-week-
mitigation-of-slow-read-denial-of-service-attack.html
 DDoS attacks in H2 2011
http://www.securelist.com/en/analysis/204792221/DDoS_attacks_in_H2_2011
 The State of the Internet
 http://www.akamai.com/stateoftheinternet/
 Evaluation of slowhttptest against servers protected by CloudFlare
 http://samsclass.info/123/proj10/slow-read.html
 Blog posts on hardening web servers
 https://community.qualys.com/blogs/securitylabs/

61. Contact
 V Raman teja
 Network Security , Web Technologies, Graphic
Designing & Coding
 Email: venigallaramanteja@gmail.com
 Ph: 9032195562
 V Raman teja
 Network Security , Web Technologies, Graphic
Designing & Coding
 Email: venigallaramanteja@gmail.com
 Ph: 9032195562