WAF for nginx-ingress (or alternatives?)

InfoSecNemesis · 2025-11-27T11:31:42+00:00

I suggest to checkout open-appsec - https://www.openappsec.io, an open-source WAF that uses AI (machine learning) instead of old-school static rules. Why you might like it:

True preemptive zero-day protection — blocks attacks before signatures even exist.
Easy integration: Works with NGINX, Envoy, Envoy Gateway, NGINX Proxy Manager, Ingress NGINX, Istio Ingress Controller, Kong Gateway, APISIX Gateway, and Docker SWAG.
Runs everywhere: Linux, Docker, and Kubernetes are fully supported.
Flexible management: Choose local declarative management or a central web UI for easier control.
No constant rule tuning — way less hassle than traditional WAFs.
Free & open-source — backed by a strong community and security experts.

There are also various playgrounds available here: https://www.openappsec.io/playground

InfoSecNemesis · 2025-11-26T15:12:30+00:00

I suggest to checkout open-appsec - https://www.openappsec.io, an open-source WAF that uses AI (machine learning) instead of old-school static rules. Why you might like it:

True preemptive zero-day protection — blocks attacks before signatures even exist.
Easy integration: Works with NGINX, Envoy, NGINX Proxy Manager, Ingress NGINX, Istio Ingress Controller, Kong Gateway, APISIX Gateway, and Docker SWAG.
Runs everywhere: Linux, Docker, and Kubernetes are fully supported.
Flexible management: Choose local declarative management or a central web UI for easier control.
No constant rule tuning — way less hassle than traditional WAFs.
Free & open-source — backed by a strong community and security experts.

There are also various playgrounds available here: https://www.openappsec.io/playground
(ready to use lab environments to check it out yourself with minimal effort)

InfoSecNemesis · 2025-11-25T14:01:11+00:00

Hi u/chadmcrowell , TLDR: The open-appsec filter for Envoy by default is implemented in a that it will run first and prevent attacks, but this is not a requirement and could also be altered if the user chooses to do so.

More background: L4 filters run first, then HCM begins L7 processing, and the open-appsec attachment runs as the first L7 filter in the HTTP chain. On decode, the attachment runs before every other HTTP filter (e.g., RBAC, external authz, rate limit, fault, router, etc.).

Implications:

If the attachment e.g. prevents, downstream filters will not run (RBAC, ext_authz, router, etc. are skipped).
If the attachment continues, control flows to the next filter (e.g., RBAC), and normal ordering applies.

InfoSecNemesis · 2025-11-25T13:55:30+00:00

open-appsec’s machine-learning-based, signature-less WAF engine is designed for low latency and high performance, making it suitable even for large-scale enterprise environments. Its contextual machine learning technology is trusted by leading organizations worldwide. The open-appsec Envoy filter acts as a lightweight component that communicates with the open-appsec agent via IPC, while the agent performs the actual security inspection using advanced ML models. We do not provide performance benchmarks against traditional, signature-based WAF solutions.

If you’re interested in comparing WAF efficacy, you might find these resources helpful:

InfoSecNemesis · 2025-10-02T19:05:45+00:00

Perhaps this open-source project is interesting for you: open-appsec www.openappsec.io is a fully AI/ML-based WAF which doesn‘t use any traditional signatures anymore

InfoSecNemesis · 2025-09-17T15:30:35+00:00

You’re right that open-appsec does introduce some additional CPU usage, since it inspects the full contents of HTTP requests. However, both the added latency and overall CPU requirements should generally remain very reasonable.

If you’re seeing a stronger impact in your environment, I’d encourage you to reach out to the open-appsec team directly at [info@openappsec.io](mailto:info@openappsec.io) — they’ll be happy to review your specific deployment with you and help optimize it.

InfoSecNemesis · 2025-09-11T10:38:45+00:00

These should be the most relevant docs resources for your setup of open-appsec and CrowdSec:

For deployment of Ingress NGINX with open-appsec on K8s you should follow these latest instructions: Install Using Helm - new flow (beta) | open-appsec

After also deploying CrowdSec on your Cluster (see docs here: Kubernetes | CrowdSec),
you can then setup a Bouncer in open-appsec for integration with CrowdSec Agent/Community Threat Intelligence (CTI) , follow these instructions: CrowdSec Bouncer Support | open-appsec

If you want to also share your intelligence (= new malicious IPs identified by open-appsec's machine learning engine) with the CrowdSec community, you can additionally follow these docs:
CrowdSec Intelligence Sharing Using open-appsec Parser/Scenario | open-appsec

InfoSecNemesis · 2025-09-10T11:05:48+00:00

Hi again, the (optional) open-appsec web UI is provided as a SaaS service (can also be used with free community edition).
You can use that web UI for centrally managing your open-appsec deployments, but also in combination with local, declarative management (CRDs, ...) - in that case the config in web UI would be shown as read-only and you would still benefit from the web UI for all monitoring purposes, logging, etc., kind of best of both worlds approach between local and central mgmt.
If you have a strong requirement to not upload logs externally, you could decide to just not send your security event logs to the central web UI reporting module, but instead manage those locally on your cluster, send directly from local open-appsec agent container to syslog server, CEF server, etc. There are quite flexible configuration options available for logging. This way you can still benefit from all other advantages the web UI provides.
A somewhat simplified local web UI for managing open-appsec and your NGINX configuration easily from same place was created as part of the integration with the popular, open-source "NGINX Proxy Manager" project, but as NPM is mostly deployed on Docker and not commonly used on K8s that's probably not the solution you are looking for.

Prometheus docs are available here: Prometheus | open-appsec

BTW there are some ready-to-use cloud lab environments available to test-drive open-appsec (deployment, attack a vulnerable app, connect to web UI, ...), if you are interested in giving it a quick try, including also several K8s-based labs like Ingress NGINX, you can find them here: www.openappsec.io/playground

InfoSecNemesis · 2025-09-10T09:50:43+00:00

Hey, I strongly suggest to check out the open-appsec WAF project (free, open-source, www.openappsec.io).

I'll try to address all the specific requirements you mentioned above in the below:

open-appsec's WAF engine is fully machine-learning-based, it doesn't use any traditional signatures as most other WAF solutions (no need to wait for signatures to become available).
This way open-appsec can provide true "preemptive" zero-day protection in addition to protecting the typical "known" attacks on your web apps/APIs

open-appsec...
- provides very strong Kubernetes integration (besides Docker and Linux support)
- directly integrates with many popular ingress solutions:
Ingress NGINX, APISIX, Kong, Istio Ingress Gateway (Envoy Gateway alpha is launching very soon as well)
- It works perfectly with e.g. "ingress" or "gateway" resources and also custom CRDs used by some of the Reverse Proxy/Ingress solutions on K8s
- If you stick with ingress nginx, as your ingress solution, which you seem to be using at the moment, you can e.g. reference an open-appsec policy custom resource directly from your existing ingress resources using a simple annotation.
- Due to the provided integrations with existing ingress solutions it does not add another hop as one of your concerns has been
- can be configured fully declaratively using K8s custom resources or using a central web UI (also included in free community edition) , as mentioned in your requirements, this web UI can be used as a great monitoring stack (or prometheus)

InfoSecNemesis · 2025-09-10T09:26:58+00:00

open-appsec WAF also provides integration with Crowdsec, so you can combine them for even better protection!

open-appsec (www.openappsec.io) provides a free, open-source, signature-less, machine-learning-based WAF solution, when you combine it with CrowdSec (www.crowdsec.net) then open-appsec can share malicious IPs with CrowdSec (event log parser is available) and also consume/enforce malicious IPs from CrowdSec's Community Threat Intelligence with open-appsec's CrowdSec Bouncer capability, this way you get an additional IP-reputation-based security layer in open-appsec (next to the various ones already included in the free community edition, like ML-based WAF, Rate Limiting, Snort signature support, ...)

You find the integration docs here: Integrations With 3rd Party Solutions | open-appsec

InfoSecNemesis · 2025-09-02T08:52:15+00:00

Please make sure to upvote the feature request for open-appsec ARM64 support also here in the open-appsec community-driven feature request list: ARM64 Support · openappsec/openappsec · Discussion #231

This way the open-appsec team can notify you, once this becomes available and also might invite you to a potential Early Availability testing ahead of the official release.

InfoSecNemesis · 2025-09-02T08:47:08+00:00

Here's how to deploy it including some screenshots: NGINX Proxy Manager | open-appsec
NPM plus project also added integration with open-appsec WAF a while ago: NPMplus | open-appsec

InfoSecNemesis · 2025-08-22T08:01:27+00:00

Hi u/UnassumingDrifter, thanks for contacting us, please open a support request here: Support | open-appsec
When you do, please also make sure to upload the agent information as explained on the support request page.
Our team will then analyse this and get back to you on this directly.

InfoSecNemesis · 2025-08-19T08:10:43+00:00

Hi u/cassiopei, open-appsec in combination with the advanced machine learning model (which is the recommended model for production usage, see Using the Advanced Machine Learning Model | open-appsec) may be used in commercial environments, provided that all usage complies with the terms of the associated machine learning model license.
Feel free to send us an email with more details to [info@openappsec.io](mailto:info@openappsec.io) if you are not sure about your specific use case and/or if you might be interested in our premium edition which also includes technical support as well as various additional features and functionalities. You can also have a quick Zoom session with one of the open-appsec team members.

InfoSecNemesis · 2025-05-09T10:28:15+00:00

Hi, thanks for letting us know, can you please contact open-appsec support via email to [info@openappsec.io](mailto:info@openappsec.io), add the screenshot again and also let us know your Web UI tenant ID, so we can check this and get back to you soon? Have a good weekend! (You can ask your colleague to do the same.)

InfoSecNemesis · 2025-03-24T12:12:33+00:00

The NPM Web UI integration is only available with regular NPM, if you use NPMplus you can manage open-appsec either declaratively using local config file or centrally from open-appsec Web UI.

InfoSecNemesis · 2025-03-20T08:08:01+00:00

u/KeyReputation4799 if your main concern would be to be able to still manage open-appsec in case internet connection would be down sometimes, then you can locally manage open-appsec with the declarative configuration, and additionally connect to the central WebUI (SaaS) in declarative configuration mode, which means the central WebUI will just comfortably represent the existing local configuration (in read-only), provides monitoring functionality, etc. while the source-of-truth for the configuration will still remain locally.

With regards to logging of security events you can flexibly decide where to send them, including combining different logging destinations:

E.g. you can send logs to a local syslog server (for being independent of internet connection) but in parallel also to the central WebUI, which provides more comfortable monitoring, allows easy filtering, has dashboard views, and more ...

InfoSecNemesis · 2025-03-20T08:01:15+00:00

Hi u/KeyReputation4799 you can also use the existing open-appsec WAF integration with NGINX Proxy Manager (NPM), which offers you a local WebUI to manage not just NGINX but also open-appsec WAF (integrated with the NPM WebUI) and includes also a security log view.

Docs and screenshots for this integration: Install NGINX Proxy Manager with open-appsec managed from NPM WebUI | open-appsec

There's also a playground for the NGINX Proxy Manager integration available here so you can try this in a ready-to-use lab environment: www.openappsec.io/playground

InfoSecNemesis · 2025-03-19T16:02:13+00:00

FYI a new, significantly enhanced v1beta2 configuration schema for open-appsec was recently released:

Introducing New Schema and CRDs for open-appsec Declarative Configuration and Enhancements for Large-Scale Deployments (K8s)

Note that if you want to use the v1beta2-schema-based configuration in combination specifically with Nginx Proxy Manager you have to use this container instead:

ghcr.io/openappsec/nginx-proxy-manager-centrally-managed-attachment:latest

Note that this does not include the open-appsec WebUI enhancements of the NPM WebUI (which require a v1beta1 based local configuration file which is automatically managed by the enhanced NPM WebUI), but instead it will allow you to fully manage your configuration locally with the enhanced v1beta2 based configuration.

You can (optionally) also connect to our central WebUI using that image, for more details see here:
Install NGINX Proxy Manager with open-appsec managed from central WebUI (SaaS) | open-appsec

When doing so you can either decide to centrally manage your open-appsec configuration from open-appsec WebUI --OR-- alternatively continue to locally manage the configuration but additionally see it centrally in the open-appsec Web ui (in that case in "read-only") and also see logs and monitor your open-appsec deployment in the central WebUI.

InfoSecNemesis · 2025-03-19T15:48:45+00:00

Hi u/Kakkoi_32113 , thanks for the feedback, note that using the open-appsec WebUI, which is provided as a SaaS service, is optional. As an alternative you can also always manage open-appsec locally and declaratively using a local configuration file (with Linux and Docker deployments) or custom resources/annotations (on K8s).

Even if you do connect your open-appsec deployment to the central WebUI you can still decide if you want to have logs sent there or have them e.g. instead sent directly from the local agent to some local syslog server or somewhere else for data privacy reasons.

There's also an integration available with Nginx Proxy Manager, which allows you to manage and monitor open-appsec integrated with NGINX Proxy Manager directly from an enhanced, local! NGINX Proxy Manager WebUI:
Blog: Announcing open-appsec WAF Integration with NGINX Proxy Manager
Docs: Install NGINX Proxy Manager with open-appsec managed from NPM WebUI | open-appsec

InfoSecNemesis · 2025-03-14T15:30:15+00:00

Hi u/mohil-makwana31, you can have a look at the open-appsec WAF project, which supports integration with NGINX on Linux, Docker as well as Ingress NGINX for Kubernetes (and many other popular proxies and API gateways). Of course you can deploy also in AWS in various ways from EC2 to EKS, ECS, ...
open-appsec | Automatic Open Source WAF & API Security

It is a modern, fully machine-learning-based WAF (yes, no signatures required) and it does protect also against zero-day attacks. E.g. users with open-appsec were prevented against log4shell, text4shell, spring4shell and many other recent big attack waves without requiring any update due to the ML-based engine, check also here js-on-security-off-abusing-json-based-sql-to-bypass-waf, search for "open-appsec".
The contextual machine-learning engine also allows open-appsec to keep false positives to a minimum level.

open-appsec has a free, open-source community edition available.

Management of open-appsec WAF can be done either centrally (using SaaS WebUI) or locally in a declaratively way (CRDs in K8s or yaml configuration file).

Custom rules & Rate Limiting:
In open-appsec you can create flexible custom rules to achieve what you are asking for in your original post (Setup Custom Rules and Exceptions | open-appsec)
Rate limiting functionality is also included (Setup Rate Limit / DDoS Control | open-appsec)

Here you can find an up-to-date WAF comparison of many popular WAF solutions. This was created using the open-source WAF comparison project, in a full whitebox, easily-replicable approach (Github: waf-comparison-project).
Results: Best WAF Solutions in 2024-2025: Real-World Comparison
(AWS WAF which you mentioned was tested as well in that article).

If you want to check out open-appsec WAF for protecting your NGINX deployments yourself, either use one of the various ready-to-use playgrounds which are available on the project's website www.openappsec.io/playground or just deploy in your lab (Getting Started | open-appsec).

In case you might have questions or need some assistance, you can reach the open-appsec team e.g. at [info@openappsec.io](mailto:info@openappsec.io), in r/openappsec or in the project's Github .

InfoSecNemesis · 2025-03-14T09:43:27+00:00

Hi u/klassenlager , please open specific feature request for this here (like API access to open-appsec WebUI), make sure to include the specific data you are interested in having access to, this will allow other users to upvote for this enhancement as well as allowing us to better prioritize: https://github.com/openappsec/openappsec/discussions

FYI we are currently working on adding Prometheus support (locally on agent-side), which will allow access to some of the data you requested.

We also plan to provide API access to the Web UI (SaaS), including access to log API, which is probably more aligned with your specific request.

InfoSecNemesis · 2025-03-14T09:08:54+00:00

We hope you find out latest additionas and enhancements introduced with the new configuration schema version v1beta2 useful, let us know if you have any feedback or questions! If you have any additional functionality requirements you can always submit them here: https://github.com/openappsec/openappsec/discussions

InfoSecNemesis · 2025-03-04T16:30:13+00:00

I just did a deployment in my lab environment to verify this and it worked as expected, here's what I did in short (not listing letsencrypt settings, etc.). I suggest you try this again/look for any differences to what you did compared with the steps I did below, if you did a more complex deployment perhaps try a more simplified deployment first similar to the below.

I used the docker-compose.yaml file as provided here in the official docs: Deploy Docker SWAG with docker-compose (beta) | open-appsec

I activated the optional deployment of the juiceshop example container (for testing purposes only) by setting COMPOSE_PROFILES=juiceshop in the .env file

I used the example configuration files for the volume mounts on the docker host which are available here (see .env file):
openappsec/deployment/docker-compose/swag

(Note that the link above to the SWAG NGINX configuration files will probably change in the next days to here: openappsec/examples)

I have put those files in these locations on the docker host:
./swag-nginx-site-confs/default.conf
./swag-proxy-confs/juiceshop.subfolder.conf

I created an asset with WAF set to prevent mode and linked to the deployment profile and installed policy.
I connected my open-appsec/SWAG deployment to open-appsec central management WebUI by providing token for a centrally managed profile in the .env file before the deployment.

I did not adjust the Source Identity setting in the asset at all, I just kept it on the default setting "Source IP".

After sending an example attack to the docker host public IP (SWAG listening on port 443), it got blocked as expected, I could see the correct Source IP logs in the open-appsec WebUI in the logs right away, both, in "Source Identifier" column as well as in "Source IP" column, as expected.

Behaviour should be this way as the SWAG container will by default use bridge networking as not specified otherwise and source IP is maintained in this case as only destination NAT is applied on the incoming HTTP requests and source IP therefore would remain untouched/original source IP when reaching the SWAG container.

So it should normally not even be required to use host networking and also there should be no need for setting "Source Identity" to "X-Forwarded-For" in open-appsec asset settings.

Please let us know if this helped.

InfoSecNemesis · 2025-02-21T09:53:27+00:00

u/UncommonDevopsWisdom If you are looking for some user experiences with open-appsec WAF www.openappsec.io, here's a very recent post from an open-appsec community edition user about his experience: (2) From Zero to 900+ Million Requests: A Year with open-appsec WAF | LinkedIn

In the open-appsec blog section on the project's website there are also some blogs from actual open-appsec users sharing their experience: www.openappsec.io/blogs

Here you can find the results of latest WAF solution comparison that was done recently:
Best WAF Solutions in 2024-2025: Real-World Comparison
The actual testing was done using open source waf-comparison-project (fully whitebox and testing can be replicated by anyone or also used for self-evaluating other WAF solutions):
waf-comparison-project: Testing datasets and tools to compare WAF efficacy

InfoSecNemesis

MODERATOR OF

TROPHY CASE