Sous-catégories

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.

mercredi 4 janvier 2017

Bloquer des pays sur Nginx

Depuis un certains temps, mes différents sites se font spammer par des robots provenant en particulier de 3 pays, à savoir la Chine, l’Afghanistan et l'Iran.

Utilisant un compte Cloudflare gratuit, je n'ai pas la possibilité de les bloquer via l'interface, je suis donc obligé de faire cela via la configuration de nginx. J'en ai donc profité pour faire un petit script qui automatise la liste des IP à bannir pour gérer ça d'une manière plus simple.

Lire la suite...

lundi 10 octobre 2016

Décrypteur de log rsync

Comme beaucoup de monde, j'utilise rsync de manière automatisée pour effectuer mes sauvegardes mais les logs sont difficilement interprétables d'un simple regard. J'ai donc décidé de me faire un petit analyseur qui me permettra d'avoir un rendu bien plus lisible. Et en couleur pour que ce soit encore plus visuel.

Le rendu sera, pour chaque ligne de log rsync:

  • l'action effectuée (upload, download, suppression, modification ou ignore)
  • le type de contenu (fichier, répertoire, lien symbolique)
  • le nom du contenu traité
  • les raisons de la modification

A la fin de l'analyse, un comptage des différentes actions sera affiché.

Lire la suite...

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...

lundi 6 août 2012

Bind9 sur Debian

Récemment, j'ai eu un petit souci avec Bind9. Proprement configuré suite à une installation sous Debian, impossible que mes domaines soient bien pris en compte par les différents serveurs DNS.

Je laisse passer 48h pour la propagation, et toujours rien.

Coup de génie: je teste depuis la machine que bind fonctionne bien en faisant telnet 127.0.0.1 53 et ça fonctionne, bind est bien lancé (ce que j'avais vérifié avec un netstat -anp | grep 53).

Je tente d'une autre machine, et là rien...

En fait, il semblerait que les dernières versions de bind9 sur Debian remplissent ainsi le fichier /etc/bind/named.conf.options :

options {
       directory "/var/cache/bind";
       auth-nxdomain no;    # conform to RFC1035
       listen-on-v6 { any; };
       listen-on { 127.0.0.1; };
       allow-recursion { 127.0.0.1; };
};

Il suffit donc de remplacer listen-on { 127.0.0.1; }; par listen-on { any; }; (ou avec l'IP publique de votre serveur) et tout rentre dans l'ordre.

lundi 10 octobre 2011

Créer un patch et l'utiliser

Lorsqu'on développe une (ou des) application(s), il y a fréquemment des mises à jour à faire.

Très souvent, et moi le premier, la méthode la plus simple consiste à purement et simplement écraser ce que l'on a mis en place par les nouveaux fichiers, ce qui peut parfois être lourd (en quantité transférée) alors que les modifications sont mineures, et comporte des risques dûs au transfert FTP.

Heureusement, si votre application est gérée par SVN (je le conseille fortement) et si vous avez accès à l'hébergement de votre application par SSH (ce qui est malheureusement rarement le cas dans le cadre des applications web), diff et patch vont vous simplifier grandement le travail.

Lire la suite...

lundi 18 avril 2011

Réveiller un NAS

Si vous êtes l'heureux possesseur d'un NAS, vous appréciez très certainement son économie d'énergie et le fait qu'il se mette "à l'arrêt" lorsqu'il n'est pas sollicité depuis un certain temps.

Enfin, ceci est de la théorie parce qu'en pratique, si vous êtes plutôt Linux que MacOS ou Windows, il va falloir chercher un peu. J'ai moi-même cherché et j'ai trouvé sur un forum une contribution de themadmax.

Je me permet donc de traduire (et expliquer) la contribution.

Lire la suite...

- page 1 de 2