web-dev-qa-db-fra.com

Fichiers inconnus figurant dans la liste de pages d'erreur 404 de mon site Web sans URL de renvoi

J'ai vu de nombreuses entrées dans ma liste de pages d'erreur 404 dans mon compte d'hébergement partagé, qui constituent des tentatives d'accès aux sous-URL sur mon site Web 'statique', telles que (généralement sans URL de renvoi):

/\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd%20website.rar
/aspweb.rar
/520.rar
/install.tar.gz
/sql.bak
/a.rar
/web123.Zip
/aspweb.Zip
/wwwroot.tar

Ce sont en dehors des tentatives habituelles sur /wp-login.php, etc ...

Je me demande si quelqu'un peut expliquer ce qui précède. S'agit-il de tentatives de piratage? Devrais-je m'inquiéter ou les ignorer? Le site traverse CloudFlare via HTTPS.

2
zod

Tous les fichiers en cours de vérification, y compris le /\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd mentionné dans votre dernier commentaire, constituent des tentatives d'attaque visant à identifier les fichiers communs potentiellement vulnérables à la racine de votre site Web qui, sur un site Web mal configuré, peuvent fournir un attaquant les informations dont ils ont besoin pour pénétrer votre site.

À titre d'exemple, sql.bak est un fichier de sauvegarde SQL standard qu'un attaquant peut utiliser pour accéder à l'intégralité de votre base de données à partir de la dernière sauvegarde, s'il le peut. aspweb.Zip et les autres fichiers similaires sont couramment utilisés par les webmasters pour conditionner le site et le télécharger dans un fichier compressé, puis le décompresser sur le serveur, en laissant souvent le fichier compressé. Si un attaquant met la main sur ce fichier, il disposera d'une copie complète du code source de votre site si vous utilisiez cette méthode.

Toutes ces entrées de journal indiquent des tentatives d’attaque sur votre site qui sont courantes et peuvent se produire sur n’importe quel site. Essayez définitivement d'empêcher ces connexions de se connecter à votre site pour ajouter un niveau de protection supplémentaire à votre site, mais ne présumez pas qu'il sera bloqué à 100%, car aucun ne le sera à 100%, car les attaquants pourront le contourner. Effectuez un audit de sécurité sur votre site et assurez-vous que les vulnérabilités ont été corrigées, que des fichiers tels que ceux-ci ne sont pas accessibles et que, si elles doivent se trouver sur le serveur, elles ne se trouvent pas dans la racine Web.

2
Chris Rutherfurd