Volumetric DDoS attacks are loud and obvious. Low-and-slow attacks (e.g., Slowloris, R.U.D.Y., Sockstress) are silent, aimed at exhausting server resources like thread pools or socket tables rather than bandwidth. Because these attacks respect traffic thresholds, traditional WAF rate limits often fail to detect them.

To mitigate these threats without blocking legitimate long-polling users, security engineers must correlate connection behavior with IP intelligence.

The Failure of Rate Limiting

Low-and-slow attacks operate by opening connections and keeping them alive for as long as possible with partial HTTP requests. The data transfer rate is intentionally minimal.

Since the request rate per second (RPS) per IP remains below standard blocking thresholds, the WAF sees legitimate traffic. The server eventually reaches its MaxClients or worker_connections limit, resulting in a denial of service.

Fingerprinting via IP Intelligence

While the traffic pattern mimics a slow user, the source infrastructure rarely mimics a legitimate ISP. Correlating connection duration with IP metadata provides a high-fidelity detection signal.

1. ASN and Connection Type Analysis

Legitimate users exhibiting slow network speeds typically originate from Residential (ISP) or Cellular ASNs. If a "slow" connection originates from a Datacenter ASN (e.g., AWS, DigitalOcean, Linode) or a known VPN node, the probability of malicious intent increases significantly.

2. Proxy Detection

Attackers often route low-and-slow traffic through Tor exit nodes or public proxies to mask their origin. Real-time proxy detection is critical here. If an IP is flagged as a Tor node or an open proxy, long-duration connections should be aggressively terminated.

Implementation Strategy

The following strategy outlines a detection middleware:

Track Connection Duration: Monitor open socket time.
Query IP Context: On connection init, retrieve IP metadata (ISP, Type, Proxy Status).
Apply Heuristic: If Duration > Threshold AND IP_Risk_Score > High, terminate.

Python Implementation (Flask + Redis)

This pseudo-code demonstrates how to implement a timeout logic based on IP reputation using Redis for state tracking and IPASIS for intelligence.

import time
import redis
import requests
from flask import Flask, request, abort

app = Flask(__name__)
r = redis.Redis(host='localhost', port=6379, db=0)

# Configuration
MAX_CONN_DURATION = 30  # seconds
IPASIS_API_KEY = "your_ipasis_key"

def get_ip_risk_score(ip_address):
    # Check cache first
    cached = r.get(f"risk:{ip_address}")
    if cached:
        return float(cached)

    # Query IPASIS API
    try:
        resp = requests.get(f"https://api.ipasis.com/v1/{ip_address}?key={IPASIS_API_KEY}", timeout=2)
        data = resp.json()
        
        # Scoring Logic
        score = 0
        if data.get('is_proxy') or data.get('is_vpn'):
            score += 50
        if data.get('asn', {}).get('type') == 'hosting':
            score += 30
        if data.get('threat', {}).get('level') == 'high':
            score += 20
            
        # Cache the score for 1 hour
        r.setex(f"risk:{ip_address}", 3600, score)
        return score
    except:
        return 0

@app.before_request
def check_slow_risk():
    client_ip = request.remote_addr
    
    # Track connection start time in Redis
    conn_id = f"{client_ip}:{request.environ.get('REMOTE_PORT')}"
    start_time = r.get(conn_id)
    
    if not start_time:
        r.setex(conn_id, 300, time.time())
        start_time = time.time()
    else:
        start_time = float(start_time)

    duration = time.time() - start_time
    
    # If connection persists longer than standard expectation
    if duration > 5:
        risk = get_ip_risk_score(client_ip)
        
        # Aggressive termination for hosting/proxy IPs holding sockets
        if risk > 60:
            r.delete(conn_id)
            abort(403, description="Connection Terminated: High Risk Anomaly")

@app.route('/')
def index():
    time.sleep(2) # Simulate processing
    return "Request Processed"

Advanced Pattern: Rotational Slow Attacks

Sophisticated attackers rotate IPs to reset connection timers. To combat this, aggregate statistics by ASN rather than single IPs.

If ASN AS1234 (a generic hosting provider) shows a 400% increase in active socket count compared to the historical baseline, apply a temporary blanket strict-timeout policy to that specific ASN. This isolates the attack without degrading performance for legitimate residential users.

FAQ

Q: Won't this block users with poor internet connections? A: No. Legitimate users with slow connections usually originate from Residential ISPs. By filtering based on hosting or proxy classifications, you specifically target automated traffic coming from server farms, not users on 3G networks.

Q: Can't WAFs handle this natively? A: Most WAFs rely on RPS (Requests Per Second). Slowloris sends incomplete requests, often slipping under RPS radars. WAFs require specific tuning for "Low and Slow" which often results in high false positives unless enriched with IP intelligence.

Q: How often should IP data be refreshed? A: IP usage is dynamic. Proxy rotation happens in minutes. We recommend caching IP intelligence for no longer than 15-60 minutes to balance performance with accuracy.

Secure Your Infrastructure with IPASIS

Defending against layer 7 exhaustion attacks requires more than just measuring speed; it requires understanding the identity of the connection.

IPASIS provides enterprise-grade IP intelligence, allowing you to instantly detect VPNs, proxies, and hosting centers attempting to drain your server resources. Integrate our API today to harden your application layer defense.

Get your API Key

Detecting Low-and-Slow Attacks Using IP Reputation and Traffic Patterns