HTTP server missing ReadTimeout / ReadHeaderTimeout — vulnerable to slowloris-style connection exhaustion

[SanjinDedic]

Issue: HTTP server missing ReadTimeout / ReadHeaderTimeout — vulnerable to slowloris-style connection exhaustion

Submit at: https://github.com/basecamp/kamal-proxy/issues/new

Problem

The Go http.Server instances in internal/server/server.go are created without ReadTimeout, ReadHeaderTimeout, or IdleTimeout:

s.httpServer = &http.Server{
    Handler: handler,
}

Go's own documentation recommends setting these timeouts to prevent slow-client attacks:

ReadHeaderTimeout is the amount of time allowed to read request headers. [...] If ReadHeaderTimeout is zero, the value of ReadTimeout is used. If both are zero, there is no timeout.

Impact

Without these timeouts, any client can hold a kamal-proxy connection open indefinitely by slowly dripping request data. In production, we're seeing ~1000 requests/day from a botnet (mostly 5.116-127.x.x) that:

• POST to random hostnames (no matching service -> 404)
• Send application/octet-stream bodies very slowly
• Hold connections open for 150-770 seconds each

These requests return 404 correctly, but each one ties up a connection slot for minutes. The requests show up in kamal-proxy's access logs as slow 404s with empty service and target fields.

Example log entry:

{
  "host": "cancerckmecircle.com",
  "service": "",
  "target": "",
  "status": 404,
  "duration": 153461846083,
  "method": "POST",
  "req_content_type": "application/octet-stream",
  "client_addr": "5.127.41.175"
}

Suggested fix

Set sensible defaults on both HTTP servers in server.go:

s.httpServer = &http.Server{
    Handler:           handler,
    ReadHeaderTimeout: 10 * time.Second,
    ReadTimeout:       30 * time.Second,
    IdleTimeout:       120 * time.Second,
}

These should also be configurable through the proxy section of the Kamal deploy config, similar to how response_timeout is already exposed:

proxy:
  response_timeout: 30    # already exists
  read_timeout: 30        # proposed
  idle_timeout: 120       # proposed

Sensible defaults alone would close the vulnerability, but configurability would let users tune these for their specific use case (e.g. large file uploads may need a longer read_timeout).

This is distinct from the per-service --response-timeout (which controls how long to wait for the upstream target to respond). The issue here is at the HTTP server level — kamal-proxy reads the client's request body with no deadline, even when no service matches.

Workaround

Currently the only workaround is firewall-level IP blocking, which doesn't help against distributed sources.

Related

• #90 — default max-request-body (related but covers size, not time)
• Discussion #40 — DDoS defence (broader scope)

[kevinmcconnell]

@SanjinDedic agreed, we should add timeouts for this case.

I'd rather not enforce proxy-level timeouts on the deployed services. But I think what we could do is have default server-level timeouts, and then per-service, configurable timeouts that override them. That also means each service can vary its timeout settings between deploys without requiring a proxy restart.

I'll put together a fix for this. Thanks for bringing it up.

[SanjinDedic]

Thanks so much for the prompt response, looking forward to deploying the fix :)