> For the complete documentation index, see [llms.txt](https://docs.soniclabs.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.soniclabs.com/sonic/node-deployment/node-hardening.md).

# Node Hardening

Protect Sonic RPC nodes and validators, step by step, from essentials to access control.

{% hint style="info" %}
**Audience:** anyone running a Sonic node: RPC nodes (public endpoints, private endpoints for internal apps, indexers, explorers) and validators.

**Assumed knowledge:** you can SSH into a Linux server, run commands with `sudo`, and edit a file with `nano` or `vim`. Every other step is explained.

**Last updated:** October 2026
{% endhint %}

This guide assumes the node is already installed and in sync, as described in [Archive Node](/sonic/node-deployment/archive-node.md) or [Validator Node](/sonic/node-deployment/validator-node.md).

## Why this guide exists

A Sonic node is a large, complex program that processes data from outside: RPC requests from users and apps, and messages from other nodes on the peer-to-peer network. Like any such program, it will have bugs that nobody knows about yet, and some of them may be exploitable. Real-world attacks on other networking systems show two things:

* **A single bug in the node can be enough** for an attacker to run their own commands on the server.
* **"Private" systems are not safe by default.** Attackers often arrive from inside the network: through a compromised machine, a shared VPN, or an internal app that passes user input along to the system.

You can't patch a bug before it's known. What you can do is make sure that **even if an attacker finds a way into the node, they can't do much with it**:

* they can't reach the dangerous parts of the node in the first place,
* it's very hard for them to start other programs (a shell, a downloader),
* they can't use the node as a stepping stone into your private network,
* there's nothing valuable on the machine for them to steal, apart from what the node itself needs,
* and if they try, you find out quickly.

**Validators have the most to lose.** A validator runs no RPC, so the peer-to-peer port is its main way in from outside. But its server holds the validator's signing key, which the node needs to sign. An attacker who gets the key can sign in the validator's name, and two nodes signing with the same key is double-signing: the validator is removed from the network and its stake is slashed (see [Node Recovery](/sonic/node-deployment/node-recovery.md)).

## How to use this guide

The guide is split into **tiers**, from easiest to most involved. Each tier builds on the previous one. You can stop after any tier and still have a meaningful improvement, but **don't skip a tier that your situation requires** (see the table below).

| Tier                                                                                                      | What it does                                                                               | Effort                        | Needs a node restart |
| --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | ----------------------------- | -------------------- |
| [**1. Essentials**](/sonic/node-deployment/node-hardening/tier-1-essentials.md)                           | Close what shouldn't be open                                                               | 1–2 hours                     | Yes                  |
| [**2. Lock the node in a box**](/sonic/node-deployment/node-hardening/tier-2-lock-the-node-in-a-box.md)   | A compromised node can't reach your private network, and can't easily start other programs | 1–2 hours + a day of watching | Yes                  |
| [**3. Get alerted**](/sonic/node-deployment/node-hardening/tier-3-get-alerted.md)                         | You find out when someone tries                                                            | \~1 hour                      | No                   |
| [**4. Control who can talk to the node**](/sonic/node-deployment/node-hardening/tier-4-control-access.md) | Only known clients, only allowed methods                                                   | 1–3 days                      | Depends              |
| [**5. Stay current**](/sonic/node-deployment/node-hardening/tier-5-stay-current.md)                       | Hardened releases, patching, containers                                                    | Ongoing                       | Yes, on upgrade      |

### Which tiers do I need?

| Your setup                                                       | Must Do    | Strongly Recommended |
| ---------------------------------------------------------------- | ---------- | -------------------- |
| Public RPC, **no** `debug`/`trace` methods                       | 1, 2       | 3                    |
| Private RPC used only by your own apps, **no** `debug`/`trace`   | 1, 2       | 3, 4                 |
| Any node with `debug` or `trace` enabled (public **or** private) | 1, 2, 3, 4 | 5                    |
| [Validator](/sonic/node-deployment/validator-node.md) (no RPC)   | 1, 2, 3    | 4.3, 5               |

{% hint style="info" %}
**Public RPC nodes:** a few steps work differently when the whole internet is supposed to reach your RPC. Look for the **Public RPC** notes in [Tier 1](/sonic/node-deployment/node-hardening/tier-1-essentials.md) (1.3, 1.4, 1.5) and [Tier 2](/sonic/node-deployment/node-hardening/tier-2-lock-the-node-in-a-box.md) (2B).
{% endhint %}

{% hint style="info" %}
**Validators:** never enable RPC on a validator. Look for the **Validators** notes throughout the guide, and the validator checklist in [Appendix F](/sonic/node-deployment/node-hardening/appendix-f-checklist.md).
{% endhint %}

{% hint style="info" %}
**Tip:** Try every change on a secondary or staging node first. If you only have one node, schedule a maintenance window and keep the rollback steps (included in each section) at hand. 

**Validators:** test on a node that isn't validating, never on a second node with the same signing key. That can lead to network rules violation and the corresponding penalties.
{% endhint %}

## Pages in this guide

* [Before You Start](/sonic/node-deployment/node-hardening/before-you-start.md): Gather the facts about your node that later steps rely on.
* [Tier 1: Essentials](/sonic/node-deployment/node-hardening/tier-1-essentials.md): Close what shouldn't be open. Everyone should do this tier.
* [Tier 2: Lock the Node in a Box](/sonic/node-deployment/node-hardening/tier-2-lock-the-node-in-a-box.md): Keep a compromised node from reaching your private network or starting other programs.
* [Tier 3: Get Alerted](/sonic/node-deployment/node-hardening/tier-3-get-alerted.md): Find out within minutes when someone tries to abuse the node.
* [Tier 4: Control Access](/sonic/node-deployment/node-hardening/tier-4-control-access.md): Only known clients, only allowed methods. Required for nodes with debug or trace.
* [Tier 5: Stay Current](/sonic/node-deployment/node-hardening/tier-5-stay-current.md): Hardened releases, OS patching and containers.
* [Appendix A: Starter Service File](/sonic/node-deployment/node-hardening/appendix-a-starter-service-file.md): A systemd service that runs the node as a non-root user.
* [Appendix B: Hardening File](/sonic/node-deployment/node-hardening/appendix-b-hardening-file.md): The complete Tier 2 drop-in file, for configuration management.
* [Appendix C: Slack Alert Script](/sonic/node-deployment/node-hardening/appendix-c-slack-alert-script.md): Post Tier 3 security events to a Slack channel.
* [Appendix D: Filtering Proxy (nginx)](/sonic/node-deployment/node-hardening/appendix-d-filtering-proxy-nginx.md): An nginx example that meets the Tier 4 proxy requirements.
* [Appendix E: Glossary](/sonic/node-deployment/node-hardening/appendix-e-glossary.md): Plain-language definitions of the terms used in this guide.
* [Appendix F: Checklist](/sonic/node-deployment/node-hardening/appendix-f-checklist.md): All tiers on one page.