-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09/10/2015 13:27, andre_deb...@numericable.fr wrote: > Merci de cette réponse aussi détaillée que longue :-) > > Le error.log d'apache2 n'indique pas d'erreur particulière. > > si je tape dans la barre d'URL : > "www.monsite.com/index?rev==../../../../... /etc/passwd", je reçois > : Erreur ! J'y ai mis une protection sur l'accès aux répertoires > sensibles. > >> 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 page : > > C'est ce qui est fait, mais les pages 100% html sont nommées > "<fichier>.php".
Je voulais dire par pages 100% HTML des pages contenant aucun code dynamique (pas de PHP). > >> 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 : > > Le PHP est un langage de sites dynamiques, comment faire autrement > ? > > "php.ini" traite les variables de formulaires, selon le mode > "register_global = off", avec transmission de la variable à la page > de traitement par : ...$_POST["name"]... Que peut-on faire de plus > ? Filtrer en supprimant tout motif suspicieux du contenu des variables dites super-globales telle que $_GET, $_POST, $_FILE, etc... (http://php.net/manual/fr/language.variables.superglobals.php). Ces variables peuvent contenir des informations venant des visiteurs de votre sites Internet et donc potentiellement contenir des vecteurs de compromissions. Dans le cas spécifique à votre question la méthode de ma réponse prétendante est un moyen possible. Je cite : "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." (Création d'une Whitelist par exemple.) > > sinon de ne pas créer de sites Web :-) Les pages statiques, sans code dynamique telle que PHP, sont une solution sûre. > > André > Florian. > On Tuesday 06 October 2015 19:16:32 BERBAR Florian wrote: >> On 02/10/2015 15:13, andre_deb...@numericable.fr wrote: >>>>>>> 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. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWF69RAAoJEBGYNnE0a7qPjLUQALFpvLTCvnq4vhPtpgHXaYlh Ps5e0A2sUYpitvZWFQMggtwXA5LxIUQ3Ya/jsZ65t4B47KXjPGGVnwKyiYfJvVVj pkOKVwvbnSYsiXra1XiKxDHtIXgJp2DPHnG6ley7KapJd62GxGFzLjV65ZtfWgKh eNoG9HSPPQ0s0F5ny7SxQmRtksJunyiVgo0QKdQHV1bK5dcJCDXfuQcceQMwxqwQ hEYKDLhYUW5ZZ0Yx+/xuGJt7sj3Vrw8aIL/z1kshyJqGwKk4bmF1+BqjEoOSRH1g hOJRI8wGHm4F9DnWQrq3wqha8swEXnQu439Sqn5g9k3EAq9aJ0ON4DCx7DZeDaJ7 ZQgTj3l7/rEd8Aftodi469rdsgYl2uTYwyidAO/E9HwH/kQVl1W8KZFA3JNA6FM9 X/OPHBLEcxv9kWzQxLeTel43i4BIbN3Y3UQEWKres0iNiDEhBZ4dUuGdItF+XuZw qnJ9PQIgazIi/YgY41V2HvPOsbXYgjM3To34izHD63pREPeIEhGKt+44H6qv1Bjx somknjoCw9/BbA5J/RHgZTJsqWOJlJIBQ2zNNdY5wVAcuzUYnvIbr8HvDJ10fRRU OX/QvJ4L+N80A+nD3hjuT/4ikahAf9+ByHroeBcrswl6b6iW85Pa71Fvg9qLu3Dc bPF1qiZ7VTcCAkQBbOSh =eE8K -----END PGP SIGNATURE-----
