Skip to content

Commit

Permalink
Change alerts in documentation (#145)
Browse files Browse the repository at this point in the history
  • Loading branch information
wargio authored Jun 15, 2024
1 parent eaf09cb commit 3f1b6eb
Show file tree
Hide file tree
Showing 4 changed files with 63 additions and 28 deletions.
9 changes: 6 additions & 3 deletions docs/new/basic-configuration.md
Original file line number Diff line number Diff line change
Expand Up @@ -52,7 +52,8 @@ server {

This configuration enables NAXSI and sets up basic rules for blocking requests based on various threat levels.

> [!IMPORTANT]
> 📣 Important
>
> The `SecRulesEnabled` directive is mandatory to enable NAXSI in a location.
Some key directives used in this example include:
Expand All @@ -64,8 +65,10 @@ Some key directives used in this example include:

Additionally, this configuration includes directives for enabling libinjection's XSS and SQLI detection features.

> [!WARNING]
> ⚠️ Warning
>
> **Be aware that Nginx will fail to load the configuration, if `ngx_http_naxsi_module.so` is not loaded**.
> [!TIP]
> 💡 Tip
>
> It is possible to test the NGINX configuration by using `nginx -t` from the command line.
19 changes: 12 additions & 7 deletions docs/new/build-naxsi.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,10 +8,12 @@ Ubuntu & Debian do not provide a package for this, but you can easily compile na

1. **Download the required software**

> [!INFO]
> ℹ️ Info
>
> Some Debian and Ubuntu distributions uses **`libpcre2-dev`** instad of `libpcre3-dev`.
> [!INFO]
> ℹ️ Info
>
> Debian bookworm requires also **`libperl-dev`**
```bash
Expand Down Expand Up @@ -90,7 +92,8 @@ The other files you will need, are **the rules**, which can be found at the foll
naxsi/naxsi_rules
```

> [!WARNING]
> ⚠️ Warning
>
> **Be aware that you may encounter the following error related to `libinjection`, which can be safely ignored.**
```
Expand All @@ -111,10 +114,12 @@ Using submodule libinjection

# **Compiling Naxsi from Sources**

> [!INFO]
> ℹ️ Info
>
> You will need to have a working C dev environment installed on your system, for tools like `gcc` or `clang` and `make`, in order to compile Naxsi.
> [!WARNING]
> ⚠️ Warning
>
> You will need to have `libpcre` or `libpcre2` or `libpcre3` installed to correctly build Naxsi.
To compile Naxsi from source code, follow these steps:
Expand Down Expand Up @@ -161,6 +166,6 @@ The other files you will need, are **the rules**, which can be found at the foll
naxsi/naxsi_rules
```

# Next Page
# Next

Next: [Basic Configuration](basic-configuration.md).
[Basic Configuration](basic-configuration.md).
51 changes: 34 additions & 17 deletions docs/new/directives.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,8 @@ This section explains all the directives, with examples, that are available when

## **SecRulesEnabled**

> [!NOTE]
> ℹ️ Info
>
> NGINX block: `location`
This directive is mandatory to `enable` naxsi in a NGINX `location`.
Expand All @@ -19,17 +20,20 @@ location / {

## **CheckRule**

> [!NOTE]
> ℹ️ Info
>
> NGINX block: `location`
This directive is required to instruct Naxsi on which action to take when there is a rule match.

The directive requires you to specify a **score** with a variable name and its min/max value (for example `$FOO_BAR >= 4`); the score is then followed by an action to take (`LOG`, `BLOCK`, `DROP`, or `ALLOW`) when is met.

> [!IMPORTANT]
> 📣 Important
>
> Score variable names must starts with a "dollar sign" `$` and can contains "underscores" `_`.
> [!WARNING]
> ⚠️ Warning
>
> The action `BLOCK` will behave like `DROP` only when `LearningMode` is not enabled.
### Example:
Expand All @@ -44,12 +48,14 @@ location / {

## **LibInjectionXss**

> [!NOTE]
> ℹ️ Info
>
> NGINX block: `location`
When defined, this directive enables [libinjection's](https://github.com/libinjection/libinjection) xss detection on *all* requests.

> [!IMPORTANT]
> 📣 Important
>
> The detected XSS will increase the score `$LIBINJECTION_XSS` by `1` for each match; this means that is required to define `$LIBINJECTION_XSS` as a `CheckRule`.
### Example:
Expand All @@ -65,12 +71,14 @@ location / {

## **LibInjectionSql**

> [!NOTE]
> ℹ️ Info
>
> NGINX block: `location`
When defined, this directive enables [libinjection's](https://github.com/libinjection/libinjection) sqli detection on *all* requests.

> [!IMPORTANT]
> 📣 Important
>
> The detected SQLi will increase the score `$LIBINJECTION_SQL` by `1` for each match; this means that is required to define `$LIBINJECTION_SQL` as a `CheckRule`.
### Example:
Expand All @@ -86,14 +94,16 @@ location / {

## **LearningMode**

> [!NOTE]
> ℹ️ Info
>
> NGINX block: `location`
This directive instructs Naxsi that to not honor `CheckRules` which defines actions as `BLOCK` in a NGINX `location`.

All the `BLOCK` actions will be interpreted as `LOG`; this is a useful mode when deploying a new web application and detect all false positives that might be generated by the WAF.

> [!IMPORTANT]
> 📣 Important
>
> Keep in mind that internal rules (those with an `id` inferior to 1000) will drop the request even in learning mode, because it means something fishy is going on and Naxsi can't correctly process the request. You can of course apply whitelists if those are false positives.
### Example:
Expand All @@ -107,7 +117,8 @@ location / {

## **DeniedUrl**

> [!NOTE]
> ℹ️ Info
>
> NGINX block: `location`
This directive is used to define where Naxsi has to redirect (it's an NGINX's internal redirect) when blocking, dropping or logging requests.
Expand All @@ -117,7 +128,8 @@ The following headers that are added are when blocking, dropping or logging requ
- `x-orig_args`
- `x-naxsi_sig`

> [!TIP]
> 💡 Tip
>
> It is **strongly** suggested to mark the `DeniedUrl` location as `internal` to prevent possible pre-detection of the WAF as per example.
### Example:
Expand All @@ -137,12 +149,14 @@ location /RequestDenied {

## **MainRule**

> [!NOTE]
> ℹ️ Info
>
> NGINX block: `http`
This directive is required to declare a **global** [rule](rules.md) or a [whitelist](whitelist.md).

> [!TIP]
> 💡 Tip
>
> You can define these within a config file and use the `include` directive to include them within the NGINX configuration.
You can find within the [Naxsi source code a list of global rules](https://github.com/wargio/naxsi/blob/main/naxsi_rules/) which provides a basic ruleset to protect any web application; these rules requires to include the following `CheckRules`:
Expand Down Expand Up @@ -170,15 +184,18 @@ http {

## **BasicRule**

> [!NOTE]
> ℹ️ Info
>
> NGINX block: `location`
This directive is required to declare a **location-specific** (i.e. not global) [rule](rules.md) or a [whitelist](whitelist.md).

> [!TIP]
> 💡 Tip
>
> You can define these within a config file and use the `include` directive to include them within the NGINX configuration.
> [!TIP]
> 💡 Tip
>
> You can find within the [Naxsi source code a list of location-specific whitelist](https://github.com/wargio/naxsi/tree/main/naxsi_rules/whitelists) which can be used for known web applications like Wordpress, Etherpad, Drupal, and more...
### Example:
Expand Down
12 changes: 11 additions & 1 deletion docs/new/index.md
Original file line number Diff line number Diff line change
@@ -1,8 +1,10 @@
# **Naxsi Web Application Firewall Documentation**

Naxsi is a Free Open Source Web Application Firewall which runs under NGINX.

## What is a Web Application Firewall (WAF)?

A Web Application Firewall (WAF) is a security system that sits in front of a web application to inspect, filter, and block malicious traffic. It acts as an intermediary between the internet and your website or web application, examining HTTP requests and responses for potential threats.
A Web Application Firewall (WAF) is a security system that sits in front of a web application to inspect, filter, and block malicious traffic. It acts as an intermediary between the internet and your website or web application, examining HTTP requests and responses for potential threats.

One of the key features of WAFs is virtual patching, which allows them to protect against known vulnerabilities without requiring actual patches to be applied to the underlying code. Here's how it works on Naxsi:

Expand All @@ -24,6 +26,14 @@ By using virtual patching, the system owner can:

These virtual patches are expressed in form of Naxsi rules and can be applied to RAW requests or specific fields within the request.

## What does it run on?

Naxsi should be compatible with any NGINX version, and is reported to work great on NetBSD, FreeBSD, OpenBSD, Debian, Ubuntu and CentOS based systems.

## Why is it different?

Contrary to most Web Application Firewalls, Naxsi doesn't rely on a signature base like an antivirus, and thus cannot be circumvented by an "unknown" attack pattern.

# Getting Started

* **Installing Naxsi**: [Learn how to compile and install Naxsi from source code.](build-naxsi.md)
Expand Down

0 comments on commit 3f1b6eb

Please sign in to comment.