DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Last call! Secure your stack and shape the future! Help dev teams across the globe navigate their software supply chain security challenges.

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workloads.

Releasing software shouldn't be stressful or risky. Learn how to leverage progressive delivery techniques to ensure safer deployments.

Avoid machine learning mistakes and boost model performance! Discover key ML patterns, anti-patterns, data strategies, and more.

Related

  • Accelerating Connection Handshakes in Trusted Network Environments
  • C# Applications Vulnerability Cheatsheet
  • Go Application Vulnerability Cheatsheet
  • Easy Oracle Database Migration with SQLcl

Trending

  • Understanding and Mitigating IP Spoofing Attacks
  • It’s Not About Control — It’s About Collaboration Between Architecture and Security
  • Customer 360: Fraud Detection in Fintech With PySpark and ML
  • Teradata Performance and Skew Prevention Tips
  1. DZone
  2. Data Engineering
  3. Data
  4. Mitigate Slow HTTP GET/POST Vulnerabilities in the Apache HTTP Server

Mitigate Slow HTTP GET/POST Vulnerabilities in the Apache HTTP Server

Learn how you can mitigate slow HTTP GET/POST vulnerabilities in the Apache HTTP Server.

By 
Ian Muscat user avatar
Ian Muscat
·
Jun. 26, 19 · Tutorial
Likes (1)
Comment
Save
Tweet
Share
16.9K Views

Join the DZone community and get the full member experience.

Join For Free

Slow HTTP DoS

A slow HTTP Denial of Service attack (DoS), otherwise referred to as the Slowloris HTTP attack, makes use of HTTP GET requests to occupy all available HTTP connections permitted by a web server. It takes advantage of a vulnerability in thread-based web servers, which wait for entire HTTP headers to be received before releasing the open connection. A variation of this vulnerability is the slow HTTP POST vulnerability. In a slow HTTP POST attack, the attacker declares a large amount of data to be sent in an HTTP POST request and then sends it very slowly.

A malicious user can open many connections to the server by initiating HTTP requests but not closing them. If the attacker keeps every HTTP request open and feeds the server bogus data before the timeout is reached, the HTTP connection will remain open until the attacker closes it. Naturally, if an attacker occupies all available HTTP connections for a web server and keeps them busy waiting, legitimate connections cannot be processed by the server and this causes a denial of service.

This technique lets an attacker consume server resources and restrict access using very little bandwidth. This breed of DoS attack is different from other DoS/DDoS attacks such as SYN flood attacks, which misuse the TCP SYN (synchronization) segment during a TCP three-way handshake.

How it Works

An analysis of an HTTP GET request helps further explain how and why a slow HTTP DoS attack is possible. A complete HTTP GET request resembles the following:

GET /index.php HTTP/1.1[CRLF]
Pragma: no-cache[CRLF]
Cache-Control: no-cache[CRLF]
Host: testphp.vulnweb.com[CRLF]
Connection: Keep-alive[CRLF]
Accept-Encoding: gzip,deflate[CRLF]
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) 
  Chrome/28.0.1500.63 Safari/537.36[CRLF]
Accept: */*[CRLF][CRLF]


The CRLF (Carriage Return + Line Feed) is a sequence of non-printable characters that is used to denote the end of a line. Similar to text editors, an HTTP request uses an [CRLF] at the end of a line to start a fresh line and two [CRLF] sequences to denote a blank line. The HTTP protocol defines a blank line as the completion of a header. A slow HTTP DoS attack takes advantage of this by never sending a finishing blank line to complete the HTTP header.

While some thread-based servers such as Apache use a timeout when they wait for incomplete HTTP requests, it is set to 300 seconds by default and reset as soon as the client sends the rest of the data. To make matters worse, a slow HTTP DoS attack is not commonly detected by Intrusion Detection Systems (IDS) because it does not contain any malformed requests. The HTTP request will seem legitimate to the IDS.

Identifying and Mitigating Slow HTTP Attacks

Slow HTTP DoS attacks are only effective against thread-based web servers such as Apache, dhttpd, or Microsoft IIS. They are not effective against event-based web servers such as nginx and lighttpd, which are built to handle large numbers of concurrent connections.

The Acunetix Web Vulnerability Scanner is capable of identifying slow HTTP vulnerabilities such as CVE-2007-6750. When running a scan on a website that is vulnerable to a slow HTTP DoS attack, an alert is raised that looks similar to the following one:

Slow HTTP Denial of Service Attack Alert

Preventing and Mitigating Slow HTTP Attacks in the Apache HTTP Server

A number of techniques exist for preventing and mitigating slow HTTP DoS attacks in the Apache HTTP server. Following are descriptions of three of the most popular and easiest to implement techniques. Of course, other techniques for preventing and mitigating slow HTTP DoS attacks exist, for example, involving the use of load balancers and iptables.

Using mod_reqtimeout

The mod_reqtimeout module is included by default in Apache HTTP Server v2.2.15 and up. You can use it to set timeouts for receiving HTTP request headers and the HTTP request body from a client. As a result, if a client fails to send header or body data within the configured time, a 408 REQUEST TIMEOUT error is sent by the server. The following is an example of a configuration that can be used with  mod_reqtimeout:

<IfModule mod_reqtimeout.c>  
  RequestReadTimeout header=20-40,MinRate=500 body=20-40,MinRate=500
</IfModule>


The above configuration gives the client a maximum of 20 seconds to start sending header data. The client must send header data at a transfer rate of 500 bytes per second and may do it for a maximum of 40 seconds. Additionally, the configuration also gives the client a maximum of 20 seconds to start sending body data. The client must send message body data at a transfer rate of 500 bytes per second and may do it for a maximum of 40 seconds.

Using mod_qos

The mod_qos module is a quality of service extension for the Apache HTTP Server. It implements control mechanisms that can assign different priorities to different HTTP requests. The following is an example of how to configure mod_qos to mitigate slow HTTP DoS attacks:

<IfModule mod_qos.c>
  # handle connections from up to 100000 different IPs
  QS_ClientEntries 100000
  # allow only 50 connections per IP
  QS_SrvMaxConnPerIP 50
  # limit the maximum number of active TCP connections to 256
  MaxClients 256
  # disables keep-alive when 180 (70%) TCP connections are occupied
  QS_SrvMaxConnClose 180
  # minimum request/response speed 
  # (deny clients that keep connections open without requesting anything)
  QS_SrvMinDataRate 150 1200
</IfModule>


The above configuration settings track up to 100,000 connections and limit requests to a maximum of 256 connections. In addition, the configuration limits each IP address to a maximum of 50 connections and disables HTTP KeepAlive when 180 connections are used (70 percent of the connections in this case). Finally, the configuration requires a minimum of 150 bytes per second per connection and limits the connection to 1200 bytes per second when MaxClients is reached.

Using mod_security

The mod_security module is an open-source web application firewall (WAF) that may be used with the Apache HTTP server. It uses rules that can be applied to carry out specific functions. You may use the following rules to mitigate a slow HTTP DoS attack:

SecRule RESPONSE_STATUS "@streq 408" "phase:5,t:none,nolog,pass, 
  setvar:ip.slow_dos_counter=+1, expirevar:ip.slow_dos_counter=60, id:'1234123456'"

SecRule IP:SLOW_DOS_COUNTER "@gt 5" "phase:1,t:none,log,drop, 
  msg:'Client Connection Dropped due to high number of slow DoS alerts', id:'1234123457'"


The above rules identify when the Apache HTTP server triggers a 408 status code and track how many times this happened. The module keeps the data in IP-based persistent storage so it can be correlated across requests. If this event has happened more than 5 times in 60 seconds, subsequent requests from that IP address will be dropped for a given period of time, in this case: 5 minutes.

Apache HTTP Server Vulnerability Requests Connection (dance) Data (computing) Web Service

Published at DZone with permission of Ian Muscat, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Accelerating Connection Handshakes in Trusted Network Environments
  • C# Applications Vulnerability Cheatsheet
  • Go Application Vulnerability Cheatsheet
  • Easy Oracle Database Migration with SQLcl

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!