Pare-feu applicatif web (WAF)
Découvrez notre offre de Cloud Public
L'hébergement mutualisé pour tou·te·s, imaginé par des développeur·euse·s, pour des développeur·euse·s.
Découvrir le Cloud PublicUn WAF examine chaque requête HTTP pour protéger les applications web face à différents vecteurs d’attaques pour minimiser les infections. Il peut les autoriser à transiter jusqu’à l’application, ou les bloquer, alerter, consigner si elles sont jugées malveillantes.
Pour paramétrer le pare-feu applicatif web, cela se passe sur l’interface d’administration dans Web > Sites > Modifier le [site] - ⚙️ > WAF.
Profils disponibles
| Profil | Description |
|---|---|
| Aucun | (par défaut) |
| Basique | Respect strict du protocole HTTP |
| Détection de robots malveillants | |
| Fort | L’ensemble des règles du profil basique |
| Détection d’exécution de code à distance (RCE) | |
| Détection d’attaque type Cross-Site Scripting (XSS) | |
| Détection d’injection SQL | |
| Complet | L’ensemble des règles du profil fort |
| Détection d’attaques relatives au langage PHP | |
| Détection d’attaque par inclusion de fichier local (LFI) | |
| Détection d’attaque par inclusion de fichier distant (RFI) | |
| WordPress | L’ensemble des règles du profil complet |
| Règles spécifiques à WordPress | |
| Drupal | L’ensemble des règles du profil complet |
| Règles spécifiques à Drupal | |
| Nextcloud | L’ensemble des règles du profil complet |
| Règles spécifiques à Nextcloud | |
| Dokuwiki | L’ensemble des règles du profil complet |
| Règles spécifiques à Dokuwiki |
L’activation d’un profil de protection va se traduire par une légère augmentation de la latence lors du traitement d’une requête HTTP. Cette latence, de l’ordre de quelques millisecondes, augmente avec le degré de protection.
Exclure des règles
Selon votre cas d’utilisation, le comportement du WAF peut être trop restrictif. Il est aussi possible qu’il génère de faux positifs lors de son analyse. Si vous jugez que son comportement n’est pas approprié, vous avez la possibilité d’exclure certaines règles utilisées lors de l’analyse.
Seul le numéro de la règle à exclure doit être spécifié. Vous le retrouverez dans les logs Sites ($HOME/admin/logs/sites). Exemple :
[08/Jan/2019:11:09:19 +0100] [waf] - <IP attaquante> "GET /?param=%22><script>alert(1);</script> HTTP/1.1" - 941100 | XSS Attack Detected via libinjection' with value: "><script>alert(1);</script>
[08/Jan/2019:11:09:19 +0100] [waf] - <IP attaquante> "GET /?param=%22><script>alert(1);</script> HTTP/1.1" - 941110 | XSS Filter - Category 1: Script Tag Vector' with value: <script>
[08/Jan/2019:11:09:19 +0100] [waf] - <IP attaquante> "GET /?param=%22><script>alert(1);</script> HTTP/1.1" - 941160 | NoScript XSS InjectionChecker: HTML Injection' with value: <script>
Ce serait donc 941100, 941110 et 941160 qui pourraient être indiqués.
Il faut veiller à ajouter progressivement des règles car l’exclusion est applicable sur tout le site. En effet, même si ajouter un grand nombre de règles à exclure peut améliorer la navigation dans certains cas, la protection sera alors amoindrie dans tous les autres cas.
Exclure des chemins
Ce type d’exclusion permet d'éviter l’analyse de pages commençant par le chemin spécifié. En saisissant /foo/ par exemple, www.mon-site.com/foo/ sera exclu de l’analyse tout comme les query strings : www.mon-site.com/foo/?param=bar. Pour exclure aussi www.mon-site.com/foo/bar et www.mon-site.com/foo/script.php, il faut rajouter un wildcard : /foo/*. Enfin, si on veut substituer un caractère quelconque (notamment qui changerait régulièrement), ? peut être utilisé.
Donc, pour écarter de l’analyse www.mon-site.com/foo/barBaz/, foo et Baz étant des strings quelconques, le chemin à exclure serait : /*/bar?/.
Prenons le cas d’un site de type WordPress qui présente des logs similaires à ceux présentés précédemment. Si ces règles sont déclenchées lors de la navigation dans l’interface d’administration du blog, alors il est possible de les exclure de manière permanente. Cependant, le blog en lui-même ne sera plus protégé contre ces tentatives d’attaques. Dans ce cas, il est plus judicieux d’exclure le chemin (exemple : /wp-admin/*) pour que toutes vos opérations sur l’interface d’administration ne soient plus concernées par l’analyse du WAF.
Les query strings ne peuvent pas être utilisées dans ces exclusions.
Exclure des IP
Il peut être intéressant d’exclure des IP sûres (IP spécifiques ou plages d’IP) pour éviter à des outils ou des personnes d’être bloqués.
Prenons l’exemple de WPScan : en l’activant sur un site WordPress certaines des requêtes qu’il effectue peuvent être bloquées. Exclure des règles ou des chemins ne serait pas efficace comme il observe de nombreuses URLs. La solution est donc d’exclure le serveur HTTP sur lequel est installé WPScan pour qu’il puisse fonctionner normalement.
alwaysdata utilise le WAF ModSecurity et l’ensemble de règles libres OWASP Modsecurity Core Rule Set (CRS).