> 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