lundi 23 octobre 2017

Nginx: répertoire par sous-domaine

Cette petite astuce permet de simplifier la gestion des sous-domaines sur nginx, et surtout ne pas avoir à modifier sa configuration à chaque fois que l'on crée ou supprime un sous-domaine.

Elle exploite la possibilité de nginx d'utiliser des expressions rationnelles dans le nom du serveur.

Configuration

server {
        listen 80;
        server_name ~^(?<subdomain>([^\.]+))\.domaine\.com$;
        if (!-d /home/domain/public_html/$subdomain) {
                rewrite . http://domain.com redirect;
        }
        root /home/domain/public_html/$subdomain;
        index index.php index.html;
        location / {
                try_files $uri $uri/ /index.php?$args;
        }
        access_log /var/log/nginx/domain.dynam.access.log;
        error_log /var/log/nginx/domain.dynam.error.log;
        location ~ \.php$ {
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                fastcgi_pass unix:/var/run/php5-fpm.sock;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_index index.php;
                include fastcgi.conf;
        }
        location ~* ^.+.(jpg|jpeg|gif|css|png|js|ico|txt|xml)$ {
                access_log off;
                expires 30d;
        }
}

Explications

URL appelée

server_name ~^(?<subdomain>([^\.]+))\.domaine\.com$;

Cette directive permet de capturer dans la variable $subdomain tout ce qui précède .domaine.com dans l'url appelée. Notez qu'elle ne prend pas en compte l'appel http://domaine.com qui sera notre adresse par défaut et doit donc être traitée par un autre bloc de configuration.

Redirection par défaut

if (!-d /home/domain/public_html/$subdomain) {
   rewrite . http://domain.com redirect;
}

Cette directive est connue des habitués des scripts shell: s'il n'existe pas de sous-répertoire correspondant au sous-domaine, on redirige (de manière visible) l'utilisateur sur l'url par défaut.

Définition du répertoire source

root /home/domain/public_html/$subdomain;

On définit de manière dynamique le répertoire source, toutes les directives suivantes l'utiliseront.

lundi 27 juin 2016

[MAJ] Fail2ban ne donne pas les lignes correspondantes à une détection

Après avoir appliqué ce que j'ai expliqué dans ce billet, j'ai reçu des mails signalant le bannissement de certaines IP suite à la détection de tentatives d'injection SQL.

Problème : juste en dessous de Lines containing IP: <le méchant> in /var/log/nginx/*.access.log, il n'y avait rien.

Je suis allé voir le fichier /etc/fail2ban/action.d/sendmail-whois-lines.conf et l'expression régulière présente ne fonctionne pas avec mes logs.

Version initiale:

[bash]
`grep '[^0-9]<ip>[^0-9]' <logpath>`

Je l'ai remplacée par:

[bash]
`egrep '[^0-9]?<ip>([^0-9]|$)' <logpath>`

Maintenant, ça fonctionne. Ceci est dû aux types de fichiers logs que j'utilise pour nginx et dont le premier élément de la ligne est l'adresse IP.

MAJ : Problème de dates

Il arrive parfois que fail2ban envoie des mails à une date erronée (comme 01/01/1970). Pour corriger ça, il faut éditer le fichier /etc/default/fail2ban et ajouter les lignes suivantes:

[conf]
LC_ALL=C
LANG=C

samedi 25 juin 2016

fail2ban pour lutter contre les injections SQL

Si vous ne connaissez pas fail2ban, c'est un excellent utilitaire pour protéger vos serveurs des différentes attaques.

Il fonctionne à partir de filtres (des expressions régulières) qui sont appliqués aux fichiers logs et appliquer des sanctions aux petits malins qui tenteraient d'exploiter des failles.

Il existe beaucoup de filtres officiels contre les attaques les plus courantes, mais pas contre les tentatives d'injections SQL. Heureusement, TrogloGeek a créé un filtre, que j'ai un peu modifié pour le rendre plus fonctionnel et utilisable avec Apache et Nginx

# Fail2Ban configuration file
#
# Author: TrogloGeek (Damien VERON)
#
# $Revision: 1 $
#
 
[Definition]
sqlfragments_generic = select.*from|delete.*from|update.*set|insert.*into|replace.*(value|set)
sqlfragments_havij = and(\+|%%20)ascii%%28substring|and(\+|%%20)Length|union(\+|%%20)all(\+|%%20)select|and(\+|%%20)1%%3C1|and(\+|%%20)1%%3D1|and(\+|%%20)1%%3E1|and(\+|%%20)%%27.%%27%%3D%%27|%%2F\*%%21[0-9]+((\+|%%20)[0-9]*)?\*%%2F
 
# Option:  failregex
# Notes.:  Regex to try to detect SQL injection trials
# Values:  TEXT
#
failregex = (?i)<HOST> -.*"(GET|POST).*(?:%(sqlfragments_generic)s|%(sqlfragments_havij)s)[^"]*HTTP[^"]*".*
 
# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

Dans la partie Definition, vous trouvez les bouts de SQL les plus communs utilisés pour une tentative d'injection, séparés en deux parties: les génériques (requêtes de bases) et ceux qui sont clairement des signatures de tentatives de hack.

L'expression régulière est plus ou moins celle de base pour les logs apache et nginx, notez tout de même la présence de (?i) au début qui la rend insensible à la casse.

dimanche 17 mars 2013

Apache et nginx - Transmettre l'IP du visiteur

Jai omis hier dans mon billet Soulager Apache avec nginx un point essentiel. Lorsque nginx appelle un contenu dynamique, Apache voit que le demandeur est nginx et non pas le visiteur du site, donc toutes les requêtes viennent de 127.0.0.1. Heureusement, il est possible de forwarder les entêtes HTTP adaptés.

Lire la suite...

Soulager apache avec nginx

Le problème avec Apache, c'est que lorsqu'on appelle une page web, il crée un processus par élément appelé par la page (image, feuille de style, ...), ce qui peut rapidement saturer la mémoire du serveur si trop de visites simultannées sont faites sur un site. Heureusement, on peut utiliser un proxy comme nginx pour économiser des ressources.

Lire la suite...