Panel Security
The operations panel controls deployment and credentials for the whole server, and it is often itself exposed to the public internet. The panel ships multiple layers of access defense — from "can't find the entrance" to "can't get in" to "a second factor beyond the password" — each raising the attacker's cost. Every layer can be enabled independently, and each has a server-local command line recovery path for when you get locked out.
Defense Lines at a Glance
| Defense line | Blocks | Once enabled |
|---|---|---|
| Secure entrance | Internet scans and brute force | The login page and all APIs move under a random path; the bare address returns 404 |
| Domain access restriction | Direct IP access | Only the bound domain can open the panel |
| Authorized IP allowlist | Access from arbitrary sources | Only allowlisted sources get through; all others receive a fake 404 |
| Two-step verification | Password leaks | A one-time code is required after the password |
| Password complexity | Weak passwords | New passwords set or reset must be 8-30 characters with at least two character classes |
The five status cards on the "Security Overview" tab correspond to the table above one-to-one. The CAPTCHA and login lockout are two additional always-on automatic defense lines — always active, nothing to enable; see CAPTCHA and Login Lockout.
For day-to-day management of the secure entrance (view / rotate / disable) see Daily Operations - Secure Entrance; this page covers the remaining defense lines and the central configuration entry.
Panel Settings Page
All security configuration is concentrated on the "Panel Settings" page (System Tools group in the sidebar); "Security Settings" in the top-bar user menu jumps here as well. The page has three tabs:
| Tab | Contents |
|---|---|
| Security overview | A wall of status cards for the five defense lines — see at a glance which are on and which are off |
| Account security | Change password, password complexity switch, two-step verification, CAPTCHA trigger threshold |
| Access control | Secure entrance, domain restriction, authorized IP allowlist |
Domain Access Restriction
Once enabled, the panel only accepts access through the bound domain; opening it by IP directly becomes unreachable. This suits scenarios where the panel domain already sits behind a CDN / outer gateway, converging panel traffic onto the same entry as the business.
- Before enabling or rebinding, the panel probes domain reachability and shows the result on the page;
- command line:
daxpay domain show / enable / disable.
Authorized IP Allowlist
Once enabled, only allowlisted sources can reach the panel; every other request gets a fake 404 (indistinguishable from a real 404, so probes learn nothing about the panel's existence).
- Supports CIDR ranges and bare IPs, multiple entries comma-separated;
- validation uses the TCP peer address, which cannot be forged;
X-Forwarded-Forand similar headers are not trusted; - loopback and health-check endpoints are always allowed, so the panel never locks itself out;
- when enabling from the web UI, the panel verifies that your current source matches the new allowlist, preventing you from locking yourself out at the moment of saving.
Locked yourself out?
If a network change or a mistyped range leaves the panel unreachable, SSH into the server and run:
sudo daxpay ipallow disableTwo-Step Verification (TOTP)
Adds a second factor to the account: at login, a one-time code from your authenticator is required after the password.
- Binding: enable it on the Panel Settings page, then scan the QR code with Google / Microsoft Authenticator, 1Password, etc.;
- Recovery codes: shown once at binding — make sure to save them; each recovery code can be used only once, works in place of a one-time code at login, and can be regenerated;
- the same code cannot be reused (replay protection); wrong codes also count toward the lockout counter.
Authenticator lost
If the authenticator is unavailable and the recovery codes are exhausted, disable two-step verification on the server and re-bind:
sudo daxpay twofactor disableCAPTCHA and Login Lockout
Panel login has two automatic anti-brute-force mechanisms; neither needs to be enabled manually:
- CAPTCHA: once consecutive login failures reach the threshold, the next login requires a CAPTCHA. The threshold is adjustable in the "Account Security" section of the Panel Settings page (1-5, default 1; the CAPTCHA is a friction layer and cannot be turned off).
- Login lockout: 5 consecutive failures lock the account for 365 days — an independent hard backstop.
A lockout is harmless even without server access — whenever you do have server permission, run daxpay unlock to reset the failure counter and unlock; the entry in the interactive UI sits in the "Account Recovery" group (see Terminal UI (TUI)).
Password Security
- The Panel Settings page offers a password complexity switch: once on, new passwords set or reset must be 8-30 characters and combine at least two of letters / digits / special characters (existing passwords are not checked retroactively); when changing a password, live feedback shows which rules are satisfied as you type.
- Forgot your password? Run
daxpay reset-password(supports--username/--passwordfor non-interactive execution); the reset revokes all logged-in sessions.
Lockout Recovery Channels Summary
| Scenario | Recovery command | Interactive UI entry |
|---|---|---|
| Forgot the secure entrance path | daxpay entrance show | Access Recovery → Secure Entrance → View status |
| Wrong domain entered in domain restriction | daxpay domain disable | Access Recovery → Domain Restriction → Disable |
| Locked out by the IP allowlist | daxpay ipallow disable | Access Recovery → IP Allowlist → Disable |
| Login locked out | daxpay unlock | Account Recovery → Unlock login |
| Forgot the password | daxpay reset-password | Account Recovery → Reset account password |
| Two-step verification authenticator lost | daxpay twofactor disable | Account Recovery → Two-Step Verification · Disable |
For command parameter details see Command Line Usage.