Security

Backups are a prime ransomware target — treat the backup system as critical infrastructure.

Checklist

• TLS everywhere between Director, Storage Daemon, File Daemon and Console; enable TLS Authenticate for mutual auth.
• Encrypt at rest with AES-256-GCM and guard the PKI private keys (back them up separately). See Encryption & TLS.
• Immutability / WORM so a compromised admin can’t delete backups before retention. See Immutability & WORM.
• Active ransomware detection to catch and stop attacks in real time. See Ransomware detection.
• Least privilege — scope Console access with Console ACLs (see the Console reference).
• Separate credentials per daemon; rotate passwords; restrict network access to ports 9101–9103.
• Multi-factor authentication on the Web Console — see Multi-factor authentication below.

Transport security: TLS-PSK by default

NGBackup daemons (backup-dir, backup-sd, backup-fd) and backup-console ship with TLS-PSK enabled by default. Sessions upgrade to an encrypted channel keyed off the existing daemon/console password — no certificates to generate, distribute or renew. The console announces PSK support in its hello, the Director answers with a STARTTLS-style upgrade, and authentication then runs inside the tunnel.

• TlsPskEnable (Console/Director blocks in backup-console.conf) controls it on the console side and defaults to yes — a fresh console with no TLS directives at all already connects encrypted.
• Certificate TLS remains the opt-in path for mutual authentication (TLS Authenticate, CA-signed identities). Both coexist on the same port: the listener inspects the first bytes and routes a TLS ClientHello to the certificate acceptor, everything else to the plaintext/PSK path.
• Mutating console commands require a secure session. .reconfigure, config set, .enroll-token, .restart and the other write verbs are refused over a plaintext console — fail-closed; read/browse verbs keep working. See Remote management and Client enrollment.
• Non-standard binaries warn loudly. Official NGBackup packages always include TLS-PSK support. If a daemon ever logs the startup warning TLS-PSK support not compiled in … sessions will fall back to PLAINTEXT, the binary is not a standard distribution build — sessions degrade to plaintext (where the mutating verbs above are refused). Replace it with an official package.

Rollout ordering

Deploy a PSK Director before PSK consoles. A PSK console sends its upgrade token and waits for the Director’s starttls; against a pre-PSK Director it fails. The reverse is fine — a non-PSK console against a PSK Director simply proceeds in plaintext.

Multi-factor authentication (TOTP)

The Web Console supports multi-factor authentication using time-based one-time passwords (TOTP, RFC 6238) — compatible with Google Authenticator, Microsoft Authenticator, FreeOTP, Aegis and any standard authenticator app.

1. Each user enrolls a TOTP secret from their profile page (QR code or manual key).
2. After a successful password login (passwords are stored as argon2id hashes), the session is held in a pending-MFA state — no API access is granted yet.
3. The user submits the 6-digit code (30-second step); only then is the session promoted to fully authenticated. There is no bypass path.

Deployment guidance:

• Enroll MFA for every console user, administrators first. Where a security baseline demands universal enforcement, make enrollment part of the user-provisioning procedure and audit the user list periodically.
• API tokens for automation are separate credentials, scoped and revocable independently of interactive users.