Learn OpenClaw - DDoS Protection & Rate Limiting

#Introduction

In episode 12 you closed the inner perimeter: service mesh integration, cross-mesh policies, and control of ingress and egress. Now imagine that door being stormed by thousands of requests per second from thousands of different IPs. Without defense, your service goes down within minutes — and it's no longer a question of "if", but "when".

Episode 13 is defense material: rate limiting policies and traffic shaping, blocking suspicious and abusive traffic, and threshold monitoring and alerting so attacks are detected before the system collapses.

#Why Cloud Native Environments Are Vulnerable to DDoS

DDoS (Distributed Denial of Service) floods a service with more traffic than it can handle. In cloud native environments the threat has two layers. First, volume attacks at layers 3/4 — SYN floods, UDP floods — drain proxy CPU and bandwidth. Second, and more insidious, application layer attacks at layer 7: HTTP floods disguised as normal requests, forcing the app to execute database queries or process large request bodies repeatedly.

What makes cloud native environments vulnerable is misguided autoscaling. When traffic floods in, the HorizontalPodAutoscaler adds replicas — and the bill balloons even though those requests never intended to buy anything. Rate limiting exists to stop this at the gate, not let an attack control your costs.

#Rate Limiting Policy and Traffic Shaping

Rate limiting in OpenClaw works at the data plane, before requests reach the application. There are two classic strategies: token bucket, which allows short bursts up to a certain limit, and fixed window, which counts requests per fixed time span. OpenClaw uses both depending on need, and they're expressed as ordinary policies:

apiVersion: openclaw.io/v1
kind: RateLimitPolicy
metadata:
  name: api-per-client
  namespace: openclaw-system
spec:
  scope: ingress
  target:
    serviceLabels:
      app: api-gateway
  limit:
    requestsPerMinute: 300
    burst: 50
  keyBy:
    - clientIp
    - apiKey
  overLimitAction: reject

This policy limits requests to 300 per minute per clientIp and apiKey combination, with a burst allowance of 50 requests. Requests over the limit are immediately rejected with 429 Too Many Requests. Before applying, each policy is tested first with openclaw policy validate to make sure its structure is correct. Once it passes, apply it:

openclaw policy validate --file rate-limit.yaml
kubectl apply -f rate-limit.yaml

Traffic shaping goes a step subtler than simply rejecting. Instead of cutting connections, OpenClaw can delay, shrink bursts, or lower the priority of abusive clients. This keeps normal users comfortable while still holding back abuse:

apiVersion: openclaw.io/v1
kind: TrafficPolicy
metadata:
  name: shape-bursty-clients
  namespace: openclaw-system
spec:
  target:
    serviceLabels:
      app: web-store
  shaping:
    maxConcurrentRequests: 200
    burstDelayMs: 150
    prioritizeLabels:
      - subscription: premium
    deprioritizeLabels:
      - subscription: free

#Blocking Suspicious and Abusive Traffic

Rate limiting stops volume, but doesn't yet recognize who the enemy is. OpenClaw has a detection layer: IPs that violate thresholds multiple times go onto a poor-reputation list, then are blocked automatically. Block rules can combine many signals — IP, geolocation, User-Agent patterns, even requests-per-second velocity:

apiVersion: openclaw.io/v1
kind: BlockPolicy
metadata:
  name: auto-block-abusers
  namespace: openclaw-system
spec:
  detection:
    ipReputation: enabled
    geoblock:
      mode: allowlist
      regions: [ID, SG, US]
    userAgentRules:
      - pattern: "^curl/"
        action: block
    anomaly:
      requestsPerSecondThreshold: 50
  response:
    blockDuration: 15m
    httpStatus: 403

During the block duration, all requests from that IP are rejected with 403 without being sent to the application — cheap, fast, and doesn't consume resources. The signals that triggered the block are also recorded, so when you check why a certain IP was blocked, the answer is accountable:

openclaw blocklist list
openclaw blocklist describe 203.0.113.42

Beware of false positives: an overly aggressive geoblock can cut off legitimate users outside the region, and User-Agent-based blocks can catch legitimate bots like Google crawlers. Always start in report mode (record, don't block) for a few days before enabling the full block action.

#Monitoring Thresholds and Alerting

The best defense is one that's visible. Every rate limit and block decision produces metrics Prometheus can read: number of requests, number rejected due to rate limit, blocked IPs, and evaluation latency. From these metrics we build thresholds and alerts:

groups:
  - name: openclaw-ratelimit.rules
    rules:
      - alert: HighRejectionRate
        expr: |
          sum(rate(openclaw_requests_rejected_total[5m]))
            / sum(rate(openclaw_requests_total[5m])) > 0.2
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Rejection rate exceeds 20 percent"
      - alert: DDoSVolumeSpike
        expr: |
          sum(rate(openclaw_requests_total[1m]))
            > 10 * (sum(rate(openclaw_requests_total[5m])) + 1)
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Request volume spiked tenfold"

These two rules capture two scenarios: HighRejectionRate tells you many requests are being rejected (maybe the rate limit is wrong or you really are under attack), while DDoSVolumeSpike detects the sudden volume surge typical of an attack. Alerts are sent to Alertmanager and forwarded to Slack or PagerDuty:

openclaw metrics rate-limit --interval 5m
promtool check rules prometheus-alert.yaml

The key to effective alerting is baseline. Investigate normal volume per hour, then set alerts at multiples of that baseline — not absolute numbers set once and forgotten. Thresholds too low flood the on-call; thresholds too high let an attack pass before the alert sounds.

#Wrap-Up

Episode 13 equipped OpenClaw with a volume-defense layer: rate limiting and traffic shaping hold back floods at the gate, blocklists and anomaly detection block known offenders, and threshold monitoring plus alerting make attacks visible as early as possible. The application load stays tame even while the outside world rages.

Key takeaways:

• Distinguish layer 3/4 volume attacks from layer 7 application layer attacks; both need different handling.
• Use token bucket to allow bursts, and shaping to delay rather than disconnect abusive users.
• Enable automatic blocking based on IP reputation and anomalies, but start in report mode to minimize false positives.
• Measure rejection rate and volume spikes as the primary defense metrics, not just request counts.
• Calibrate alerts against the normal traffic baseline, not guessed numbers.

Attacks can now be held off, but how do you prove what happened during an incident? In episode 14 we enter the investigation domain: Network Observability & Forensics — packet flow visibility, audit logs, and combining metrics, traces, and logs to reconstruct an incident. See you there!