Skip to content
This repository has been archived by the owner on Jan 13, 2025. It is now read-only.

RPC does not rate limit egress traffic #8862

Closed
leoluk opened this issue Mar 14, 2020 · 1 comment
Closed

RPC does not rate limit egress traffic #8862

leoluk opened this issue Mar 14, 2020 · 1 comment
Labels
security Pull requests that address a security vulnerability
Milestone

Comments

@leoluk
Copy link
Contributor

leoluk commented Mar 14, 2020

Problem

An attacker can repeatedly download a snapshot or genesis.tar.bz2 from a validator that has an open RPC port. The Rust web server is highly efficient at serving static files and will happily make use of all of a node's egress bandwidth.

In a high tps network, this could impact cluster performance. In any case, it would result in high egress bandwidth costs and almost zero costs for the attacker since ingress is typically free.

Proposed Solution

  • Rate limit RPC egress to a harmless amount that will not interfere with turbine.
  • Perhaps configure RPC not to serve static files by default?
  • In a production cluster, the set of --trusted-validators would probably want to serve genesis/snapshots from a bandwidth-efficient CDN.
  • Ship with QoS config.
@mvines
Copy link
Contributor

mvines commented Mar 14, 2020

cc: #5778

I see this as mostly an issue for the --trusted-validators set. Most nodes have no business enabling public RPC (given the current implementation) but a trusted validator explicitly does enable RPC for others and is thus a prime DoS target

@mvines mvines added this to the v1.2.0 milestone Mar 14, 2020
@mvines mvines modified the milestones: v1.2.0, The Future! Apr 19, 2020
@leoluk leoluk added the security Pull requests that address a security vulnerability label Sep 16, 2020
@mvines mvines closed this as completed Feb 14, 2023
This was referenced Sep 29, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
security Pull requests that address a security vulnerability
Projects
None yet
Development

No branches or pull requests

2 participants