Managed WAF
Protect every layer.
With a team behind it.

An allowed request passes the host firewall and ModSecurity before reaching the application. The response returns over the same transport path.

TLS terminates at the web server for this deployment; this is not a DNS-to-CDN service.

Use IP reputation intelligence to block matching sources at the OS firewall before the web server and record an event for review.

Review trusted-source allowlists before enabling IPDB.

Configure IP, port, TCP/UDP and country rules for IPv4/IPv6, with temporary bans and reviewed allowlist precedence.

This example denies a source under a country rule; policies must match legitimate user locations.

Apply configured host firewall controls for SYN patterns and single-source DoS before traffic reaches the web server.

Host controls do not replace upstream scrubbing for attacks that saturate the network link.

Use bot source intelligence in firewall rules to limit unwanted AI crawlers and review exceptions for crawlers the business needs.

Separate from HTTP User-Agent checks; identification cannot cover every bot.

ModSecurity inspects requests for SQL injection and cross-site scripting patterns. A matching rule stops the request before the application and supplies a rule ID for false-positive review.

Application query handling and output encoding still need to be fixed.

Inspect HTTP requests for local/remote file inclusion and suspicious path traversal patterns using applicable rules.

Coverage depends on rules and application context; this does not scan server files.

Applicable WAF rules and upload scanning inspect PHP uploads or webshell patterns and block detected requests before application processing.

Upload scanning is an optional module requiring compatible web-server configuration; on-disk files are handled separately by the file scanner.

Evaluate and test available vulnerability rules to filter exploit requests while planning the application update.

Does not promise coverage of every CVE or zero-day and does not replace software patches.

Supported login protection can issue an external challenge. The web server validates the token and applicable rules before allowing application login processing; failed validation is denied.

Depends on the configured login module, supported login pages and external CAPTCHA provider.

Detect repeated login attempts and unwanted User-Agent patterns with supported modules, then apply denial or temporary bans under policy.

Review thresholds and exceptions; User-Agent alone does not authenticate a bot.

Watch for new or modified files in selected webroots and send them to the scanner independently of incoming HTTP traffic.

Real-time coverage follows configured watch paths and exclusions.

Combine signatures and AI-assisted detection, including team-defined custom signatures, to identify suspicious files and support handling decisions.

Findings may require operator confirmation; no scanner detects every malware variant.

Run manual, daily or weekly scans, including rescanning modified files with updated detection information.

Scan scope and schedule must fit file volume and server resources.

Select watched webroots, apply narrow exclusions and review custom signatures against actual application behavior.

Excluded files fall outside configured checks; record and review the reason.

After confirming infection, quarantine or clean according to module capability and policy. Supported CMS core files can be replaced with originals and rescanned.

Assess backup and application impact before file changes; cleanup is not automatically enabled for every account.

Inspect WordPress database content for malware signals beyond filesystem files, then review findings before remediation.

Requires supported WordPress access. Runs with directory scans or optional daily scans; CLI results are not saved in the portal.

Check supported CMS components against vulnerability information and verify file integrity to distinguish updates from unexpected modifications.

A CVE match does not prove compromise; validate the version and context.

Configure updates for supported CMS components under policy, with compatibility review, backup preparation and post-change website checks.

Updates follow agreed authorization and a rollback plan.

Monitor domain Safe Browsing status and IP DNSBL reputation so the team can investigate causes and plan remediation before requesting review.

Status monitoring does not guarantee delisting or inbox delivery.

Inspect suspicious processes and potential crypto miners, identify the related account and route findings for policy-based handling.

Stopping processes or suspending accounts follows agreed policy.

Use Lynis system auditing to identify hardening opportunities and prioritize recommendations for the server workload.

Findings are configuration recommendations, not compliance certification or automatic OS-wide changes.

Monitor outgoing mail and the mail queue for spam behavior or queue anomalies, associate senders with accounts and handle under policy.

Requires a supported cPanel / DirectAdmin / Webuzo mail stack. OSM must be enabled and thresholds configured; separate from inbound SRBL.

Check incoming SMTP source IPs against configured RBLs so the mail server can accept or deny under policy; this example shows a listed source.

This is not HTTP WAF inspection and does not promise that every accepted email is spam-free.

Inspect scheduled commands for suspicious patterns and identify the owning account before policy-based job handling.

Cron inspection is independent of web requests and must account for legitimate business jobs.

Move supported wp-cron execution from page-load triggers to configured server schedules for more predictable job timing.

Verify WordPress scheduled tasks after the change to avoid missed business jobs.

Review events and rule IDs against legitimate requests, scope exceptions narrowly, validate configuration/reload and test both business flows and retained protection.

Do not disable the entire WAF for a false positive; retain rationale and a rollback plan.

Bring findings and module status into a central dashboard, with on-server CLI tools for authorized administrators.

Dashboard logs are fetched from the server on demand with restricted access, not uploaded to central storage; CLI access is authorized.

Use supported scanner event hooks to connect notifications or team workflows with appropriate permissions and event fields.

Integrations are optional and require destination and access review.

Summarize configured findings, events and policy changes in reports or email digests so teams can track completed work and follow-up items.

Recipients, reporting cadence and report scope are agreed for the service.

When evidence meets agreed conditions, restrict or suspend an affected account under policy, verify the impact and plan service restoration.

This affects service availability; agree approval authority and restoration conditions in advance.