Analysis of Slow Denial-of-Service Attacks

FACULTY OF ENGINEERING AT UNIVERSITY OF PORTO 
COMPUTER SYSTEMS SECURITY

I. Slow read

II. Slow Loris
III. Our Implementation

iV. Protection Strategies

Slow denial of services attacks

  1. Exhaust server connections
  2. Require low amount of resources and bandwidth

Slow
READ

Explores a vulnerability in the Transmission Control Protocol (TCP) specification which allows advertising a zero byte window.


”A TCP MAY keep its offered receive window closed indefinitely. As long as the receiving TCP continues to send acknowledgements in response to the probe segments, the sending TCP MUST allow the connection to stay open.” 

- RFC 1122
  1. The malicious attacker makes a connection to the server
  2. Advertises zero byte receiving buffer windows
  3. The server tries to send data
  4. Attacker ACK data with a zero buffer window
  5. Server, keeps the connection open
  6. Server, Regularly tries to send information
  7. Indefinitely loops 4,5 and 6.

Process

16:57:44  attacker > ni.fe.up.pt: Flags [S], seq 3187993640, win 29200, length 0
16:57:44  attacker > ni.fe.up.pt: Flags [S], seq 3930293194, win 1152, length 0
16:57:44  ni.fe.up.pt > attacker: Flags [S.], seq 4063001143, ack 3187993641, win 28960, length 0
16:57:44  attacker > ni.fe.up.pt: Flags [.], ack 1, win 229, length 0
16:57:44  attacker > ni.fe.up.pt: Flags [P.], seq 1:177, ack 1, win 229, length 176
16:57:44  ni.fe.up.pt > attacker: Flags [S.], seq 3470787838, ack 3930293195, win 28960, length 0
16:57:44  attacker > ni.fe.up.pt: Flags [.], ack 1, win 1152, length 0
16:57:44  attacker > ni.fe.up.pt: Flags [P.], seq 1:177, ack 1, win 1152, length 176
16:57:44  ni.fe.up.pt > attacker: Flags [.], ack 177, win 235, length 0
16:57:44  attacker > ni.fe.up.pt: Flags [.], ack 4526, win 0, length 0
16:57:45  ni.fe.up.pt > attacker: Flags [.], ack 528, win 243, length 0
16:57:45  attacker > ni.fe.up.pt: Flags [.], ack 4526, win 0, length 0
16:57:45  ni.fe.up.pt > attacker: Flags [.], ack 528, win 243, length 0
16:57:45  attacker > ni.fe.up.pt: Flags [.], ack 4526, win 0, length 0
16:57:46  ni.fe.up.pt > attacker: Flags [.], ack 528, win 243, length 0

Experiment

Detection

  1. The server accepts SYN packets with abnormal window size
  2. The server does not send RST or FIN packets if the receiver does not accept data.
  3. The server enables persistent connections.

Mitigation

  1. Reject connections with abnormal window size
  2. Disable persistent connections
  3. Limit the absolute connection lifetime

Slow
LOris

EXPLOITS THE THREAD-BASED ARCHITECTURE OF SOME WEB SERVERS

Uses HTTP protocol as a mean

  1. Large number of HTTP connections
  2. Attacker sends data painfully slow
  3. Before timeout, sends data
  4. Indefinitely loops between 2 and 3
  5. If a request ends, the attacker creates a new one and starts from 2

Process

  1. Low CPU usage
  2. Lot of 'server' processes

  3. Practically no new requests

  4. Probably, max thread-pool error

Detection

  1. Using netstat, to list the most active IP's on the server

  2. And use something to block:

    • iptables

    • route

    • ip

Detection

Mitigation

  1. Load-Balancers
    • Delayed binding
  2. Iptables
    • Create rules
  3. Or, use some module depending on the web server

OUR
Implementation

SlowREAD-RS

  • Implemented from scratch;
  • Asynchronous, configurable CLI tool;
  • Written in Rust;

 

Help menu

Live demo

$ ./slowread -a https://ni.fe.up.pt/images/projects/PKyl13EDPj3HLxF4.png

https://github.com/bernardobelchior/slowread-rs

Protection
Strategies

  • Overall protections
  • Particular protections
    • ​Apache
    • Nginx

Overall Protections

  • Reject or drop connections with HTTP methods that are not supported by the URL;
  • Limit the header and the body of a message;
  • Define a minimum incoming data rate.

PROTECTIONS FOR APACHE

  • Between both servers Apache is the most sensible with Slow Denial-of-Services attacks; 
  • RequestReadTimeout sets the minimum data rate and timeout for receiving requests;
  • MaxRequestWorkers increase the maximum number of simultaneous connections to handle.

Protections FOR Nginx

  • Has the same modules as Apache;
  • HttpLimitReqModule and HttpLimitZoneModule  allow to limit the number of request and also the number of simultaneous connections related to a given session or same address.
In terms of handling connections, Apache has a maximum number of simultaneous connections that it can handle at the same time, while Nginx don't have a maximum connections, but instead, uses a scalable event-driven architecture to manage them. Apache receives requests and handles them by it self and Nginx instead, ignore those and let them run in the background, needing only to process connections with some logic associated.

Analysis of Slow Denial-of-Service Attacks

By Pedro Costa

Made with Slides.com

Analysis of Slow Denial-of-Service Attacks

  • 466

More from Pedro Costa