TigerProtect pour protéger votre hébergement !

La règle de sécurité par défaut correspond à toutes les règles de sécurités mises en place, nativement, par o2switch. Ces règles là sont activées par défaut, pour tous les noms de domaines 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 nombres 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 pattern d’attaques connus, par exemple pour bloquer des tentatives d’injections SQL grossières via des paramètres passées dans l’URL

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

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

Cela correspond aux fichiers de développements, comme 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é.

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.

Cette règle de sécurité peut être activé dans le cas ou votre site se fait attaqué 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 robots 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.

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.

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.

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.

Cette règle permet de bloquer totalement ou de limiter le nombres 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.

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.

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.

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

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.

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.