NAXSI is an open-source WAF for NGINX that uses whitelists to determine whether traffic should be authorized. Don’t think of it as some simple, ready-to-use IDS, though. You will need to generate the whitelists yourself, based on your own set-up.
Here is an excerpt of the description:
_NAXSI means Nginx Anti XSS & SQL Injection.
Technically, it is a third party nginx module, available as a package for many UNIX-like platforms. This module, by default, reads a small subset of simple (and readable) rules containing 99% of known patterns involved in websites vulnerabilities. For example, <, | or drop are not supposed to be part of a URI.
Being very simple, those patterns may match legitimate queries, it is Naxsi’s administrator duty to add specific rules that will whitelist those legitimate behaviours. The administrator can either add whitelists manually by analyzing nginx’s error log, or (recommended) start the project by an intensive auto-learning phase that will automatically generate whitelisting rules regarding website’s behaviour.
In short, Naxsi behaves like a DROP-by-default firewall, the only job needed is to add required ACCEPT rules for the target website to work properly._
Here’s how it works:
- Install it and set it to Learning Mode (which is the default)
- Logs will be appended to /var/log/nginx/error.log, with the “NAXSI_FMT” prefix. Let it run for a while (hours, days, weeks…)
- While you do that, set up an Elasticsearch instance and create an index called “nxapi”
- Alter nxapi.json to make it point to your Elasticsearch instance
- Feed all the generated logs into Elasticsearch:
- Generate whitelists and manually review them:
- Apply your reviewed whitelists and disable Learning Mode; you’re all set!
Now, I know… Using Elasticsearch simply to store the logs might seem a bit much, but using Postgres/MySQL apparently wasn’t so easy. Setting up an ES instance isn’t so hard anyway, I’ll write up an article about that.
The source for NAXSI can be found here: https://github.com/nbs-system/naxsi