URLs bannissement

De EjnTricks
Révision de 29 mars 2018 à 13:35 par Etienne (discussion | contributions)

(diff) ← Version précédente | Voir la version courante (diff) | Version suivante → (diff)

Lors de la publication d'un site Web, les attaques sont nombreuses sur des URLs connues. Les attaques tentent d'accéder à des scripts ou des consoles d'administration. Cet article présente une règle personnalisée sous <code<Fail2ban</code> pour banir rapidement les tentatives d'intrusions sur des essais d'accès à des URLs qui sont forcément inexistantes, les produits n'étant pas installés..


Hand-icon.png Votre avis

Nobody voted on this yet

 You need to enable JavaScript to vote


Study icon.png Etude

Par défaut, Fail2ban fournit une configuration sur les tentatives d'attaque sur les serveurs Apache, commes les configurations apache-badbots/code> ou <code>apache-fakegooglebot qui se basse sur le fichier trace des accès.

Dans le fichier jail.conf, dans le répertoire /etc/fail2ban pour une installation sous Ubuntu, les sections suivantes sont disponibles pour une installation en version 0.9.7.

[apache-fakegooglebot]

port     = http,https
logpath  = %(apache_access_log)s
maxretry = 1
ignorecommand = %(ignorecommands_dir)s/apache-fakegooglebot <ip>

Par défaut, les configurations de bannissement sont dans le sous répertoire filter.d avec des fichiers portant le nom de la section. Pour la configuration apache-fakegooglebot, la configuration est la suivante.

# Fail2Ban filter for fake Googlebot User Agents

[Definition]

failregex = ^<HOST> .*Googlebot.*$

ignoreregex =


# DEV Notes:
#
# Author: Lee Clemens
# Thanks: Johannes B. Ullrich, Ph.D.
# Reference: https://isc.sans.edu/forums/diary/When+Google+isnt+Google/15968/

Il suffit de s'inspirer de cette organisation pour créer une règle spécifique.


Icon-Configuration-Settings.png Configuration

Add-icon.png Ajout bannissement

La première étape consiste à référencer le nouveau bannissement. Pour cette règle, il n'est pas souhaité de laisser beaucoup de chance aux attaques et dès la première tentative elle doit se déclencher.

Un nouveau fichier apache-try-url.local est créé dans le sous répertoire jail.d avec le contenu suivant.

[apache-try-url]
enabled  = true
bantime  = 21600
maxretry = 1
port     = http,https
logpath  = %(apache_access_log)s

La durée de bannissement est configurée à 6 heures, valeur 21600 dans bantime, et la variable apache_access_log est utilisée pour référencer l'emplacement des fichier traces à vérifier comme dans les configurations fournies.

Process-icon.png Définition règle

La seconde étape consiste à définir les règles de déclenchement du bannissement. Un fichier est le nom apache-try-url.conf, contenant le nom du bannissement, est ajouté dans le sous répertoire filter.d.

Dans un premier temps, les URLs sont mises individuellement sans utiliser les possibilités de liste dans les expressions régulières. Dans cet exemple, les accès suivants seront bannis.

  • wp-login.php page login de Wordpress;
  • /wp/wp-admin/ console d'administration de Wordpress;
  • /cgi-bin ou cgi-sys sur lesquels il y a des tentatives d'accéder à php.

Le contenu du fichier est le suivant.

# Fail2Ban configuration file
#
# Regexp to catch URLs access that will never exist.

[Definition]

failregex = ^<HOST> -.*"GET /wp-login.php HTTP.*" 404 .*$
            ^<HOST> -.*"GET /wp/wp-admin/ HTTP.*" 404 .*$
            ^<HOST> -.*"GET /cgi-(bin|sys)/.* HTTP.*" 404 .*$

ignoreregex =

Process-Icon.png Configuration avancée

La première configuratin décrite est basée sur une liste assez figée des URLs. Or lors des attaquest, les personnes essayent de nombreuses combinaisons en alternant les contextes et la casse. Par exemple, les tentatives sur les URLs suivantes peuvent être constatées.

  • /phpmyadmin/scripts/setup.php
  • /phpMyAdmin/scripts/setup.php
  • /pma/scripts/setup.php

Cette nouvelle version de configuration va utiliser des variables, qui seront substituées dans les expressions régulières, afin de définir des racines communes. L'objectif est que cela soit insensible à la casse également, grace à la syntaxe (?i) avant la chaîne de caractères.

Une première variable, phpMyAdminRoot est mise en place pour référencer toutes les racines attaquées.

phpMyAdminRoot = (?i)(myadmin|phpmyadmin|pma)

Ainsi, les racines suivantes seront surveillées.

  • myadmin
  • phpmyadmin
  • pma

Une seconde variable, phpMyAdminSub permet de définir un niveau intermédiaire entre la racine et le script setup.php.

phpMyAdminSub = /(?i)(scripts)

Dans ce cas, seul le niveau intermédiaire scripts est contrôlé.

Puis une troisième variable, wpAdmin, est mise en place pour les tentatives sur la page de connexion ou d'administration à une instance WordPress.

wpAdmin = (?i)(wp-login.php|wp-admin/?)

Dans ce cas, les tentatives sur les URLs suivantes seront contrôlées.

  • /wp-login.php
  • /wp-admin/


# Fail2Ban configuration file
#
# Regexp to catch URLs access that will never exist.

[Definition]

phpMyAdminRoot = (?i)(myadmin|phpmyadmin|pma)
phpMyAdminSub = /(?i)(scripts)
wpAdmin = (?i)(wp-login.php|wp-admin/?)

failregex = ^<HOST> -.*"GET .*/%(wpAdmin)s HTTP.*" 404 .*$
            ^<HOST> -.*"GET /+%(phpMyAdminRoot)s(%(phpMyAdminSub)s?)/setup.php HTTP.*" 404 .*$
            ^<HOST> -.*"GET /cgi-(bin|sys)/.* HTTP.*" 404 .*$

ignoreregex =

A noter, le caractère optionnel du niveau intermédiaire lors de la vérification pour phpmyadmin, à l'aide de l'opérateur ? dans l'expression %(phpMyAdminSub)s?.

Warning-icon.png Pour rappel, la substitution des variables s'effectue en l'encadrant du préfixe %( et du suffixe )s.

Ce type de configuration nécessite une surveillance régulière des traces Apache.


Run-icon.png Test

Avant d'activer la nouvelle règle, il est possible de la tester à l'aide de la commande fail2ban-regex.

#sudo fail2ban-regex --print-all-matched /var/log/apache2/access.log /etc/fail2ban/filter.d/apache-try-url.conf

Running tests
=============

Use   failregex filter file : apache-try-url, basedir: /etc/fail2ban
Use         log file : /var/log/apache2/access.log
Use         encoding : UTF-8


Results
=======

Failregex: 11 total
|-  #) [# of hits] regular expression
|   1) [3] ^<HOST> -.*"GET /wp-login.php HTTP.*" 404 .*$
|   3) [8] ^<HOST> -.*"GET /cgi-(bin|sys)/.* HTTP.*" 404 .*$
`-

Ignoreregex: 0 total

Date template hits:
|- [# of hits] date format
|  [21615] Day(?P<_sep>[-/])MON(?P=_sep)Year[ :]?24hour:Minute:Second(?:\.Microseconds)?(?: Zone offset)?
`-

Lines: 21615 lines, 0 ignored, 11 matched, 21604 missed
[processed in 3.61 sec]

|- Matched line(s):
|  79.113.169.153 - - [16/Mar/2018:02:06:20 +0100] "GET /wp-login.php HTTP/1.1" 404 509 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1"
|  79.144.210.62 - - [16/Mar/2018:06:11:06 +0100] "GET /wp-login.php HTTP/1.1" 404 509 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1"
|  85.118.206.11 - - [16/Mar/2018:09:48:41 +0100] "GET /cgi-bin/php HTTP/1.1" 404 450 "-" "-"
|  85.118.206.11 - - [16/Mar/2018:09:48:41 +0100] "GET /cgi-bin/php5 HTTP/1.1" 404 451 "-" "-"
|  85.118.206.11 - - [16/Mar/2018:09:48:41 +0100] "GET /cgi-bin/php-cgi HTTP/1.1" 404 454 "-" "-"
|  85.118.206.11 - - [16/Mar/2018:09:48:41 +0100] "GET /cgi-bin/php.cgi HTTP/1.1" 404 454 "-" "-"
|  85.118.206.11 - - [16/Mar/2018:09:48:41 +0100] "GET /cgi-bin/php4 HTTP/1.1" 404 451 "-" "-"
|  85.118.206.11 - - [16/Mar/2018:09:48:42 +0100] "GET /cgi-bin/php5-cli HTTP/1.1" 404 455 "-" "-"
|  85.118.206.11 - - [16/Mar/2018:09:48:42 +0100] "GET /cgi-bin/test.cgi HTTP/1.1" 404 455 "-" "-"
|  85.118.206.11 - - [16/Mar/2018:09:48:42 +0100] "GET /cgi-sys/php5 HTTP/1.1" 404 451 "-" "-"
|  108.239.33.139 - - [16/Mar/2018:11:50:19 +0100] "GET /wp-login.php HTTP/1.1" 404 509 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1"
`-
Missed line(s): too many to print.  Use --print-all-missed to print all 21604 lines

A noter dans le cadre de ce test l'utilisation de l'argument --print-all-matched pour afficher les lignes qui déclenchent les expressions régulières.

Update icon.png Activation

Une fois validée, il suffit d'activer la règle à l'aide de la commande fail2ban-client avec l'argument reload.

#sudo fail2ban-client reload