Je gère un petit site pro. J'ai vraiment analysé les logs pour la 1re fois et j'ai eu un choc.
Des milliers de requêtes par jour vers des trucs comme /wp-admin, /.env, /phpmyadmin, /.git/config. On n'a même pas WordPress sur le site.
C'est une attaque ciblée contre nous ou c'est pareil pour tout le monde ? Qu'est-ce que je dois faire ?
D'abord, détends-toi : c'est pas une attaque ciblée, c'est le bruit de fond que reçoit n'importe quelle adresse exposée sur internet. Les bots scannent en continu toutes les plages d'IP et testent les failles connues. Ils s'en foutent de savoir ce qu'est ton site.
Maintenant, le côté sceptique, car "normal" ne veut pas dire "sans importance". Fais bien la distinction :
Bruit automatique : requêtes sur des adresses aléatoires qui renvoient des 404, venant d'IP différentes, motifs répétitifs. Ça, c'est juste du bruit.
À surveiller : les tentatives sur tes adresses qui existent vraiment. Tentatives de mot de passe à la suite sur ta page de connexion, accès au panneau d'admin, manipulations de paramètres. Ça veut dire que quelqu'un a vraiment regardé ton site.
À faire, par ordre d'importance : ne laisse pas le panneau d'admin ouvert à tout le monde, limite le débit des tentatives de connexion, garde tes logiciels à jour, fais des sauvegardes et teste-les en les restaurant.
Le dernier point est le plus souvent oublié. Une sauvegarde non testée n'est pas une sauvegarde.
Ajout technique de ma part, côté SOC.
Essayer de bloquer tout ce bruit (genre blacklister chaque IP) est souvent inutile. Les IP changent tout le temps, la liste gonfle, et un jour tu bloques tes propres utilisateurs.
À la place, filtre le bruit pour voir les vrais incidents. Méthode pratique : mets les requêtes 404 dans un canal à part, garde seulement les 200 et 500 dans ton flux de log principal. Et tiens un compteur séparé pour les échecs de connexion.
Comme règle d'alerte, je recommande : beaucoup d'échecs de connexion en peu de temps depuis une seule source. C'est le motif qui se distingue vraiment du bruit et qui demande une intervention.
N'oublie pas non plus : les vrais incidents les plus fréquents commencent pas par une intrusion brute, mais par une connexion avec un mot de passe fuité. Donc autant surveiller les logs que d'activer la double authentification.
Une question : tu dis que c'est la première fois que tu analyses bien ces logs. Mais jusqu'à quand peux-tu remonter dans le temps ?
Le problème, c'est que sur la plupart des serveurs, la durée de rétention des logs est courte par défaut. Quand un incident arrive, tout le monde se heurte au même mur : pas de logs.
En tant que quelqu'un qui veut des preuves, conseil concret : vérifie ta durée de rétention des logs et passe-la à au moins 90 jours. Le coût en stockage est faible, mais la valeur en cas d'incident est énorme. Garde aussi les logs ailleurs que sur le serveur lui-même ; si le serveur est compromis, les logs sont la première chose effacée.
Je te donne des chiffres côté hébergement, pas des estimations, c'est le motif qu'on voit régulièrement sur notre propre panneau.
Même un nom de domaine fraîchement créé, jamais promu, sans aucun lien nulle part, commence à recevoir ce genre de tentatives automatiques dès la première semaine. La raison est simple : les registres de transparence des certificats sont publics, on peut y voir les nouveaux domaines.
Donc, non, il n'y a pas de sécurité du type "mon site est petit, personne ne le connaît". Être petit ne te rend pas invisible, ça réduit juste la probabilité d'une attaque ciblée.
Je suis étudiant, j'ai une question, désolé si ça paraît bête.
Pourquoi ces navigateurs cherchent le fichier /.env ? Qu'y a-t-il dedans qui soit si précieux ?
Pas du tout absurde, c'est une question très pertinente.
Le fichier .env est un fichier texte qui contient les paramètres de l'application (environment, soit les variables d'environnement). Il contient généralement l'adresse et le mot de passe de la base de données, les clés des services tiers et la clé de chiffrement des sessions.
Pour un attaquant, ce fichier revient à trouver la clé plutôt que de forcer la porte. C'est pourquoi les scanners le testent en premier ; le coût est une seule requête, le gain est tout.
Normalement, ce fichier doit se trouver en dehors du dossier servi par le serveur web. En cas de mauvaise configuration, il reste dans le dossier public et devient lisible via le navigateur. La même logique s'applique à /.git/config : si le dépôt du projet est publié par erreur, tout le code source peut être téléchargé.
C'est très facile à vérifier : tapez /.env à la suite de votre propre adresse. Si vous obtenez une erreur 404, tout va bien ; si vous voyez le contenu, bloquez l'accès immédiatement et changez toutes les clés contenues dans ce fichier. Le blocage ne suffit pas, on considère qu'il y a eu fuite.
En tant qu'équipe Doki, ajoutons une note, car ce sujet résume bien une question fréquente.
Nous observons aussi le tableau décrit ci-dessus : toute ressource exposée sur Internet est scannée, même si elle n'est pas déclarée. C'est pourquoi nous recommandons d'abord à nos clients d'établir un inventaire des actifs — quels domaines, quels sous-domaines, quels serveurs nous appartiennent vraiment et lesquels sont encore actifs par oubli.
En pratique, la porte ouverte la plus fréquente que nous rencontrons sont les environnements de test oubliés. Le système de production est bien protégé, mais un serveur d'essai ouvert il y a deux ans continue de pointer vers la même base de données.
Les partages ici sont à titre informatif général ; nous vous recommandons de faire réaliser une évaluation au périmètre défini pour votre propre système.
En regardant le processus, le tableau change. Si la double authentification est activée, un mot de passe volé seul ne suffit pas.
Si la double authentification est activée, un mot de passe volé seul ne suffit pas. Si vous écrivez le résultat ici, cela aidera aussi d'autres personnes.
Je suis d'accord, j'aimerais même souligner ce point. Si le chemin de notification est long, la notification n'arrive pas ; une notification manquante signifie un événement détecté tardivement.
Je suis aussi curieux de savoir si d'autres font autrement.
Il y a un point qui m'interpelle. Les décisions hâtives finissent par être corrigées six mois plus tard.
Bon courage.
Résumé rapide pour les nouveaux : Plus il est difficile de revenir sur une décision, plus il faut la prendre lentement.
Tout point non écrit est un point que les deux parties se rappelleront différemment plus tard. Bon courage.
Merci d'avoir écrit cela, c'est exactement ça. Si l'autorisation et le périmètre ne sont pas écrits, ne lancez pas ce test.
C'est mon avis, je ne l'écris pas comme une vérité absolue.
J'ai travaillé longtemps sur ce sujet. La plupart des pertes de temps s'accumulent sur les tâches en attente de validation.
L'erreur commise du côté de log est généralement réversible, mais coûteuse. J'espère que cela vous sera utile.
Comment avez-vous résolu ce point ? Essayer de faire cela seul est la voie la plus coûteuse.
L'erreur commise du côté de log est généralement réversible, mais coûteuse. C'est mon avis, je ne l'écris pas comme une vérité absolue.