A server management panel is not a security product. It is an infrastructure management tool that includes security features. This distinction matters more than any firewall rule or encryption algorithm you will ever configure.
At Panelica, we build every security feature we can into the panel — five isolation layers, automated firewall management, ModSecurity WAF, fail2ban integration, encrypted storage, and OpsAI-assisted hardening. We are proud of what we deliver. But we refuse to pretend that installing our panel makes your server "secure" by default.
Security is a shared responsibility between the tool and the person using it.
In This Article
- Where the Panel's Job Ends and Yours Begins
- What Panelica Does Automatically — And Why It Is Not Enough
- What Only a System Administrator Can Do
- The Responsibility Matrix — A Complete Checklist
- Scenario: The Compromised WordPress Plugin
- Scenario: The Forgotten SSH Key
- Scenario: The Backup That Nobody Tested
- Building a Security Culture, Not Just a Security Stack
1. Where the Panel's Job Ends and Yours Begins
Every security breach has two contributing factors: a technical vulnerability and a human decision that allowed it to be exploited. Panels address the first. System administrators address the second.
Neither side alone is sufficient. A perfectly configured panel on a server where every user has "admin123" as their password is not secure. A server with the strongest passwords in the world but no process isolation is not secure either.
2. What Panelica Does Automatically — And Why It Is Not Enough
When you install Panelica, the following security features activate without any configuration:
Cgroups v2 Resource Isolation
Every user gets a dedicated cgroup slice with CPU, RAM, I/O, and PID limits. A compromised account cannot consume server resources beyond its allocation. But cgroups do not prevent data exfiltration — that requires network policies you define.
Linux Namespace Isolation
PID and Mount namespaces ensure users cannot see other users' processes or filesystem. But namespaces do not prevent a user from running a cryptocurrency miner within their own allocation — monitoring policies detect that.
Automated SSL Certificates
ACME integration issues and renews certificates automatically. But SSL only encrypts data in transit. If your application stores passwords in plaintext, SSL does not help. Application security is your responsibility.
ModSecurity WAF
OWASP Core Rule Set blocks common attack patterns — SQL injection, XSS, path traversal. But a WAF cannot protect against business logic flaws. If your checkout page allows negative quantities, no firewall rule catches that.
3. What Only a System Administrator Can Do
These are responsibilities that no panel — regardless of how advanced — can automate:
3.1 Define a Backup Strategy That Actually Works
Panelica provides backup tools: scheduled backups, incremental snapshots, offsite replication. But the panel cannot decide:
- How often your business needs backups (hourly? daily? weekly?)
- How long retention should be (7 days? 90 days? 7 years for compliance?)
- Whether your backups are being tested (when was the last restore test?)
- Where offsite copies should be stored (geographically separate datacenter?)
3.2 Enforce Password and Access Policies
The panel enforces RBAC with 260+ permissions. But it cannot force your organization to:
- Use strong, unique passwords for every account
- Enable two-factor authentication for all admin users
- Revoke access when employees leave the company
- Review permissions quarterly to remove unnecessary access
3.3 Keep Applications Updated
The panel manages server-level software. But your WordPress installations, custom PHP applications, Node.js dependencies — those are yours. An outdated WordPress plugin is the number one entry point for web server compromises.
3.4 Respond to Incidents
The panel logs every action and can alert on anomalies. But when an incident occurs, a human must decide: isolate the server? notify affected users? engage law enforcement? preserve forensic evidence? These are judgment calls that require context no software possesses.
4. The Responsibility Matrix — A Complete Checklist
| Security Domain | Panel Provides | Admin Must Do |
|---|---|---|
| User Isolation | Cgroups, Namespaces, Chroot, PHP-FPM pools | Define resource plans per user, monitor abuse patterns |
| Firewall | nftables engine, rule management UI | Define allowed ports, geo-blocking policy, review rules quarterly |
| Brute Force | fail2ban jails, automatic IP banning | Set ban thresholds, whitelist trusted IPs, monitor ban logs |
| SSL/TLS | Auto-issue via ACME, auto-renewal | Enforce HTTPS-only, configure HSTS headers, test certificate chains |
| WAF | ModSecurity + OWASP CRS deployment | Tune false positives, add custom rules for your apps, review WAF logs |
| Email Security | SPF/DKIM/DMARC auto-configuration | Monitor delivery reputation, review spam queues, train users on phishing |
| Backups | Scheduled, incremental, snapshot tools | Define retention policy, test restores monthly, maintain offsite copy |
| Access Control | RBAC with 260+ permissions, 2FA support | Enforce 2FA, review access quarterly, revoke promptly on termination |
| Logging | Audit trail for every panel action | Review logs regularly, set up alerts, retain logs per compliance |
| Updates | Server software updates via Central | Update applications (WordPress, plugins), test updates before applying |
| Docker | Cgroups isolation, RBAC labels, network isolation | Vet container images, scan for vulnerabilities, limit registry access |
| DNS | BIND management, DNSSEC support | Monitor zone integrity, watch for unauthorized changes, use CAA records |
5. Scenario: The Compromised WordPress Plugin
Tuesday, 2:47 AM — Automated attack begins
/wp-content/uploads/.
- PHP-FPM pool isolation prevented the web shell from accessing other users' files
- Cgroups v2 prevented the attacker from consuming excessive resources
- open_basedir restriction contained file access to the user's home directory
- ModSecurity blocked 47 subsequent SQL injection attempts through the shell
- Audit log recorded every request to the uploaded file
- The panel did not know the plugin was outdated (application-level responsibility)
- The panel contained the damage but could not prevent the initial upload (zero-day at plugin level)
- The admin must: remove the web shell, update the plugin, scan for other compromised files, check if data was exfiltrated, notify affected users if applicable
- The admin must: implement a plugin update policy to prevent recurrence
Lesson: The panel's isolation layers limited a breach that could have compromised the entire server to a single user's directory. But the breach happened because a human did not update a plugin. Infrastructure security contained it. Application security could have prevented it.
6. Scenario: The Forgotten SSH Key
A developer leaves the company. Their SSH key remains.
~/.ssh/authorized_keys on three servers. The developer's laptop is stolen from a coffee shop. The thief finds the private key. The thief now has direct server access — bypassing the panel entirely.
- SSH key management UI to view and revoke keys
- SSH chroot jails to limit what an SSH session can access
- Audit logging of SSH sessions
- OpsAI can audit all SSH keys: "List all SSH keys and when they were last used"
- The panel does not know who left the company (HR system integration is outside scope)
- The panel cannot enforce an offboarding checklist
- The admin must: implement a key rotation policy, tie SSH key revocation to employee offboarding, audit authorized_keys files regularly
- Prevention: use OpsAI quarterly — "Audit all SSH keys, flag any not used in 90 days"
Lesson: Technical controls (chroot, audit logs) exist. But the process control (revoking access on termination) is an organizational decision. The panel provides the mechanism. The organization must provide the policy.
7. Scenario: The Backup That Nobody Tested
The database corruption that revealed a 6-month-old problem.
- Automated backup scheduling (daily, weekly, monthly)
- Incremental backup support to reduce storage usage
- Backup status indicators in the dashboard
- Email notifications on backup failures (if configured)
- That someone reads the failure notification emails
- That backup storage has enough capacity for retention requirements
- That backup integrity is verified (can the backup actually restore?)
- That offsite copies exist in case of hardware failure
- The admin must: test restores monthly, monitor backup storage capacity, maintain at least one offsite copy, document RTO/RPO targets and verify they are met
Lesson: A backup that has not been tested is not a backup — it is a hope. The panel automates the mechanical process of creating backups. The administrator ensures the process actually produces usable results.
8. Building a Security Culture, Not Just a Security Stack
The most secure organizations are not the ones with the most tools. They are the ones where security is a habit, not an afterthought.
Practical Steps to Start Today
- Audit access. Use the panel's user management to review every account. Remove any that are unused. Enable 2FA for every admin account.
- Test your backups. Restore a backup to a test environment this week. Verify the data is complete and current. Schedule this monthly.
- Update applications. Check every WordPress installation for outdated plugins and themes. Set a weekly update schedule.
- Review firewall rules. Are you blocking countries you do not serve? Are unnecessary ports open? Use OpsAI: "Review my firewall rules and suggest improvements."
- Document your incident response plan. Who gets called at 3 AM? What gets shut down first? Where are forensic logs preserved? Write it down before you need it.
Security Is a Partnership
We build the strongest tools we can. You bring the expertise that makes them effective. Together, we build servers that can withstand what the internet throws at them.
Explore Panelica Security FeaturesPanelica — we provide the armor. You provide the strategy.