Mon serveur continue à recevoir des requêtes avec l'agent utilisateur identifié comme étant BOT/0.1 (BOT for JCE)
. Le premier est arrivé le 2013-09-14 22:13:17 CEST, le dernier il y a environ trois jours, 2014- 08-12 06:05:39 CEST.
La plupart d'entre eux (environ 60%) utilisent la méthode GET de HTTP/1.1 et tentent d'obtenir index.php
à divers emplacements sur mon site en fonction des chemins que j'utilise déjà. Ils donnent toujours une réponse avec le code d’état 404 (Introuvable) ou 400 (Demande incorrecte), car je n’utilise pas du tout PHP.
Environ 40% d'entre elles sont des requêtes HTTP/1.1 POST pour /index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager…&cid=20…
où …
sont soit
&version=1576
et chaîne vide (environ 50%), ou&method=form
et
&6bc427c8a7981f4fe1f5ac65c1246b5f=cf6dd3cf1923c950586d0dd595c8e20b
(environ 50%), ou
rarement &method=form
et
&6bc427c8a71281f4fe1f5ac65c1246b5f=cf6dd3cf11223c1250586d0dd5125c8e20b
Comme pour les requêtes GET, il est parfois ajouté après une URL utilisée par mon site. La plupart (75%) aboutissent à 404 ou 400; mais quand ils arrivent sur mon installation de MwForum (25%), même 200 OK (pour le premier sous-type) ou 500 Internal Server Error (pour les deuxième et troisième sous-types) sont générés, ce qui, je suppose, est simplement un mauvais codage de MwForum.
Environ 5% d'entre elles (erreur d'arrondi dans les pourcentages ci-dessus) sont des requêtes totalement mal formées, ayant des parties de code HTML sur la ligne de requête où le chemin et la chaîne de requête doivent se trouver. La plupart d'entre eux essaient POST to MwForum. Au début, il y a l'URL de l'une des pages de mon site, suivie d'un guillemet, du code HTML, puis d'un autre URL avec /index.php?option=com_jce&…
ajouté. Ils viennent probablement de Webscraping muet.
Exemple de lignes de journal:
2014-08-05 22:50:32 93.95.74.25 "HTTP/1.1" GET example.com "/index.php" 400 0 0 "-" "BOT/0.1 (BOT for JCE)" "-"
2014-02-23 08:50:35 202.29.16.241 "HTTP/1.1" POST example.com "/mwforum/topic_show.pl?tid=1485/index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&method=form&cid=20&6bc427c8a7981f4fe1f5ac65c1246b5f=cf6dd3cf1923c950586d0dd595c8e20b" 500 711 0 "-" "BOT/0.1 (BOT for JCE)" "-"
2014-01-28 15:25:55 94.23.4.47 "class=\"url\" data-dot=\"url\">example.com/mwforum/topic_show.pl?tid=1485</a> </div> </div> </div> <script> JAK.Fulltext.ResultScreenshotResize(\"#resultNumber4\"); </script> </div> <div data-dot=\"4\" data-Elm=\"r4\"> <div class=\"modCont result cr\" id=\"resultNumber5\"> <a href=\"http:/tracker.modx.com/issues/7324\" class=\"fullclick\"></a> <div class=\"screenshot\"> <a id=\"modImgA-5\" href=\"http:/tracker.modx.com/issues/index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&method=form&cid=20&6bc427c8a7981f4fe1f5ac65c1246b5f=cf6dd3cf1923c950586d0dd595c8e20b HTTP/1.1" POST example.com "/mwforum/topic_show.pl?tid=1485\"" 500 711 0 "-" "BOT/0.1 (BOT for JCE)" "-"
Le bot essaie-t-il d’exploiter Joomla Content Editor (JCE)? Je n’utilise ni JCE, ni Joomla, ni PHP lui-même. Que dois-je faire à propos de ces demandes?
Oui, ce bot tente d'exploiter JCE. Il utilise probablement un très puissant exploit publiquement disponible (+ miroir ) pour JCE < 2.0.11. Bien qu'il s'agisse d'une version vraiment obsolète, de nombreuses instances sont toujours dans la nature. JCE 2.0.11 est sorti le 2011-08-29, l'exploit est disponible après la sortie (si son auteur a gardé son mot).
Si JCE n'est pas installé sur votre site, vous pouvez ignorer ces entrées de journal en toute sécurité. (À moins que quelqu'un d'autre ne masque son attaque comme celle-ci. On ne peut jamais savoir…)
Si vous utilisez une version obsolète de JCE, mettez-le immédiatement à niveau et vérifiez si votre site n'a pas été endommagé. Vous devriez probablement plonger dans la section Vers les webmasters. d'un article en rapport sur le blog Unmask Parasites .
Comme vous pouvez le constater, c’est quelque chose que vous ne pouvez ni négliger ni considérer comme une menace insignifiante. C’est idiot d’espérer que les pirates informatiques ne trouveront pas votre site. Aujourd'hui, les pirates disposent de ressources pour naviguer sur Internet presque aussi efficacement que Google il y a à peine 10 ans. Il n'y a donc aucune chance que votre site reste inaperçu. Le seul moyen d'éviter les intrusions est d'être proactif: maintenez tous les logiciels à jour et renforcez vos sites.
En cas d'attaque de l'entreprise criminelle commune:
- Assurez-vous de mettre à niveau votre site Joomla vers la version la plus récente.
- Mettez à niveau JCE vers la dernière version. Vous pouvez trouver des packages de téléchargement pour les trois branches de Joomla ici .
Protégez tous les répertoires de téléchargement de fichiers et tous les répertoires qui ne devraient pas contenir de fichiers .php. Par exemple, placez-y le fichier .htaccess suivant pour empêcher l'exécution des fichiers PHP:
<Files *.php> deny from all </Files>
Essayez de bloquer les demandes avec la chaîne " BOT/0.1 (BOT pour JCE) " de l'agent utilisateur. Bien entendu, cela ne devrait pas être considéré comme une véritable protection. Les pirates peuvent modifier la chaîne User-Agent comme bon leur semble. Mais cela peut aider à garder certains bots ennuyeux et ennuyeux loin de votre site.
- Si, pour une raison quelconque, vous ne pouvez pas mettre à niveau votre site à ce moment, envisagez de le placer derrière un pare-feu de site Web qui bloquera tout trafic malveillant avant qu’il n’atteigne votre serveur. C’est quelque chose que nous appelons patch virtuel dans Sucuri CloudProxy .
Avertissement: Je ne suis affilié à Sucuri d'aucune façon.
.htaccess
@ Stack Overflow (blocage via l'envoi de 403 Forbidden lorsque l'agent utilisateur est détecté)