Attaque massive 404 avec des URL inexistantes. Comment éviter cela?

Le problème est une charge entière de 404 erreurs, comme signalé par les outils pour les webmasters de Google, avec des pages et des requêtes qui n'y ont jamais été. 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 équipé d'une défense contre le scan / le piratage. Cependant, cela ne semble pas s'arrêter. Le referrer est, selon Google Webmaster, totally.me.

J'ai cherché une solution pour arrêter cela, car ce n'est certainement pas bon pour les vrais 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érenceur standard (pour les sites pornographiques, à base de plantes, de casino), et même certains logiciels pour protéger le 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 le réparer, ou mieux, d'éviter ce gaspillage inutile de ressources?

EDIT Je n'ai jamais utilisé la question pour remercier pour les réponses, et j'espère que cela pourra être fait. Merci à tous pour vos réponses perspicaces, qui m'ont aidé à trouver un moyen de m'en sortir. J'ai suivi les suggestions de tout le monde et mis en œuvre ce qui suit:

• un pot de miel
• un script qui écoute les URL suspectes dans la page 404 et m'envoie un e-mail avec l'agent utilisateur / 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 certaines adresses IP suspectes, toutes répertoriées dans Spamhaus. Toutes les adresses IP enregistrées jusqu'à présent appartiennent à des sociétés d'hébergement VPS spam.

Merci encore à tous, j'aurais accepté toutes les réponses si j'avais pu.

Je vois souvent un autre site qui renvoie vers des tonnes de pages de mon site qui n'existent pas. Même si vous cliquez sur cette page et ne voyez pas le lien:

• Le site peut avoir précédemment eu ces liens
• Le site peut être masqué et servir ces liens uniquement à Googlebot et non aux visiteurs

C'est un gaspillage de ressources, mais cela ne confondra pas Google et ne nuira pas à votre classement. Voici ce que John Mueller de Google (qui travaille sur les outils pour les webmasters et les sitemaps) a à dire sur les erreurs 404 qui apparaissent dans les outils pour les webmasters :

AIDEZ-MOI! MON SITE A 939 ERREURS DE CRABE !! 1

Je vois ce genre de question plusieurs fois par semaine; vous n'êtes pas seul - de nombreux sites Web comportent des erreurs d'exploration.

1. Les erreurs 404 sur les URL invalides ne nuisent en rien à l'indexation ou au classement de votre site . Peu importe qu'il y en ait 100 ou 10 millions, ils ne nuiront pas au classement de votre site. http://googlewebmastercentral.blogspot.ch/2011/05/do-404s-hurt-my-site.html
2. Dans certains cas, les erreurs d'exploration peuvent provenir d'un problème structurel légitime au sein de votre site Web ou CMS. Comment le dites-vous? Vérifiez l'origine de l'erreur d'analyse. S'il y a un lien cassé sur votre site, dans le HTML statique de votre page, cela vaut toujours la peine d'être réparé. (merci + Martino Mosna )
3. Qu'en est-il des URL géniales qui sont "clairement cassées?" Lorsque nos algorithmes aiment votre site, ils peuvent essayer de trouver plus de contenu sur celui-ci, 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 manquer d'important (insérez ici un mème Googlebot trop attaché). http://support.google.com/webmasters/bin/answer.py?answer=1154698
4. Vous n'avez pas besoin de corriger les erreurs d'exploration dans les outils pour les webmasters. La fonction «marquer comme fixe» est uniquement pour vous aider, si vous souhaitez suivre vos progrès là-bas; cela ne change rien dans notre pipeline de recherche sur le Web, alors n'hésitez pas à l'ignorer si vous n'en avez pas besoin. http://support.google.com/webmasters/bin/answer.py?answer=2467403
5. Nous répertorions les erreurs d'exploration dans les outils pour les webmasters par priorité, qui est basée sur plusieurs facteurs. Si la première page d'erreurs d'exploration n'est clairement pas pertinente, vous ne trouverez probablement pas d'erreurs d'exploration importantes sur les pages suivantes. http://googlewebmastercentral.blogspot.ch/2012/03/crawl-errors-next-generation.html
6. Il n'est pas nécessaire de «corriger» les erreurs d'exploration sur votre site Web. Trouver des 404 est normal et attendu d'un site Web sain et bien configuré. Si vous avez une nouvelle URL équivalente, la redirection vers celle-ci est une bonne pratique. Sinon, vous ne devez pas créer de faux contenu, vous ne devez pas rediriger vers votre page d'accueil, vous ne devez pas empêcher robots.txt de ces URL - toutes ces choses nous rendent plus difficile de reconnaître la structure de votre site et de le traiter correctement. Nous appelons ces erreurs «soft 404». http://support.google.com/webmasters/bin/answer.py?answer=181708
7. Évidemment - si ces erreurs d'exploration apparaissent pour les URL qui vous intéressent, peut-être des URL dans votre fichier Sitemap, c'est quelque chose que vous devez prendre immédiatement. Si Googlebot ne peut pas explorer vos URL importantes, elles peuvent être supprimées de nos résultats de recherche et les utilisateurs ne pourront peut-être pas y accéder non plus.

Il existe des tonnes de scripts qui analysent de manière optimiste des adresses IP aléatoires sur Internet pour trouver des 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 alimentera la machine et fera tout ce que le contrôleur de script veut. En règle générale, ces scripts sont exécutés par des réseaux de zombies anonymes à partir de machines qui ont été précédemment pwnd, et non à partir de la machine réelle du script kiddie d'origine.

Que devrais tu faire?

1. Assurez-vous que votre site n'est pas vulnérable. Cela nécessite une vigilance constante.
2. Si cela génère une charge telle que les performances normales du site sont affectées, ajoutez une règle de blocage basée sur IP pour éviter d'accepter des connexions à partir du site particulier.
3. Apprenez à filtrer les analyses pour CMD.EXE ou cPanel ou phpMyAdmin ou des tonnes d'autres vulnérabilités lorsque vous parcourez les journaux de votre serveur.

Vous semblez croire que tout 404 renvoyé par votre serveur à quiconque aura un impact 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 les utilisateurs de Chrome, 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 aucun cas à Google.

Si vous êtes attaqué de manière réelle, vous devrez vous inscrire à une sorte de service de fournisseur d'atténuation DoS. Verisign, Neustar, CloudFlare et Prolexic sont tous des fournisseurs qui ont différents types de plans pour différents types d'attaques - du simple proxy Web (qui peut même être gratuit auprès de certains fournisseurs) au DNS basé sur le filtrage à la demande, jusqu'au BGP complet des balançoires de point de présence basées qui envoient tout votre trafic à travers des centres de données de "nettoyage" avec des règles qui atténuent les attaques.

Mais, d'après ce que vous dites, il semble que vous ne voyez que les scripts de vulnérabilité normaux que toute IP sur Internet verra s'il écoute sur le port 80. Vous pouvez littéralement installer une nouvelle machine, démarrer un Apache vide, et dans quelques heures, vous commencerez à voir ces lignes dans le journal d'accès.

Ce n'est probablement pas une attaque, mais un scan ou une sonde.

Selon le scanner / prober, il peut être bénin, ce qui signifie qu'il recherche simplement des problèmes dans un certain type de capacité de recherche ou qu'il pourrait avoir une fonction pour attaquer automatiquement s'il trouve une ouverture.

Les navigateurs Web mettent des informations de référence valides, mais d'autres programmes peuvent simplement constituer le référent qu'ils aiment.

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 le définir comme totally.meou 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 avez essayé de bloquer toutes les demandes de ce type, vous finissez par devoir maintenir une très grande liste et cela n'en vaut pas la peine.

Tant que votre hôte suit les correctifs et prévient les vulnérabilités, cela ne devrait pas vous causer de problèmes réels.

En effet, cela ressemble à une frénésie de bot. Nous avons également été frappés par des milliers d'IP sur de nombreux hôtes, probablement à l'insu du site OP. Avant de proposer des solutions utiles, une question que j'ai:

Q: Comment voyez-vous les 404 de votre site dans son ensemble dans les outils Google pour les webmasters? GWT est la sortie des résultats de Googlebots, pas la sortie d'autres bots. De plus, ces autres bots n'exécutent pas JS pour l'analytique ... avez-vous une sorte d'API qui va à GWT où vous pouvez voir les statistiques de votre serveur? Si ce n'est pas le cas, cela peut être alarmant, car googlebot lui-même trouve des erreurs.

• S'il s'agit JUSTE d'erreurs googlebot, cela pourrait indiquer que quelqu'un a planté des liens vers votre site sur des forums et des choses pour des cibles de robots malveillants réels sur PC. Pensez harverstor + planter fonctionnant sur un serveur exploité, établissant une tonne de cibles pour les futurs "contrats de spam" à passer.

• Si vous savez en effet qu'il rapporte vos statistiques complètes sur le serveur, alors vous avez besoin de quelques outils. Quelques applications et services peuvent vous aider à le réduire. En supposant que vous exécutez un serveur Linux:

1) Commencez à ajouter des adresses IP incriminées à une liste noire htaccess. Il ressemble à "refuser de 192.168.1.1" et sera interdit par 403. Ne vous laissez pas emporter, bloquez simplement les biggens. Vérifiez-les par rapport aux sites de l'étape 4) pour vous assurer qu'ils ne sont pas de vrais FAI. Vous pouvez même copier ce fichier et le coller sur n'importe quel compte / application au-delà du pare-feu.

2) Installez APF. il est très facile de gérer le pare-feu via SSH sous linux. Lorsque 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.

3) Installez cPanel Hulk et assurez-vous de mettre votre IP en liste blanche afin qu'elle ne vous bloque jamais si vous oubliez un laissez-passer. Ce sera également une bonne source d'IP à ajouter à ht + apf. Il a quelques astuces pour qu'il puisse 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 / filets / chinaspam. Il existe également des filtres de messagerie, mais Gmail en est propriétaire en ce qui concerne le filtre anti-spam.

5) Puisque les bots ne lâchent jamais, protégez vos chemins d'administrateur. Si vous exécutez wordpress, changez le chemin d'administration, ajoutez captcha, etc. Si vous utilisez SSH, changez le port de connexion en quelque chose de non utilisé, puis désactivez la connexion root SSH. Créez un "radmin" auquel vous devez vous connecter d'abord, puis su pour root.

• Une note sur le captcha, si vous exécutez votre propre captcha sur un site à volume élevé et ne niez pas la frénésie du bot au niveau du pare-feu / ht, ils peuvent marteler vos cycles de processeur en raison de la génération d'images dans tous ces widgets "antispam".

• Une note sur la charge, si vous exécutez CentOS sur votre serveur et avez 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 maintenir la charge du compte (site) plafonnée afin de ne pas planter votre serveur. C'est un bon ajout pour accentuer tout le système de "gestion d'entités malveillantes" :)

Juste quelques réflexions, j'espère que ça 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 chaque IP et recherchent des vulnérabilités courantes. Donc, ils essaient essentiellement de trouver ce que vous utilisez et si vous utilisez phpmyadmin, ils essaieront plus tard un tas de combinaisons de mots de passe de nom d'utilisateur standard.

Je suis surpris que ce genre de chose que vous ayez 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 (il s'agit très probablement d'un ordinateur infecté et son utilisateur réel ne sait pas ce qu'il fait, il y a aussi beaucoup de telles adresses IP).

Effet SEO

Cela n'a aucun effet. Cela signifie simplement que quelqu'un a essayé d'accéder à quelque chose sur votre ordinateur et qu'il n'était pas là

Est-ce vraiment important?

Bien sûr, ces gens essaient de vous sonder pour certains 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 le réparer

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 en faire) que j'ai pu trouver est fail2ban

Vous avez également la chance car j'ai déjà trouvé un moyen de résoudre le même problème et je l'ai même documenté ici (vous n'avez donc pas besoin de trouver comment l'installer et comment le faire fonctionner). Vérifiez ma question sur ServerFault . Mais s'il vous plaît lisez un peu sur fail2ban pour savoir comment cela fonctionne.

Comme beaucoup l'ont déjà dit, il ne s'agit pas d'une attaque mais d'une tentative de sonder ou d'analyser votre application de site et / ou les capacités de votre serveur. La meilleure façon de filtrer tout ce trafic inutile et les analyses potentiellement dangereuses est d'implémenter un WAF (Web Application Firewall). Cela va attraper toutes les différentes tentatives et les signaler et ensuite seulement envoyer un véritable trafic propre légitime à vos serveurs et à votre application Web.

Vous pouvez utiliser le WAF DNS basé sur le cloud ou des appareils dédiés. J'utilise personnellement 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 fera économiser de l'argent et augmentera la vitesse.En outre, ces appareils offrent la conformité PCI 6.6 et des examens avec des rapports.

J'espère que cela t'aides.