Comment installer et configurer Naxsi sur Ubuntu 14.04

introduction

Naxsi est un module tiers Nginx qui fournit des fonctionnalités de pare-feu pour applications Web. Il renforce la sécurité de votre serveur Web et vous protège de diverses attaques Web telles que les injections XSS et SQL.

Naxsi est flexible et puissant. Vous pouvez utiliser des règles facilement disponibles pour les applications Web populaires telles que WordPress. Dans le même temps, vous pouvez également créer vos propres règles et les affiner en utilisant le mode d’apprentissage de Naxsi.

Naxsi est similaire à ModSecurity for Apache . Ainsi, si vous connaissez déjà ModSecurity et / ou recherchez des fonctionnalités similaires pour Nginx, Naxsi vous intéressera certainement. Cependant, il se peut que vous ne trouviez pas toutes les fonctionnalités de ModSecurity dans Naxsi.

Ce didacticiel explique comment installer Naxsi, comprendre les règles, créer une liste blanche et où trouver les règles déjà écrites pour les applications Web couramment utilisées.

Conditions préalables

Avant de suivre ce didacticiel, assurez-vous de remplir les conditions préalables suivantes:

Une goutte Ubuntu 14.04
Un utilisateur sudo non root. Consultez la page https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-14-04 (Configuration initiale du serveur avec Ubuntu 14.04] pour plus de détails.

Sauf indication contraire, toutes les commandes nécessitant des privilèges root dans ce tutoriel doivent être exécutées en tant qu’utilisateur non root avec des privilèges sudo.

Étape 1 - Installation de Naxsi

Pour installer Naxsi, vous devez installer un serveur Nginx compilé avec ce dernier. Pour cela, vous aurez besoin du paquet + nginx-naxsi +. Vous pouvez l’installer de la manière habituelle Ubuntu avec la commande + apt-get +:

sudo apt-get update
sudo apt-get install nginx-naxsi

Cela installera Naxsi avec Nginx et toutes ses dépendances. Il s’assurera également que le service démarre et s’arrête automatiquement sur le droplet.

L’installation par défaut de Nginx fournit un environnement Nginx fonctionnel de base, suffisant pour se familiariser avec Naxsi. Nous ne passerons pas de temps à personnaliser Nginx, mais à passer directement à la configuration de Naxsi. Toutefois, si vous n’avez aucune expérience de Nginx, il est judicieux de consulter How To Installez Nginx sur Ubuntu 14.04 LTS et ses articles associés, en particulier https://www.digitalocean.com/community/tutorials/how-to-set-up-nginx-server-blocks-virtual-hosts-on-ubuntu-14 -04-lts [Comment configurer des blocs de serveur Nginx (hôtes virtuels) sur Ubuntu 14.04 LTS].

Étape 2 - Activer Naxsi

Premièrement, pour activer Naxsi, nous devons charger ses règles de base trouvées dans le fichier + / etc / nginx / naxsi_core.rules +. Ce fichier contient des signatures génériques pour détecter les attaques malveillantes. Nous discuterons de ces règles plus en détail ultérieurement. Pour le moment, nous allons simplement inclure les règles dans le fichier de configuration principal de Nginx + / etc / nginx / nginx.conf + dans la partie écouteur HTTP. Alors, ouvrez ce dernier fichier pour le modifier avec nano:

sudo nano /etc/nginx/nginx.conf

Recherchez ensuite la section + http + et décommentez la partie include pour les règles de Naxsi en supprimant le caractère + # + au début de la ligne. Cela devrait maintenant ressembler à ceci:

/etc/nginx/nginx.conf

http {
...
       # nginx-naxsi config
       ##
       # Uncomment it if you installed nginx-naxsi
       ##


...

Enregistrez le fichier et quittez l’éditeur.

Deuxièmement, nous devons activer les règles précédentes et configurer certaines options de base pour Naxsi. Par défaut, la configuration de base Naxsi se trouve dans le fichier + / etc / nginx / naxsi.rules +. Ouvrez ce fichier:

sudo nano /etc/nginx/naxsi.rules

Remplacez uniquement la valeur de + DeniedUrl + par un fichier d’erreur qui existe déjà par défaut et laissez le reste inchangé:

/etc/nginx/naxsi.rules

# Sample rules file for default vhost.
LearningMode;
SecRulesEnabled;
#SecRulesDisabled;


## check rules
CheckRule "$SQL >= 8" BLOCK;
CheckRule "$RFI >= 8" BLOCK;
CheckRule "$TRAVERSAL >= 4" BLOCK;
CheckRule "$EVADE >= 4" BLOCK;
CheckRule "$XSS >= 8" BLOCK;

Enregistrez le fichier et quittez.

Voici les directives de configuration d’en haut avec leur signification:

+ LearningMode + - Démarre Naxsi en mode apprentissage. Cela signifie qu’aucune demande ne sera réellement bloquée. Seules les exceptions de sécurité seront générées dans le journal des erreurs Nginx. Un tel comportement initial non bloquant est important car les règles par défaut sont plutôt agressives. Plus tard, en fonction de ces exceptions, nous allons créer une liste blanche pour le trafic légitime.
+ SecRulesEnabled + - Activer Naxsi pour un bloc / emplacement de serveur. De même, vous pouvez désactiver Naxsi pour un site ou une partie de site en supprimant la mise en commentaire de + SecRulesDisabled +.
+ DeniedUrl + - URL à laquelle les demandes refusées seront envoyées en interne. C’est le seul paramètre que vous devriez changer. Vous pouvez utiliser la page d’erreur + 50x.html + immédiatement disponible qui se trouve à la racine du document par défaut (+ / usr / share / nginx / html / 50x.html +), ou vous pouvez créer votre propre page d’erreur personnalisée.
+ CheckRule + - Définissez le seuil pour les différents compteurs. Une fois ce seuil franchi (par ex. 8 points pour le compteur SQL) la demande sera bloquée. Pour rendre ces règles plus agressives, diminuez leurs valeurs et inversement.

Le fichier + naxsi.rules + doit être chargé par emplacement pour un bloc de serveur. Chargerons-le pour l’emplacement racine (+ / +) du bloc serveur par défaut. Commencez par ouvrir le fichier de configuration du bloc serveur + / etc / nginx / sites-enabled / default +:

sudo nano /etc/nginx/sites-enabled/default

Ensuite, trouvez l’emplacement racine + / + et assurez-vous qu’il ressemble à ceci:

   location / {
           # First attempt to serve request as file, then
           # as directory, then fall back to displaying a 404.
           try_files $uri $uri/ =404;
           # Uncomment to enable naxsi on this location

   }

Une fois que vous avez apporté les modifications ci-dessus, vous pouvez recharger Nginx pour que les modifications prennent effet:

sudo service nginx reload

L’étape suivante explique comment vérifier si les modifications ont abouti et comment lire les journaux.

Étape 3 - Vérification des journaux

Pour vous assurer que Naxsi fonctionne, même en mode apprentissage, donnons accès à une URL qui devrait renvoyer une exception et surveillons le journal des erreurs.

Nous verrons plus tard comment cette règle fonctionne exactement. Pour l’instant, le journal des erreurs de Nginx cherche l’exception (l’option + -f + maintient la sortie ouverte et y ajoute un nouveau contenu:

sudo tail -f /var/log/nginx/error.log

Essayez d’accéder à votre Droplet à l’URL + http: ///index.html? Asd = ---- +. Cela devrait déclencher une exception de sécurité Naxsi à cause des tirets, utilisés pour les commentaires en SQL et donc considérés comme des parties d’injections SQL.

Dans la sortie de + sudo tail -f / var / log / nginx / error.log +, vous devriez maintenant voir le nouveau contenu suivant:

Output of nginx's error log2015/11/14 03:58:35 [error] 4088#0: *1 NAXSI_FMT: ip=X.X.X.X&server=Y.Y.Y.Y&uri=/index.html&learning=1&total_processed=24&total_blocked=1&, client: X.X.X.X, server: localhost, request: "GET /index.html?asd=---- HTTP/1.1", host: "Y.Y.Y.Y"

La partie la plus importante de la ligne ci-dessus est mise en surbrillance: + zone0 = ARGS & id0 = 1007 & nom_var_0 = asd +. Il vous donne la zone (la partie de la requête), l’identifiant de la règle déclenchée et le nom de la variable de la requête suspecte.

En outre, + X.X.X.X + est l’adresse IP de votre ordinateur local et + Y.Y.Y.Y + est l’adresse IP de votre droplet. L’URI contient également le nom de fichier de la requête (+ index.htm +), le fait que Naxsi fonctionne toujours en mode d’apprentissage (+ learning = 1 +) et le nombre total de toutes les requêtes traitées (`+ total_processed = 24 + `).

De plus, juste après la ligne ci-dessus, un message concernant la redirection vers le + DeniedUrl + devrait suivre:

Output of nginx's error log2015/11/14 03:58:35 [error] 4088#0: *1 rewrite or internal redirection cycle while internally redirecting to "/50x.html" while sending response to client, client: X.X.X.X, server: localhost, request: "GET /favicon.ico HTTP/1.1", host: "Y.Y.Y.Y", referrer: "http://Y.Y.Y.Y/index.html?asd=----"

Lorsque Naxsi est en mode d’apprentissage, cette redirection n’apparaîtra que dans les journaux, mais ne se produira pas réellement.

Appuyez sur + CTRL-C + pour quitter + tail + et arrêter la sortie du fichier journal des erreurs.

Plus tard, nous en apprendrons davantage sur les règles de Naxsi, puis il sera important d’avoir cette compréhension de base des journaux.

Étape 4 - Configuration des règles Naxsi

La partie la plus importante de la configuration de Naxsi réside dans ses règles. Il existe deux types de règles: les règles principales et les règles de base. Les règles principales (identifiées par + MainRule +) sont appliquées globalement pour le serveur et font donc partie du bloc + http + de la configuration principale de Nginx. Ils contiennent des signatures génériques pour détecter les activités malveillantes.

Les règles de base (identifiées par + BasicRule +) sont principalement utilisées pour la mise en liste blanche des signatures et règles faussement positives. Ils sont appliqués par emplacement et devraient donc faire partie de la configuration du bloc serveur (vhost).

Commençons par les règles principales et examinons celles par défaut fournies par le paquetage + nginx-naxsi + dans le fichier + / etc / nginx / naxsi_core.rules +. Voici un exemple de ligne:

/etc/nginx/naxsi_core.rules

...
MainRule "str:--" "msg:mysql comment (--)" "mz:BODY|URL|ARGS|$HEADERS_VAR:Cookie" "s:$SQL:4" id:1007;
...

A partir de la règle ci-dessus, nous pouvons définir les parties suivantes, qui sont universelles et présentes dans chaque règle:

+ MainRule + est la directive avec laquelle commencer chaque règle. De même, chaque règle se termine par son numéro d’identification.
+ str: + se trouve dans la deuxième partie de la règle. Si c’est + str: + cela signifie que la signature sera une chaîne simple, comme dans l’exemple ci-dessus. Les expressions régulières peuvent également être associées à la directive + rx: +.
+ msg: + donne quelques précisions sur la règle.
+ mz: + représente la zone de correspondance ou la partie de la demande qui sera inspectée. Cela pourrait être le corps, l’URL, les arguments, etc.
+ s: + détermine le score qui sera attribué lorsque la signature sera trouvée. Les scores sont ajoutés à différents compteurs tels que + SQL + (attaques SQL), + RFI + (attaques par inclusion de fichiers distants), etc.

La règle ci-dessus (+ id 1007 +) avec le commentaire + mysql comments + signifie que si la chaîne + - + est trouvée dans une partie quelconque d’une requête (corps, arguments, etc.), 4 points sera ajouté au compteur SQL.

Si nous revenons à l’exemple d’URI (+ http: ///index.html? Asd = ---- +) qui a déclenché l’exception SQL dans le journal, vous remarquerez que pour déclencher la règle 1007, il nous fallait 2 paires de tirets (+ - +). En effet, pour chaque paire, nous obtenons 4 points et la chaîne SQL nécessite 8 points pour bloquer une requête. Ainsi, une seule paire de tirets ne poserait pas de problème et, dans la plupart des cas, le trafic légitime n’en souffrirait pas.

Une directive de règle spéciale est + négatif +. Il applique les scores si la signature ne correspond pas, c.-à-d. vous suspectez une activité malveillante lorsque quelque chose manque dans la demande.

Par exemple, regardons la règle avec + id 1402 + du même fichier + / etc / nginx / naxsi_core.rules +:

/etc/nginx/naxsi_core.rules

...
MainRule negative "rx:multipart/form-data|application/x-www-form-urlencoded" "msg:Content is neither mulipart/x-www-form.." "mz:$HEADERS_VAR:Content-type" "s:$EVADE:4" id:1402;
...

La règle ci-dessus signifie que 4 points seront ajoutés au compteur EVADE si l’en-tête de la requête + Content-type + n’a ni + multipart / form-data +, ni + application / x-www-form-urlencoded + dedans . Cette règle est également un exemple de la manière dont les expressions régulières (+ rx: +) peuvent être utilisées pour la description de la signature.

Étape 5 - Règles de la liste blanche

Les règles par défaut de Naxsi vont probablement bloquer un trafic légitime sur votre site, en particulier si vous utilisez une application Web complexe prenant en charge une grande variété d’interactions entre utilisateurs. C’est pourquoi il existe des listes blanches pour résoudre de tels problèmes.

Les listes blanches sont créées avec le deuxième type de règles, les règles de base de Naxsi. Avec une règle de base, vous pouvez ajouter à la liste blanche une règle entière ou des parties de celle-ci.

Pour illustrer le fonctionnement des règles de base, revenons à la règle de commentaire SQL (id 1007). Imaginez que vous avez un fichier avec deux tirets dans le nom du fichier, par exemple. + some - file.html + sur votre site. Avec la règle 1007 en place, ce fichier augmentera le compteur SQL de 4 points. Ce nom de fichier seul et le score obtenu ne suffisent pas pour bloquer une demande, mais il s’agit toujours d’un faux positif qui pourrait poser problème. Par exemple, si nous avons également un argument avec deux tirets, la demande déclenchera la règle 1007.

Pour le tester, réduisez le journal des erreurs comme auparavant:

sudo tail -f /var/log/nginx/error.log

Essayez d’accéder à + http: ///some—file.html? Asd = - +. Vous n’avez pas besoin d’avoir ce fichier sur votre site Web pour le test.

Vous devriez voir une exception familière semblable à celle-ci dans la sortie du journal des erreurs:

Output of nginx's error log2015/11/14 14:43:36 [error] 5182#0: *10 NAXSI_FMT: ip=X.X.X.X&server=Y.Y.Y.Y&uri=/some--file.html&learning=1&total_processed=10&total_blocked=6&zone0=URL&id0=1007&var_name0=&zone1=ARGS&id1=1007&var_name1=asd, client: X.X.X.X, server: localhost, request: "GET /some--file.html?asd=-- HTTP/1.1", host: "Y.Y.Y.Y"

Appuyez sur + CTRL-C + pour ne plus afficher la sortie du journal des erreurs.

Pour remédier à ce faux positif, nous aurons besoin d’une liste blanche ressemblant à celle-ci:

BasicRule :1007 "mz:URL";

Le mot clé important est + wl + pour la liste blanche, suivi de l’ID de la règle. Pour être plus précis sur notre liste blanche, nous avons également spécifié la zone de correspondance - l’URL.

Pour appliquer cette liste blanche, créez d’abord un nouveau fichier pour les listes blanches:

sudo nano /etc/nginx/naxsi_whitelist.rules

Ensuite, collez la règle dans le fichier:

/etc/nginx/naxsi_whitelist.rules

BasicRule wl:1007 "mz:URL";

Si vous avez d’autres listes blanches, elles peuvent également figurer dans ce fichier, chacune sur une nouvelle ligne.

Le fichier avec les listes blanches doit être inclus dans votre bloc serveur. Pour l’inclure dans le bloc serveur par défaut, utilisez à nouveau nano:

sudo nano /etc/nginx/sites-enabled/default

Ajoutez ensuite le nouvel include juste après le précédent pour Naxsi comme ceci:

/ etc / nginx / sites-enabled / default

       location / {
               # First attempt to serve request as file, then
               # as directory, then fall back to displaying a 404.
               try_files $uri $uri/ =404;
               # Uncomment to enable naxsi on this location
               include /etc/nginx/naxsi.rules;

       }

Pour que cette modification soit prise en compte, rechargez Nginx:

sudo service nginx reload

Maintenant, si vous réessayez la même requête dans votre navigateur pour indiquer + / some - file.html? Asd = - +, seul le paramètre + asd + égalant deux tirets déclenchera 4 points pour le compteur SQL, mais le paramètre peu commun le nom de fichier ne sera pas. Ainsi, vous ne verrez pas cette demande dans le journal des erreurs comme une exception.

Écrire toutes les listes blanches nécessaires peut être une tâche fastidieuse et une science en soi. C’est pourquoi, au début, vous pouvez utiliser les listes blanches immédiatement disponibles Naxsi. Il en est ainsi pour la plupart des applications Web populaires. Il vous suffit de les télécharger et de les inclure dans le bloc serveur comme nous venons de le faire.

Une fois que vous vous êtes assuré de ne voir aucune exception pour les demandes légitimes dans le journal des erreurs, vous pouvez désactiver le mode d’apprentissage de Naxsi. Pour cela, ouvrez le fichier + / etc / nginx / naxsi.rules + avec nano:

sudo nano /etc/nginx/naxsi.rules

Mettez en commentaire la directive + LearningMode + en ajoutant le caractère + # + devant lui, comme suit:

/etc/nginx/naxsi.rules

...
LearningMode;
SecRulesEnabled;
#SecRulesDisabled;
...

Enfin, rechargez Nginx pour que la modification soit prise en compte:

sudo service nginx reload

Désormais, Naxsi bloquera toute demande suspecte et votre site sera plus sécurisé.

Conclusion

C’est comme cela qu’il est facile d’avoir un pare-feu d’applications Web avec Nginx et Naxsi. C’est suffisant pour un début et nous espérons que vous voudrez en savoir plus sur ce que le puissant module Naxsi a à offrir. Vous pouvez maintenant rendre votre serveur Nginx non seulement rapide, mais également sécurisé.

TOC