DEV Community: openappsec

AWS WAF vs. open-appsec ML-Based open source WAF

openappsec — Thu, 15 Dec 2022 18:00:31 +0000

Written by: Rubaiat Hossain

Web application firewalls (WAFs) are the first layer of defense for protecting your apps or services from threat actors. Amazon Web Services (AWS) WAF is a popular choice due to its seamless integration with other AWS services as well as its ability to protect from a wide range of common attacks.

However, rule-based firewalls, like the one AWS offers, are only as secure as the rules they follow. As a result, traditional WAFs often fail to block sophisticated attacks faced by critical systems. In these cases, it's best to opt for an advanced WAF solution, like open-appsec. open-appsec uses an innovative machine learning (ML)–based threat engine that automatically prevents and blocks suspicious requests.

In this article, you'll compare these two WAFs based on their core feature set, installation experience, documentation quality, ease of use, and pricing and support.

Core Features

AWS WAF and open-appsec both offer a robust set of features for blocking malicious HTTP requests. However, each tool has certain features that the other lacks.

AWS WAF Features

AWS WAF is a security service from AWS that monitors and blocks suspicious traffic using a rule-based system. Rules in AWS WAF are definitions of how to parse the HTTP request for inspection and what to do when a rule matches. You can define rules for inspecting various parts of a web request, including the body, header, and cookie.

In addition, it uses signature-based threat detection to prevent many common web attacks, including SQL injections, cross-site scripting (XSS) attacks, distributed denial-of-service (DDoS) attacks, and botnets.

Traditional Threat Detection

AWS WAF's threat detection model can be effective against both regular and targeted attacks. However, signature-based detection models are reactive by design. As such, AWS WAF only detects known attack types and cannot protect from zero-day attacks. In addition, frequent rule updates are required to block newer threats.

Reliable Rule Sets

The effectiveness of rule-based WAFs depends mainly on the quality of the rules. Therefore, you need a strong rule set to protect your app from complex attacks. The managed rule sets that are included with AWS WAF offer some protection; however, you may still need to create a custom rule set that fits your specific use case.

You can buy these rule sets from the AWS Marketplace or supported partners. However, as you'll soon learn, managed services, like AWS WAF, can quickly become costly if you start purchasing premium add-ons.

Request Inspection with Rules

Another drawback of AWS WAF is that it doesn't support inspecting large chunks of the request body. Instead, it only checks the first 8 KB. This means that if an attacker knows this and includes the payload after the first 8 KB of the request, AWS WAF will not block it in default settings.

You can inspect oversize contents by specifying oversize handling in the component specification. But handling oversize content depends on various factors and must be done correctly. If you're using vendor-supported rules for AWS WAF, you'll need to tune the inspection levels accordingly.

Reliable Bot Control

The AWS WAF Bot Control mechanism provides adequate protection against bot attacks. For instance, it can detect standard and advanced bots based on their signature and heuristics. In addition, you can define rules to enforce various handling methods for bots, including rate limiting, CAPTCHA, and challenge actions.

Moreover, bot visibility is clear on the intuitive Bot Control dashboard, where you can easily block scrapers, crawlers, and other invasive bots. However, you'll need to pay additional fees for using the AWS WAF Bot Control managed rule group.

Fraud Control Prevention

AWS WAF Fraud Control can protect your app's login page from unauthorized sign-in attempts. It secures data and credentials using the managed AWS WAF rule group but also comes at an additional cost.

open-appsec WAF Features

open-appsec is a fully automated WAF solution for securing modern web services and APIs. It uses contextual ML to identify and detect malicious web requests preemptively. This means there's no need for manual rule enforcement or maintenance. Instead, the ML engine of open-appsec learns the behavior patterns of your users through continuous monitoring and uses this information to block anomalies.

Because open-appsec is ML-based, it doesn't need tuning or exception creation like AWS WAF. You can tune some parameters to speed up the learning phase of the contextual ML engine. But this isn't required for blocking common attacks.

Advanced Threat Detection

The default open-appsec installation can stop regular web attacks without additional configurations. In addition, unlike AWS WAF, open-appsec doesn't suffer from attacks that contain payloads after 8 KB of the request body.

Since open-appsec is preemptive by design, you can use it to protect your apps from a wide range of attacks, including OWASP Top Ten, zero-day, and bot attacks. The robust intrusion prevention system also readily protects against over 2,800 Common Vulnerabilities and Exposures (CVEs) without new updates, including severe threats like Log4Shell and Spring4Shell.

open-appsec also identifies and blocks automated bot attacks before intrusion or data theft can occur. In addition, its intuitive software-as-a-service (SaaS) WebUI makes threat visualization clear so you can mitigate problems more effectively.

Cloud-Native

The cloud-native design of open-appsec offers seamless integration with modern continuous integration, continuous delivery (CI/CD) tools.

You can automate everything from installation and upgrades to configuration management using simple APIs or declarative infrastructure as code (IaC). For deployment, you can choose from Helm charts, Kubernetes annotations, or Terraform.

Free and Open Source

Another key feature of open-appsec is that it's open source. Anyone can use this ML-based threat detection engine to protect their web apps and APIs for free.

Installation Experience and Documentation

While features can be beneficial, choosing the right WAF solution for you is more complex. You also need to take into account how the tool is installed, as well as what documentation is available.

To use AWS WAF, you need to set it up and create a web access control list (web ACL) using the AWS console. Then you need to choose the AWS resources that you want to protect and add rules and rule groups that you'll use for filtering traffic.

You can't associate your AWS WAF directly with Amazon EC2 or S3 instances. Instead, you need to associate your AWS WAF with an Application Load Balancer (ALB), which will forward the traffic to your web app.

AWS is a leader in the cloud industry and generally offers good documentation for its services. The AWS WAF documentation covers a broad range of topics, from initial setup to custom rule enforcement. Moreover, AWS also offers whitepapers to support its WAF users.

However, new AWS users may find the documentation too extensive and hard to follow. Some customers also report that they could use more detailed guides on how to best use the rules, as well as a more dedicated configuration process.

In contrast, you can deploy open-appsec as agents for Kubernetes Ingress, Nginx/Nginx Plus plugin, and Docker. Using the interactive command line tool, you can quickly install this WAF for Kubernetes and Nginx.

Advanced users can also use Kubernetes CustomResourceDefinitions (CRDs) for installation. The SaaS management portal makes connecting with deployed agents and managing assets and policies painless.

The open-appsec documentation contains detailed instructions on how to install and set up the WAF. In addition, you'll find information on everything needed to perform day-to-day operations. The reference materials also cover topics on writing Snort signatures and using an Event Query Language (EQL) for log visualization.

Ease of Use

For users with some cloud experience, AWS WAF is easy to use. All you need to get started is an AWS account. In addition, creating and configuring the ACL is also straightforward, thanks to the intuitive wizards.

However, since AWS WAF requires add-ons for additional features, managing this WAF will require a detailed understanding of the components. You'll also need to manage, update, and audit the rule sets to keep up with emerging threats.

In comparison, open-appsec also offers excellent usability, and getting started with this WAF is fast, thanks to its detailed, step-by-step documentation. The interactive CLI tool, open-appsec-ctl, makes deployment straightforward. Once deployed, you can use the centralized SaaS management UI to connect with the agents and set up assets and policies:

Visualization is available as a single-pane view of important security events. In addition, the monitoring dashboard is intuitive to use and displays valuable statistics about the attacks:

You can click the dashboard controls for in-depth details of events. The Event view gives a tabular view of the events and displays event cards highlighting the incident types, severity, assets under attack, and mitigation steps taken by open-appsec:

You can also filter events based on time ranges. This gives better visibility regarding individual attacks:

Pricing and Support

Cost is an essential factor when choosing a WAF solution. AWS WAF is a relatively cheap option compared to traditional WAF services, like F5 Advanced Web Application Firewall (WAF) and Kona Site Defender from Akamai. Users are charged based on the number of ACLs created, the number of rules in each group, and the volume of requests.

At the time of writing this article, the pricing for AWS WAF starts at $5 USD per ACL, $1 USD per rule, and $0.60 USD per million requests processed. In addition, you'll have to pay additional fees for AWS WAF Bot Control and AWS WAF Fraud Control services and any purchased rules. Moreover, if you want dedicated support, you need to sign up for a support plan with AWS, which will also increase the cost.

This pricing model can be a bit confusing for new AWS users. So you can use the AWS Pricing Calculator to get an idea of how much it would cost to protect your application with AWS WAF.

In contrast, open-appsec is a fully open source solution that offers all the core features, including the ML-based detection engine, for free, and this version is more than enough to get you started.

If you want more advanced protection and dedicated support, consider signing up for CloudGuard AppSec, the enterprise version of open-appsec. You can explore the available plans from their Pricing page.

Conclusion

AWS WAF and open-appsec are both great options for protecting your apps. They can detect and block many common attacks that would otherwise cause service disruption. However, both of these tools perform their tasks differently.

AWS WAF is a rule-based solution that integrates easily with other AWS services and offers managed and custom rules for effective blocking.

In contrast, open-appsec uses a modern, ML-based threat detection engine to detect attacks preemptively. This means that there's no need to write rules or manage them. Moreover, the proactive nature of open-appsec allows engineers to focus more on development than security. open-appsec also blocks many severe threats, like the Log4Shell and Spring4Shell vulnerabilities, in default settings.

How to protect Apps and APIs in Kubernetes from zero day attacks?

openappsec — Thu, 01 Dec 2022 21:45:16 +0000

Written by: Eze Onukwube

A zero-day attack is a cybersecurity incident that occurs when a hacker exploits a vulnerability before anyone else, including key stakeholders like the product vendor or developers, realize anything is wrong.

To counteract these attacks, you can use open-appsec, a fully automated, open-source web application firewall (WAF). As a cutting-edge cybersecurity tool, open-appsec prevents zero-day attacks through its preemptive web app and API protection that leverages the dynamism of continuous machine learning (ML). However, its ML-based engine isn't a signature-based solution.

This differentiates open-appsec from most security products on the market, especially antivirus, intrusion detection systems (IDS) and existing WAF solutions that rely on discerning threat signatures to detect malware and malicious code. As a result, open-appsec is ideal for remediating pen test results and protecting against zero-day and other Open Web Application Security Project (OWASP) Top 10 attacks such as broken access control, data integrity failures, authentication failures, and code injections.

In this article, you’ll learn about zero-day attacks and how to set up and use open-appsec to secure your web application.

open-appsec and ML

The key to open-appsec's ability to prevent zero-day attacks lies with its contextual ML engine.
It uses two machine ML models:

A supervised learning model that was trained offline based on millions of requests, both malicious and benign.
An unsupervised model to train itself in real time on incoming HTTP/S requests. This allows it to establish a baseline of what constitutes normal or benign traffic for a specific web application or API.

In order to enable an ML engine to quickly learn how an application is used, it should be allowed to run in learn/detect mode for two to three days. This typically provides ample time for the ML engine to train itself on a substantial amount of diverse traffic for better prediction accuracy.

As a result, open-appsec is able to detect suspicious patterns and anomalous behavior that is not in line with the web application or API's conventional traffic, unlike most WAFs that are typically rule-based. This equips the ML engine to detect zero-day attacks without having any prior knowledge of the attack vector, threat signature, or payload used. In addition, a security administrator can apply tuning suggestions to the ML engine to improve targeted accuracy.

Agents and Other Key Concepts of open-appsec

In this tutorial, you'll use agents to implement open-appsec. But before you begin this tutorial, let's talk a bit more about what an open-appsec agent is and what it does.

What Is an open-appsec Agent?

Agents are the primary means of deployment in open-appsec. They're ideal for any infrastructure due to their light digital footprint, minimal latency, and the fact that they don't alter the existing infrastructure.

The first step in implementing open-appsec for your application is deciding the type of agent deployment you want to use. In order to make an informed decision, it's imperative to understand how agents and their different deployment types work in open-appsec.

While agents are designed as standalone components, open-appsec also gives you the option to connect them to the software as a service (SaaS) management portal (more on this in the following sections).

Agents are generally deployed on any computing endpoint where client requests are received or routed such as a web server, reverse proxy, or Kubernetes Ingress. Because of this, the agent is best poised to detect and prevent malicious threats since the open-appsec core ML engine is designed to process incoming HTTP/S requests.

Agents are empowered to act as standalone entities since their security processing is done locally. However, they can be managed by a master SaaS component called a Fog. The Fog is responsible for logging in addition to configuration and software updates necessary for ML learning data synchronization between agents.

To further bolster security, agents communicate with the Fog only through encrypted and authenticated channels. When the Fog is unreachable for one reason or another, the agent is still capable of security enforcement. However, some administrative functions will be unavailable when the Fog is unattainable.

open-appsec aims for flexibility and it provides three agent deployment types: container, NGINX addon, and Kubernetes Ingress Controller.

Deploying an Agent Stand-Alone vs. Connected to the SaaS Management Portal

After you've deployed an open-appsec agent, you have the option of managing the deployment with the SaaS Central Management web user interface. If you choose to use SaaS Central Management, its portal allows you to centrally manage your open-appsec deployment with more flexibility and comfort.

However, there is a significant difference between deploying a standalone agent and deploying one connected to the SaaS management portal. While the former is adequate for implementing open-appsec security, the latter offers more to users with its multilayered functionality that provides granular control and oversight of several agent deployments.

With the SaaS management portal, you can edit your web application/API security settings from the convenience of a user-friendly web UI. In addition to policy editing, its web interface provides advanced situational awareness tools. This is a huge benefit, especially when you are managing large deployments:

As you can see, it provides three major hubs, namely: Protection, Central Management, and Situational Visibility. While deploying standalone open-appsec for Kubernetes Ingress provides effective protection, you have more opportunities and options when you connect to the management portal.

Implementing open-appsec for Your API or Web Application

The fastest way to set up open-appsec for K8s is through the interactive Kubernetes CLI tool. One of the best things about this tool is that it's easy to use, and guides you through most of the common customizations needed.

However, a certain amount of Kubernetes knowledge and system resources are needed before you can successfully install and run this interactive tool. According to open-appsec's documentation, the following are the prerequisites required to use the Kubernetes CLI tool:

An understanding of Kubernetes Ingress, in addition to knowing how to configure it or having previously deployed Ingress.
A Kubernetes 1.16.0+ cluster with role-based access control (RBAC) enabled cluster admin permissions.
Access to command line tools such as wget and kubectl on either a bastion host or a cloud platform that provides you with a Kubernetes cluster.
Helm 3, the Kubernetes package manager, installed on your local machine.

You can also peruse the open-appsec source code and information in this GitHub repo to gain more insight into the nuts and bolts of the system.

Deploying an Agent to Your Application

To download and run the open-appsec installer, you can set up open-appsec either in the Killercoda Playground (which is what you'll use her) or on your own Kubernetes cluster.

Please note: The information given and explained in this section (and subsequent ones) can be found in the official open-appsec documentation.

Setting Up open-appsec to Use the Kubernetes CLI Tool

Killercoda's Playground provides interactive environments. As its name implies, these playground environments can be used risk-free for quick and easy deployment and first hands-on experience with modern solutions like open-appsec in immediately available, ready-to-use environments.

You can launch open-appsec's Playground by navigating to Killercoda's website or by clicking on the Playground menu item on the SaaS portal:

If you haven't logged in, or if you don't have an open-appsec Playground account, you'll see an interface with various options to sign in or create an account, using either GitLab, GitHub, Google, or email:

The Playground provides you with a free, computing environment through a terminal in your browser. After you've successfully logged in and the Playground has finished initializing, you’ll see a terminal interface similar to this:

To begin using open-appsec, you need to download the install script and adjust its permissions:

wget https://downloads.openappsec.io/open-appsec-k8s-install && chmod +x open-appsec-k8s-install

If you're using the Playground, all you need to do is click on the link following Download open-appsec install script to activate the download:

Then, run the downloaded install script:

./open-appsec-k8s-install

If you're using the interactive Playground, you'll notice the script is run as ./open-appsec-k8s-install --prevent. However, in a live environment, you don't want to add the --prevent attribute since you'll want to start open-appsec in its learn-detect mode. This allows its ML engine to learn the traffic patterns of your application.

Once the install script has been successfully executed (it may take some time), you should see a message similar to this on the command line:

open-appsec for Kubernetes Ingress Installer v1.2232.1

Most likely, you'll see a variation of the current Kubernetes version that open-appsec is using.

After the Kubernetes installer version is displayed, a subsequent line will give you a heads-up and preview of what the installer will be doing next:

Below is a panoramic view of Playground after running the install script:

Adding the open-appsec Agent to Kubernetes Ingress

After downloading and running the installer, the next step involves adding open-appsec to either a duplicate of an existing Ingress or directly to an existing Ingress.

Immediately after the successful installation of open-appsec, the installer displays a table of the existing ingresses, detailing information pertaining to it:

As shown in a prior image depicting its successful installation, Playground then provides you with two options to apply to the existing Ingress:

Duplicate an existing Ingress and add open-appsec to it.
Add open-appsec to an existing Ingress resource.

The first option allows the existing Ingress to operate without disruption to traffic while you add open-appsec and conduct tests on the newly created Ingress. The second option merely adds open-appsec to the existing Ingress. Due to the risk of disruption, the second option is suited for testing purposes or use in a non-critical production environment.

Select the option that corresponds to your situation and you'll be prompted to enter both the name and namespace of the existing or duplicate Ingress.

The next step gives you the opportunity to change the Ingress' policy. The CLI displays the default policy rules of the current Ingress:

You have the option of using the default Ingress policy as it is or selecting other options. As you can see from the image below, some of the options presented include changing a rule, adding a rule, deleting a rule, or saving the current policy:

For instance, if you decide to change the rule of the default policy, and select option 1 (Change Rule in the previous screenshot), you’ll be asked to make further choices. You can choose to set a new name, namespace, Ingress rule, protection level, mode, or web response:

The final step of adding the open-appsec agent to Kubernetes Ingress applies the configuration options you selected in the previous two steps to either a manifest (YAML file) or a Helm chart. Finally, save your current policy by selecting one of those options:

When executed, the installer will apply your configuration to one of these three files:

The ingress.yaml file, which is the manifest created based on your instructions in the first step.
The open-appsec-policy.yaml file, which is created based on your selections in the second step.
The open-appsec Helm chart, which includes CRDs and other necessary files.

Because you selected to save your current policy, your setup should be saved to the open-appsec-policy.yaml file:

You may see something different depending on the prior options you chose.

Playground will then notify you it's time for the final configuration step. This is initiated when you execute the Run now option:

After you execute the run command, you will see the installation steps being executed (for open-appsec Helm chart, Ingress resource and the open-appsec policy custom resource):

Connect Your Deployment to the SaaS Web-Based Management

As its name suggests, the SaaS web-based management portal provides the convenience of a graphical UI interface along with sophisticated functionality to oversee, optimize, and control the security configuration of open-appsec deployed agents. You can also analyze all security logs in a flexible way. Before you can connect the deployed open-appsec agent to the SaaS web-based management portal, you'll be required to first create an account on it.

Creating an Account on the open-appsec Portal

To reach the open-appsec portal's main page, navigate to https://my.openappsec.io.

You should see a web form that asks you to create an open-appsec account using your Google, GitHub, or email account. Once you provide your credentials and are authenticated, you will be taken to the Getting Started page.

After you create and deploy an agent to protect a website or app, you have the option of connecting it to SaaS web-based management.

The SaaS-based management provides central policy editing using a web interface and other advanced situational awareness tools. These are huge benefits when managing large deployments.

Once you’ve logged in successfully, you'll be redirected to the home page. Once there, you need to confirm your agent has been deployed. Under the Protection box, check "I deployed an agent" which will enable the Central Management box:

Then, under Central Management, select Manage, and from the dropdown menu, select Kubernetes Profile:

This creates a Kubernetes profile that represents and controls the agents deployed in your cluster:

In order to create secure communication between your agent and the SaaS management, you need to connect to the SaaS application. Onscreen instructions might advise you to enforce the policy if you haven’t already done so:

Under Downloads & Deployment, you'll also see a message reiterating the need to enforce the policy (if you haven’t already done so). After this message, copy the commmand required to connect to your deployment from the Connect your deployment box, which contains the open-appsec token. This token connects your agents deployment to the newly created profile and creates a secure communication channel between the open-appsec deployment and the cloud:

Paste the command into the Kubernetes console, which could be Playground or your own Kubernetes setup. After it executes, your deployment can now be centrally managed in the SaaS portal.

Monitoring Cybersecurity Events after You Simulate an Attack

The best way to understand how open-appsec's event monitoring works is to simulate a cyber attack. This enables you to see how it chronicles threat protection and other relevant sequences of actions.

Fortunately, you don't have to come up with a cybersecurity incident on your own. Through the Playground, you can access open-appsec's Acme Audit application to simulate a SQL injection attack:

Validating open-appsec Protection and Events Monitoring After Attack Simulation

In open-appsec, event monitoring is done through the SaaS management portal. You need to have previously configured it with a deployed open-appsec agent protecting the website or the application. This is why, in the previous section, you used the Playground interactive environment to simulate an attack on the Acme Audit application.

As you can see from the following image, the SQL injection attack attack on the Acme Audit app failed, HTTP error 403 is shown indicating that open-appsec successfully prevented the threat:

This signals that the Kubernetes Ingress and its services were protected. However, it's also beneficial to see how the threat protection worked by viewing the actions and events generated by the attack.

To do this, log in to the SaaS portal and select Monitoring and the All Events tab. This will display the relevant actions triggered by the attack and its threat prevention:

As you can see, a table is displayed with rows containing all the events that occurred within a certain time range. It includes the timestamps of the individual events, along with their level of severity, source IP address, and several other details.

You can see that there was a critical severity event that occurred precisely on Oct 4, 2022, at 4:49:33 PM. It reports that the incident type was a SQL injection attack that was prevented.

When you scroll horizontally to the right across the table, you'll find other granular details that help you better understand the nature of the threat and attack vector used. For instance, the text command used for the SQL injection attack is revealed under the Matched String field, while HTTP URI Path shows the exploit was carried out during a login procedure:

Alternatively, you can select the Important Events tabs to display only those security events with critical and high severity. To target event types more narrowly, filters are activated by checking the box options you want to view:

Additionally, the portal provides you with a panoramic and graphical appsec dashboard through which you can access various sections with important security sections. These sections include security actions, overall HTTP traffic, malicious activity, attack levels, and top attacked assets. You can drill down for more information by clicking on individual sections.

Conclusion

ML-based threat prevention is the best and most practical defense against zero-day attacks. In this article you learned how to configure and deploy an open-appsec in Kubernetes. You also learned how to leverage open-appsec’s SaaS management portal as an effective agent monitoring dashboard to provide centralized logging, events analysis, and handling of multiple deployments in a scalable manner.

NGINX WAF alternatives: App Protect vs. ModSecurity vs. open-appsec

openappsec — Thu, 24 Nov 2022 21:02:30 +0000

Written by: Rubaiat Hossain

Nginx is a popular web server software that can also be used for caching, load balancing, and reverse proxying. Its asynchronous, event-driven architecture makes Nginx a good choice for high-traffic systems, which is the reason a lot of DevOps engineers and web developers choose to use it. However, having a high-performance web server is only helpful when you protect your web app accordingly.

This is where web application firewalls (WAFs) come into play. WAFs sit between your web app and its traffic, and they filter out malicious HTTP requests. A solid WAF solution can prevent various layer 7 attacks, including the OWASP Top Ten, bot attacks, and zero-day attacks.

Since Nginx has different use cases, protecting your application depends on how and where you use it. It's recommended that you have a reliable WAF solution since they block most harmful requests in the first place. In this article, you'll compare three tools—ModSecurity, F5 Nginx App Protect, and open-appsec—based on their active development, advanced security features, and open source commitment to help you figure out which tool is right for you.

ModSecurity

ModSecurity is an open source WAF that has been developed since 2002. It's proved to be a great success, and developers across the world use it.

Active Development

Before addressing ModSecurity's active development, it's important to define what the term active development means here. In this article, when a tool is reviewed based on its active development, it's in reference to the program having a continuous development effort and a committed community.

Effective July 1, 2024, Trustwave SpiderLabs, the developers behind ModSecurity, announced the end-of-life (EOL) support for this WAF. The open source community should continue the development of ModSecurity, as the code is freely available and many projects use it. However, commercial support will no longer be available after the EOL date.

ModSecurity v3 has also introduced major changes in how ModSecurity works. The entire WAF is not packed together anymore. Instead, the single libmodsecurity engine is paired with a connector module that interfaces the application with the server. Different connectors are available based on the server and are hosted as independent packages. This means that there's a separate ModSecurity v3 Nginx Connector project.

Advanced Security Features

Advanced security features of a WAF are the functionalities that set it apart. As a public-facing component of the internet, modern WAFs require solid defense mechanisms to protect from rapidly emerging new threads and malicious activities.

ModSecurity offers many powerful features, such as continuous inspection of HTTP streams, reliable blocking capabilities, and a robust rule engine complemented by a straightforward rule language called SecRule. What sets ModSecurity apart is its flexibility. You can use its features any way you see fit, from real-time application monitoring to full traffic logging, and URL encoding to web app hardening—the scope of creativity is unlimited.

Its solid HTTP blocking capabilities and flexible rule engine allow ModSecurity to patch vulnerabilities without touching the application itself. This practice is known as virtual patching, and it can protect any app using communication channels like HTTP. However, it should be noted that signature-based solution are reactive by nature, meaning that often signatures aren't available until after vulnerabilities have been known for some time and exploits are put into circulation.

ModSecurity also excels in logging HTTP requests. Since most web servers log a few pieces of information by default, ModSecurity's effective logging capabilities make it a lucrative choice from a security standpoint.

Open Source

ModSecurity is an open source project, with its codebase open for third-party contributions. It has an active GitHub community of open source developers who maintain the project and fix issues. You can easily fork this WAF and tune features yourself. However, with its backing organization announcing ModSecurity's end of support, you can expect little to no active development from the vendor in the future.

Nginx App Protect

Nginx App Protect is a premium WAF solution that seamlessly integrates with Nginx and provides robust features for DevOps teams. F5 has acquired Nginx and is actively developing its paid offerings. As a result, Nginx App Protect should be viable for those looking to safeguard enterprise systems and data.

Active Development

You can expect new features and updates to be added once every few months to Nginx App Protect for handling newer threats, and support is available on demand. Coupled with Nginx's extensive documentation and active community, finding support should be effortless for developers.

Advanced Security Features

Nginx App Protect is a capable WAF solution that can protect modern web applications, APIs, containers, and microservices. Nginx App Protect follows the same role-based access control policy used by ModSecurity. It benefits from the security rules derived from other F5 security solutions and excels at preventing regular layer 7 attacks. Like ModSecurity it is based on signatures and so usually reactive to zero day attacks as signatures aren't available until after vulnerabilities have been known for some time and exploits are put into circulation.

This WAF solution aligns with modern software architecture and continuous integration, continuous deployment (CI/CD) principles. The platform-agnostic nature and declarative policies used by Nginx App Protect allow engineers to focus on innovation rather than worrying about security right from the very beginning.

The Nginx Controller App Security allows to manage declarative configuration files for App Protect in a centralized manner. It makes managing Nginx App Protect simpler than ModSecurity, which, though immensely flexible, lacks central control.

Open Source

Nginx App Protect is a closed source solution. To use the WAF product, you'll need to sign up for a premium offering from F5 Nginx that includes NGINX Plus or NGINX Ingress Plus and a licence for App Protect. U.S. List Prices starts at $362 per month for Nginx Plus for Single Instance and Standard Support, plus $620 per month for the App Protect Add-On for Single Instance.

Although the enterprise nature of Nginx App Protect ensures prompt support and in-depth documentation, the absence of an open source model prevents DevOps engineers or developers from auditing the code themselves and diving deeper into the features.

open-appsec

open-appsec is a modern-day WAF solution that leverages machine learning (ML) to detect and prevent unknown "zero-day" attacks as well as standard known attacks.

Active Development

open-appsec is under active development, and the code is open source and public. This move allows for regular feature updates and bug fixes by open source developers. The core open-appsec WAF engine is developed in C++ and is available via GitHub.

Additional security components are written in C and Go and are readily available. The developers are actively adding new features and adjustments to the ML-based threat engine. In addition, the open source codebase is updated regularly and offers thorough documentation, making it a suitable choice for securing modern-day Nginx systems.

Advanced Security Features

open-appsec offers several advanced security features, of which the flagbearer is its ML-based threat detection engine. The ML-powered core automatically prevents OWASP Top Ten and zero-day attacks without requiring any tuning or configurations. The intelligent WAF engine continuously analyzes user behavior and transaction profiles to detect and mitigate threats before escalation.

This shift toward proactive threat mitigation from the reactive approaches utilized by standard rule-based WAFs makes open-appsec a worthy WAF solution for the future generation of web apps.

Moreover, open-appsec's seamless integration with modern CI/CD tools allows developers to spend less time securing apps and more time shipping new builds. It's also a breeze to automate. You can use declarative infrastructure as a service (IaaS) or APIs to take care of heavy tasks.

In addition, open-appsec needs little manual administration. It's an install-and-forget solution that preemptively prevents newer threats and reduces the attack surface significantly compared to traditional WAFs like ModSecurity, which require manual rule enforcement to stop the latest threats. Users of paid solutions like Nginx App Protect must also wait for vendor-supplied signaure/rules for newer vulnerabilities.

Open Source

open-appsec provides a fully open source solution that can be audited by third parties or extended by individual developers. As previously stated, the project is hosted on GitHub and has undergone rigorous auditing by independent security experts.

The code is easy to read and understand. You can also compile open-appsec with standard compilation tools, and it makes analyzing program behavior simple using traditional code analysis tools.

This WAF solution also meets the [security standards of the Open Source Security Foundation (OpenSSF), which indicates the high quality of the source material. The advanced machine learning model of this tool is also open source and available for download by anyone.

Conclusion

Nginx is one of the most widely used software for serving web content, proxying, and load balancing. However, you still need to secure your Nginx-consuming web apps from threat actors and malware. A solid WAF should be your first layer of defense, as they block harmful requests at the application layer.

In this article, you reviewed ModSecurity, Nginx App Protect, and open-appsec based on their active development, advanced security features, and open source principles.

ModSecurity is a robust solution that offers an advanced rule engine and an open source codebase. But it lacks active development commitments from the vendor. In contrast, Nginx App Protect is actively being developed and offers intelligent features and CI/CD integrations. However, it doesn't offer any open source edition.

open-appsec is the only WAF in this list that not only is under active development but also offers the solution as open source software. These, coupled with its advanced ML-based threat detection engine, make open-appsec a viable solution for modern web apps.

open-appsec NGINX WAF makes machine learning friendly using gamification

openappsec — Wed, 28 Sep 2022 00:31:53 +0000

In a previous blog we explained how open-appsec, an open source WAF project, is using machine-learning to preemptively block attacks against Web Apps & APIs.

Machine learning is often a black-box which is difficult to understand and track. open-appsec uses gamification in order to demonstrate the learning progress.

We developed a system that uses human understandable terms to describe the progress of learning as well as explanation as to what is needed in order to reach the next level.

Depending on amount and variance of traffic the machine learning engine will reach a stage where it has observed a sufficient amount of web requests to understand how the application is used. The faster this stage is reached, the faster detection is accurate and it is recommended to move to Prevent mode.

When the learning level becomes Graduate, it is recommended to change the Mode to Prevent. Graduate level ensures very good level of accuracy (e.g. low amount of false positives). To reach Master or PhD level is is necessary to configure Trusted Sources. The Phd level is the highest level, which means that more learning is less likely going to improve the model further.

To speed up the learning period the Contextual Machine Learning engine proposes tuning suggestions. The administrator can review the tuning suggestions and help the engine reach even better accuracy, a Machine Learning process also known as supervised learning.

We get nice feedbacks from users saying that this allows them to understands the status and what they are expected to do no next.

For additional details see here.

Kubernetes Ingress Security using Machine Learning

openappsec — Sat, 17 Sep 2022 19:20:54 +0000

open-appsec is an open-source initiative that builds on Machine Learning. It utilizes a three-phase approach for detecting and preventing web application and API attacks.

This blog explains how these three phases deliver accurate results with a very low amount of false positives and how they protect the environment against known and unknown zero-day attacks with real-time protection.

Phase 1 – Payload Decoding

Effective machine learning requires a deep understanding of the underlying application protocols which is continuously evolving. The engine analyzes all fields of the HTTP request including the URLs, HTTP headers, which are critical in this case, JSON/XML extraction and payload normalization such as base64 and other decoding's. A set of parsers covering common protocols feeds the relevant data into phase 2.
For example, in the case of Log4Shell attacks, some exploit attempts were using base64 and escaping encoding so it was possible to pass a space character for applying parameters.

Phase 2 – Attack Indicators

Following parsing and normalization, the network payload input is fed into a high-performance engine which is looking for attack indicators. An attack indicator is a pattern of exploiting vulnerabilities from various families. We derive these attack patterns based on on-going off-line supervised learning of huge number of payloads that are each assigned a score according to the likelihood of being benign or malicious. This score represents the confidence level that this pattern is part of an attack. Since combinations of these patterns can provide a better indication for an attack a score is also calculated for the combination of patterns.

For example, in the case of Log4Shell and Spring4Shell attacks, open-appsec used several indicators from Command Injection / Remote Code Execution / Probing families that signaled payloads to be malicious in a very high score which was enough on its own, but to ensure accuracy and avoidance of false positives, the engine always moves to the third and last phase.

Phase 3 – Contextual Evaluation Engine

This contextual engine is using machine learning techniques to make a final determination whether the payload is malicious, in the context of a specific customer/environment, user, URL and field that in a weighted function sums up to a confidence score. If the score is larger than the threshold the request is dropped.

These are the factors that are considered by the engine:

Reputation factor
In each request, the request originator is assigned a score. The score represents the originator’s reputation based on previous requests. This score is normalized and used to increase or decrease the confidence score.

Application awareness
Often modern applications allow users to modify web pages, upload scripts, use elaborate query search syntax, etc. These provide a better user experience but without application awareness, these are detected as malicious attacks. We use ML to analyze and baseline the underlying application’s behavior.
Learn user input format
The system can identify special user input types that are known to cause false detection and apply ML to modify our detection process and allow legitimate behavior without compromising attack detection.

False detection factor
If there is an inconsistency in detection a factor is applied to the confidence score based on the reputation factor per detection location.

Supervised learning module
Optional module that shows administrators payload and ask them to classify them thus accelerating the learning process.

Hello, world! about open-appsec beta program.

openappsec — Sun, 11 Sep 2022 18:50:53 +0000

Open-source has enabled the tech industry to creatively use, build, connect and innovate. Can you imagine a modern tech stack without open-source projects like Linux, Kubernetes, Kafka, Python, NodeJS, ElasticSearch, NGINX, Redis, MySQL, Mongo and numerous others?

In November 2002 Ivan Ristić, an English engineer, released a module for monitoring application traffic for Apache HTTP Server, known as ModSecurity or ModSec. A few years later, the module was released under an open-source license, and together with OWASP Core Rule Set (CRS) — a set of signatures for detecting web exploits, became the cornerstone of the entire WAF industry.

In 2022, many companies including Imperva, AWS, Microsoft, CloudFlare, Akamai, F5, NGINX and others are providing WAF products based on open-source ModSec concepts, signature-based technology and code.

Signature-based solutions are well proven, but they are reactive by nature, meaning that often signatures aren’t available until after vulnerabilities have been known for some time and exploits are put into circulation, as such they don’t provide good enough response for modern fast-spreading attacks. From an operational perspective they require constant tuning and exception handling to avoid false positives.

We are now starting open-appsec beta program — a new open-source initiative that builds on machine learning to provide enterprise web application and API security with the visibility, protection and manageability that is required by modern workloads.

open-appsec:

protects web applications & APIs preemptively against OWASP-Top-10- and zero-day attacks using patented machine learning with no threat signature upkeep
blocks attacks such as Log4Shell and Spring4Shell, with default settings and no updates, due to its pre-emptive nature
delivers precise threat prevention through continuous learning, finding attacks while eliminating the tuning & exception creation inherent to traditional WAFs
can be deployed as add-on to Kubernetes Ingress (Kubernetes WAF), NGINX (NGINX WAF), Envoy (Envoy WAF) and API Gateways and provides CI/CD-friendly deployment and automation — from installation to upgrades, to configuration — using declarative infra-as-code or APIs

The open-appsec program is now in initial beta exposure. You are welcome to learn about the project, read the documentation and test it in your environment.

We are working to make the code available on GitHub once we have additional community feedback.

Please join our community, share your feedback and thoughts.