eth-rpc-infra-checklist.md

Ethereum RPC Infra Security

Over the years, as a DevOps engineer who has deployed and maintained blockchain nodes in production, I've compiled this list of security standards that should be used as a checklist, whether you are a node operator (or developer) or building an application using blockchain for production.

This docs defines:

• what must be secured on RPC nodes

1. Network

• By default, RPC endpoints should not be accessible to the public
• RPC endpoints should be bound to a private interface (such as 127.0.0.1 or a VPC/private IP)
• Access to RPC endpoints should be restricted to an API Gateway or a reverse proxy
• Security groups and firewalls should be configured to allowlist specific IPs (avoid 0.0.0.0/0)
• internal and external RPC endpoints should be separated
• WebSocket (WS) connections should be disabled unless they are absolutely necessary

2. Authentication & Authorization

Make sure that access to RPC endpoints can be tracked.

• Secure RPC endpoints with a robust authentication mechanism (such as API keys, JWT, or mTLS).
• Implement rate limiting based on the authenticated identity rather than just the source IP.
• Define separate credentials for production, staging and testing.
• Thoroughly document and routinely test the procedures for revoking credentials.

3. RPC Method Restrictions (Critical)

• The following RPC methods should be disabled for externally accessible endpoints because these methods can expose secrets or internal state:
  • admin_*
  • debug_*
  • personal_*
  • miner_*
• Use an explicit allowlist and expose only the methods your application actually needs (e.g. eth_call, eth_getLogs)
• Define separate RPC access profiles for:
  • public users
  • internal services
  • ops / debug access

4. Rate Limiting & Abuse Protection

• Rate limits should be applied per IP and per key
• You should ensure that burst protection is enabled
• You should apply throttling to heavy RPC methods (eth_getLogs, archive queries)
• You should ensure that limits on request sizes are enforced
• WAF/bot protection should be implemented in front of RPC endpoints.

5. Infrastructure Hardening

Harden the underlying host and runtime environment to reduce the blast radius of any compromise.

• Run the node as a non root user
• Use a minimal OS or container image with only required dependencies
• You should not expose SSH to the public internet
• Enable and enforce host level firewall rules
• You should automate security updates and patching
• You should ensure that disks are encrypted at rest

6. Secrets Management

Handle secrets in a way that limits exposure and allow for fast recovery in case of compromise.

• Never store secrets in command-line flags, environment files, or container images
• Store all secrets in a secure vault or managed secrets service
• You should define and enforce a regular secret rotation policy
• Log RPC authentication keys only as hashes, never in plaintext
• Maintain and regularly test a compromise runbook (SEV-1 ready)

7. Logging, Monitoring & Alerting

• Enable RPC access logs, including method name, latency, and response status

• Monitor authentication and authorization failures

• Track rate limit violations and throttling events

• Set up alerts for:

  • sudden or abnormal traffic spikes
  • suspicious RPC method usage
  • unexpected increases in error rates

• Retain logs according to policy, using UTC timestamps

8. Client-Specific Hardening (Execution / Consensus)

• Explicitly define --http.api and avoid relying on client defaults
• Restrict --http.corsdomain and never use * in production environments
• Keep --http.vhosts tightly scoped to known hosts only
• Secure the JWT secret with strict filesystem permissions
• Expose the Engine API only to the local consensus client
• Keep P2P ports fully separated from RPC and HTTP ports

9. DDoS & High-Traffic Events

• Define and test autoscaling or failover strategies
• Enable load balancer health checks and ensure they reflect real service health
• Use read only replicas to absorb heavy or expensive queries
• Configure fallback RPC providers for emergency use

10. Incident Response Readiness

Ensure you can detect, contain, and recover from critical incidents quickly and consistently.

• Treat any RPC compromise as a SEV-1 incident
• Regularly test token and key rotation procedures
• Verify the ability to block methods or clients in under 15 minutes
• Define a dedicated incident communication channel
• Maintain a postmortem template for consistent incident reviews