Panel security

#Panel addresses and TLS

On a native server installation the panel runs on two TLS ports; the plain HTTP ports only redirect to HTTPS.

Until the hostname has a Let's Encrypt certificate, the panel uses a self-signed one. When you issue the hostname certificate under Server Admin → SSL & AutoSSL, it is loaded into the listeners without restarting the panel. Don't make a habit of clicking through browser warnings; see SSL certificates.

On Docker and Railway the panel listens only on 127.0.0.1 inside the container, behind the container's web server; TLS terminates at the outer layer (Railway's edge or the reverse proxy in the Docker setup). See Docker and Railway.

#Sign-in and passwords

• Passwords are 8–128 characters and cannot contain spaces, quotes or backslashes. Only hashes are stored.
• For an unknown username the panel answers with the same error and the same timing, so the sign-in form does not reveal which accounts exist.
• Suspended accounts cannot sign in, and their API tokens stop working.
• Server Admin → Password Policy lets you set a maximum password age; a user whose password has expired must change it at the next sign-in.
• Change the initial administrator password right after installation under Server Admin → Password & Security.

#Two-factor authentication

Every user turns on TOTP two-factor authentication on their own Password & Security page, in Server Admin or in the user panel. Scan the QR code with an authenticator app and confirm with a 6-digit code. The name shown in the app is the hosting provider's brand (a reseller's customer sees the reseller's name). Turning 2FA off requires the account password. Wrong 2FA codes count as failed sign-ins and feed the brute-force counter.

No backup recovery codes are generated. If someone loses their phone:

• the server administrator can reset another administrator's 2FA from the administrator accounts screen, and an account owner can reset a team member's 2FA on the Team page;
• as root on the server, the command below resets the password and turns 2FA off. It works while the panel is down, signs out the user's open sessions and lifts all IP blocks.

$ sudo bipanel admin reset-password admin --disable-2fa

#Mandatory 2FA for administrators

When "Require two-factor authentication for administrators and resellers" is on under Server Admin → Security Center, administrators and resellers without 2FA cannot use Server Admin; they can only open the Password & Security page to set it up. The Pro time-limited vendor support access is exempt, because that account signs in through a one-time link for a short period.

#Sessions

• The session cookie is HttpOnly and SameSite=Lax, and Secure over HTTPS. The server stores only a hash of the session ID.
• A session expires after 12 hours of inactivity and is extended while in use.
• Changing a password signs out all other sessions of that user.
• The Active sessions list on the Password & Security page shows IP address, browser and last activity, and lets you sign sessions out one by one.

#Brute-force protection and IP blocks

Failed sign-ins are counted per IP and per username. When a threshold is crossed, the IP address is blocked for a while and cannot reach the panel API. The settings are under Server Admin → Security Center.

On the same screen you can block an IP address or CIDR range by hand, lift blocks and see the addresses with the most failed attempts over the last 7 days. You cannot block your own IP address. Fixed IP addresses you list under Trusted IP addresses are never blocked by the brute-force counter. On top of this, the panel API has a per-IP request rate limit; see Network and attack protection.

#Request protection (CSRF and headers)

Every state-changing request made with the session cookie (anything other than GET, HEAD and OPTIONS) must carry a custom header that the panel interface adds; a form or request triggered from another site cannot add it and is rejected. Panel responses also carry a strict Content-Security-Policy, X-Frame-Options: DENY and X-Content-Type-Options: nosniff, so the panel cannot be embedded in another site's frame.

#Re-authentication for dangerous operations

Some server operations ask for the panel password again, plus the verification code when 2FA is on, even inside an active session:

• changing the server's root password and rebooting the server
• changing the MySQL/MariaDB admin or root password
• applying an operation in the Disk Manager (you also type a confirmation text)
• Pro: MySQL version upgrade, remote desktop settings and sessions, exporting the backup encryption key, the OpenLiteSpeed console password

If an administrator fails verification 5 times within 15 minutes, these operations are locked for 15 minutes; every failed attempt is written to the activity log.

#Activity log

Sign-ins, failed sign-ins, 2FA and password changes, signing in to an account as its owner, token creation and deletion, and administrative actions are recorded with username, target and IP address. When someone acts inside another account, the administrator or reseller who signed in is recorded as the actor. Server Admin → Activity Log filters by user, action type, date range and free text. Resellers see only their own actions and records that belong to their accounts. Entries are kept for 180 days, login attempts for 30 days.

#API tokens

Tokens are created on the API Tokens page in both the user panel and Server Admin. A token is shown only once, when it is created; the server keeps a hash. You can optionally give it a lifetime of 1 to 3650 days.

Tokens have no separate permission scopes: a token acts with all the rights of the user who owns it. Use expiring tokens for automation and delete the ones you no longer need; when a job needs fewer rights, create the token on an account that has only those rights. Packages can turn the API token feature off, and team members and staff who sign in to an account for support cannot create tokens. The command-line tool's root token only works for local connections from the server itself. More in API and CLI.

#Team and administrator roles

• Team (user panel): the account owner invites members with the Administrator, Developer, Email manager, Viewer or Custom role. Members sign in as member@account with their own password and, optionally, their own 2FA; they cannot manage the team, API tokens or the account password. Community allows up to 3 members per account; Pro has no limit.
• Administrator Roles (Server Admin): extra administrators can get the Auditor (read-only), Support (signing in to accounts and support tickets) or Operator (services, updates, components) role. Limited roles cannot read sensitive endpoints such as backup downloads, passwords and credentials.
• Account access consent: while this setting is on, resellers and limited administrators can enter an account only with a time-limited grant the owner gives on their Support Access page.
• Pro: time-limited administrator access for vendor support, up to 7 days, opened through a one-time link; the temporary account is removed automatically when it expires.

For resellers and teams in depth, see Resellers, teams and branding.

#External authentication

OpenID Connect providers are added under Server Admin → External Authentication; users link their identities under Password & Security → Linked accounts. The generic OpenID Connect provider is included in Community; the Google, Microsoft Entra ID, GitHub, GitLab and Keycloak presets are Pro.

By default, a user with 2FA on in the panel still enters the code after an external sign-in. If a provider is set to "Trust the provider's multi-factor authentication" and reports that multi-factor authentication took place, the code is skipped; you can separately choose to always ask Server Admin users for the code.

#Requiring SSO (Pro)

With Pro you can require SSO for administrator and reseller sign-ins; a correct password then no longer opens a session. You must pick an emergency administrator before turning the requirement on. If the panel becomes unreachable, use these commands on the server:

$ sudo bipanel admin sso-link
$ sudo bipanel admin sso-disable

The first creates a one-time emergency sign-in link, the second turns the requirement off.

#Post-installation checklist

1. Change the initial administrator password and turn on 2FA.
2. In the Security Center, require 2FA for administrators and add your fixed IP addresses to the trusted list.
3. Get a Let's Encrypt certificate for the hostname.
4. If you can, open port 2087 in the firewall only to office or VPN addresses.
5. Delete unused API tokens and review the activity log regularly.

For the overall security approach, see Security.