Security
bipanel protects a server in layers: accounts are isolated from each other, panel logins and sessions are protected, network traffic is filtered, web files are scanned, installed packages are checked for known vulnerabilities, and updates are signature-verified and rolled back if they fail. This page summarizes each layer, points to the detailed pages and lists what remains your responsibility.
On this page
#Layers at a glance
bipanel is server management software that runs with root privileges, so it relies on several complementary layers rather than a single safeguard. Most admin screens live in Server Admin (port 2087, /admin) under the Security group.
| Layer | What it protects | Server Admin menu | Edition |
|---|---|---|---|
| Account isolation | Accounts reaching each other's files and the system | Account Isolation, Shell Isolation, File Safety | Basic isolation Community; systemd account isolation Pro |
| Panel security | Logins, sessions, admin accounts | Security Center, Password & Security | Community |
| Network and attack protection | Port access, brute force, DDoS, web attacks | Firewall, CrowdSec, DDoS Protection, Web Application Firewall, Country Blocking, Attack Detection | Mostly Community; attack detection Pro |
| Malware and integrity | Web shells, backdoors, unexpected file changes | Malware Scanner, File Integrity | Scanning Community; scheduled and real-time scanning and file integrity Pro |
| Vulnerability monitoring | Known vulnerabilities in installed packages | Vulnerabilities | Community and Pro |
| Safe updates and configuration | Panel updates, OS patches, risky settings | Updates, Security Advisor | Community |
The Community edition runs up to 3 hosting accounts; see Pricing for edition differences.
#Account isolation
Every hosting account is a separate Linux user. Its home directory is created with mode 0711, each account gets its own PHP-FPM pool, and the panel writes open_basedir into every pool, so a site's PHP code can only read files in its own home directory. Symbolic links are followed only when the target has the same owner.
- Account Isolation (Pro): the account's PHP-FPM process, Node.js and Python apps and build commands are confined with systemd namespaces. The file system appears read-only, and other accounts' home directories and panel data are hidden. Each account is switched over only after a compatibility check and is rolled back on failure.
- Shell Isolation: choose a shell mode per account (disabled, jailed, full). The jailed shell uses bubblewrap to run SSH, SFTP, git and web terminal sessions in an environment that only sees the account's home directory; compiler access can be restricted as well.
- File Safety: the File Manager blocks symlink race attacks, zip-slip and archive bombs, and logs every blocked attempt.
Details: Account isolation.
#Panel security
Session cookies are issued as HttpOnly and SameSite=Lax, plus Secure over HTTPS; the database stores only a hash of the session key. State-changing requests made with a cookie must carry a custom header (CSRF protection). Accounts can enable two-factor authentication, and Security Center can make it mandatory for administrators. The same page counts failed logins and temporarily blocks IP addresses that exceed the threshold.
Details: Panel security.
#Network and attack protection
On a server installation the firewall (UFW on Debian and Ubuntu, firewalld on AlmaLinux, Rocky Linux and RHEL) and Fail2Ban are configured by default. You can add CrowdSec, ModSecurity (OWASP CRS) on Apache servers, and nftables-based country blocking. DDoS Protection rate-limits the panel API and websites. Attack Detection (Pro) spots brute force, vulnerability scans and bot traffic in site access logs.
On Docker and Railway the network edge belongs to the platform; brute-force protection, IP blocks and rate limits still apply at panel level.
Details: Network and attack protection and Security tools.
#Malware and file integrity
The Malware Scanner uses heuristic rules to look for web shells, backdoors and signs of obfuscation in web files (PHP, JS, HTML, .htaccess, .user.ini and images). In the Community edition users scan their own home directory and admins scan individual accounts on demand. Scheduled scans of all accounts, real-time monitoring and automatic quarantine are Pro features.
File Integrity (Pro) records a baseline of site files, reports PHP, JS and .htaccess changes made outside the maintenance window, and supports directory locking and restoring from backup. On the Server Admin side it also verifies system files and packages.
Details: Malware and file integrity.
#Vulnerability monitoring
Every installation sends a regular installation report to bipanel Hub. It includes the version, channel, run mode, operating system, hostname, account and domain counts, and component and package versions; no customer data, email content, passwords, files or databases are sent. The Hub matches installed packages against known vulnerabilities (CVEs). Findings are listed on the Vulnerabilities page with severity, fixed version and exploitation data, and administrators are notified of important new ones.
The report is mandatory and cannot be turned off: there is no setting, install option or environment variable for it. It is sent a few minutes after startup and then every 2 hours by default. You can see the exact body of the next report under Server Admin → Installation Report.
Details: Vulnerability monitoring.
#Safe updates and configuration
For panel updates, the release manifest and the downloaded file are verified with an Ed25519 signature and a SHA-256 digest. On a server installation the panel database is backed up first, a health check runs after the service restarts, and the previous version is restored if the check fails. On Docker and Railway the panel is updated with a new image.
On a server installation, operating system security patches are installed automatically every day in the window you choose. The Security Advisor audits and scores SSH, PHP, TLS, mail and account settings; its one-click fixes show a preview first and can be reverted. Apache configuration changes that fail the config test are reverted.
Details: Safe updates and configuration, Updates and Automatic security updates.
#Differences by installation type
| Topic | Server installation | Docker and Railway |
|---|---|---|
| Accounts | Separate Linux users | Separate Linux users inside one container |
| Account Isolation (systemd, Pro) | Available | Not available (no systemd) |
| Firewall, Fail2Ban, CrowdSec, country blocking | Available | Network edge handled by the platform |
| OS patches | Automatic, daily window | Via a new image |
If you host customers who do not trust each other, choose a server installation. Details: Docker and Railway.
#Shared responsibility
bipanel protects the panel layer and the services it manages, but no software delivers complete security on its own. The following remain your responsibility:
- Change the initial admin password and enable two-factor authentication for every admin and reseller.
- If possible, open port 2087 only to your own IP addresses or a VPN; use keys instead of passwords for SSH.
- Get a valid certificate for the server hostname: SSL certificates.
- Keep backups off the server and test a restore: Backups and migration.
- Keep the applications, themes and plugins on your sites up to date; the panel cannot fix vulnerabilities in a site's own code.
- Volumetric attacks in the Gbps range must be stopped before they reach the server; use your provider's or a CDN's DDoS protection for that.
- Review the Vulnerabilities and Security Advisor findings regularly.
For common questions, see the FAQ.
Something missing or wrong on this page? Let us know.