How Maxinodes protects your site

Applies to: All plans (Self-Managed and Managed).

Every Maxinodes server runs a layered security stack: a web application firewall (WAF) that blocks attacks before they reach your site, server-side malware scanning, account isolation, brute-force protection on logins, and automatic SSL certificates. It works around the clock, in the background, and you do not have to configure or pay extra for it — it is built into every plan.

This page explains what each layer does and how they fit together, so you know what is protecting your site and what to do when something is flagged.

The layers, at a glance

Layer	What it does	What it protects against
ModSecurity + OWASP Core Rule Set	A rule-based web application firewall in front of every site. Inspects each incoming request and rejects the ones that match a known attack pattern.	SQL injection, cross-site scripting (XSS), path traversal / file-inclusion attempts and other request-level web attacks.
ImunifyAV malware scanning	Scans account files on the server itself, against signatures held on that server, and reports what it finds to us. Nothing from your account is uploaded anywhere for analysis.	Backdoors and malicious code that get written into your files.
CloudLinux (CageFS + LVE)	Isolates every account in its own ring-fenced environment so one account cannot see, read or affect another.	A compromise or runaway process on one account spreading to or starving its neighbours.
cPHulk	Brute-force protection on the server's own login services.	Password-guessing against cPanel, WHM, FTP and SSH.
Mail login protection	Locks a mailbox for 5 minutes after 10 failed logins within 5 minutes (webmail, IMAP, POP3 or SMTP), and blocks an address for 5 minutes after 100 failed logins across mailboxes within 5 minutes.	Password-guessing against your mailboxes.
Mail filtering	Refuses mail from known spam sources when they connect (a DNS blocklist check); ImunifyEmail then scores the rest on our server and files likely spam into the Junk folder.	Spam and malicious mail sent to your mailboxes.
AutoSSL (Let's Encrypt)	Issues and renews a free TLS certificate for every domain automatically.	Traffic between your visitors and the server travelling unencrypted.

The layers are complementary: the WAF blocks bad requests at the front door, CloudLinux contains each account, cPHulk guards the logins, and the malware scanner tells us if something malicious still landed in your files.

The web application firewall (ModSecurity + OWASP CRS)

Every node runs ModSecurity with the OWASP Core Rule Set v3, enforced by the LiteSpeed web server. It reads each request to your site and rejects any that match its rules, before the request reaches WordPress, your PHP code or your database. Typical blocks return a 403 Forbidden:

SQL-injection payloads in query strings, form fields or cookies
Cross-site scripting (XSS) attempts
Path-traversal and local-file-inclusion attempts (../../etc/passwd and similar)
Malformed or hostile request headers and known exploit signatures

This is a generic, always-on rule set: it protects any application you host, not just WordPress, and it needs nothing installed on your side.

Because ModSecurity matches patterns, it can occasionally block a legitimate request by mistake (a "false positive") — for example a content editor saving a page that happens to contain code-like text. If a legitimate action of yours is being blocked, the offending rule can be whitelisted: contact support with your domain and the exact action that failed, and we can exempt it. See Understanding ModSecurity (and false positives) for the full picture.

Malware scanning (ImunifyAV)

We run ImunifyAV on every node. It watches accounts for suspicious files — as files are written, uploaded over FTP, or flagged by the firewall — and reports what it finds so our team can act.

The scan runs entirely on the server your site is on. Signature definitions are downloaded to the node and your files are matched against them there. ImunifyAV's cloud-assisted analysis and its option to submit files to the vendor are both switched off, so no file from your account — and nothing inside one — is ever uploaded to the vendor or to any other third party for inspection. Scanning never moves your content off the machine in the Netherlands that serves it.

Two more things are worth being clear about, because they change what you should do:

Scanning is something we run, not something you run. Customer-initiated scans are not enabled on your account. You may notice an Imunify icon in cPanel, but it will not start a scan for you — please do not spend time trying. If you suspect your site is infected, contact support and we will look at the server-side scan results with you.
Detection is not automatic cleanup. Our scanner reports malicious files; it does not silently edit or repair your site's code. Removing malware means cleaning the affected files or restoring a clean copy — that part is a real piece of work, and My site was flagged for malware — what now? walks you through it. On Managed plans we do this with you.

Account isolation (CageFS + LVE)

CloudLinux is the layer that keeps accounts apart. CageFS puts each account in its own isolated filesystem so one account cannot read another's files, and the LVE resource limits cap how much CPU, memory and disk activity each account can use. The security benefit is containment: even if one site on the server were compromised, the attacker is locked inside that single account and cannot reach yours. The same isolation also stops a busy or misbehaving neighbour from slowing your site down.

Brute-force protection (cPHulk)

cPHulk watches the server's own login services — cPanel, WHM, FTP and SSH — and temporarily blocks an address that keeps failing to log in. That stops automated password-guessing against your hosting account.

Note what it does not cover: cPHulk protects the server's logins, not the login page of your CMS. Attacks on /wp-login.php are up to you (and your plugins) to limit — see How to secure and harden your WordPress site.

Protection for your mailboxes

Mail logins. Failed logins to webmail, IMAP, POP3 and SMTP are counted per mailbox: 10 failures within 5 minutes lock that mailbox for 5 minutes, and an address that fails 100 times across mailboxes within 5 minutes is blocked for 5 minutes. A phone still trying an old password is the usual cause, so update saved passwords on every device after a change.
The firewall covers mail too. An address that trips the web application firewall (often an office whose own WordPress keeps triggering a rule) can be graylisted by the server firewall. That blocks every service from the address, mail apps included, until someone on that network opens your site or webmail in a browser and passes the captcha. Webmail on a phone using mobile data keeps working meanwhile. See My mail app can't connect, or keeps asking for my password.
Incoming mail. Mail from known spam sources is refused when the sending server connects. ImunifyEmail scores the rest on our server and files likely spam into your Junk folder rather than deleting it. See Spam filtering and your Junk folder.
Outgoing mail. Mail sent from your mailboxes and your website leaves through our outbound relay, MailChannels. With our mail records in your zone, it is authenticated with SPF, DKIM and DMARC. Each domain has an hourly sending limit (see Mailbox and sending limits), and newsletters or bulk mail belong on a dedicated sending service.

Encryption in transit (AutoSSL)

AutoSSL issues and renews a free Let's Encrypt certificate for every domain and subdomain on your account, so your site can be served over HTTPS without you buying or installing anything. See Free SSL (AutoSSL) and how to force HTTPS.

What this does not include

So you can plan around it honestly:

No automatic malware removal. We detect and report; cleaning or restoring is a deliberate step, done by you (Self-Managed) or with us (Managed).
No self-service scan button. Scanning happens at server level, on our schedule — ask support rather than looking for it in cPanel.
No cloud analysis, and no second opinion from one. Local signatures only. That keeps your files on our server, but it also means detection is bounded by the signature set on the node.
No substitute for keeping your own software patched. The firewall blocks attack patterns; it cannot make an abandoned plugin safe.

What you should still do

These layers protect the platform, but they are not a substitute for keeping your own site healthy:

Keep software updated. Most malware gets in through an outdated CMS, theme or plugin. Update WordPress and its plugins promptly. On Managed plans we handle patching for you.
Use strong passwords and 2FA. Turn on two-factor authentication for your client area and cPanel.
Keep your own backups. We back up your account, mailboxes included, with JetBackup (weekly on Self-Managed Lite, daily on the other plans), but you should keep your own copies too.

If your site is flagged

If we tell you malware was found on your account, or you see the warning signs yourself (unexpected redirects, spam pages, a browser warning), follow My site was flagged for malware — what now? to review what was found, clean your site and restore from a clean backup — and contact support if you need a hand.