RASP (Beta)

Runtime Application Self-Protection (RASP) is a security technology embedded directly within an application’s runtime environment. Unlike traditional perimeter-based defenses, RASP provides real-time protection by actively monitoring and analyzing application behavior during execution. This allows it to detect and block malicious activities with high precision. In the context of Monarx’s RASP, this solution integrates seamlessly into PHP environments, delivering deep visibility and fine-grained control over application execution.

A Web Application Firewall (WAF) operates at the network layer, inspecting incoming HTTP traffic to filter out malicious requests before they reach the application. While effective for broad-spectrum protection, a WAF lacks contextual awareness of the application’s internal behavior and can often be bypassed using techniques such as encryption, obfuscation, or encoding. By contrast, RASP runs within the application’s runtime, giving it unparalleled insight into what each request actually does once processed.

RASP Pros:

RASP Cons:

WAF Pros:

WAF Cons:

For PHP-based applications, Monarx’s RASP offers a compelling alternative or complement to a WAF, providing deeper, context-aware security tailored to the application’s runtime.

Monarx’s RASP delivers comprehensive analysis of web requests and PHP program execution, covering the entire lifecycle—from request initialization to the invocation of specific native PHP functions like shell_exec, file_put_contents, and others. By hooking into these function calls, RASP gains a distinct advantage over traditional security tools. Instead of speculating about a request’s intent, it operates as an integral part of the PHP runtime, ensuring no bypass is possible and providing exact visibility into what each function does. This enables real-time detection and blocking of malicious activities with minimal guesswork. RASP features are powered by various modules, each designed to complement the others and add layers of security and capabilities. These modules can be independently enabled or disabled based on user needs.

In modern vernacular, WAFs are often associated with a core set of security capabilities rather than their strict architectural definition. Common industry standards, such as ModSecurity and OWASP’s Core Ruleset, continue to shape these expectations.

During request initialization, Monarx’s RASP inspects payloads for signals of common OWASP-defined attacks, terminating malicious requests early in the process. This feature provides a tailored OWASP Core Ruleset capability set, optimized for Linux PHP runtime environments. It protects against a wide range of generic threats, including:

While the WAF module offers broad, OWASP-compatible protection against common attack patterns that might be leveraged in zero-day exploits, it may still encounter false positives or fail to address logical, access, or authorization vulnerabilities.

The Virtual Patching module enhances this protection by providing specific, tailored defenses against known, high-impact vulnerabilities in various frameworks and core CMS platforms like WordPress, Joomla, Drupal, Laravel, and more. Examples include:

This module delivers extensive protection against XSS, SQLi, RCE, XXE, LFI, and other threats tied to known vulnerabilities actively exploited in the wild, including logical, access control, and privilege escalation issues.

Building on Monarx’s Core AntiVirus (AV) product, RASP extends runtime protection to combat a variety of threats, including:

This feature strengthens PHP applications by enforcing security best practices, including:

In cybersecurity, “bots” refer to automated software programs or scripts designed to execute specific tasks over the internet, often at speeds and scales far beyond human capability. While some bots, like search engine crawlers, serve legitimate purposes, malicious bots pose significant risks—spamming, launching Denial of Service (DoS) attacks, delivering malware, or probing for vulnerabilities. Even benign bots, such as aggressive data scrapers, may be undesirable. Monarx’s RASP helps customers identify and manage these threats, though its scope can sometimes cause confusion. Here’s how it works.

Behavioral Analysis:
Malicious bots often exhibit distinct patterns that threaten system security, such as:

These behaviors are typically tied to a source IP address (e.g., “185.X.XX.XX”). However, equating an IP with a bot can be misleading. Bots are software running on servers, and their traffic may shift across multiple IPs over time. Conversely, legitimate human traffic might share an IP with a bot in shared network environments. Blocking large IP ranges risks disrupting legitimate users—a pitfall noted by industry leaders like Cloudflare (see Consequences of IP Blocking at

The unintended consequences of blocking IP addresses ). Even blocking a single IP based purely on activity can affect many users due to technologies like CGNAT, where a single public IPv4 address serves dozens, hundreds, or thousands of connections.

Moreover, these behaviors aren’t exclusive to bots—humans or manual scripts can perform similar actions. Monarx’s RASP mitigates threats like malware payloads, vulnerability exploits, and brute-force attacks regardless of origin (bot, script, or human), grouping them by behavior (e.g., “Exploits,” “WAF”) in the UI for actionable insights.

Self-Identification via User-Agent Strings:
Many bots—benign, malicious, or otherwise—announce their identity via user-agent strings in HTTP requests (e.g., Googlebot). In Monarx’s “Bots” category, we highlight automated programs that self-identify as known malicious bots (e.g., Zeus), flagging them proactively regardless of behavior. When “bots” appears in Monarx, it specifically refers to programs identifying as such via their user-agent strings.

Beyond Bots: A Layered Approach
While the “Bots” category focuses on self-identified malicious or undesirable bots, Monarx’s RASP goes further. The UI breaks down events into complementary categories—WAF, IP Blocking, Exploits (Anti-Malware), and Application Hardening—each tackling overlapping threats. For example:

This overlap is intentional—cybersecurity threats don’t fit neatly into silos. Monarx prioritizes mitigating impact over categorizing origins.

Why “Bots” Matters
The “Bots” category isn’t about catching every automated program—it’s a focused lens on self-identified malicious or undesirable bots posing clear risks. Meanwhile, RASP’s broader capabilities ensure protection against the full spectrum of threats. RASP targets requests based on user-agent strings:

Layer 7 (application-layer) IP blocking is tailored to mitigate threat actors targeting web-based applications. Monarx selectively blocks traffic from specific IP addresses when consistent malicious activity is detected, whether from bots, manual programs, or humans. This can mitigate certain DoS attacks.

In a web application context, a Denial of Service (DoS) attack seeks to disrupt normal functioning, making the service unavailable to legitimate users by overwhelming the application, server, or infrastructure. DoS attacks vary:

Monarx does not mitigate Distributed DoS (DDoS) attacks. However, it can address certain logic-based DoS attacks via Virtual Patching and some traffic-based DoS attacks via IP blocking. For comprehensive DDoS protection, a purpose-built, DNS-based solution like Cloudflare is recommended.

Monarx’s RASP activates whenever PHP is invoked, typically within web frameworks like Drupal, Joomla, Laravel, WordPress, or CLI applications. It does not engage in these scenarios:

Designed exclusively for PHP environments on Linux, RASP mirrors capabilities of tools like ModSecurity while tailoring its ruleset to PHP-specific threats. It offers minimal to no protection for:

Other limitations include:

Monarx’s RASP is delivered as an add-on to the Monarx PHP Zend extension, Monarx Protect. To enable it, ensure:

Proper setup is essential for effective operation. Monarx is generally compatible with existing WAF solutions.

Monitoring:
RASP activity can be monitored through the Monarx Web Application UI or accessed programmatically via Monarx APIs.

Handling False Positives: