Beta security — implemented, awaiting independent review
Security you can verify.
A hosting panel controls root, so we treat it like it. Below is what the panel actually implements today in v1.5.45 — shipped mechanisms, not roadmap items. What it is not: an independent review. No external review has happened yet — that testing is exactly what this beta is for, and experienced testers are invited to try to break every item below.
🔏Updates designed to be verifiable
The update channel is the highest-value target on the box. Ours is built to be checkable.
Cryptographically signed self-updates: the build host signs SHA256SUMS with an Ed25519 key whose private half never leaves development. The updater verifies against an install-time trust anchor, checks every file hash, and refuses downgrades, replays and unsigned tarballs.- Every update takes a snapshot first and rolls back automatically on failed health checks — and you can roll back to any kept release by hand.
- Update-available banners on the dashboard and Update page (persistent until installed, red for security releases) with a daily probe, so a known-vulnerable panel never sits quietly out of date.
- Daily file-integrity watch (tripwire-lite) over panel code, scripts and control configs, with notifications and one-click re-baseline. Updates and SSL/mail scripts re-baseline themselves, so legitimate changes don't cry wolf.
- Installer verifies each release against a signature from the KarnakPanel build host before anything runs, and the admin console on :7080 is closed by default (SSH tunnel, or one allowed address).
- OS-level safety: release upgrades pinned off, apt-sources integrity-watched, a dist-upgrade warning on the Update page — and release upgrades (22.04 → 24.04) are console migrations with a full backup, never a panel button.
🔑Logins that resist people, not just bots
Stolen passwords are the most common breach. The panel assumes yours will leak.
- TOTP 2FA with
enforcement for admin + reseller logins — staff get herded to setup until enabled, with a persistent nudge and a scannable QR. End users are never forced.
Breached-password check on every password set, using HaveIBeenPwned k-anonymity — known-leaked passwords are rejected without ever sending the password anywhere.- Fail2ban
panel-login jail plus a login-flood jail with port-scoped bans, brute-force throttling with attempt logging, and new-IP login alerts (first login silent, hourly dedup).
- Session manager (view + kill), fully logged login-as support sessions, role-scoped hashed API tokens with optional IP pinning — and the token API is unaffected by 2FA enforcement, so automation doesn't break.
- SSH keys-only toggle with lockout guard, keypair generator, live status, and SSH-key-first hardening that never strands you without root access.
🧱Tenants isolated by design
Shared hosting means tenants who share one server. These mechanisms aim to keep them apart — all awaiting hostile testing.
- Per-user PHP-FPM pools with
open_basedir confinement and a disable_functions shell lockdown in every pool — with an admin status page, one-click re-apply, and a weekly re-apply cron so drift gets corrected.
- Customer PHP runs in a systemd sandbox. The system is read-only to PHP except the folders sites write to; a PHP worker sees only its own account's processes; PHP gets its own
/dev/shm, no longer shared with cron jobs, apps or the host (sites on the same PHP version still share one); and setuid file creation plus low-level calls — mount, ptrace, raw I/O, kernel modules — are blocked. mail() keeps working. Applied automatically on update, with a PHP version that won't start put back without the sandbox, and fpm-sandbox.sh off to turn it off as root.
- Private /tmp per account: cron jobs and supervised apps get their own
/tmp and /var/tmp that other accounts can't see (plus a private /dev/shm), and website PHP uses the account's own temp folder instead of the shared /tmp. DNS zone edits and file-manager zip downloads no longer use the shared /tmp either.
- The panel runs as its own system user (
karnak-panel), not the web server's user, switched over automatically on update with a check before and an automatic switch-back if it fails. The panel may run only the server scripts its own code names; any other script is refused.
- The web server reads only website folders. Everything else in a home — mail, backups, logs, cron output — is readable by the account and the panel only.
pcntl fork functions blocked in pools, a 5-minute per-request CPU cutoff, and MySQL query caps on all app-installer databases — one runaway script can't eat the box.- Over-quota sites go offline in an orderly way (pool suspend + FTP lock) and self-heal when usage drops — quota enforcement that actually enforces.
- Chrooted, shell-less FTP users, per-user database grants, memory-capped + niced pools, and bcrypt storage everywhere (nothing sensitive in plaintext).
🛡️Active defences, on by default
Security that ships switched on beats security you have to discover.
- Per-domain
bot shield — default on, toggleable — plus OpenLiteSpeed per-IP request-rate caps against floods.
- Upload
webshell block with upload-time antivirus: hostile files never land on disk, and email attachments face ClamAV malware rejection.
- Fail2ban jails across SSH, web, mail, FTP and the panel itself, a UFW firewall manager with SSH guard, and daemon/cron denylists against known-abusive patterns.
- Egress canary: sampled alerting on each new (user, destination) outbound connection, so a compromised site phoning home gets noticed. Inbound traffic never alerts.
- Panel security headers on all responses, CSRF on every state-changing route (completed by internal review), and no shell interpolation — allow-listed commands with escaped arguments.
🔍Self-reviewed, and we show our work
Internal sweeps are a start, not proof. No independent review yet.
- Internal sweep in v1.4.0 across all 132 POST routes, queries, views and shell handling — no issues found by us. Independent review pending; testers are explicitly invited to prove us wrong.
- CSRF coverage completed across email/FTP/database creates by internal review; ShellCheck + PHP lint in CI; domain → vhost → SSL → backup smoke tests.
- Templates diffed against Ubuntu defaults, least-privilege scoped sudo per service, and prepared statements throughout.
✉️Mail & DNS safety specifics
The boring details that decide whether your mail arrives.
- SPF hard-fail option, DKIM wizard, deliverability scoring out of 100, per-mailbox + global SMTP rate limits — with malware rejects, rate caps and relay policy always applying even when weekend scan-skip is on.
- DNSSEC with one click, CAA/SRV/SSHFP records under strict validation, and zone validation before every reload with automatic rollback on BIND rejection.