Blog geekesque... ou presque

Aller au contenu | Aller au menu | Aller à la recherche

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:

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

Je l'ai remplacée par:

`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:

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

jeudi 12 mars 2009

Apache avec de multiples utilisateurs

Lorsqu'on installe apache sur un serveur, celui-ci fonctionne sous l'utilisateur www-data ou apache. Cela permet de limiter ses droits d'accès, ce qui est une sécurité pour le serveur, mais cela pose un problème pour les fichiers créés par le site ou envoyés par formulaire, car ils n'appartiennent pas au propriétaire du site.

Ceci fait que si l'on ne modifie pas les droits d'accès de l'utilisateur (par exemple en le mettant dans le même groupe qu'apache) ou les permissions par défaut des fichiers, le webmaster ne pourra pas détruire un fichier de son site si ce n'est pas lui qui l'a mis en ligne.

Heureusement, une solution existe, c'est de faire fonctionner chaque sous-processus d'apache en tant que propriétaire du site.

Pour ce faire, il suffit de déclarer dans les définitions des sites sous quel propriétaire et sous quel groupe le site doit s'éxecuter:

<VirtualHost *>
   ServerName server1
   AssignUserID user1 group1
</VirtualHost>
 
<VirtualHost *>
   ServerName server2
   AssignUserID user2 groips
</VirtualHost>