Re: Tentatives possible réussies attaque serveur
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_debian@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.
Reply to: