Essential Security Settings After Installing BT Panel (Troubleshooting 4 Causes of Access Failure)

BT Panel is ready to use right after installation, which is also its problem—installation completion does not mean it can go live. In the default configuration, ports, entry paths, and usernames are publicly known, and scanners are batch-finding these default values.

Another equally common issue is: the panel was working fine yesterday, but today it won’t open. Behind this phenomenon are four completely different causes, with entirely different handling methods. Reinstalling without distinguishing between them is basically a waste of time.

Four Causes of Panel Access Failure

# Timeout
This site can't be reached / ERR_CONNECTION_TIMED_OUT

# Self-signed certificate
Your connection is not private

# Login restriction
Incorrect username or password (IP will be locked after multiple failures)

# phpMyAdmin exposure
Unauthenticated access to phpMyAdmin — databases can be directly dumped

Troubleshooting Commands

# ① Panel status and port
bt status
ss -lntp | grep -E '8888|888|80|443'

# ② Forgot security entry path
cat /www/server/panel/data/admin_path.pl

# ③ Forgot password / want to change username / want to change port
bt 5      # Change panel password
bt 6      # Change username
bt 8      # Change panel port

# ④ Restart panel service
bt restart

# ⑤ Allow port in firewall (CentOS)
firewall-cmd --permanent --add-port=NewPort/tcp
firewall-cmd --reload

# ⑥ Check panel error logs
cat /www/server/panel/logs/error.log 2>/dev/null

Must-Do Checklist After Installation

1. Change port: Do not use default ports like 8888; these are targets for batch scanning.
2. Change security entry: Set it to a random string path; do not stay on the default login path.
3. Change default username: Do not use ‘admin’.
4. Strong password: And enable lockout on failed login attempts.
5. Enable two-factor authentication: Google Authenticator or BasicAuth.
6. Bind domain name: Only access the panel via your own domain.
7. IP whitelist: Cloud security groups should only allow your outgoing IP, do not allow 0.0.0.0/0.
8. Secure phpMyAdmin: Change the port or disable public access entirely — this is the main cause of database dumps.
9. Enable panel backup: Back up the panel itself so you can quickly recover if issues arise.
10. Update promptly: Vulnerabilities within the panel itself are a major risk area.

Decision Tree

Panel inaccessible
├─ Local curl also fails    → Panel service crashed → bt restart
├─ Works locally, fails externally
│  ├─ Security group not allowed     → Allow port in cloud console
│  ├─ Firewall not allowed           → Allow via firewall-cmd
│  └─ Port blocked                 → Change port (bt 8)
├─ Entry path not found       → cat admin_path.pl to retrieve real path
└─ Incorrect password         → bt 5 to reset

Scenario Simulation: Changed Port for Safety, But Locked Yourself Out

Phenomenon: A server with a freshly installed BT panel had its default port changed to a custom one to reduce scanning risks. After changing it and logging out, the new port was inaccessible, and the old port was also gone.

1. First, distinguish between total inaccessibility and path issues → Connect to the server remotely,
   confirm the host is alive and the panel process is running — this step rules out “service didn’t start”.
2. Test the port from the server itself → If local access works, the panel service itself is fine.
3. Test the same port from outside → Fails. Local works, external fails, immediately narrowing the problem to the network layer, not the panel.
4. Check both layers of allowance → The system firewall did not allow the new port; more critically, the cloud platform’s security group also did not allow it.
   These two layers are independent; allowing one does not imply the other is effective.
5. Use the panel’s built-in command-line interface to retrieve access details → The panel provides a CLI menu to view the current entry and port directly.
6. Restore access after allowing both layers → External test returns normal, and this time, the new port was added first, verified, and then the old port was removed.

# Is the host alive? Is the process running?
uptime
ps aux | grep -i '[b]t-panel' | head

# Does it work locally? (Key diagnostic criterion)
curl -sS -o /dev/null -w '%{http_code}n' http://127.0.0.1:NewPort

# Is the port actually listening?
ss -lntp | grep NewPort

# System firewall
firewall-cmd --list-ports 2>/dev/null
iptables -L -n | grep NewPort

# Built-in panel CLI entry (a fallback if changes go wrong)
bt

Root Cause: When changing the port, only the panel’s own configuration was modified, without synchronously allowing the two control layers in the chain;
more importantly, the operation order was wrong — logged out before verifying the new port was usable.

Two key points to remember:

• For operations involving opening external ports, the fixed order is “Add new → Verify access → Remove old”.
  Getting the order wrong doesn’t always cause issues, but when it does, you lock yourself out and must use the CLI on the server to recover.
• Panel ports require allowance in two layers: system firewall and cloud security group. Both must be changed.
  Changing only one results in “works locally, fails externally,” which is itself the most accurate diagnostic clue.

How to Configure Security Groups

Many panel intrusions occur not because the panel itself has vulnerabilities, but because the security group allows 0.0.0.0/0 — effectively opening it to the entire internet. The correct approach is to only allow your own outgoing IP:

# First, check your outgoing IP
curl ifconfig.me

# Then, in the cloud console security group, fill in the source for the panel port as: YourIP/32
# Synchronize with system firewall (using port 12345 as an example)
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="YourIP" port protocol="tcp" port="12345" accept'
firewall-cmd --reload

# Confirm effectiveness
firewall-cmd --list-all

The only cost is updating this when your outgoing IP changes (e.g., switching office networks). In exchange, the panel is completely hidden from the public internet — if it can’t be scanned, it can’t be attacked.

The three layers of allowance must be consistent: Cloud Security Group → System Firewall → Panel Configuration. If any layer blocks it, access fails; if any layer opens it to the whole internet, a vulnerability remains.

Operational Reference for Panel-Specific Security Settings

For changing the port and entry path, the verification order cannot be reversed: Add new first, confirm login works, then remove old.
Changing everything at once and logging out immediately means if the new config doesn’t take effect, you can’t even enter the panel, forcing you to use the CLI on the server to retrieve the entry.

# Built-in panel CLI entry (fallback if changes go wrong)
bt
# Common items: Change panel port, change username, change password, disable API, remove entry restrictions

# Confirm panel process and port (check here first if port changed to see if it updated)
ss -lntp | grep -E '8888|888|YourNewPort'

# Confirm new port is reachable from outside before removing old port
curl -sS -o /dev/null -w '%{http_code}n' https://PanelDomain:Port/EntryPointPath

Final reminder: No matter how comprehensive the panel security settings are, they cannot replace system-level hardening.
The panel is the entrance, while the system firewall and security group are the door; both are necessary.
Changing only the panel port while the security group still exposes it to the whole internet is like changing the lock but leaving the door wide open.

7 Common Pitfalls

1. Changing port but not entry path: Scanners can still find the panel; both must be changed.
2. Allowing 0.0.0.0/0 in security group: Equivalent to having no whitelist; the panel is open to the entire internet.
3. Ignoring phpMyAdmin: Even if the panel is secured, the database management interface on port 888 might still be open, leading to database dumps.
4. Not enabling panel backup: If panel data is corrupted, reinstallation is required, and all site configurations must be redone.
5. Using default username ‘admin’: Directly minimizes the cost of brute-force attacks.
6. Clicking through self-signed certificate warnings: Developing a habit of ignoring certificate warnings makes it impossible to detect real man-in-the-middle attacks.
7. Changing port but forgetting to sync allowance in security group: Works locally, fails externally; this is the most common “changed but not effective” scenario.
8. Logging out immediately after changing port: Closing the old port before verifying the new one works locks you out, requiring CLI recovery on the server.

Real Customer Feedback (From Cloud Market Reviews and Consultations for Similar Products)

The following excerpts are taken from real buyer reviews and consultations for similar O&M services on Alibaba Cloud / Tencent Cloud / Huawei Cloud Cloud Markets (service providers include our store and peers, provided solely for reference of real feedback, not fictional tickets from this site):

1****n Rating: 5.0 Points 2018-01-04 18:04

d****9 Rating: 5.0 Points 2023-02-15 09:11 a****7 Rating: 5.0 Points 2023-02-15 09:10 d****8 Rating: 5.0 Points 2023-02-14 10:48 d****8 Rating: 5.0 Points 2023-02-14 10:43 a****3 Rating: 5.0 Points 2023-01-17 17:20

9****3 Rating: 5.0 Points 2021-07-22 10:31