"Advanced security" on a hosting plan usually means some combination of intrusion detection and intrusion prevention running in the background. The terms get used loosely in marketing copy, but the underlying distinction, detecting an attack versus actively stopping it, determines what actually happens the moment someone tries to break into your site.
Detection vs Prevention: The Core Distinction
An Intrusion Detection System watches traffic and system activity, compares what it sees against known attack signatures or anomalous behavior patterns, and raises an alert when something matches. It is fundamentally passive from an action standpoint, its job ends at notification, and a human or a separate automated system has to decide what to do next. This made sense in an earlier era of network security when traffic volumes were low enough that a security team could realistically review alerts and respond manually.
An Intrusion Prevention System does the same detection work but sits inline with the traffic path, meaning it can act on what it detects immediately, dropping a malicious connection, blocking an IP address, or rejecting a malformed request before it ever reaches your application. This is now the standard for hosting-focused security, because the volume of automated attack traffic hitting any public website (bots scanning for known WordPress vulnerabilities, brute-force login attempts, SQL injection probes) is far too high for manual review to be practical. Most tools marketed as hosting security today (Imunify360, Wordfence's live-blocking mode, Sucuri's firewall) function primarily as an IPS, with detection-only alerting as a secondary, supplementary feature rather than the primary mode.
Network-Based vs Host-Based: Where the Detection Happens
The second axis that matters is where the monitoring actually occurs, because network-level and host-level detection catch fundamentally different classes of attack.
Network-based (NIDS/NIPS) inspects traffic as it crosses a network boundary, commonly at a firewall, load balancer, or edge device before it reaches any individual server. This is effective against attacks visible in the traffic pattern itself: port scanning, distributed brute-force attempts spread across many source IPs, known-bad request signatures, and volumetric attacks. Its blind spot is anything that happens after a request has already been let through and looks legitimate at the network level, a compromised plugin quietly modifying files, or a stolen password used for a single, unremarkable-looking login.
Host-based (HIDS/HIPS) runs directly on the server and monitors local activity: file integrity (has a core WordPress file been modified unexpectedly), process behavior (is a PHP process spawning a shell, a classic sign of a web shell attack), login attempt patterns on that specific account, and log file contents for suspicious sequences. This catches what network-level inspection cannot see, because it has visibility into what is actually happening on the machine itself, not just what the traffic looked like on the way in.
Neither layer alone is sufficient. A network-level system with no host-level counterpart will miss a compromise that originates from a stolen credential or a vulnerable plugin already installed on the site. A host-level system with no network-level counterpart still lets a volumetric attack or a coordinated brute-force campaign consume server resources before host-level detection ever gets a chance to notice anything wrong. Effective hosting security layers both.
What This Looks Like on Real Hosting Plans
On shared and managed hosting, intrusion detection and prevention is provisioned and managed by the host, not configured by you, and it typically protects the whole server, not just your individual account, since a compromise on one account can be used to attack neighboring accounts on the same machine. cPanel-based hosting commonly runs Imunify360 or a comparable product, which bundles a web application firewall, host-based malware and file-integrity scanning, and network-level IP reputation blocking into a single system that runs automatically with no configuration required from you.
On a self-managed VPS or dedicated server, none of this exists unless you set it up yourself. The baseline most self-managed server administrators install is Fail2ban, a lightweight host-based tool that watches log files (SSH login attempts, web server access logs) for repeated failure patterns and automatically firewalls off offending IPs after a threshold is crossed. This is a genuine IPS by definition, it detects and blocks automatically, but it is far narrower in scope than a commercial product like Imunify360, and it requires you to configure the rules and thresholds yourself rather than inheriting a pre-tuned ruleset.
What to Actually Check When Evaluating a Host's Security Claims
- Is it detection-only or does it block automatically? A host advertising "monitoring" or "alerts" without specifying automated blocking may only be providing detection, which is meaningfully weaker protection against automated, high-volume attacks than a true IPS.
- Does it cover both network and host level? A firewall alone (network-level) does not catch a compromised plugin already inside your account. Ask specifically whether file-integrity or malware scanning (host-level) is included, not just a firewall.
- Is it a named, established product or a vague marketing claim? "Imunify360 included" or "Wordfence Premium included" is a concrete, verifiable claim you can research independently. "Advanced security monitoring" with no named tool behind it is harder to evaluate and sometimes means less than it implies.
- On a VPS, is anything provisioned by default, or is it entirely your responsibility? Some managed VPS providers install and configure baseline protection (Fail2ban or equivalent) automatically; fully unmanaged VPS hosting leaves this to you entirely, which is a real, easy-to-overlook setup step for anyone moving from shared hosting to a VPS for the first time.
FAQ: Intrusion Detection and Prevention
What is the actual difference between an IDS and an IPS?
An IDS (Intrusion Detection System) monitors traffic and server activity, identifies patterns matching known attacks, and generates an alert, but it does not take action to stop the traffic itself, a human or a separate system has to respond. An IPS (Intrusion Prevention System) does everything an IDS does, plus it sits inline with the traffic and can block or drop a connection automatically the moment it matches a malicious pattern, without waiting for anyone to react. The practical distinction: an IDS tells you something bad is happening, an IPS stops it from happening. Most hosting-focused security tools today (Imunify360, Wordfence's more aggressive modes) function as an IPS specifically because automatic blocking scales far better than alerting a human for every attempted attack, of which a public-facing site can see thousands per day.
What is the difference between network-based and host-based detection?
A network-based IDS or IPS (NIDS/NIPS) inspects traffic as it crosses the network, typically at a firewall or router level, looking at packet contents and connection patterns without regard to what is happening inside any individual server. A host-based IDS or IPS (HIDS/HIPS) runs on the server itself and monitors what is happening locally, file changes, process behavior, login attempts, log file contents, which lets it catch attacks that network-level inspection cannot see, such as a compromised WordPress plugin modifying files on disk after a legitimate-looking HTTP request already passed through. Effective hosting security typically layers both: network-level filtering to block obvious attack traffic before it reaches the server, and host-level monitoring to catch anything that gets through or originates from within (a compromised plugin, a stolen admin password).
What does Imunify360 actually do?
Imunify360, common on cPanel-based shared and VPS hosting, combines several of these functions into one product: a web application firewall (WAF) that filters malicious HTTP requests before they reach PHP, a host-based intrusion detection component that scans files for malware signatures and unexpected changes, a network-level component that blocks IPs showing brute-force or scanning behavior across the whole server (not just your account), and a patch management feature that can automatically fix certain known vulnerabilities in common software. It functions as an IPS for most of its detections, meaning it blocks in real time rather than only alerting, which is why it is a commonly cited feature on hosting plans marketed as having strong security.
Do I need to configure IDS/IPS myself on shared hosting?
No, on shared and most managed hosting, whatever intrusion detection and prevention system the host runs (Imunify360, or an equivalent) operates at the server or account level automatically, you do not install or configure it yourself, and in most cases you cannot disable it even if you wanted to, since it is protecting the shared server's other accounts as well as yours. On a self-managed VPS or dedicated server, this is entirely your responsibility, if you do not install and configure something like Fail2ban (a lightweight host-based intrusion prevention tool) or a commercial equivalent yourself, your server has no automated protection against brute-force login attempts or common attack patterns beyond whatever your web server and firewall do by default.
Can an IPS block legitimate traffic by mistake?
Yes, this is called a false positive, and it is the central tradeoff in tuning any IPS. A ruleset aggressive enough to catch subtle attacks will occasionally match legitimate traffic that happens to look similar, a security researcher's scanner, a legitimate but unusually-formed API request, or in rare cases, a real visitor whose behavior trips a rate-limiting rule during a traffic spike. Quality intrusion prevention systems include a whitelisting mechanism for exactly this reason, letting you or your host exempt specific IPs or request patterns once a false positive is identified. A system with zero false positives is almost certainly also missing real attacks, some false-positive rate is the normal cost of actually catching the attacks that matter.
Is a web application firewall the same thing as an IPS?
A web application firewall (WAF) is a specific, narrower category: it inspects HTTP requests specifically, looking for patterns associated with web application attacks (SQL injection attempts, cross-site scripting payloads, known WordPress plugin exploit signatures) and blocks matching requests before they reach your application code. This makes a WAF a type of IPS, but scoped specifically to the web application layer, rather than the broader network or host-level scope a full IPS might cover. In practice, most hosting security products (Imunify360, Wordfence, Sucuri) bundle a WAF alongside broader host and network-level protection, so the distinction matters more for understanding what a specific feature covers than as a meaningful product category difference.