> For the complete documentation index, see [llms.txt](https://bitnet-whitepaper.gitbook.io/developer-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://bitnet-whitepaper.gitbook.io/developer-docs/security-essentials/validator-security-checklist.md).

# Validator Security Checklist

### Validator Security Checklist for BitNet

Follow these recommended best practices across data center, system configuration, access control, and key management to ensure validator security and resilience.

***

#### Hosting Data Center

| **Control Category** | **Best Practice**                     |
| -------------------- | ------------------------------------- |
| Power                | Redundant, uninterrupted power supply |
| Cooling              | Redundant cooling infrastructure      |
| Networking           | Redundant uplinks and routers         |
| Physical Security    | Gated access or cage-enclosed racks   |
| Surveillance         | Remote alerting and camera monitoring |

***

#### Node System Security

| **Control Category**    | **Best Practice**                                         |
| ----------------------- | --------------------------------------------------------- |
| OS Patching             | Up-to-date kernel and OS patches (x86\_64 architecture)   |
| Auto-Updates            | Use `dnf-automatic`, `yum-cron`, or `unattended-upgrades` |
| Security Frameworks     | Enforce SELinux, AppArmor, or similar                     |
| Insecure Services       | Remove telnet, rsh, inetd, etc.                           |
| Boot Protection         | Password-protect GRUB bootloader                          |
| File Permissions        | Ensure only root can access core system files             |
| Node Directory Security | Restrict `~/.bitnetd` access to node operator only        |

***

#### BitNet Config Settings (Recommended)

* **Validator Node:**

  ```toml
  max_num_inbound_peers = 100
  max_num_outbound_peers = 10
  flush_throttle_timeout = "100ms"
  ```
* **Sentry Node:**

  ```toml
  max_num_inbound_peers = 500
  max_num_outbound_peers = 50
  flush_throttle_timeout = "300ms"
  ```

***

#### Account Security & Remote Access

| **Control Category** | **Best Practice**                                                                        |
| -------------------- | ---------------------------------------------------------------------------------------- |
| SSH Configuration    | `PermitRootLogin no`, `PasswordAuthentication no`, `UsePAM yes`, `AllowUsers` restricted |
| Password Policy      | Enforce strong passwords, disallow blanks                                                |

***

#### Networking and Firewall

| **Control Category** | **Best Practice**                                             |
| -------------------- | ------------------------------------------------------------- |
| Bandwidth            | Minimum 5 Mbps upload/download                                |
| Firewalls            | Use `iptables`, AWS Security Groups, etc.                     |
| Access Restrictions  | Expose TCP 26656 only; limit SSH (port 22) to select IPs      |
| IDS/IPS              | Enable tools like Fail2Ban, OSSEC, or Snort                   |
| RPC Endpoint         | Bind RPC to `127.0.0.1` only or secure it via ACLs            |
| Sentry Architecture  | Isolate validator node; connect only via trusted sentry nodes |

***

#### Redundancy & Monitoring

| **Control Category** | **Best Practice**                         |
| -------------------- | ----------------------------------------- |
| Hot Standby          | Maintain a backup node with synced config |
| Monitoring           | Set up alerts for downtime or anomalies   |

***

#### Key Management

| **Control Category** | **Best Practice**                                          |
| -------------------- | ---------------------------------------------------------- |
| Key Security         | Use Tendermint KMS with Ledger or YubiHSM                  |
| Static Key Avoidance | Avoid using static `priv_validator_key.json` in production |

***

#### DDoS Protection

Deploy your validator in a **sentry node architecture**:

* Place validator nodes in private networks
* Route traffic through rotating sentry IPs
* Restrict peer list to trusted nodes


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://bitnet-whitepaper.gitbook.io/developer-docs/security-essentials/validator-security-checklist.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.