Tiger Protect : règles de sécurité web

L'outil Tiger Protect vous permet de personnaliser les règles de sécurité qui sont en place sur la partie web de votre espace d'hébergement.

Ces sécurités agissent directement au niveau du serveur web, c'est-à-dire là où cela est le plus efficace et consomme le moins de ressources possibles.

Les requêtes sont contrôlées avant l'arrivée sur vos pages par des serveurs "WAF". TigerProtect devient un véritable bouclier pour protéger vos projets.

L'outil n'est pas qu'un "simple" WAF comme pourrait l'être ModSecurity par exemple. La majorité des règles proposées sont des règles exclusives à o2switch et sont le fruit de plusieurs années de recherches et affinage.

Ces règles-là sont proposées depuis plusieurs années, mais le fait de pouvoir les personnaliser depuis un outil dans cPanel est récent.

Outils TigerProtect

Permet de personnaliser les règles de sécurités en place l'hébergement web

Offre Unique GrowOffre Unique CloudOffre Unique ProServeurs infogérés

Récapitulatifs des règles de sécurité

Voici un tableau récapitulatif des règles de sécurité proposées.

Description	Recommandation	Actions
règles de sécurité par défaut de o2switch	Recommandé	Activer, désactiver
Bloque les accès automatisés (robots, brute force) sur les pages d'administrations courantes des sites internet	Recommandé	Challenge Complexe, Challenge Simple
Bloque l'accès aux fichiers utilisés dans le développement des sites internet. Par exemple .git	Recommandé	Tout bloquer (403)
Bloque l'accès direct au fichier .php	Contexte	Tout bloquer (403)
Active le mode "Je suis attaqué". Vérifie que toutes les requêtes sont réalisées depuis un vrai navigateur web	Temporaire	Challenge complexe, Challenge simple
Bloque l'accès au fichier xmlrpc.php de WordPress	Recommandé	Tout bloquer (403)
Permet de limiter le nombre d'accès par IP et par minute aux /wp-login et /wp-admin	Contexte	5req/min, 20req/min, 40req/min
Bloque l'accès direct aux fichiers .php sensibles de WordPress	Recommandé	Tout bloquer (403)
Permet de bloquer ou de mettre en place un taux limite pour les robots SEO	Recommandé	Tout bloquer (403), 5req/min, 20 req/min, 40req/min
Bloquer les robots malveillants ou suspects	Recommandé	Tout bloquer (403), Bloquer POST, Bloquer GET
Bloquer les robots se faisant passer pour Google	Recommandé	Tout bloquer (403), Bloquer POST, Bloquer GET
Bloquer les requêtes venant du réseau Tor	Recommandé	Tout bloquer (403), Bloquer POST, Bloquer GET
Bloquer les requêtes venant d'adresses IP considérées comme malveillante	Recommandé	Tout bloquer (403), Bloquer POST, Bloquer GET

règles de sécurité

Les règles de sécurité dans TigerProtect sont organisées en plusieurs catégories. Chaque catégorie dispose d'une ou plusieurs règles de sécurité.

L'outil TigerProtect contient plusieurs règles de sécurité organisées en catégories

Pour chaque sécurité, il est possible de choisir une action. L'action correspond à ce qui sera fait lorsque la règle de sécurité est déclenchée. Chaque règle de sécurité à ces spécificités, il est par exemple possible de :

• Tout bloquer (403)
• Bloquer que les requêtes de type GET ou POST
• Mettre en place un taux limite (pour limiter le nombre de connexions maximum et par IP)
• Vérifier que la requête vient d'un vrai navigateur web, via un challenge (Proof of work)

Exemple des actions possibles pour le mode Je suis attaqué

Les règles de sécurité s'activent instantanément, le délai de prise en compte est très court (quelques secondes) et c'est compatible avec des outils comme ipxtender, xtremCache ou litespeed.

Règles de sécurité génériques

Les règles génériques sont les règles de sécurité qui peuvent être activés sur n'importe quel type de site internet. Ces règles-là ne sont pas spécialement conçus pour un type de site particulier par exemple un site conçu avec WordPress.

Sécurité par défaut d'o2switch

La règle de sécurité par défaut correspond à toutes les règles de sécurité mises en place, nativement, par o2switch. Ces règles-là sont activées par défaut, pour tous les noms de domaine hébergés.

Si cette règle-là ne pose pas de problème particulier, il est recommandé de la laisser active.

La règle de sécurité par défaut peut changer régulièrement, cela étant mis à jour en fonctions des attaques ou scans détectés par nos équipes. La règle par défaut correspond en réalité à un grand nombre sous-règles.

Voici un exemple des sous-règles qui peuvent être utilisées par cette règle par défaut.

• des blocages sur des adresses IP considérées malveillantes sur des ressources sensibles. Exemple : une IP ayant mauvaise réputation se verra refusé un accès à une page /wp-login.php d'un site internet.
• des contrôles de navigateur web. Si une requête est effectuée avec un User-Agent qui correspond à celui d'un vrai navigateur web, le serveur peut être susceptible de vérifier qu'il s'agit d'un vrai navigateur web en envoyant un challenge (Proof of work) à résoudre. Cela permet de bloquer des robots se faisant passer pour des vrais navigateurs web
• des contrôles sur la validité d'un User-Agent. Par exemple, un robot se faisant passer pour Google-Bot peut être bloqué si l'accès est effectuée depuis une adresse IP n'appartenant au réseau de Google.
• des blocages ou rate-limit de robots ayant mauvaise réputation ou étant utilisé sur des outils de scans / téléchargement de sites internet
• les requêtes HTTP sont analysées pour voir si cela correspond à des patterns d'attaques connus, par exemple pour bloquer des tentatives d'injections SQL grossières via des paramètres passées dans l'URL
• blocage de l'accès à des fichiers PHP qui ne devraient pas être directement accessible, par exemple, sur WordPress, la majorité des fichiers du dossier wp-includes ne doivent pas être accessibles publiquement.
• blocage de l'accès à des fichiers PHP qui ne devraient pas exister. Pour reprendre l'exemple de WordPress, cela va bloquer la tentative d'accès à un fichier qui ne devrait pas exister / n'est pas natif à WordPress, par exemple un shell dans wp-includes

Contrôle du navigateur sur les pages d'administrations courantes

Cette règle de sécurité permet de vérifier que les accès effectués à destination des pages d'administrations (exemple : /wp-admin, /administrator) sont réalisées depuis des vrais navigateurs web et non des robots automatisés.

Pour cela, le navigateur web retournera un challenge que le navigateur web à l'origine de la requête devra résoudre. Ce challenge peut facilement être passé par un vrai navigateur web, mais cela bloquera un robot conventionnel qui ne s'attendra pas à ce type de réponse.

Le challenge se base sur le principe de proof of work. Autrement dit, le serveur demande au navigateur web de calculer le résultat d'une opération et vérifiera la réponse avant de laisser passer la requête.

Bloquer l'accès aux fichiers de développement

Cette règle de sécurité permet de bloquer l'accès à des fichiers qui ne devraient normalement pas être accessibles ou publiés.

Cela correspond aux fichiers de développements, par exemple le fichier .env d'un site internet qui peut contenir des secrets. Un autre exemple de blocage concerne les fichiers se terminant par .sql pour bloquer le téléchargement d'un fichier de sauvegarde de base de données qui pourrait se trouver à la racine d'un site et oublié.

Bloquer l'accès directs aux fichiers .php

Cette règle-là permet de bloquer tous les accès directs aux fichiers se terminant par .php. Cette règle de sécurité là n'est pas compatible avec tous les sites internet, c'est donc à activer avec vigilance et en fonction du type de site que vous avez.

Cette règle de sécurité peut être activé si votre site fait appel à des règles de redirections, via un fichier .htaccess et que vous êtes sûr à 100% qu'il n'y a pas d'appel légitime vers des fichiers .php.

Par exemple, cette règle est incompatible avec WordPress (voir la règles Bloquer les fichiers sensibles de WordPress en remplacement).

Cette règle devrait cependant être compatible avec un site utilisant le Framework Symfony car ce dernier utilise massivement les règles de redirections et c'est rare de conserver des appels vers des fichiers .php directement.

Mode "Je suis attaqué"

Cette règle de sécurité peut être activé dans le cas ou votre site se fait attaquer massivement par des accès automatisés ou des robots. Cette sécurité-là va vérifier que l'accès est effectuée depuis un vrai navigateur web, en envoyant un challenge (simple ou complexe) que seul un vrai navigateur web peut résoudre.

Cela se base sur le principe de proof of work. Le serveur web va demander au navigateur d'effectuer un calcul et de renvoyer la réponse avant d'autoriser l'accès au site internet. Cela bloquera tous les robots ou systèmes automatisés qui ne s'attendent pas à ce genre de réponse.

Il y a quelques exceptions sur les robots bloqués. Par exemple, le robot de Google est en liste blanche, il ne sera pas bloqué lorsque cette sécurité est activée.

Il est recommandé de n'activer cette sécurité que lorsque le site est attaqué. Il ne faut pas laisser cette sécurité active 7j/7 car cela peut être contraignant pour les visiteurs qui verront une page de sécurité sur leur premier accès au site internet.

Règles de sécurité WordPress

Contrôler les requêtes vers le xmlrpc.php

Cette règle permet de bloquer l'accès direct au fichier xmlrpc.php de WordPress.

Ce fichier-là sert à exposer une API pour WordPress. Ce fichier est de moins en moins utilisé légitimement sur WordPress mais reste un vecteur d'attaque important. Si votre site n'utilise pas ce fichier/API, il est recommandé de bloquer l'accès.

Ces règles de sécurité sont spécifiques au CMS WordPress.

Mettre en place un taux limite sur le /wp-admin et /wp-login.php

Cette règle de sécurité permet d'activer un taux limite sur les pages /wp-login.php et /wp-admin de WordPress. Cela permet de limiter les attaques de types brutes forces sur des adresses IP qui ne seraient pas bloquées par d'autres sécurités (par exemple si une adresse IP à une très bonne réputation).

L'activation systématique de cette sécurité n'est pas nécessairement recommandé. Il faut voir en fonction du contexte et tester que cela fonctionne bien avec votre site internet.

Pour éviter des faux positifs et blocages intempestifs, le fichier admin-ajax.php est exclu de cette sécurité, bien que présent dans wp-admin.

Bloquer l'accès directs aux fichiers .php sensible de WordPress

Cette règle de sécurité permet de bloquer l'accès direct aux fichiers .php sensible de WordPress.

Les fichiers PHP dit sensibles sont ceux pour lesquels ils ne devraient pas y avoir d'accès direct légitimes. Cette règle de sécurité est similaire à la règle bloquer l'accès à tous les fichiers PHP mais est spécialement conçu pour les sites WordPress, avec des exceptions pour éviter de bloquer des usages légitimes.

Par exemple, cette règle de sécurité bloquera l'accès aux fichiers dans wp-includes, wp-content/uploads/*.php mais ne bloquera pas l'accès au wp-login.php ou admin-ajax.php.

Règles de sécurité réputation Robots

Ces règles de sécurité sont en rapport avec les robots qui peuvent scanner votre site internet. Ce sont des règles qui se basent sur le User-Agent défini dans chaque requête.

Contrôler les requêtes venant des robots SEO

Cette règle permet de bloquer totalement ou de limiter le nombre de requêtes effectués par des robots de SEO.

Les robots de SEO comme Majestic, Semrush, Ahrefs (et d'autres) peuvent générer massivement des requêtes vers des sites internet. Cela peut engendrer une consommation excessive de ressources et donc laisser moins de ressources pour les vrais visiteurs, voire être à l'origine de plantage ou d'erreurs.

Avec cette règle de sécurité, vous pouvez décider de totalement bloquer l'accès à ces robots, si vous estimez que cela ne vous apporte rien et est même négatif pour votre site. Ou mettre en place un taux limite, par exemple autoriser 5 requêtes / minute pour ce robots vers votre site internet.

Contrôler les requêtes venant des robots malveillants ou suspects

Cette sécurité permet de bbloquer les requêtes effecutées par des robots considérés comme malveillants ou suspects.

Les robots malveillants scannent les sites internet à la recherche d'informations ou de failles.

Bloquer ou limiter les accès effectués depuis ces robots malveillants (ou inutiles) permet de protéger votre site internet et d'économiser des ressources qui seront utilisés pour répondre aux visites légitimes.

Contrôler les requêtes venant des faux robots Google Bot

Cette sécurité permet de bloquer les robots qui se font passer pour le robots de Google.

Bien souvent, il existe des exceptions de sécurités en ce qui concerne le robots de Google. Des robots malveillants ont compris cela et usurpe le User-Agent du robots de Google dans le but de contourner certaines sécurités.

Cette règle de sécurité permet de bloquer tous les accès qui sont effectuées par un logiciel qui imite le User-Agent de Google mais dont l'accès est effecutée depuis une adresse IP qui n'appartient pas à Google.

Contrôler les requêtes n'ayant pas de User-Agent

Cette sécurité permet de bloquer les requêtes venant de logiciels ne définissant par de User-Agent.

La majorité des requêtes qui sont effectuées sans User-Agent sont des requêtes qui sont lancées par des systèmes automatisés (robots), souvent à des fins malveillantes (ou inutiles).

Bloquer ce type de requêtes permet de protéger votre site internet et d'économiser des ressources sur votre hébergement.

Règles de sécurité réputation IP

Ces règles-là se basent sur l'adresse IP du visiteur, son origine, sa réputation.

Bloquer le trafic venant des adresses IP du réseau Tor

Permet de bloquer les requêtes qui viennent d'un noeud de sortie du réseau Tor.

Se connecter au réseau Tor permet de naviguer sur internet améliorant sont anonymat. Il est difficile, voire impossible, de tracer l'origine d'une visite effectuée depuis le réseau Tor. C'est en théorie quelque chose d'intéressant mais force est de constater que la majorité du trafic web reçu depuis Tor est malveillant. Pour cette raison, cela peut être une bonne idée de bloquer le trafic venant de Tor.

Bloquer le trafic venant des adresses IP ayant une mauvaise réputation

Permet de bloquer les accès qui sont effectués depuis des adresses IP ayant une mauvaise réputation.

o2switch maintient en interne une liste d'adresse IP ayant une mauvaise réputation. Cela est basée sur notre expérience et les attaques que nos systèmes d'intrusions peuvent détecter. Lorsqu'une attaque est averré et confirmée, l'adresse IP à l'origine de l'attaque est listée dans une RBL interne. Si l'adresse IP est à l'origine de plusieurs attaques, sur plusieurs serveurs différents, elle est considirée comme malveillante.

Bloquer les adresses IP considérées comme malveillante amélioera la sécurité des sites hébergés et économisera des

ressources sur votre hébergement.

Règles ModSecurity

Nous avons intégré ModSecurity dans l'outil TigerProtect. Il s'agit en réalité d'un autre type de protection, un WAF conventionnel, mais l'option a été ajouté dans TigerProtect pour unifier ce type de sécurité au même endroit. Depuis l'outil TigerProtect vous pouvez décider d'activer ou non ModSecurity par défaut.

ModSecurity à un fonctionnement différents de TigerProtect. Ce dernier va analyser en profondeur les requêtes effectuées et bloquer en fonction de pattern d'attaque pré-définies. Les règles utilisées par ModSecurity sont mise à jour quotidiennement. O2switch utilise les règles ModSecurity commerciales de malware.expert.

Si ModSecurity ne cause pas de problème avec votre site internet, nous vous recommandons de le laisser actif.

Que faire en cas d'erreurs 403 ?

De nouvelles règles de sécurité, plus restrictives, ont été déployées. L'objectif de ces règles est de bloquer, le plus tôt possible, les scans automatisés des sites internet, les accès malveillants et les activations de backdoor sur des sites qui seraient déjà compromis. Une grande partie de ces règles ciblent WordPress spécifiquement. Les nouvelles règles de sécurité s'ajoutent aux règles existantes.

Plutôt que de fonctionner avec un mode de blacklist, c'est-à-dire de bloquer une liste pré-établie de fichiers/patterns d'URL, la mise à jour de sécurité fait l'inverse.

Pour illustrer cela, prenons l'exemple WordPress et de son dossier wp-admin.

Plutôt que d'avoir des règles qui bloquent wp-admin/fichier-malveillant.php manuellement, l'inverse est fait.

Tout le dossier wp-admin est bloqué SAUF ce qui est nécessaire au fonctionnement du site, c'est-à-dire les fichiers devant rester accessibles publiquement (exemple wp-admin/admin-ajax.php).

Un fichier, non natif à WordPress, ajouté dans ce dossier, ou un fichier n'ayant aucune raison d'être accessible publiquement, se retrouvera bloqué, par défaut, affichant l'erreur 403 comme ci-dessous.

La page d'erreur qui s'affiche lorsque TigerProtect bloque quelque chose

Les listes de fichiers ont été testées de manière approfondie pour éviter des blocages qui ne seraient pas légitimes.

Cependant, si vous vous retrouvez dans un cas particulier, avec quelque chose qui serait bloqué à tort, vous pouvez :

• désactiver la règle “Règles de sécurité par défaut d'o2switch” dans Tiger Protect, cela désactivera les règles de sécurité les plus restrictives
• contacter le support en indiquant l'URL / la page qui est bloquée, pour que nous puissions analyser le cas et ajuster les règles de sécurité