-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/10/2015 15:13, andre_deb...@numericable.fr wrote: > On Friday 02 October 2015 13:38:21 BERTRAND Joc3abl wrote: >> andre_deb...@numericable.fr a écrit : >>> On Friday 02 October 2015 12:34:49 yamo' wrote: >>>> andre_deb...@numericable.fr a écrit le 02/10/2015 11:10 : >>>>> Je reçois ce message d'alerte (logwatch), venant d'un >>>>> serveur sous Debian : ==================== A total of 3 >>>>> possible successful probes were detected (the following >>>>> URLs contain strings that match one or more of a listing of >>>>> strings that indicate a possible exploit): >>>>> /index.php?rev=../ect/passwd HTTP Response 200 >>> /index.php?rev=../../../../../../../../../../../../../../../../../.. /etc/passwd >>>>> >>> HTTP Response 200 >>>>> /index.php?rev=../../../../../../../../../etc/passwd HTTP >>>>> Response 200 ==================== Il est indiqué "3 >>>>> possible tentatives avec succès..." Y a t-il un danger que >>>>> les mots de passe soient connus... ?
Cette alerte fait référence à une attaque nommé "Local File Inclusion". Cette technique permet à un utilisateur mal attentionnée d'inclure dans le contenu d'une page, soufrant de ce problème de conception, un fichier présent sur le serveur hébergeant le site internet (Fichier Local au serveur). Dans le cas de votre extrait de Log, le fichier qui à tenté d'être inclut est le fichier '/etc/passwd'. Que ces trois requêtes HTTP répondent toutes les trois le code de réponse HTTP 200 (Code signifiant réponse HTTP réussi). Cela ne signifie pas distinctement la réussite de l'attaque visant à accéder au fichier '/etc/passwd' de votre serveur. En effet toute requête HTTP valide vers une page mise à disposition par un serveur HTTP (apache, nginx, etc..) renvoie le code 200 lorsque la page est accessible. Vulgairement, si le fichier 'index.php' existe sur votre serveur, votre serveur répondra le code 200 lorsqu'un utilisateur tentera d'accéder à cette page, et ce quelque soit l'argument passé à cette page. Dans le cas de votre log, nous voyons que les 3 requêtes relevés par l'utilitaire 'watchlog' répondent toutes les 3 un code 200. Et c'est 3 requêtes ont à chaque fois un argument différent : * ?rev=../ect/passwd * ?rev=../../../../../../../../../../../../../../../../../../etc/passwd * ?rev=../../../../../../../../../etc/passwd La réponse d'un code de réponse HTTP 200 n'étant pas un élément suffisant pour dire que cela est l'efficience d'une intrusion, il faut aussi savoir que l'inclusion réussi d'un fichier ne génère aucune erreurs. Dans ce genre de cas, l'audit, communément appeler "analyse forensic", permettant de savoir si il y eu réellement une intrusion peut s'avérer vraiment difficile. Pour vous donner un ordre idée, les éléments techniques nécessaires pour le diagnostique des 3 paragraphes ci-dessus nécessite la connaissance des éléments suivants : La concepts de base du protocole HTTP : http://abcdrfc.free.fr/rfc-vf/rfc3229.html Les concepts de base du langage PHP : http://fr.php.net/manual/fr/ Les chemins d'accès aux fichiers : http://www.cyberciti.biz/faq/relative-pathname/ Les rudiments sur le fichier de mots de passe de Linux : http://man7.org/linux/man-pages/man5/passwd.5.html A votre niveau, votre extrait de log fait référence à 3 tentatives d'inclusion de fichier avec un argument différent. Ces arguments étant des chemin d'accès, cela laisse la chance qu'il ait un échec d'inclusion et donc une erreur dans vos log. L'erreur relative à l'inclusion d'un fichier, dans une configuration conventionnel, n'est pas une réponse du protocole HTTP mais un message générer par le moteur de script permettant la génération d'un contenu dynamique : PHP, ASP, Python, etc... Il est intéressant de regarder les erreurs de ce dernier afin d'avoir une meilleur idées au sujet de l'éventuelle inclusion survenu sur votre serveur. Ce sont les motifs suspicieux "../" et "/etc/passwd" qui ont fait réagir l'utilitaire 'watchlog'. Ces motifs sont des éléments rencontrés lors d'intrusion et il est intrigant de les trouver dans une requête HTTP conventionnelle. Je pense que ces lignes de log sont à voir comme des éléments initiaux d'une investigation plus avancées pouvant être décider par le responsable d'un serveur. Et cela est unique l'intêret d'un outil d'analyse de fichier Log. A ce niveau, cette investigation est la vérification des erreurs PHP via le fichier 'syslog', le systéme de journal de 'systemd' ou les logs de votre services de serveur WEB. Vous avez fait référence à "apache" dans les messages précédant et au vu de la sortie de votre outils d'audit de log votre moteur de script dynamique est PHP. Il serait intéressant, dans le cas d'un désir d'investigation de votre part, de regarder les erreurs de PHP relatives aux fonctions d'inclusion de contenu de PHP dans le fichier de Log '/var/log/apache/error.log'. Je précise que la lecture des documentations ci-dessus sont nécessaires pour cette investigation. >>> >>>> Les mots de passe, non, mais les logins et les mots de passe >>>> chiffrés. Sans indiscrétion, quel est ce index.php moisi ? >>>> Cordialement, JKB >>> >>> Le fichier d'index du site et pourquoi serait-il "moisi" ? p. >>> ex : "http://trucmuche.fr/index.php?rev=kata.php" >> >> Ce qui m'inquiète, c'est la réponse '200' qui aurait tendance à >> indiquer qu'un utilisateur distant peut récupérer le contenu de >> /etc/passwd. Si c'est le cas, le fichier index.php est moisi et >> la configuration d'apache est à revoir. La question était : >> est-ce que le index.php est fait maison ou provient d'un logiciel >> tiers (spip, joomla ou autre) ? JKB > > fait maison, c'est du classique dans les sites Web, la page > "index.php" reçoit les contenus des autres pages. > J'imagine que vous faites référence à l'utilisation des fonctions "include" ou "require" de PHP. Ces dernières sont connu pour être sensible pour la sécurité d'un site Internet et du serveur qui l'héberge . > Comment faire autrement ? Le plus sure est d'utiliser des pages statique (100% HTML) avec des liens fixe pointant vers les pages que vous souhaitez rendre accessible depuis votre pages. Si vous souhaitez maintenir une technologie dynamique pour votre page Internet, il est intéressant de connaître les risques d'implémentation de se type de langage. Dans le contexte de votre question, il est capitale de savoir que pour la sécurité d'une page Internet dynamique tout les arguments passés a une page Internet, qu'ils soit par l'URL ou par des formulaires, sont à considérer comme potentiellement dangereux. La sécurité de toute votre infrastructure dépends du fait qu'ils soient filtrés le plus strictement possible. Dans le cas de la sécurité lors d'inclusion de fichier, qui n'est qu'un concept de sécurité des sites internet dynamique parmi plusieurs autres, il faut que tout les tentatives d'inclusions de fichiers soit vers des fichiers que vous avez expressément vérifié comme étant légitimes. > > André > Bonne chance Florian. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWFAHwAAoJEBGYNnE0a7qPXqoQAJw6dcA2YDVbQeu1e7aY0et6 hOcycVGobJ7h0Uj8u8/B/j3/TkQbWxMnY6FjCkgbIJrvwlVU381pbWjNI/OCmF8X DvCqqXViTxvkoPhInV8MWDVR/Q+S7qIKsrY60Gx4kTuEtYjSFBX20RTNlgAWRNZe D+eEiuN+q+Kbwf3gfNhLB4vuvfrx8z49VCYDbhAqVf0HihK69o98La+QDFeD2iVI kcE0hxsu7N6IS1SXeWpi0fv91RSZSUM1i4By9wO8O/XVfutKRhKSxNs4RIhSULGJ VXbW3JGs4MsQic0W3BveGeq5AQ8BBJksQNZ2gAuP/OpjRB43PQKICfKh2LfQZJAv oyhLVkhf1ANWciznxT5fF22WaQVeFdqyOcr185M+pURWcPKBoWkbFxdCI9xxnP/j 1fXg0wevTeU2oZuzDlBM65dugoWL5PZrp6BYi/70AltbLzvWj2quvMAUyFbCbfmK LyzEKy/BikV8uj9Qf6x+HVBZQBZ3839OC44Sr6fm5QT6Ve5zYG2w13uKbCkFjPWR Da5TPYEwceASEJqg76Uf7OS0o8tscH/EK6ihkCE/uyzqvY0vt2Kbhoc5JHtWL1/K S07omnpJVfpFzm03XbYt0ayD8sdH65P4m1Ov59BB46pQWlV+5s8RIhkY+73jAdMi iZLT+9rxEH2ZEtlTnUoV =5oR5 -----END PGP SIGNATURE-----