Server Security: What Your Panel Does and What You Must Do Yourself
A hosting panel is a tool, not a shield. It gives you the instruments to secure your server -- but using them is your responsibility.
This guide references exact Panelica panel locations. Every feature mentioned here is available in your panel right now.
1. Understanding the Shared Responsibility Model
When you install Panelica, the system automatically configures several layers of protection:
However, none of these protections can compensate for weak passwords, unchanged default ports, or disabled security features. The panel provides the foundation. You build the walls.
You can view an automated assessment of your current security posture at any time:
2. Actions You Must Take Immediately After Installation
2.1 Enable Two-Factor Authentication (2FA)
This is the single most important action you can take. A strong password can be phished, leaked in a data breach, or brute-forced given enough time. 2FA adds a second verification layer that requires physical access to your device.
What happens if you skip this: An attacker who obtains your password -- through phishing, credential stuffing, or a compromised database elsewhere -- gains full control of your panel. Every domain, database, email account, and file on your server becomes accessible.
How to enable in Panelica:
Enable 2FA for every panel account, not just root. Any account with administrative privileges is a target.
2.2 Change the Default SSH Port
The default SSH port (22) is continuously targeted by automated scanners worldwide. These bots attempt thousands of login combinations per hour against every publicly accessible server.
What happens if you skip this: Your authentication logs will fill with failed login attempts. While Fail2ban helps mitigate this, changing the port eliminates the vast majority of automated attacks before they even reach your authentication layer.
How to change in Panelica:
2.3 Disable Root SSH Login
Root is the most powerful account on any Linux system. Allowing direct root login over SSH means an attacker only needs to guess one password to gain complete control.
How to configure in Panelica:
2.4 Implement SSH Key-Based Authentication
Password-based SSH authentication is inherently vulnerable to brute-force attacks. SSH keys use cryptographic key pairs that are practically impossible to guess.
How to configure in Panelica:
2.5 Enforce Strong Password Policies
Every account on your server -- panel users, database users, FTP accounts, email accounts -- must use strong, unique passwords.
Minimum requirements:
3. Regular Maintenance and Monitoring
3.1 System Updates
The majority of successful attacks exploit known vulnerabilities that already have patches available. The server was not insecure by design -- it was insecure because the administrator did not apply updates.
Schedule a weekly review at minimum. Critical security patches should be applied within 24 hours of release.
3.2 Panel and Service Updates
Panelica releases updates that include security patches, bug fixes, and new features. These are delivered through the built-in update system.
How to check in Panelica:
3.3 Log Review
Logs are your early warning system. They tell you what is happening on your server before it becomes a crisis.
How to review in Panelica:
3.4 Backup Verification
A backup that has never been tested is not a backup. It is a hope.
How to manage in Panelica:
4. Network Security
4.1 Firewall Configuration
The principle is simple: deny everything, then allow only what is necessary.
How to manage in Panelica:
4.2 Fail2ban and IP Blocking
Fail2ban monitors log files for patterns of malicious behavior and automatically bans offending IP addresses.
How to manage in Panelica:
4.3 CDN and DDoS Protection
Services like Cloudflare provide DDoS mitigation, WAF rules, real IP masking, and bot detection at the network edge. For any production website, using a CDN with security features is strongly recommended.
Panelica integrates with Cloudflare for DNS management. If your domains use Cloudflare, DNS records are managed directly from the panel.
5. Application Layer Security
5.1 WordPress Management
CMS platforms are the most frequently exploited entry point on managed servers. Not because the core software is weak, but because administrators neglect maintenance.
How to manage in Panelica:
5.2 PHP Version Management
Each PHP version has a defined support lifecycle. When a version reaches End of Life (EOL), it no longer receives security patches.
How to manage in Panelica:
5.3 File Permissions
Incorrect file permissions are one of the most common security misconfigurations.
Rules:
5.4 ModSecurity (Web Application Firewall)
ModSecurity inspects incoming HTTP requests and blocks those matching known attack patterns: SQL injection, cross-site scripting (XSS), remote file inclusion, and more.
How to manage in Panelica:
6. SSL/TLS Certificate Management
Every domain on your server should use HTTPS. Unencrypted HTTP connections expose user data, login credentials, and session tokens to anyone on the network path.
How to manage in Panelica:
7. Email Security
If you operate a mail server, misconfiguration can result in your server being used to send spam, your IP being blacklisted, or your users' emails being intercepted.
7.1 DNS Authentication Records (SPF, DKIM, DMARC)
How to manage in Panelica:
7.2 TLS Encryption for Mail
All mail connections should use TLS encryption. Unencrypted email transmission means anyone on the network path can read the contents. Panelica configures TLS by default for Postfix and Dovecot.
8. Preparing for the Worst: Incident Response
Security is not only about prevention. You must plan for the scenario where prevention fails.
Questions you should be able to answer right now:
If you cannot answer these questions, your incident response plan does not exist.
Basic incident response steps:
9. Quick Reference: Panel Security Features Map
Final Note
Security is not a product you install. It is a practice you maintain.
Your hosting panel automates the complex parts -- service isolation, process containment, firewall management, certificate provisioning. But automation cannot replace judgment. It cannot decide that your password should be stronger. It cannot force you to apply updates. It cannot enable 2FA on your behalf.
Every feature listed in this guide is available in your Panelica panel. The tools are there. The responsibility is yours.
If you have questions about any of these topics, post them in this thread. We will provide specific guidance for your situation.
A hosting panel is a tool, not a shield. It gives you the instruments to secure your server -- but using them is your responsibility.
This guide references exact Panelica panel locations. Every feature mentioned here is available in your panel right now.
1. Understanding the Shared Responsibility Model
When you install Panelica, the system automatically configures several layers of protection:
- Cgroups v2 resource isolation per user
- PHP-FPM process isolation with per-user, per-version pools
- Chroot environments for SSH/SFTP access
- nftables firewall with sensible defaults
- Fail2ban with pre-configured jails
- ModSecurity with OWASP Core Rule Set
- AES-256 encryption for sensitive data
- JWT-based authentication with automatic token rotation
However, none of these protections can compensate for weak passwords, unchanged default ports, or disabled security features. The panel provides the foundation. You build the walls.
You can view an automated assessment of your current security posture at any time:
Security > Security Advisor -- scans your server configuration and reports issues with severity levels (critical, high, medium, low). Offers one-click fixes with rollback capability for most findings.
2. Actions You Must Take Immediately After Installation
2.1 Enable Two-Factor Authentication (2FA)
This is the single most important action you can take. A strong password can be phished, leaked in a data breach, or brute-forced given enough time. 2FA adds a second verification layer that requires physical access to your device.
What happens if you skip this: An attacker who obtains your password -- through phishing, credential stuffing, or a compromised database elsewhere -- gains full control of your panel. Every domain, database, email account, and file on your server becomes accessible.
How to enable in Panelica:
Navigate to your Profile > Settings > Security tab. Click on Two-Factor Authentication and scan the QR code with your authenticator app (Google Authenticator, Authy, or similar). Store the recovery codes in a secure offline location.
Direct path: /profile/settings#2fa
Direct path: /profile/settings#2fa
Enable 2FA for every panel account, not just root. Any account with administrative privileges is a target.
2.2 Change the Default SSH Port
The default SSH port (22) is continuously targeted by automated scanners worldwide. These bots attempt thousands of login combinations per hour against every publicly accessible server.
What happens if you skip this: Your authentication logs will fill with failed login attempts. While Fail2ban helps mitigate this, changing the port eliminates the vast majority of automated attacks before they even reach your authentication layer.
How to change in Panelica:
Navigate to Tools > Remote Access > SSH Access and select the SSHD Config tab. You will find the Port field where you can change the listening port to any unused value between 1024 and 65535.
After changing the port, make sure your firewall allows the new port before the change takes effect:
Security > Firewall Rules -- add an inbound rule allowing TCP traffic on your new SSH port.
Direct path: /tools/ssh
After changing the port, make sure your firewall allows the new port before the change takes effect:
Security > Firewall Rules -- add an inbound rule allowing TCP traffic on your new SSH port.
Direct path: /tools/ssh
2.3 Disable Root SSH Login
Root is the most powerful account on any Linux system. Allowing direct root login over SSH means an attacker only needs to guess one password to gain complete control.
How to configure in Panelica:
Navigate to Tools > Remote Access > SSH Access and select the SSHD Config tab. Locate the PermitRootLogin setting and change it to one of the following:
Before disabling root login, create a regular user with sudo privileges and verify you can log in with it. Locking yourself out of your own server is not a security improvement.
Direct path: /tools/ssh
- no -- completely disables root SSH login (recommended)
- prohibit-password -- allows root login only with SSH keys, not passwords
- without-password -- same as prohibit-password (legacy alias)
Before disabling root login, create a regular user with sudo privileges and verify you can log in with it. Locking yourself out of your own server is not a security improvement.
Direct path: /tools/ssh
2.4 Implement SSH Key-Based Authentication
Password-based SSH authentication is inherently vulnerable to brute-force attacks. SSH keys use cryptographic key pairs that are practically impossible to guess.
How to configure in Panelica:
Navigate to Tools > Remote Access > SSH Access. The SSH Keys tab allows you to manage authorized keys for your server users.
On your local machine, generate a key pair and copy it to the server:
Important: Always verify key-based login works in a separate terminal session before disabling password authentication.
On your local machine, generate a key pair and copy it to the server:
Code:
# Generate a key pair on your LOCAL machine
ssh-keygen -t ed25519 -C "your-identifier"
# Copy the public key to your server
ssh-copy-id -p YOUR_PORT user@your-server-ip
# After confirming key-based login works, disable password auth
# In SSHD Config tab: set PasswordAuthentication to "no"
Important: Always verify key-based login works in a separate terminal session before disabling password authentication.
2.5 Enforce Strong Password Policies
Every account on your server -- panel users, database users, FTP accounts, email accounts -- must use strong, unique passwords.
Minimum requirements:
- At least 14 characters
- Mix of uppercase, lowercase, numbers, and special characters
- Never reused across services
- Managed through a password manager, not memory or sticky notes
3. Regular Maintenance and Monitoring
3.1 System Updates
The majority of successful attacks exploit known vulnerabilities that already have patches available. The server was not insecure by design -- it was insecure because the administrator did not apply updates.
Code:
# Check for and apply OS-level updates
apt update && apt upgrade -y
# Enable automatic security updates
apt install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades
Schedule a weekly review at minimum. Critical security patches should be applied within 24 hours of release.
3.2 Panel and Service Updates
Panelica releases updates that include security patches, bug fixes, and new features. These are delivered through the built-in update system.
How to check in Panelica:
Navigate to Support > System Updates. This page lists all installed services with their current and available versions. Security-related updates are flagged. You can apply updates individually or review changelogs before applying.
The update system supports rollback -- if an update causes issues, you can revert to the previous version from the same page.
Direct path: /support/updates
The update system supports rollback -- if an update causes issues, you can revert to the previous version from the same page.
Direct path: /support/updates
3.3 Log Review
Logs are your early warning system. They tell you what is happening on your server before it becomes a crisis.
How to review in Panelica:
Navigate to Monitoring > Log Management. The log viewer provides six tabs:
What to look for:
Direct path: /monitoring/log-management
- Overview -- summary dashboard of recent log activity
- Access Logs -- HTTP request logs per domain
- Error Logs -- application and server errors
- System Logs -- OS-level events and service logs
- Logrotate -- log rotation configuration
- Settings -- log retention and storage preferences
What to look for:
- Repeated failed login attempts from the same IP or IP range
- Successful logins from unfamiliar IP addresses or at unusual times
- Unexpected spikes in traffic or resource usage
- Error messages indicating configuration changes you did not make
- New cron jobs or scheduled tasks you did not create
Direct path: /monitoring/log-management
3.4 Backup Verification
A backup that has never been tested is not a backup. It is a hope.
How to manage in Panelica:
Navigate to Backup in the main menu. Panelica provides a comprehensive backup system:
Critical practices:
- Backup > Create Backup (/backup/server/create) -- create on-demand backups with domain selection, encryption options, and incremental support
- Backup > Restore (/backup/server/restore) -- restore from any available backup point
- Backup > Schedules (/backup/schedules) -- configure automated backup schedules
- Backup > Snapshots (/backup/snapshots) -- manage server snapshots
- Backup > Remote Storage (/backup/remote) -- configure offsite storage (SFTP, Google Drive) for disaster recovery
- Backup > Activity (/backup/activity) -- review backup job history and results
Critical practices:
- Verify that automated backups are running on schedule
- Periodically download a backup and test restoration on a separate environment
- Store at least one copy offsite using the Remote Storage feature
- Ensure database backups are included, not just file backups
- Document your restoration procedure so you can execute it under pressure
4. Network Security
4.1 Firewall Configuration
The principle is simple: deny everything, then allow only what is necessary.
How to manage in Panelica:
Navigate to Security > Firewall Rules. The firewall management interface allows you to:
Ports that should be open:
Everything else should be closed. Database ports (3306, 5432), Redis (6379), administrative interfaces -- none of these should be accessible from the public internet unless you have a specific, documented reason.
Direct path: /security/firewall
- Create inbound and outbound rules
- Specify protocols (TCP, UDP, ICMP, or Any)
- Define source and destination IP addresses and ports
- Set actions (Allow, Deny, Reject)
- Enable or disable individual rules without deleting them
Ports that should be open:
- 80 (HTTP) and 443 (HTTPS) -- web traffic
- Your custom SSH port -- remote administration
- Mail ports only if you run a mail server (25, 465, 587, 993, 995)
Everything else should be closed. Database ports (3306, 5432), Redis (6379), administrative interfaces -- none of these should be accessible from the public internet unless you have a specific, documented reason.
Direct path: /security/firewall
4.2 Fail2ban and IP Blocking
Fail2ban monitors log files for patterns of malicious behavior and automatically bans offending IP addresses.
How to manage in Panelica:
Navigate to Security > IP Fail2ban Management. This page provides:
Check that the SSH jail is configured for your custom port (not the default 22) after changing the SSH port.
Direct path: /security/ip-blocking
- Preset Rules -- pre-configured jails for SSH brute force, FTP attacks, and other common vectors. Verify they are active.
- Manual IP Blocking -- add specific IPs or ranges to the blacklist with temporary or permanent duration
- Whitelist -- ensure your own IPs are whitelisted to prevent self-lockout
- Country Blocking -- block entire countries if your service does not operate in those regions
- Ban Logs -- review which IPs have been banned and why
Check that the SSH jail is configured for your custom port (not the default 22) after changing the SSH port.
Direct path: /security/ip-blocking
4.3 CDN and DDoS Protection
Services like Cloudflare provide DDoS mitigation, WAF rules, real IP masking, and bot detection at the network edge. For any production website, using a CDN with security features is strongly recommended.
Panelica integrates with Cloudflare for DNS management. If your domains use Cloudflare, DNS records are managed directly from the panel.
5. Application Layer Security
5.1 WordPress Management
CMS platforms are the most frequently exploited entry point on managed servers. Not because the core software is weak, but because administrators neglect maintenance.
How to manage in Panelica:
Navigate to WP Toolkit in the main menu. Panelica provides a dedicated WordPress management suite:
Mandatory practices:
- WP Toolkit > Sites (/wordpress/sites) -- overview of all WordPress installations with version, status, and health indicators
- WP Toolkit > Updates (/wordpress/updates) -- centralized update management for core, plugins, and themes across all installations
- WP Toolkit > Plugins (/wordpress/plugins) -- manage plugins across all sites from a single interface
- WP Toolkit > Themes (/wordpress/themes) -- manage themes across all sites
- WP Toolkit > Security (/wordpress/security) -- security activity monitoring and hardening recommendations
- WP Toolkit > Staging (/wordpress/staging) -- test changes in a staging environment before applying to production
- WP Toolkit > Backup (/wordpress/backup) -- WordPress-specific backup and restore
Mandatory practices:
- Update core, themes, and plugins immediately when updates are available
- Remove themes and plugins you are not actively using -- they remain attack vectors even when deactivated
- Never install plugins or themes from untrusted sources
- Change the default admin login path (/wp-admin)
- Limit login attempts with a security plugin
- Disable XML-RPC if you do not use it
- Disable file editing from the dashboard: add
to wp-config.phpCode:
define('DISALLOW_FILE_EDIT', true);
5.2 PHP Version Management
Each PHP version has a defined support lifecycle. When a version reaches End of Life (EOL), it no longer receives security patches.
How to manage in Panelica:
Navigate to Tools > PHP Settings. The PHP management interface provides four tabs:
Current PHP lifecycle status (2026):
Running an EOL version of PHP is equivalent to leaving a known unlocked door in your building and hoping nobody tries the handle.
Direct path: /tools/php
- Versions -- set PHP version per domain, bulk version changes
- Extensions -- enable or disable PHP extensions
- Configuration -- edit php.ini directives per version
- System PHP -- configure the global system PHP binary
Current PHP lifecycle status (2026):
- PHP 8.1 -- End of Life. Migrate immediately.
- PHP 8.2 -- Security fixes only. Plan migration.
- PHP 8.3 -- Actively supported. Recommended minimum.
- PHP 8.4 -- Latest stable. Recommended for new projects.
Running an EOL version of PHP is equivalent to leaving a known unlocked door in your building and hoping nobody tries the handle.
Direct path: /tools/php
5.3 File Permissions
Incorrect file permissions are one of the most common security misconfigurations.
Rules:
- Files: 644 (owner read/write, group and others read)
- Directories: 755 (owner full, group and others read/execute)
- Configuration files with sensitive data (wp-config.php, .env): 600 (owner read/write only)
- Never use 777 for anything. There is no legitimate reason to make files world-writable on a production server.
Code:
# Fix permissions for a web directory
find /home/username/public_html -type f -exec chmod 644 {} \;
find /home/username/public_html -type d -exec chmod 755 {} \;
# Protect sensitive config files
chmod 600 /home/username/public_html/wp-config.php
5.4 ModSecurity (Web Application Firewall)
ModSecurity inspects incoming HTTP requests and blocks those matching known attack patterns: SQL injection, cross-site scripting (XSS), remote file inclusion, and more.
How to manage in Panelica:
Navigate to Security > ModSecurity. The WAF management interface provides:
Be aware that overly aggressive rules may block legitimate requests. Monitor your logs after enabling ModSecurity and create whitelist exceptions where necessary.
Direct path: /security/modsecurity
- Global ModSecurity toggle and OWASP Core Rule Set management
- Per-domain custom rules -- enable or disable WAF protection for individual domains
- Whitelist entries by IP address, URL path, User-Agent, or parameter name
- Security event logs showing blocked requests with details
- Real-time monitoring of WAF activity
Be aware that overly aggressive rules may block legitimate requests. Monitor your logs after enabling ModSecurity and create whitelist exceptions where necessary.
Direct path: /security/modsecurity
6. SSL/TLS Certificate Management
Every domain on your server should use HTTPS. Unencrypted HTTP connections expose user data, login credentials, and session tokens to anyone on the network path.
How to manage in Panelica:
Navigate to Domains > SSL Certificates. The SSL management interface supports:
Let's Encrypt certificates are issued automatically when you create a domain and are renewed before expiration. Verify that auto-renewal is functioning by checking certificate expiration dates periodically.
Direct path: /domains/ssl
- Let's Encrypt -- free, automated certificate issuance and renewal
- Custom Certificates -- upload your own certificates for specific requirements
- CSR Generation -- create Certificate Signing Requests for commercial certificate authorities
- Certificate status overview with expiration dates
- One-click renewal for expiring certificates
Let's Encrypt certificates are issued automatically when you create a domain and are renewed before expiration. Verify that auto-renewal is functioning by checking certificate expiration dates periodically.
Direct path: /domains/ssl
7. Email Security
If you operate a mail server, misconfiguration can result in your server being used to send spam, your IP being blacklisted, or your users' emails being intercepted.
7.1 DNS Authentication Records (SPF, DKIM, DMARC)
How to manage in Panelica:
Navigate to Mail > Email Authentication. This page displays the DNS authentication status for each domain with three tabs:
Panelica configures these records automatically when you set up email for a domain with Cloudflare DNS integration. Verify they exist and are correct using online tools such as MXToolbox or dmarcanalyzer.com.
Direct path: /email/authentication
- SPF -- Sender Policy Framework records. Declares which IP addresses are authorized to send email for your domain. Without it, anyone can forge emails appearing to come from your domain.
- DKIM -- DomainKeys Identified Mail records. Cryptographically signs outgoing emails, allowing recipients to verify the message was not altered in transit. Panelica generates DKIM keys automatically.
- DMARC -- Domain-based Message Authentication, Reporting and Conformance records. Instructs receiving servers on how to handle emails that fail SPF or DKIM checks. Should be set to quarantine or reject.
Panelica configures these records automatically when you set up email for a domain with Cloudflare DNS integration. Verify they exist and are correct using online tools such as MXToolbox or dmarcanalyzer.com.
Direct path: /email/authentication
7.2 TLS Encryption for Mail
All mail connections should use TLS encryption. Unencrypted email transmission means anyone on the network path can read the contents. Panelica configures TLS by default for Postfix and Dovecot.
8. Preparing for the Worst: Incident Response
Security is not only about prevention. You must plan for the scenario where prevention fails.
Questions you should be able to answer right now:
- If your server is compromised at 3 AM, what is your first action?
- Where are your offsite backups stored, and how quickly can you restore from them?
- Do you have a separate, secure way to access your server if the primary credentials are compromised?
- Who needs to be notified (customers, partners, authorities) and how will you contact them?
- How will you determine what was accessed or stolen?
- Do you have a clean server image or installation procedure ready to deploy?
If you cannot answer these questions, your incident response plan does not exist.
Basic incident response steps:
- Isolate: Disconnect the compromised server from the network or restrict access via firewall
- Preserve: Do not wipe logs or data. They are evidence and will help you understand the scope.
- Assess: Determine what was accessed, modified, or exfiltrated
- Remediate: Rebuild from clean backups rather than attempting to "clean" a compromised system
- Notify: Inform affected parties as required
- Review: Identify how the breach occurred and implement measures to prevent recurrence
9. Quick Reference: Panel Security Features Map
| Feature | Panel Location | Path | Priority |
|---|---|---|---|
| Two-Factor Authentication | Profile > Settings > Security | /profile/settings#2fa | Critical |
| SSH Port / Root Login / Keys | Tools > Remote Access > SSH Access | /tools/ssh | Critical |
| Firewall Rules | Security > Firewall Rules | /security/firewall | Critical |
| Fail2ban / IP Blocking | Security > IP Fail2ban Management | /security/ip-blocking | High |
| ModSecurity (WAF) | Security > ModSecurity | /security/modsecurity | High |
| Security Advisor | Security > Security Advisor | /security/advisor | High |
| SSL/TLS Certificates | Domains > SSL Certificates | /domains/ssl | High |
| Log Management | Monitoring > Log Management | /monitoring/log-management | High |
| System Updates | Support > System Updates | /support/updates | High |
| Backup Management | Backup > Create / Schedules / Remote | /backup/server/create | High |
| PHP Version Management | Tools > PHP Settings | /tools/php | Medium |
| Email Authentication | Mail > Email Authentication | /email/authentication | Medium |
| WordPress Management | WP Toolkit > Sites / Security | /wordpress/sites | Medium |
Final Note
Security is not a product you install. It is a practice you maintain.
Your hosting panel automates the complex parts -- service isolation, process containment, firewall management, certificate provisioning. But automation cannot replace judgment. It cannot decide that your password should be stronger. It cannot force you to apply updates. It cannot enable 2FA on your behalf.
Every feature listed in this guide is available in your Panelica panel. The tools are there. The responsibility is yours.
If you have questions about any of these topics, post them in this thread. We will provide specific guidance for your situation.
Last edited: