APIM Vulnerability Scan - Sloworis and DDOS attack

Document ID : KB000117181
Last Modified Date : 09/10/2018
Show Technical Document Details

ENV: APIM Gateway 9.2 CR09

The customer has had the 2 items below reported on a penetration test of their API Gateway, could you confirm if there are any recommended fixes?

The web application is possibly vulnerable to a "slow HTTP POST" Denial of Service (DoS) attack. This is an application-level DoS that consumes server resources by maintaining open connections for an extended period of time by slowly sending traffic to the server. If the server maintains too many connections open at once, then it may not be able to respond to new, legitimate connections. Unlike bandwidth-consumption DoS attacks, the "slow" attack does not require a large amount of traffic to be sent to the server -- only that the client is able to maintain open connections for several minutes at a time.
The attack holds server connections open by sending properly crafted HTTP POST headers that contain a Content-Length header with a large value to inform the web server how much of data to expect. After the HTTP POST headers are fully sent, the HTTP POST message body is sent at slow speeds to prolong the completion of the connection and lock up server resources. By waiting for the complete request body, the server is helping clients with slow or intermittent connections to complete requests, but is also exposing itself to abuse.

2. SSL/TLS Renegotiation Vulnerability (CVSS: 2.6)
The remote service encrypts traffic using TLS/SSL; however it allows any client to renegotiate the connection after the initial handshake. An unauthenticated remote attacker may take approach of this issue to inject an arbitrary amount of plain text into the beginning of the application protocol stream, which could facilitate Man-in-The-Middle attacks. Further information can be found on the following URL: http://www.securityfocus.com/bid/36935


ENV: 9.2 CR09


Here are my findings: 


Unfortunately, for any types of a DoS attack, there are only mitigations with pros and cons and no complete solution. 

For deployment of Gateway alone to mitigate against Slowloris is: 
1. Configure Socket Connector properties to drop/clean connections that are idle for x number of seconds 
- Under Policy Manager, configure Listen Port Advanced Properties, and create the following properties 
- connectionTimeout=3000 
- connectionLinger=-1 
Con: If legitimate connection idles more than x number of seconds (in the above example, 3 seconds), you will end up terminating the legitimate connection 
Con: If the Slowloris attacker sends the keep alive traffic every x number of seconds, that are smaller than the connectionTimeout value above, this will not mitigate the attack 

Pro: Gateway will clean up the malicious connections every x number of seconds, and other non-malicious connections will have the opportunity to establish connection. 

2. Configure the firewall settings to limit number of connections per IP address 
- For example, adding the following line to the iptables configuration file (/etc/sysconfig/iptables) manually 
-A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 100 -j REJECT --reject-with tcp-reset 
Con: You might be blocking a mega proxy 
Con: This mitigation is not applicable if the DoS attack is coming from distributed sources 

For more complete mitigation, customers can deploy a reverse-proxy entity in front of the Gateway (FYI, load balancer is a reverse proxy) that has special modules that specifically mitigates Slowloris attack. 

3. Commercial load balancer with such protection capabilities 
4. Apache Server in front of Gateway 
- Using Apache modules (for example, mod_reqtimeout, mod_qos, mod_antiloris) 
- ModSecurity in front of Gateway (web application firewall) 
Using specific Slow DoS security rules 

2) SSL/TLS Renegotiation Vulnerability - The fix for this is already been patched with almost all the JDK versions (https://www.oracle.com/technetwork/java/javase/downloads/tlsreadme2-176330.html). 
In Gateway 9.2 and above we are using JDK8 which has this fix available. 
You can set sun.security.ssl.allowUnsafeRenegotiation=false and sun.security.ssl.allowLegacyHelloMessages=false System Properties to strictly follow RFC5746 (which fixes this issue with TLS)."