diff --git a/docs/new/basic-configuration.md b/docs/new/basic-configuration.md index 08d9bbd8..ec0c7749 100644 --- a/docs/new/basic-configuration.md +++ b/docs/new/basic-configuration.md @@ -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: @@ -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. \ No newline at end of file diff --git a/docs/new/build-naxsi.md b/docs/new/build-naxsi.md index f30a5b98..3239826f 100644 --- a/docs/new/build-naxsi.md +++ b/docs/new/build-naxsi.md @@ -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 @@ -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.** ``` @@ -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: @@ -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). \ No newline at end of file +[Basic Configuration](basic-configuration.md). \ No newline at end of file diff --git a/docs/new/directives.md b/docs/new/directives.md index 030fb38a..3d24976c 100644 --- a/docs/new/directives.md +++ b/docs/new/directives.md @@ -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`. @@ -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: @@ -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: @@ -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: @@ -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: @@ -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. @@ -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: @@ -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`: @@ -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: diff --git a/docs/new/index.md b/docs/new/index.md index 4fbcbf8f..b5732425 100644 --- a/docs/new/index.md +++ b/docs/new/index.md @@ -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: @@ -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)