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". > 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 ? sinon de ne pas créer de sites Web :-) André 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.