Attaque massive 404 avec des URL inexistantes. Comment empêcher cela?
Le problème est dû à toute une série d'erreurs 404 signalées par Google Webmaster Tools avec des pages et des requêtes qui n'y sont jamais allées. L'un d'eux est viewtopic.php, et j'ai également remarqué un nombre effrayant de tentatives pour vérifier si le site est un site WordPress (wp_admin) et pour la connexion à cPanel. Je bloque déjà TRACE, et le serveur est doté d’une protection contre le balayage/le piratage. Cependant, cela ne semble pas s'arrêter. Selon Google Webmaster, le référent est totally.me.
J'ai cherché une solution pour arrêter cela, car ce n'est certainement pas bon pour les utilisateurs réels pauvres, sans parler des problèmes de référencement.
J'utilise la mini liste noire de Perishable Press ( trouvée ici ), un bloqueur de référent standard (pour les sites pornographiques, à base de plantes, de casino) et même certains logiciels de protection du site (blocage XSS, injection SQL, etc). Le serveur utilise également d'autres mesures, donc on pourrait supposer que le site est sûr (espérons-le), mais il ne se termine pas.
Quelqu'un d'autre a-t-il le même problème ou suis-je le seul à le voir? Est-ce ce que je pense, c'est-à-dire une sorte d'attaque? Existe-t-il un moyen de résoudre ce problème ou mieux d'éviter ce gaspillage de ressources inutile?
EDIT Je n'ai jamais utilisé cette question pour remercier mes réponses, et j'espère que cela sera possible. Merci à tous pour vos réponses perspicaces, qui m'ont aidé à trouver le moyen de m'en sortir. J'ai suivi les suggestions de chacun et mis en œuvre les éléments suivants:
- un pot de miel
- un script qui écoute les URL suspectes dans la page 404 et m'envoie un courrier électronique avec l'utilisateur agent/ip, tout en renvoyant un en-tête 404 standard
- un script qui récompense les utilisateurs légitimes, dans la même page personnalisée 404, au cas où ils finiraient par cliquer sur l'une de ces URL. En moins de 24 heures, j'ai pu isoler certains IP suspects, tous répertoriés dans Spamhaus. Toutes les adresses IP enregistrées jusqu'à présent appartiennent à des sociétés d'hébergement de spam VPS.
Merci encore à tous, j'aurais accepté toutes les réponses si je le pouvais.
Je vois souvent un autre site qui renvoie à des tonnes de pages de mon site qui n'existent pas. Même si vous cliquez sur cette page sans voir le lien:
- Le site peut avoir déjà eu ces liens
- Le site peut masquer et servir ces liens uniquement à Googlebot et non aux visiteurs.
C'est un gaspillage de ressources, mais cela ne va pas dérouter Google et cela ne nuira pas à votre classement. Voici ce que John Mueller de Google (qui travaille sur les outils pour les webmasters et les sitemaps) doit dire environ 404 erreurs qui apparaissent dans les outils pour les webmasters :
HELP! MON SITE A 939 ERREURS DE CRAWL !! 1
Je vois ce genre de question plusieurs fois par semaine; vous n'êtes pas seul - de nombreux sites Web contiennent des erreurs d'analyse.
- Les erreurs 404 sur des URL non valides ne nuisent en aucune façon à l’indexation ou au classement de votre site . Peu importe qu’il y en ait 100 ou 10 millions, ils ne nuisent pas au classement de votre site. http://googlewebmastercentral.blogspot.ch/2011/05/do-404s-hurt-my-site.html
- Dans certains cas, les erreurs d'analyse peuvent provenir d'un problème structurel légitime sur votre site Web ou votre CMS. Comment vous dites Vérifiez l’origine de l’erreur d’analyse. S'il existe un lien brisé sur votre site, dans le code HTML statique de votre page, cela vaut toujours la peine de le corriger. (merci + Martino Mosna )
- Qu'en est-il des URL funky qui sont "clairement cassées?" Lorsque nos algorithmes aiment votre site, ils peuvent essayer de trouver du contenu de qualité supérieure, par exemple en essayant de découvrir de nouvelles URL en JavaScript. Si nous essayons ces "URL" et trouvons un 404, c’est génial et attendu. Nous ne voulons simplement rien rater d’important (insérez ici le mot Googlebot trop lié). http://support.google.com/webmasters/bin/answer.py?answer=1154698
- Vous n'avez pas besoin de corriger les erreurs d'analyse dans les Outils pour les webmasters. La fonctionnalité "marquer comme fixe" est uniquement destinée à vous aider si vous souhaitez suivre vos progrès là-bas; cela ne change rien à notre pipeline de recherche Web, alors n'hésitez pas à l'ignorer si vous n'en avez pas besoin. http://support.google.com/webmasters/bin/answer.py?answer=24674
- Nous répertorions les erreurs d'analyse dans les outils pour les webmasters par priorité, en fonction de plusieurs facteurs. Si la première page d’erreurs d’analyse n’est manifestement pas pertinente, vous ne trouverez probablement pas d’erreurs d’analyse importantes dans les pages suivantes. http://googlewebmastercentral.blogspot.ch/2012/03/crawl-errors-next-generation.html
- Il n’est pas nécessaire de "réparer" les erreurs d’analyse sur votre site Web. Trouver 404 est normal et attendu d’un site Web sain et bien configuré. Si vous avez une nouvelle URL équivalente, il est recommandé d’y rediriger. Sinon, vous ne devriez pas créer de faux contenu, vous ne devriez pas rediriger vers votre page d'accueil, vous ne devriez pas non plus robots.txt interdire ces URL - toutes ces choses rendent plus difficile pour nous de reconnaître la structure de votre site et de la traiter correctement. Nous appelons ces erreurs "soft 404". http://support.google.com/webmasters/bin/answer.py?answer=181708
- Évidemment, si ces erreurs d’exploration apparaissent pour les URL qui vous intéressent, par exemple les URL de votre fichier Sitemap, vous devez agir immédiatement. Si Googlebot ne parvient pas à analyser vos URL importantes, elles risquent alors d’être supprimées de nos résultats de recherche et les utilisateurs risquent de ne pas pouvoir y accéder.
Il existe une multitude de scripts qui analysent avec optimisme des adresses IP aléatoires sur Internet afin de détecter les vulnérabilités connues dans divers types de logiciels. 99,99% du temps, ils ne trouvent rien (comme sur votre site), et que 0,01% du temps, le script se connecte à la machine et fait ce que le contrôleur de script souhaite. Généralement, ces scripts sont exécutés par des réseaux de zombies anonymes à partir de machines qui ont été précédemment utilisées, et non à partir de la machine réelle du script original kiddie.
Que devrais tu faire?
- Assurez-vous que votre site n'est pas vulnérable. Cela nécessite une vigilance constante.
- Si cela génère une charge si importante que les performances normales du site sont affectées, ajoutez une règle de blocage basée sur IP pour éviter d'accepter les connexions du site particulier.
- Apprenez à filtrer les analyses de CMD.EXE, de cPanel ou de phpMyAdmin ou de nombreuses autres vulnérabilités lorsque vous parcourez les journaux de votre serveur.
Vous semblez croire que tout 404 renvoyé par votre serveur à quelqu'un aura une incidence sur ce que Google pense de votre site. Ce n'est pas vrai. Seuls les 404 renvoyés par les robots d'exploration de Google, et peut-être Chrome utilisateurs, affecteront votre site. Tant que tous les liens sur votre site sont des liens appropriés et que vous n'invalidez pas les liens que vous avez précédemment exposés au monde, vous ne verrez aucun impact. Les robots de script ne parlent en aucune manière à Google.
Si vous vous faites attaquer de manière réelle, vous devrez vous inscrire à un type de service de fournisseur de protection contre le déni de service. Verisign, Neustar, CloudFlare et Prolexic sont tous des fournisseurs qui prévoient différents types d’attaques - du simple proxy Web (qui peut même être gratuit de certains fournisseurs) au DNS basé sur le filtrage à la demande jusqu’au BGP complet. Basculements basés sur des points de présence qui envoient l'intégralité de votre trafic via un "nettoyage" de centres de données avec des règles permettant d'atténuer les attaques.
Ce que vous dites, c’est, semble-t-il, que vous ne voyez que les scripts de vulnérabilité normaux que toute adresse IP sur Internet verra si elle écoute sur le port 80. Vous pouvez littéralement mettre en place une nouvelle machine, démarrer un Apache vide, et dans quelques heures, vous verrez ces lignes dans le journal des accès.
Ce n'est probablement pas réellement une attaque mais un scan ou une sonde.
En fonction du scanner/prober, cela peut être bénin, c'est-à-dire qu'il ne recherche que les problèmes liés à un type de capacité de recherche ou qu'il peut avoir une fonction permettant d'attaquer automatiquement s'il trouve une ouverture.
Les navigateurs Web affichent des informations de référence valides, mais d’autres programmes ne peuvent créer que les références de leur choix.
Le référent est simplement une information fournie en option par les programmes accédant à votre site Web. Il peut s'agir de tout ce qu'ils choisissent de définir, par exemple totally.me ou random.yu. Il peut même s'agir d'un véritable site Web qu'ils viennent de sélectionner.
Vous ne pouvez pas vraiment résoudre ce problème ou l’empêcher. Si vous essayez de bloquer toutes les demandes de ce type, vous devez garder une très longue liste et cela ne vaut pas la peine.
Tant que votre hôte suit les correctifs et évite les vulnérabilités, cela ne devrait pas vous causer de problèmes.
En effet, cela ressemble à une frénésie de bot. Nous avons également été martelés par des milliers d'adresses IP sur de nombreux hôtes, probablement à l'insu de l'OP du site. Avant de proposer des solutions utiles, une question que je me pose est la suivante:
Q: Comment voyez-vous les 404 de votre site dans son ensemble dans les outils pour les webmasters de Google? GWT est la sortie des résultats de Googlebots, pas la sortie des autres robots. En outre, ces autres robots ne font pas tourner JS pour l'analyse ... Avez-vous une sorte d'API allant à GWT où vous pouvez voir les statistiques de votre serveur? Si ce n'est pas le cas, cela peut être une cause d'alarme car c'est Googlebot lui-même qui trouve des erreurs.
S'il s'agit juste d'erreurs googlebot, cela peut indiquer qu'une personne a créé des liens vers votre site sur des forums et autres pour les cibles de robots malveillants générés par des ordinateurs réels qui le touchent. Pensez à harverstor + planter exécuté sur un serveur exploité, en configurant une tonne de cibles pour les futurs "contrats de spam".
Si vous savez en effet qu’il signale l’ensemble des statistiques de votre serveur, vous avez besoin de quelques outils. Quelques applications et services peuvent vous aider à le réduire. En supposant que vous utilisez un serveur linux:
1) Commencez à ajouter des adresses IP offensantes à une liste noire htaccess. Cela ressemble à "nier à partir de 192.168.1.1" et 403 leur sera interdit. Ne vous laissez pas emporter, ne faites que bloquer les biggens. Vérifiez-les par rapport aux sites de l’étape 4) pour vous assurer qu’ils ne sont pas de vrais fournisseurs d’accès Internet. Vous pouvez copier ce fichier et le coller sur n'importe quel compte/application au-delà du pare-feu, même.
2) Installez APF. c'est vraiment facile de gérer le pare-feu via SSH sous Linux. Pendant que vous construisez le ht, ajoutez-les dans APF comme "apf -d 192.168.1.1". Ht semble redondant à cause de l'APF, mais Ht est portable.
) Installez cPanel Hulk et veillez à ce que votre adresse IP soit inscrite dans la liste blanche afin qu'elle ne vous bloque jamais si vous oubliez un laissez-passer. Ce sera également une belle source d’adresses IP à ajouter à ht + apf. Il a certaines capacités pour pouvoir atténuer intelligemment les tentatives de connexion par force brute.
4) Connectez-vous à stopforumspam.com et projecthoneypot.org et lancez leurs modules. Les deux aident beaucoup à refuser les demandes connues et à identifier + signaler de nouvelles brutes/nets/chinaspam. Vous pouvez également utiliser des filtres de messagerie, mais Gmail en est le propriétaire en ce qui concerne le filtre anti-spam.
5) Puisque les robots ne lâchent jamais, protégez vos chemins d'administrateur. Si vous exécutez wordpress, modifiez le chemin d'accès de l'administrateur, ajoutez captcha, etc. Si vous utilisez SSH, modifiez le port de connexion en indiquant un paramètre non utilisé, puis désactivez la connexion root SSH. Créez un "radmin" auquel vous devez vous connecter en premier, puis su pour root.
Une remarque à propos de captcha, si vous exécutez votre propre captcha sur un site à volume élevé et que vous ne refusez pas la frénésie de bot au niveau pare-feu/ht, ils risquent de marteler vos cycles de processeurs en raison de la génération d'images dans tous ces widgets "antispam".
Remarque sur la charge, si vous utilisez CentOS sur votre serveur et que vous possédez des capacités VPS, CloudLinux est fantastique pour le renforcement et le contrôle de la charge. Supposons qu'un bot passe, CageFS est là pour le limiter à un compte. Disons qu'ils décident de DDoS .... LVE est là pour garder la charge du compte (site) limitée afin de ne pas planter votre serveur. C'est un bon ajout pour accentuer tout le système de "gestion des entités erronées" :)
Juste quelques réflexions, j'espère que cela vous aide
Explication du problème
Tout d’abord, vous n’êtes pas le seul à avoir ce problème, tout le monde l’est. Ce que vous avez vu est le résultat de robots automatisés qui explorent toutes les adresses IP et recherchent des vulnérabilités communes. Donc, ils essaient de trouver ce que vous utilisez et si vous utilisez phpmyadmin, ils essaieront plus tard un ensemble de combinaisons de mots de passe username standard.
Je suis surpris que ce genre de chose que vous avez trouvé tout à l'heure (vous venez peut-être de démarrer votre serveur). Le problème est que vous ne pouvez pas bloquer leur adresse IP pour toujours (le plus probablement, il s'agit d'un ordinateur infecté et son utilisateur réel ne sait pas ce qu'il fait, il existe également beaucoup d'adresses IP de ce type).
Effet SEO
Cela n'a aucun effet. Cela signifie simplement que quelqu'un a essayé d'accéder à quelque chose sur votre ordinateur et que ce n'était pas là
Est-ce vraiment important?
Bien sûr, ces personnes essaient de vous chercher des problèmes. De plus, ils gaspillent vos ressources (votre serveur doit réagir d’une manière ou d’une autre) et polluent votre fichier journal.
Comment dois-je résoudre ce problème
J'ai eu le même problème que j'ai essayé de résoudre et le meilleur outil (simplicité d'utilisation vs ce que je peux faire avec), j'ai été capable de trouver est fail2ban
Vous avez également la chance d'avoir déjà trouvé un moyen de résoudre le même problème et même de l'avoir documenté ici (vous n'avez donc pas besoin de savoir comment l'installer ni le faire fonctionner). Vérifiez ma question sur ServerFault . Mais s'il vous plaît lisez un peu sur fail2ban pour savoir qu'il fonctionne.
Comme beaucoup l'ont déjà dit, il ne s'agit pas d'une attaque, mais d'une tentative d'analyse ou d'analyse de votre application de site et/ou des capacités de votre serveur. Le meilleur moyen de filtrer tout ce trafic inutile et ces analyses potentiellement dangereuses consiste à mettre en œuvre un WAF (Web Application Firewall). Cela capturera toutes les différentes tentatives et les signalera, puis seulement à envoyer du trafic propre et légitime à vos serveurs et à vos applications Web.
Vous pouvez utiliser un WAF DNS basé sur un nuage ou des périphériques dédiés. Personnellement, j'utilise Incapsula et F5 ASM pour différents sites clients. Les coûts sont aussi bas que 500 $ par mois et aident énormément. Il offre également une meilleure protection à vos clients et réduit les ressources sur les serveurs Web eux-mêmes, ce qui vous permettra d'économiser de l'argent et d'augmenter votre vitesse. En outre, ces périphériques offrent la conformité à la norme PCI 6.6 et des rapports avec des rapports.
J'espère que cela t'aides.