From 093b950f5b66d8084461f449bd2b575e2e4a9bd9 Mon Sep 17 00:00:00 2001 From: "mergify[bot]" <37929162+mergify[bot]@users.noreply.github.com> Date: Wed, 8 Mar 2023 07:31:52 -0500 Subject: [PATCH] docs: Emphasize docs on attack exposure for RPC in production (backport #454) (#481) * docs: Emphasize docs on attack exposure for RPC in production (#454) For some reason this topic keeps coming up and I'd like us to emphasize this part of the documentation to put this topic to rest. Operators are, and have always been, ultimately responsible for securing their RPC endpoints if they choose to make them available publicly. [Rendered](https://github.com/cometbft/cometbft/blob/thane/docs/rpc-production/docs/core/running-in-production.md#rpc) --- #### PR checklist - [ ] Tests written/updated - [ ] Changelog entry added in `.changelog` (we use [unclog](https://github.com/informalsystems/unclog) to manage our changelog) - [x] Updated relevant documentation (`docs/` or `spec/`) and code comments (cherry picked from commit 93c0eddaaa6a359b526e6e09667e814626a5845f) # Conflicts: # docs/core/running-in-production.md * Resolve conflicts Signed-off-by: Thane Thomson --------- Signed-off-by: Thane Thomson Co-authored-by: Thane Thomson --- docs/core/running-in-production.md | 38 +++++++++++++++++++++++------- 1 file changed, 30 insertions(+), 8 deletions(-) diff --git a/docs/core/running-in-production.md b/docs/core/running-in-production.md index 9998acb2d3..88ef6686c7 100644 --- a/docs/core/running-in-production.md +++ b/docs/core/running-in-production.md @@ -93,15 +93,37 @@ mechanisms. ### RPC +#### Attack Exposure and Mitigation + +**It is generally not recommended for RPC endpoints to be exposed publicly, and +especially so if the node in question is a validator**, as the CometBFT RPC does +not currently provide advanced security features. Public exposure of RPC +endpoints without appropriate protection can make the associated node vulnerable +to a variety of attacks. + +It is entirely up to operators to ensure, if nodes' RPC endpoints have to be +exposed publicly, that appropriate measures have been taken to mitigate against +attacks. Some examples of mitigation measures include, but are not limited to: + +- Never publicly exposing the RPC endpoints of validators (i.e. if the RPC + endpoints absolutely have to be exposed, ensure you do so only on full nodes + and with appropriate protection) +- Correct usage of rate-limiting, authentication and caching (e.g. as provided + by reverse proxies like [nginx](https://nginx.org/) and/or DDoS protection + services like [Cloudflare](https://www.cloudflare.com)) +- Only exposing the specific endpoints absolutely necessary for the relevant use + cases (configurable via nginx/Cloudflare/etc.) + +If no expertise is available to the operator to assist with securing nodes' RPC +endpoints, it is strongly recommended to never expose those endpoints publicly. + +**Under no condition should any of the [unsafe RPC endpoints](../rpc/#/Unsafe) +ever be exposed publicly.** + +#### Endpoints Returning Multiple Entries + Endpoints returning multiple entries are limited by default to return 30 -elements (100 max). See the [RPC Documentation](https://docs.cometbft.com/v0.34/rpc/) -for more information. - -Rate-limiting and authentication are another key aspects to help protect -against DOS attacks. Validators are supposed to use external tools like -[NGINX](https://www.nginx.com/blog/rate-limiting-nginx/) or -[traefik](https://docs.traefik.io/middlewares/ratelimit/) -to achieve the same things. +elements (100 max). See the [RPC Documentation](../rpc/) for more information. ## Debugging CometBFT