Validator DDoS Protection: Sentries, Signers and Public RPC

Validator DDoS protection is a different job from protecting a website. A website that goes down loses visitors. A validator that drops off the network misses votes and gets penalised or jailed, and if you rush a second copy online, it can double-sign and lose far more. Its peer-to-peer port must stay open to the whole internet, and on some chains everyone knows when you are due to propose.

This post covers why validators and RPC nodes get attacked, what the included 100 Gbps of Layer 3/4 filtering removes, the CometBFT sentry node architecture with real config.toml keys, remote signers, Ethereum ports, and rate-limiting a public RPC. For sizing by chain, see our crypto node hosting guide.

Why validators and public RPC nodes get attacked

• Downtime has a published price. The Cosmos Hub's slashing parameters in October 2026: sign at least 5% of the last 10,000 blocks, or be jailed for 600 seconds and slashed 0.01%, then stay out of the active set until you unjail. On Ethereum, missed attestations cost about what they would have earned.
• Some chains announce who acts next. Ethereum's upcoming proposers are public, and ethereum.org notes their IP addresses can be mapped and targeted with denial-of-service attacks. A 2024 study located over 15% of Ethereum validators using four nodes for three days. Solana computes each leader schedule about an epoch ahead.
• The P2P port cannot hide. 26656 on CometBFT chains, 30303 for Ethereum execution clients, 9000 for Lighthouse: a peering node accepts strangers, and its address travels to every peer.
• A public RPC is expensive to answer. By default one HTTP request to Geth can batch 1,000 calls, and each eth_call may run for 5 seconds and 50 million gas. A flood of valid-looking requests pins CPU and disk while the link looks quiet.

Validator DDoS protection: what 100 Gbps removes and what stays yours

Every Noded VPS and dedicated server includes 100 Gbps of always-on DDoS protection at Layers 3 and 4: nothing to enable, no ticket, no agent. UDP floods, DNS and NTP amplification and SYN floods are filtered upstream, before they reach your port, while clean traffic keeps flowing, the same in every location. For a blockchain node:

Threat	Included tier	Your job
Floods and amplification at P2P or RPC ports	Filtered upstream	Nothing, up to 100 Gbps
Peers that complete a handshake, then misbehave	Not filtered: real connections	Client peer limits, bans
HTTP or JSON-RPC request floods	Layer 7 only on the 10 Tbps tier	Rate limits, keys, node caps
Double-signing, key theft	Out of scope	One signer, runbooks

The rule to plan around: above 100 Gbps, the first five attacks in a month are still mitigated, but from the sixth the attacked IP address is null-routed until the attack stops or the server is moved to a higher tier. Paid tiers are per server, per month, plus VAT where it applies, from 500 Gbps at €156.45 to 10 Tbps with Layer 7 at €4,723.95. Each covers only the server it is ordered with, so architecture beats one big tier: with three sentries in three cities, a null-routed sentry is one path out of three, not a jailed validator.

Cosmos validator sentry nodes and remote signers

The sentry node architecture is CometBFT's own answer; its validator documentation presents it as mainly for DDoS prevention. Public full nodes, the sentries, do all the peering. The validator talks only to them over a private link and has no public P2P presence.

The config.toml keys

Across cities, WireGuard is the simplest private link. Here the validator is 10.10.0.1 on the tunnel and the sentries 10.10.0.2 to 10.10.0.4:

# validator: config.toml
[p2p]
laddr = "tcp://10.10.0.1:26656"
pex = false
persistent_peers = "[email protected]:26656,[email protected]:26656,[email protected]:26656"
unconditional_peer_ids = "S1_ID,S2_ID,S3_ID"
private_peer_ids = ""
addr_book_strict = false

[consensus]
double_sign_check_height = 10

# each sentry: config.toml
[p2p]
laddr = "tcp://0.0.0.0:26656"
pex = true
persistent_peers = "[email protected]:26656"
private_peer_ids = "VALIDATOR_ID"
unconditional_peer_ids = "VALIDATOR_ID"
addr_book_strict = false

• pex = false: the validator dials only its sentries and never shares addresses.
• private_peer_ids on every sentry keeps the validator's ID out of gossip. Forget it on one sentry and it leaks.
• addr_book_strict = false lets the non-routable 10.x tunnel addresses in.
• unconditional_peer_ids keeps the validator connected when a sentry's 40 default inbound slots are full.
• double_sign_check_height = 10 (default 0) makes a restarting node panic if its key signed any of the last 10 blocks.

Keeping the validator's IP out of address books

Config cannot hide an address already known. If the validator ever ran as a public node, assume its IP sits in other nodes' addrbook.json and move it to a fresh server. Let only WireGuard from the sentries and SSH from you through its firewall. Keep RPC (26657), API (1317) and gRPC (9090) on localhost, as the defaults do. Prometheus metrics, when enabled, listen on :26660 on every interface; bind them to the tunnel. Sentries need no history: pruning = "everything" in app.toml keeps two states, and state sync brings a replacement up without replaying the chain.

Remote signers: one signer, ever

CometBFT's docs advise against leaving the consensus key in priv_validator_key.json. With priv_validator_laddr set, bound to the private interface, the node sends every vote to a signer:

• tmkms holds the key in an HSM such as a YubiHSM 2. Its README warns there is no double-signing defence when several instances run at once.
• Cosmos-KMS, first released in July 2026, supports PKCS#11 HSMs and AWS KMS and dials out to the node. Its docs recommend "never to run two signers for the same key"; for a backup, one signer connects to two nodes.
• Horcrux offers threshold signing, but its repository is archived; the last release was in March 2025.

The trap is naive failover: the same key on a hot spare that starts when the primary looks dead. The day a flood makes the primary look dead while it is still signing, you double-sign. On the Cosmos Hub that means a 5% slash and a permanent tombstone, against 0.01% for downtime. Keep redundancy in the nodes and one signer; to move it, stop the old one, confirm it is dead and wait several blocks.

Where to put the sentries

Spread them across Bucharest, Sofia, Warsaw, Amsterdam and Ashburn, so one null-routed address never takes the validator offline:

Role	Shape	Bucharest	Warsaw / Amsterdam	Sofia / Ashburn
Pruned sentry, smaller chain	VPS III: 8 GB, 2 vCPU, 60 GB	€10	€14	€16
Sentry with more state	VPS IV: 16 GB, 4 vCPU, 80 GB	€16	€24	€26
Monitoring, outside the nodes	VPS I: 2 GB, 1 vCPU, 20 GB	€4	€5	€5.50

Prices are monthly. Extra disk is €4 per 50 GB, up to three increments, so check your chain's pruned size first. All Noded locations sit behind AS60982 with one upstream carrier, so for network diversity keep one sentry elsewhere too.

Ethereum validator DDoS: ports, Engine API and one validator client

Ethereum has no sentry setting: the beacon node peers in public, and Lighthouse advertises its public IP once peers can reach it. What you expose is the defence. Client defaults:

Port	What it is	Public?
30303 TCP and UDP	Execution P2P and discovery (Geth)	Yes
9000 TCP and UDP, 9001 UDP	Lighthouse P2P; 9001 is QUIC	Yes
13000 TCP and UDP, 12000 UDP	Prysm P2P and discovery	Yes, with Prysm
8545, 8546	JSON-RPC, WebSocket	No: localhost by default
8551	Engine API, JWT-authenticated	No: consensus client only
5052 (Lighthouse); 3500, 4000 (Prysm)	Beacon API, validator gRPC	Your validator client only

ethereum.org's run-a-node guide warns that opening the RPC to the internet "will let anyone on the internet control your node". Geth binds 8545 and 8551 to localhost by default, so leave --http.addr and --authrpc.addr alone.

The validator client needs no public port: it talks only to your beacon node, and that is where safe redundancy lives. Lighthouse accepts --beacon-nodes http://localhost:5052,http://10.10.0.3:5052 and fails over between them, so a second beacon node in another city covers a null-routed first one. Never load the same keys into two validator clients: the Lighthouse book warns that ends in slashing and a forced exit. --enable-doppelganger-protection stays silent for two to three epochs at start-up to spot a twin, but Lighthouse calls it imperfect.

ethereum.org's minimum for a full node is a 2 TB NVMe SSD, so execution and beacon clients belong on a dedicated EPYC server with NVMe, not a VPS.

RPC node DDoS protection: rate limits before bandwidth

A public RPC is a web service, and what hurts it is Layer 7: valid requests that each cost CPU and disk. Never serve it from a validator or sentry, and never expose the node's port. Run a separate RPC node, its RPC on 127.0.0.1, behind nginx:

limit_req_zone  $binary_remote_addr zone=rpc:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=conn:10m;
map $http_x_api_key $key_ok { default 0; "replace-with-long-key" 1; }

server {
    listen 443 ssl;
    server_name rpc.example.net;
    # ssl_certificate lines here
    client_max_body_size 256k;
    limit_req_status  429;
    limit_conn_status 429;
    location / {
        if ($key_ok = 0) { return 401; }
        limit_req  zone=rpc burst=20 nodelay;
        limit_conn conn 10;
        proxy_pass http://127.0.0.1:8545;   # 26657 for CometBFT
    }
}

Each address gets 10 requests a second, a burst of 20 and 10 connections; excess gets 429, not nginx's default 503, and keyless requests never reach the node. Then cap the node:

• Geth: enable only --http.api eth,net,web3, never admin or debug, and set --rpc.batch-request-limit well below 1,000.
• CometBFT: keep unsafe = false and size max_open_connections (900 by default), max_request_batch_size (10) and max_body_bytes (1 MB).
• Cosmos SDK: set a non-zero query-gas-limit in app.toml; at zero, queries can use unbounded gas.

A CDN rarely helps: JSON-RPC is mostly POST requests, which CDNs do not cache by default. Noded filters Layer 7 only on the 10 Tbps tier, so for one endpoint, keys and limits are the cheaper defence.

What this is not

• Not Layer 7 protection below 10 Tbps. RPC request floods are yours to rate-limit.
• Not without limits. From the sixth attack above 100 Gbps in a month, the attacked IP is null-routed until the attack stops or the server moves to a higher tier.
• Not for heavy nodes. VPS disks are SATA SSD in Europe, NVMe only in Ashburn, 270 GB at most, and the guest CPU is an older Intel generation. Full Ethereum, archive and busy RPC nodes belong on dedicated hardware.
• Not a key vault. A VPS has no USB HSM and no snapshots or backups. A signer on a VPS needs a cloud KMS backend; otherwise keep it on hardware you control.
• Unmanaged, and not financial advice. You patch clients and handle upgrades; nobody at Noded watches for jailing. Nothing here is a view on any token or staking returns.

How Noded Can Help

For a Cosmos validator, start with three VPS III sentries in Bucharest, Warsaw and Ashburn from the VPS hosting page, €40 a month together, plus a €4 VPS I for monitoring. All include 100 Gbps of always-on Layer 3/4 DDoS protection; a paid tier, from €156.45 a month for 500 Gbps, only makes sense for a server that keeps drawing attacks above 100 Gbps. Test the layout on a testnet by the hour (€5 of account credit; only destroying a VPS stops the meter). You can pay in BTC, ETH, USDC or LTC, as our crypto hosting page and crypto payment guide explain. Unsure what fits? Open a ticket.

FAQ

What is a sentry node architecture?

It puts public full nodes, the sentries, between your validator and the peer-to-peer network. The validator connects only to its sentries over a private link with peer exchange off, and each sentry lists the validator's node ID in private_peer_ids so it is never gossiped. Attackers can flood sentries, which you replace, but cannot find the validator.

Can a DDoS attack get a validator slashed?

Downtime alone brings small penalties. On the Cosmos Hub, signing under 5% of the last 10,000 blocks means 600 seconds in jail and a 0.01% slash; on Ethereum, missed attestations cost about what they would have earned. Heavy slashing comes from double-signing, usually after a failover starts a second signer.

Which ports should an Ethereum node expose?

Only the peer-to-peer ports: 30303 TCP and UDP for Geth, and 9000 TCP and UDP plus 9001 UDP for Lighthouse, or 13000 and 12000 for Prysm. Keep JSON-RPC on 8545, the Engine API on 8551 and the beacon API on localhost or a private link. The validator client needs no public port.

Is it safe to run two validators for failover?

Not with the same key. Two nodes or validator clients signing with one key will eventually double-sign: a 5% slash and a permanent tombstone on the Cosmos Hub, a forced exit on Ethereum. Run several sentries or beacon nodes behind one signer instead, and move the signer only once the old one is confirmed stopped.

Does Noded's DDoS protection cover a public RPC endpoint?

Against volumetric and protocol attacks, yes: 100 Gbps of always-on Layer 3/4 filtering is included on every VPS and dedicated server. Floods of valid HTTP or JSON-RPC requests are Layer 7, filtered only on the 10 Tbps tier at €4,723.95 a month, so a public RPC needs your own rate limits and API keys.