Security tools

#Tools at a glance

Most admin tools live in Server Admin (port 2087, /admin) under the Security group. Some have a counterpart for hosting accounts in the User panel (port 2083).

The Community edition runs up to 3 hosting accounts; see Pricing for the edition differences.

#Firewall

The Firewall page manages UFW on Debian and Ubuntu and firewalld on AlmaLinux, Rocky Linux and RHEL. The installer configures the firewall by default; pass --without-firewall at install time if you do not want that.

• Add and delete rules: allow or deny, port, protocol, optional source address and a comment.
• Before the firewall is turned on, the SSH, panel (2083, 2087) and web (80, 443) ports are allowed. Make sure rules exist for FTP, email and DNS.
• SSH settings: port, root login and password authentication. When you change the SSH port, the new port is allowed in the firewall first, and the only rule that allows SSH cannot be deleted.
• Fail2Ban bans are listed and can be lifted one by one. On the RHEL family, the SELinux section is on this page too.

On Docker and Railway installations the network edge is managed by the platform, so you control port access in the platform's network settings. At panel level only brute-force protection and IP blocks apply.

#Brute-force protection

#Panel logins

The Security Center counts failed panel logins and temporarily blocks an IP address that crosses the threshold. Defaults:

The same page has an allowlist of IPs that are never blocked, manual IP or CIDR blocks, the login attempt history, and an option to require two-factor authentication for administrators. You cannot block your own IP address.

#Fail2Ban

Fail2Ban is installed by default on new server installations. It bans an IP address for 1 hour after 5 failed SSH, mail (Postfix, Dovecot) or FTP logins within 10 minutes; jails are enabled for the services that are installed.

#CrowdSec

The CrowdSec page installs the optional CrowdSec agent and nftables bouncer. It reads domain logs, SSH, Postfix/Dovecot, Pure-FTPd and panel logins, and shows active decisions, alerts, the allowlist and hub collections. It can run alongside Fail2Ban or take over on its own. If CrowdSec has taken over and then stops working, the panel turns Fail2Ban back on and notifies you. It is not available on container installations.

#ModSecurity

The Web Application Firewall page manages ModSecurity with the OWASP Core Rule Set: engine mode (Off, DetectionOnly, On), CRS version, paranoia level, anomaly thresholds, exclusions for WordPress, Drupal, Nextcloud and phpMyAdmin, and the audit log. Any change that fails the Apache configuration test is rolled back. Users pick the mode for their own domains on the ModSecurity page and add an exclusion for a false positive in one click. Custom rule sets are a Pro feature.

ModSecurity runs as an Apache module, so it is only available on server installations with Apache, and it is not installed by default (use --with-modsecurity at install time).

#Country blocking

Country Blocking in Server Admin drops traffic from the selected countries on the selected services using nftables. Administrator IPs, the server itself, private networks and the allowlist always get through, and if you do not confirm a change the rules are rolled back. The country database is refreshed monthly. This works on server installations only. Per-domain rules on the User panel's Country Blocking page (block, allow only, custom 403 page) are a Pro feature.

#DDoS protection and attack detection

DDoS Protection has three levels: Off, Normal and Under attack. Depending on the level it applies a panel API rate limit, a per-IP request threshold for websites, timeouts for slow requests and, on server installations, network-layer limits.

Attack Detection (Pro) compares site access logs against a baseline learned per domain, and detects CMS login brute force, vulnerability scanning, credential stuffing, form spam bots and sudden traffic spikes. Depending on the response policy, IPs are blocked temporarily. Users see detections for their own domains in read-only form.

#Security headers

On the Security Headers page users set HSTS (with a pre-flight check), Content Security Policy (CSP), X-Frame-Options, Referrer-Policy, Permissions-Policy and other headers per domain; the active headers are checked over HTTPS. On the admin Security Headers page you set the default for new domains and can apply it in bulk to existing domains that have no settings; HSTS is never applied in bulk.

#Security Advisor

The Security Advisor audits the server across SSH, panel, network and firewall, updates, kernel, PHP, MySQL, TLS, mail, web and accounts, and gives a severity-weighted score. Audits can be scheduled weekly, with a notification when new critical findings appear. You can accept a finding with a note.

Safe cases come with one-click fixes: you see a preview before applying, and every fix stores a revert plan. On container installations, server-specific checks are marked as not applicable. If an SSH fix locks you out of the panel, list the applied fixes from the server console and revert the last one:

$ bipanel advisor fixes
$ bipanel advisor revert --last

#Detailed pages

• Security: the overall security model.
• Network and attack protection: firewall, DDoS and attack detection in detail.
• Panel security: protecting panel logins and administrator accounts.
• Malware and file integrity.
• Vulnerability monitoring.