server: configure ReadHeaderTimeout on HTTP servers#8848
Conversation
Configure ReadHeaderTimeout to 10 seconds on all HTTP server instances to mitigate Slowloris DDoS attacks where clients can keep connections open indefinitely by sending headers slowly. Signed-off-by: RinZ27 <222222878+RinZ27@users.noreply.github.com>
|
This is the first time I hear of this attack, released in 2009. Is this an issue you're facing in your OPA deployments? (Usually, people try not to let adversarial actors reach the OPA HTTP API directly.) |
|
@srenatus While we haven't hit this in our production setup yet, adding a default |
|
If it's common, can you please share some examples? Also, let's consider if the examples make this configurable or hardcode a duration, too. Thanks! |
|
@srenatus Sure, these are few notable examples:
Regarding configurable vs hardcode — a sensible hardcoded default (like the 10s value here) is what most projects start with. Could add a config flag down the road if users need finer control, but for now the default alone already closes the gap. If you'd prefer making it configurable from the start, I can wire that up. |
Do they? All I find is a rather factual description of what the setting is for. Do you think a 10s timeout will effectively block a Slowloris DDoS attack? How many TCP connections can your computer open in 10s? What does k8s use? If we put a hardcoded value here, it should be a good one 😅 |
|
Fair point on the docs — "explicitly recommend" was overstated on my end. The docs describe the field factually, not as a prescriptive best-practice. That said, gosec G112 does treat the absence of On the 10s question — Checked k8s: |
|
If you can share a reference to genericapiserver.go, I couldn't find it skimming the file, please? Then let's do 32s. |
Why the changes in this PR are needed?
Preventing Slowloris DDoS attacks is essential because the default Go HTTP server does not configure any read timeouts, which allows clients to keep connections open indefinitely. When auditing the server initialization, I noticed the lack of ReadHeaderTimeout, meaning an attacker could easily exhaust file descriptors by sending headers extremely slowly.
What are the changes in this PR?
Adding a 10-second ReadHeaderTimeout to all HTTP server instances (standard HTTP, HTTPS, and Unix domain socket) in server.go fixes this vulnerability. Using ReadHeaderTimeout instead of ReadTimeout ensures that large payload uploads, such as big policy bundle updates, are not interrupted while protecting the server against slow header attacks.
Notes to assist PR review:
Running the server tests locally shows everything passes successfully without breaking existing functionalities.
Further comments:
No public API or config schema changes are introduced.