Skip to content
Joey Wang
Menu

Search

DevOps and Reliability

Defending Against DoS Attacks

How to defend against DoS and DDoS attacks with request throttling, input validation, firewall rules, load balancers, and cloud-based mitigation.

· 4 min read

security #security#nginx#networking#devops

Audio summary

Understanding DOS and DDoS Attacks

In the digital realm, a Denial of Service (DOS) attack is a malicious attempt to disrupt the normal functioning of a targeted server, service, or network by overwhelming it with traffic. When this attack is distributed from multiple sources, it’s known as a Distributed Denial of Service (DDoS) attack. These attacks aim to exhaust an application’s resources, rendering it unavailable to legitimate users.

Common Types of DOS Attacks

  1. Volume-Based Attacks: These floods the network with a high volume of traffic.

    • UDP floods
    • ICMP floods
    • Amplification attacks
  2. Protocol Attacks: These exploit vulnerabilities in network protocols.

    • SYN floods
    • Ping of Death
    • Smurf attack
  3. Application Layer Attacks: These target vulnerabilities in web applications.

    • HTTP floods
    • Slowloris
    • DNS query floods

Strategies for DOS Protection

To safeguard against these threats, a multi-layered approach is essential. Here are some effective strategies:

Application Level Defenses

Throttling Mechanisms

Throttling is a rate-limiting technique that controls the number of requests a user can make to an application within a certain period. It prevents abuse and keeps the application handling legitimate traffic without being overwhelmed.

Example: Rack Attack is a Ruby gem that can be used to throttle requests based on IP or other parameters. It’s a middleware for Rack apps that tracks and controls the number of requests an IP can make to prevent your application from being overwhelmed by too many requests.

# Rack::Attack configuration example
Rack::Attack.throttle("req/ip", limit: 5, period: 2.minutes) do |req|
  req.ip
end

Input Validation and Sanitization

Properly validating and sanitizing user inputs can prevent application-layer attacks that exploit vulnerabilities in form submissions or API endpoints.

Example: Using Rails’ built-in sanitization helpers:

<%= sanitize @user_input %>

Rack Attack

Rack Attack is a middleware that can be used to mitigate DOS attacks by limiting the number of requests from a single source. It can be configured to block or throttle traffic based on various criteria, such as IP addresses or user agents.

Example Usage:

# Allow requests from a certain IP range
Rack::Attack.blocklist('block bad ip addresses') do |request|
  ['192.168.1.1', '192.168.1.2'].include?(request.ip)
end

Network Level Defenses

Firewall Configuration

Properly configured firewalls can help filter out malicious traffic before it reaches your application servers.

Example: Using iptables to limit connection rate:

iptables -A INPUT -p tcp --dport 80 -m limit --limit 25/minute --limit-burst 100 -j ACCEPT

Intrusion Detection and Prevention Systems (IDS/IPS)

These systems can detect and block suspicious traffic patterns in real-time.

Example: Using Suricata, an open-source IDS/IPS:

# Suricata rule to detect HTTP floods
alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"Possible HTTP flood"; flow:to_server; threshold: type both, track by_src, count 100, seconds 60; classtype:attempted-dos; sid:1000001; rev:1;)

Load Balancer Strategies

Load balancers distribute incoming network traffic across multiple servers to ensure no single server bears too much demand. This distribution not only improves user experience but also acts as a first line of defense against DOS attacks.

NGINX Rate Limiting:

NGINX can be configured to limit the rate of requests to certain locations, effectively acting as a rate limiter and protecting against DOS attacks.

http {
    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s;
    server {
        location / {
            limit_req zone=mylimit burst=5;
        }
    }
}

Cloud-based Solutions

Cloudflare

Cloudflare offers a DOS protection service that uses its global network to absorb and mitigate attacks before they reach your origin server. It provides always-on traffic monitoring and adaptive real-time tuning to protect against a variety of DOS attack vectors.

Example: Configuring Cloudflare’s WAF rules:

{
  "description": "Block requests from suspicious IPs",
  "expression": "ip.src in { 192.0.2.0/24 192.0.2.1/32 }",
  "action": "block"
}

Google Cloud Armor

Google Cloud Armor is a Distributed Denial of Service (DDoS) protection service that can be integrated with Google Cloud Load Balancing. It allows you to create security policies that define how to handle incoming traffic, providing an additional layer of protection against DOS attacks.

Example: Creating a Cloud Armor security policy:

resources:
- name: dos-protection-policy
  type: compute.v1.securityPolicy
  properties:
    rules:
    - action: deny(403)
      priority: 1000
      match:
        versionedExpr: SRC_IPS_V1
        config:
          srcIpRanges:
          - 192.0.2.0/24

Advanced Considerations

Protect the most critical infrastructure components first, and run vulnerability assessments regularly. Tune detection logic to cut false positives, ideally moving past static IP or user-agent rules toward behavior-based detection that adapts to new attack patterns. Keep an incident response plan written down and tested, not just assumed.

Monitoring and Analytics

Monitoring and analytics tools matter for early detection and mitigation of DOS attacks.

Prometheus and Grafana

Use Prometheus to collect metrics and Grafana to visualize them, allowing for real-time monitoring of traffic patterns and system health.

Example: Prometheus configuration to scrape NGINX metrics:

scrape_configs:
  - job_name: 'nginx'
    static_configs:
      - targets: ['localhost:9113']

ELK Stack (Elasticsearch, Logstash, Kibana)

The ELK stack can be used to aggregate, analyze, and visualize logs from various sources, helping to identify potential attack patterns.

Example: Logstash configuration to parse NGINX access logs:

input {
  file {
    path => "/var/log/nginx/access.log"
    start_position => "beginning"
  }
}

filter {
  grok {
    match => { "message" => "%{COMBINEDAPACHELOG}" }
  }
}

output {
  elasticsearch {
    hosts => ["localhost:9200"]
    index => "nginx-access-%{+YYYY.MM.dd}"
  }
}

The principle

No single layer stops a DOS attack. Application-level throttling, network defenses, load balancer configuration, and cloud-based mitigation each catch what the others miss. Test and update these defenses regularly, because attack patterns keep changing.