Security Best Practices

Running a Flux node hosting operation means you are responsible for securing both your own infrastructure and your clients' investments. A single security lapse can result in lost collateral, compromised nodes, or reputational damage. This guide covers the essential security practices every Flux provider should implement from day one.

Private Key & Wallet Security

Your private keys and identity keys are the most critical assets in your operation. If compromised, an attacker can steal collateral, redirect rewards, or take control of your nodes. Treat key security as your absolute top priority.

• •Use hardware wallets for high-value collateral — Ledger or Trezor via Zelcore for Stratus-level holdings
• •Use SSP Wallet with 2-of-2 multisig for an extra layer of transaction security
• •Store seed phrases offline — write them on paper or use metal backup plates, never store digitally
• •Test recovery before locking collateral — verify you can restore your wallet from the seed phrase
• •Use separate wallets for operational funds vs. collateral to limit exposure
• •Enable encryption on all wallet files stored on computers

Server Security Fundamentals

Every server running a FluxNode is a potential target. Securing your servers properly is essential to maintaining uptime, protecting client nodes, and ensuring PNR eligibility.

SSH Hardening

SSH is the primary access method for your servers. Hardening SSH is the first line of defense against unauthorized access.

1. 1

   Use SSH key authentication

   Generate an ED25519 key pair: ssh-keygen -t ed25519. Copy your public key to the server and disable password authentication entirely.

2. 2

   Disable root login

   Set PermitRootLogin no in /etc/ssh/sshd_config. Create a regular user with sudo privileges instead.

3. 3

   Change the default SSH port

   Move SSH from port 22 to a non-standard port (e.g., 2222) to reduce automated brute-force attempts.

4. 4

   Limit login attempts

   Install fail2ban to automatically ban IPs after repeated failed login attempts.

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
Port 2222
AllowUsers youruser

Firewall Configuration

A properly configured firewall ensures only necessary traffic reaches your node. FluxOS requires specific ports to be open for node communication and the web UI.

# Reset and set defaults
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow SSH (use your custom port if changed)
sudo ufw allow 2222/tcp

# FluxOS required ports
sudo ufw allow 16124/tcp    # Flux daemon
sudo ufw allow 16125/tcp    # Flux daemon
sudo ufw allow 16126/tcp    # FluxOS API
sudo ufw allow 16127/tcp    # FluxOS API
sudo ufw allow 16128/tcp    # FluxOS communication
sudo ufw allow 16129/tcp    # FluxOS communication
sudo ufw allow 16132/tcp    # FluxOS UI

# Enable firewall
sudo ufw enable

System Maintenance & Updates

Keeping your systems updated is critical for security. Unpatched vulnerabilities are one of the most common attack vectors.

• •Enable automatic security updates — install unattended-upgrades on Ubuntu to auto-apply critical patches
• •Keep FluxOS updated — always run the latest version; outdated versions may fail benchmarks or lose PNR eligibility
• •Monitor CVEs — subscribe to Ubuntu security notices for your server OS version
• •Reboot regularly — kernel updates often require reboots; plan maintenance windows
• •Use ArcaneOS — the hardened OS handles security updates automatically

sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

# Verify it is enabled
cat /etc/apt/apt.conf.d/20auto-upgrades

Client Credential Management

As a provider, you may handle client Zel IDs, identity keys, and payment information. Protecting this data is both an ethical obligation and a business necessity.

• •Never store client private keys — clients should manage their own keys; you only need their Zel ID for node setup
• •Use encrypted channels for sharing any sensitive information (encrypted email, Signal, or in-portal messaging)
• •Implement access controls — limit which team members can access client data
• •Delete sensitive data when no longer needed — don't retain identity keys after node configuration
• •Document your data handling — have a clear privacy policy that clients can review

Backup Strategy

A robust backup strategy protects against data loss, server failures, and ransomware attacks.

Incident Response Plan

Despite best efforts, security incidents can occur. Having a plan ensures you react quickly and minimize damage.

1. 1

   Detect

   Monitoring alerts notify you of unusual activity — unauthorized logins, unexpected reboots, benchmark failures.

2. 2

   Contain

   Immediately isolate the affected server. Change SSH keys and passwords. Block suspicious IPs.

3. 3

   Assess

   Determine the scope: was collateral at risk? Were client nodes affected? Check wallet balances and node statuses.

4. 4

   Remediate

   Rebuild compromised servers from scratch (never trust a compromised system). Rotate all keys and credentials.

5. 5

   Communicate

   Notify affected clients promptly and transparently. Explain what happened and what you've done to fix it.

6. 6

   Learn

   Document the incident. Update your security practices to prevent recurrence.