Skip to content

The Security Center, tab by tab

Server › Security holds every security tool on the server. This page goes through it tab by tab and says, for each tool, whether to switch it on, leave it off, or only use it in an emergency. For the order to do things in on a new server, start with Securing your server.

At a glance

Tool Where What to do
Firewall, armed Firewall Always on. Arm it on day one.
Threat feeds Firewall On — press Switch on the recommended feeds.
Country blocking Firewall › Countries and networks Only if your sites sell in a few countries.
Login protection Attack protection On. Check no line reads 0.
DDoS protection Attack protection Basic or Web server. Under attack only during an attack.
SMTP block Attack protection On for shared hosting, unless customers send through Gmail, SendGrid and the like.
Web firewall Web & malware › Web firewall Detecting first, then Blocking once the log is clean.
Malware Watch Web & malware › Malware Watch On.
Account isolation Malware scans On, every day — essential if you sell hosting.
Rootkit scan Malware scans On, every week.
Hardening audit Malware scans Run by hand every few months.
Virus engine (ClamAV) Malware scans Only to scan mail, and only with 4 GB of RAM or more.
Malware scan (maldet) Malware scans Optional, recent files only. Never turn its quarantine on for a schedule.
Fail2Ban Malware scans Leave off — not offered, because csf already does its job.
SSH passwords SSH access › SSH server settings Off. Root signs in with an SSH key.
Customer shells SSH access › Shell access by account Only for accounts that need one. Compiler off.

Overview

The dot on each tab says whether that tool is working; the number is what it holds. The Overview starts with what needs a look first, then shows every tool's state and what it stopped, then the latest events. Read it after every change.

Firewall

The firewall (csf) is the wall around the whole server.

  • Arm it. Until it is armed it runs in testing mode and its rules are flushed every few minutes, so nothing stays blocked. Arming is refused if SSH or the panel's port would be shut out. Use testing mode only while you are changing ports, then arm it again.
  • Threat feeds: turn on the recommended ones (Spamhaus DROP and Emerging Threats). They block networks known for attacks before they reach anything, and the panel checks them so they never block your own addresses.
  • Block an address / Allow an address: an address, a network, an AS number or a country. An allowed address skips every block and country rule, so allow only addresses you trust completely, such as your office.
  • Countries and networks: block countries only when a site really has no visitors there. Never use allowed past the firewall for a whole country — it opens every port to that country.
  • Open ports: open only what a service needs. SSH and the panel always stay open, whatever you change here.

Attack protection

  • Login protection blocks an address after repeated failed sign-ins to SSH, FTP, IMAP, POP3 and outgoing mail, and after repeated web firewall hits. The number on each line is how many failures it takes; 0 means that service is not watched, so do not set any line to 0. Add your own office under Firewall › Countries and networks › Never blocked automatically.
  • DDoS protection — pick a template:
    • Basic: a limit on connections to web ports, plus port-scan detection. A safe start for any server.
    • Web server: Basic plus per-port and burst limits. Best for a server that mostly hosts websites.
    • High traffic: higher limits, for busy sites whose visitors share addresses (offices, mobile networks).
    • Under attack: strict limits and SYN-flood protection. Use it only while an attack is happening — some real visitors get blocked — and switch back afterwards.
    • Off: no limits. Not recommended.
  • SMTP block stops a website's scripts from connecting straight to other mail servers. A hacked site then cannot send thousands of spam messages from your server's address and get it blacklisted, while normal mail keeps working. It also stops sites that send through an outside provider (Gmail, SendGrid, Mailgun, a plugin's SMTP settings). If one customer needs that, add their user name under Users that may connect directly instead of turning the block off for everyone.

Web & malware

Web firewall (ModSecurity)

It reads every request to every site and refuses attacks: SQL injection, uploads of web shells, command injection.

  • Start in Detecting: everything is logged, nothing refused.
  • After a few days of normal use, read Activity. When it looks clean, switch to Blocking. It stays in Blocking when the rules update, so newer rules can refuse a request the old ones allowed — check Activity after an update.
  • Rule packs are maintained add-ons, from the people who write the rules, that stop one application (WordPress, Nextcloud) from tripping rules by mistake. Turn on the ones for the software your customers run.
  • When one site keeps being refused, Turn off one rule (its id is in the activity log). Exclude a site switches the firewall off for that whole site — a last resort, never the first fix.

Malware Watch

Checks every script file the moment it is written. A file it is sure about is refused at upload or moved to quarantine; a doubtful one is only reported. Switch it on. Quarantined files can always be put back, and Safe on every account clears one exact file everywhere at once. See Securing your server for details.

Malware scans

Scans that look for problems on a schedule. None of them changes anything by itself: a scan reports, and you decide. Each one starts switched off.

⚠ Switching a scan on does not schedule it. Set Run automatically (Every day or Every week) and press Save — with Never, it runs only when you press Run it now.

Account isolation — on, every day. Checks that the walls between accounts are still standing: every site confined to its own home, every PHP pool naming only its own account, no home readable by the account next door. Keep Look for setuid files on: a setuid root file in a customer's home turns a web shell into a root shell. Run Look for world-writable directories now and then, not nightly — it is slow and noisy. Essential if you sell shared or reseller hosting, and above all if customers have SSH or the terminal.

Rootkit scan (rkhunter) — on, every week. Compares system programs against a baseline taken when it was installed, and looks for the traces known rootkits leave. The panel tunes it for this server, so it does not report the web server's own memory as suspicious. Keep Update its data before each scan on. ⚠ After you update the operating system it may report changed programs — that is the update, not an attack, but read the list before you dismiss it.

Hardening audit (Lynis) — by hand, every few months. Scores how hard the server is to attack and lists suggestions. It cannot be scheduled on purpose: read it, act on the parts that apply, run it again later. Not every suggestion suits a hosting server.

Virus engine (ClamAV) — only for mail, only with enough memory. With Scan mail attachments on, every attachment is checked and an infected message is refused at the door. It keeps about 1 GB of RAM in use all the time, so only use it on a server with 4 GB or more. Not worth installing just for the malware scan below.

Malware scan (maldet) — optional. Signature scanning of every account's web space. Keep Only files changed recently on (a full nightly scan mostly re-reads files it cleared the day before). ⚠ Leave Move what it finds into quarantine off for scheduled scans: a signature match is not a verdict, and a file moved at 3 a.m. can be a customer's whole site going down. Turn it on only while cleaning up a known break-in. It is slow without ClamAV, and its download comes from rfxn.com, which is not a signed repository. Malware Watch already covers the same ground for PHP.

Fail2Ban — leave it. Shown as not offered: csf already blocks repeated failed logins, and csf flushes Fail2Ban's rules whenever it restarts, so Fail2Ban would report bans it no longer enforces.

Findings. Fix all safe applies only the one-click fixes the panel is sure about, then runs the scan again to prove they worked. Ignore hides one finding you have checked; it shows who ignored it and when, and Show again brings it back.

Activity

Everything that was tried and what was blocked: failed sign-ins, web firewall hits, firewall blocks. Needs attention comes first, and Busiest addresses shows who is hitting the server hardest — an address can be blocked or unblocked right there. Look at it after any change, and before you move the web firewall to Blocking.

SSH access

Password sign-in over SSH is what bots attack all day, every day. Use keys.

For the administrator — root by key, passwords off:

  1. Add a key for root. Under Keys, either Generate a pair (copy the private key when it is shown — it is shown once) or Import a key you already have (your public key, for example ~/.ssh/id_ed25519.pub).
  2. Test it. Open a new terminal and sign in as root with the key. Keep your current session open until this works.
  3. Turn passwords off. Under SSH server settings, untick Allow password authentication and save. Leave Allow root to log in ticked: with passwords off, root can then only sign in with its key.
  4. Check the line under the setting: it should say the server accepts keys only.

⚠ Turn passwords off only after the key works — otherwise the only way back in is your provider's console. The page warns you when root has no key installed.

Optional, for more caution: create a named user with a key in the wheel group, check that it can reach root with sudo, and only then untick Allow root to log in. The page lists which accounts qualify and refuses to leave you with none. Keys for root plus passwords off is already the recommended setup; this step is extra.

SSH port: changing it cuts down on log noise from bots, but it is not a security measure on its own. The firewall opens the new port before SSH moves, so you are not locked out.

  • Shell access by account: a customer's shell is always confined to their own files — no other customer's folders, no server configuration, no sudo or su. Even so, give a shell only to accounts that need one; tick SSH access only on those plans (Accounts › Packages).
  • Compiler: leave it off unless a customer must build a Python or Node package with native code. A compiler on a shared server is how a local exploit is usually built on the box.

Never do these

  • Leave the firewall in testing mode.
  • Set Allowed past the firewall for a whole country, or allow an address you do not control.
  • Set a login protection line to 0.
  • Leave DDoS protection on Under attack after the attack.
  • Switch the web firewall to Blocking before reading the log, or Exclude a site to fix one rule.
  • Turn on maldet's quarantine for a scheduled scan.
  • Install ClamAV on a small server just to scan files.
  • Install Fail2Ban by hand alongside csf.
  • Turn on the Compiler for every account.
  • Leave SSH password authentication on.
  • Turn SSH passwords off before your key works.