Hardening Operating System
Running a validator node is a significant responsibility that directly contributes to the security and decentralization of the network. To safeguard your investment and ensure the integrity of your operations, it's crucial to implement robust security measures. Hardening your validator involves a multi-layered approach, securing everything from the underlying operating system to the node architecture setup.
Note
You can also apply the security recommendations in this guide to Full Nodes, Archive Nodes, and Light Nodes.
The security of your validator node begins with a hardened operating system. A compromised OS can expose your entire setup to attackers.
General Recommendations
| Recommendation | Requirement |
|---|---|
| Use a Minimal, Long-Term Support (LTS) OS | Start with a minimal installation of a stable and well-supported operating system, such as Ubuntu Server LTS. This reduces the attack surface by avoiding unnecessary pre-installed software. |
| Minimize OS Active Services | Disable or remove unnecessary services to reduce the attack surface. Regularly audit running services and remove or disable any that aren't required for node operations. |
| Mandatory Access Control (MAC) | Implement MAC frameworks like SELinux or AppArmor to enforce granular access controls and limit the capabilities of running applications. |
| Secure Communication | Use secure protocols such as HTTPS, SSH, or VPNs for communication. Ensure that all data in transit is encrypted to protect against eavesdropping and tampering. |
| Encryption | Encrypt sensitive data at rest and in transit to protect it from unauthorized access. Use strong encryption algorithms and manage encryption keys securely. |
| Private Key Security | Store private keys in secure locations, such as Hardware Security Modules (HSMs) or encrypted storage. Never hard-code private keys in source code or configuration files. Implement multi-signature setups to add an extra layer of security to key management. |
| Regular Backups | Implement a backup strategy that includes regular backups of critical data and configurations. Store backups in secure locations and ensure they are encrypted. Test backup restoration procedures periodically to ensure data can be recovered in case of failure. |
| Software Updates and Automated Patching | Update your system regularly or configure automated security updates to promptly address vulnerabilities. However, ensure that automated updates are tested to prevent potential disruptions. |
| Redundancy | Deploy redundant systems and infrastructure to ensure high availability and fault tolerance. Distribute nodes across different geographic regions and cloud providers to mitigate the impact of localized failures. |
User Management
Running your blockchain node software as the root user is a major security risk. If an attacker compromises
your node, they would gain complete control over your entire system. To mitigate this, create a dedicated non-root
user that will exclusively run the node software.
Create a new user; Replace validator with your desired username:
Grant sudo privileges, it is optional but recommended for maintenance. This allows the user to perform administrative tasks
when needed by prefixing commands with sudo:
Switch to the new user:
Isolate Node Data with Specific Directories
To further enforce the principle of least privilege, create dedicated directories for your execution and consensus client data. This prevents the node software from accessing or modifying other parts of your system.
Create directories for the execution and consensus clients:
Set ownership of the directories to the dedicated user. This ensures that only the validator user can write to these directories:
Enforce Strict File Permissions
Setting restrictive file permissions ensures that only the owner of the files (the validator user) can read, write, and execute them.
Set permissions for the main data directory: The 700 permission gives full access (read, write, execute) to the owner and no access to anyone else:
Verify the permissions:
The output should look like this:
SSH Hardening
Disable unwanted configurations in the /etc/ssh/sshd_config config file and apply additional security measures:
| Recommendation | Requirement |
|---|---|
| Disable root login | PermitRootLogin no |
| Disable password authentication | PasswordAuthentication no |
| Change the default SSH port to a non-standard one to reduce automated attacks | Port 2222 |
| Use strong ciphers and key exchange algorithms | Ciphers aes256-gcm@openssh.com,chacha20-poly1305@openssh.com KexAlgorithms curve25519-sha256@libssh.org MACs hmac-sha2-512,hmac-sha2-256 |
| Restrict SSH access to specific users and groups | AllowUsers admin-username blockchain-username |
| Implement Multi-Factor Authentication (MFA) for SSH access | Configure SSH to use two-factor authentication |
Restart the SSH service to apply the changes:
Firewall Configuration
First, ensure ufw is installed on your system:
Then, set up the default deny policy for incoming traffic and allow all outgoing traffic, which is a standard configuration:
Allow all outgoing traffic by default:
Next, you need to create "allow" rules for the services you need:
For enhanced security, you can change your default SSH port to a non-standard one (e.g. 2222) and create a new rule for it:
For better protection against brute-force attacks, you can use the limit command instead. This will block an IP address if it tries to connect too many times in a short period:
If you previously had a rule allowing the default SSH port (22), you should delete it. List your current rules with numbers:
Identify the rule number for port 22 in the output. Delete the old rule using its number (replace X with the correct number):
Note
You can modify the ufw configuration and rules to match your desired architecture.
Securing Your Clients
To secure your clients, ensure that the following recommendations are implemented:
| Recommendation | Requirement |
|---|---|
| Run Clients as a Non-Root User | Ensure your execution client and consensus client are run by the dedicated non-root user (e.g. validator) you created. |
| Secure the Engine API JWT Token | Ensure the JWT file has restricted read permissions so only the necessary user accounts can access it. |