Caddy: Timeout, max body size, etc ...

[rande]

Hello,

I cannot find any information about how to configure timeout, or max body size for an http request. These settings are quite important to avoid a DOS attack.

[abiosoft]

Good point raised. I will have a look and see how best to implement them.

Thanks.

[mholt]

This discussion on HN has some great comments and resources related to rate limiting. It's not an easy problem, but it's obvious that people are still looking for a great solution. I agree Caddy would do well to have both rate limiting, timeout, and body size limiting sooner rather than later.

[Immortalin]

@mholt relevant link on hardening caddy.

[mholt]

There are a few different things to consider:

• Timeout (what kind of timeouts?)
• Max body size of requests
• Rate limiting

How should these be implemented? What would the defaults be? How should it be configurable?

[Nixtren]

The following text applies to rate limiting when Caddy is running in "server mode" (as opposed to a reverse proxy):

There could be an option in Caddyfile to specify the maximum amount of requests an IP address could do per second (or even per minute). The default of 2 requests per second via FastCGI seems to be enough for most websites. 50 requests per second for static files (JS, CSS, etc) should be enough.

[netixen]

And when running as a reverse proxy a token bucket like github.com/juju/ratelimit would be very useful.

[Nixtren]

Is there any progress on this matter?

[mholt]

No, need moar contributors. :smile: This could be related or tied into #312 as well...

[captncraig]

Rate limiting can be tricky. One simple method is to have a directive that limits a path to a simple number per window:
rateLimit /foo 500 1h
Would limit all requests to the foo path to 500 requests per hour. Can be implemented by storing a simple counter and reset timestamp per ip address. The counts and reset times per ip could be kept in memory, or in an external store (redis is often used for this when multiple servers are involved)

There are advanced use cases that could make it more complex:

• rate limit based on a particular header or cookie value instead of ip.
• apply increasing limits based on response codes (make them wait longer each time they fail to login).
• global rate limiting based on total failed logins. Or global rate limits for unauthenticated users.

The simple case is fairly easy to implement. More advanced cases require more advanced configuration. I may take a stab at simple limit directive.

[captncraig]

How about:

limit /foo 50 1s
limit / {
  requests 500
  window 10m
  requestSize 1M
}

Request body limiting is pretty strightforward to do with http.MaxBytesReader but max header size is handled at a layer above in the http package, and would not be possible to do in a directive I think.

[mholt]

Max body size has something actionable in #1027 and the rate limit plugin was added at #922. I think that's enough to close this issue then.