Re: Tentatives possible réussies attaque serveur
On Saturday 17 October 2015 13:33:10 pmenier wrote: > >site fait maison, c'est du classique dans les sites Web, > > la page "index.php" reçoit les contenus des autres pages. > > Comment faire autrement ? > Pour éviter ce genre d'inclusion j'utilise le module mod_security > d'apache2. Bien configuré il ne ralentit pas trop les accès. > Patrick Merci de ce rappel de module à installer. J'ai bien dans "/etc/apache2/mods-enabled" : mod-security.conf & mod-security.load
Re: Tentatives possible réussies attaque serveur
Bonjour, +1 pour un mod_security bien configuré, couplé à ceci c'est bien pratique ! https://github.com/derhansen/logwatch-modsec2 Cordialement, Nathan Malo Le 17 oct. 2015 1:33 PM, "pmenier" a écrit : > Le 02/10/2015 15:13, andre_deb...@numericable.fr a écrit : > >> 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... ? >> > 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. >> >> Comment faire autrement ? >> >> André >> >> >> Bonjour, > > Pour éviter ce genre d'inclusion j'utilise le module mod_security > d'apache2. Bien configuré il ne ralentit pas trop les accès. > > Patrick > > >
Re: Tentatives possible réussies attaque serveur
Le 02/10/2015 15:13, andre_deb...@numericable.fr a écrit : 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... ? 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. Comment faire autrement ? André Bonjour, Pour éviter ce genre d'inclusion j'utilise le module mod_security d'apache2. Bien configuré il ne ralentit pas trop les accès. Patrick
Re: Tentatives possible réussies attaque serveur
On Wednesday 14 October 2015 10:12:59 Eric Degenetais wrote: > @andre, une dernière fois, au cas où: > si tu veux avoir une indication sur le succès ou non des requêtes > relevées, tente ce qui t'a été suggéré: > fais la même requête depuis ton navigateur, et vois si tu obtiens ou > non le contenu d' /etc/passwd > si oui => il y a un risque que l'attaque ait réussi > si non=> l'attaque a dû échouer > on ne peut rien dire de plus sans connaître le contenu de index.php ... > si jamais ça marche, c'est à dire qu'index.php utilise la valeur du > paramètre rev alors il EST mal écrit et il FAUT le changer pour > refermer la faille. > La meilleure manière de limiter les failles c'est de réduire la partie > dynamique au strict minimum. > Pour naviguer de page en page, il vaut 100 fois mieux utiliser des > liens vers des URL statiques, car alors les contrôles de sécurité du > serveur HTTP (apache2, par exemple) ne sont pas contournés, donc la > sécurité est meilleure. Éric Dégenètais Je voulais simplement marquer le coup sur un mail de mauvais aloi, accusateur d'un serveur web et scripts php, moisis. C'est désagréable. Maintenant, un mail peut agacer, je comprends, et on y répond par le silence. Le silence est d'or, la parole est d'argent, et l'écriture est... Concernant ton mail, aimable et courtois, il est équivalent au silence :-) L'incident est clos. Bonne fin de soirée. André
Re: Tentatives possible réussies attaque serveur
@andre, une dernière fois, au cas où: si tu veux avoir une indication sur le succès ou non des requêtes relevées, tente ce qui t'a été suggéré: fais la même requête depuis ton navigateur, et vois si tu obtiens ou non le contenu d' /etc/passwd si oui => il y a un risque que l'attaque ait réussi si non=> l'attaque a dû échouer on ne peut rien dire de plus sans connaître le contenu de index.php ... si jamais ça marche, c'est à dire qu'index.php utilise la valeur du paramètre rev alors il EST mal écrit et il FAUT le changer pour refermer la faille. La meilleure manière de limiter les failles c'est de réduire la partie dynamique au strict minimum. Pour naviguer de page en page, il vaut 100 fois mieux utiliser des liens vers des URL statiques, car alors les contrôles de sécurité du serveur HTTP (apache2, par exemple) ne sont pas contournés, donc la sécurité est meilleure. __ Éric Dégenètais Henix http://www.henix.com http://www.squashtest.org Le 13 octobre 2015 23:17, Philippe Gras a écrit : > > Le 13 oct. 2015 à 21:54, andre_deb...@numericable.fr a écrit : >> >> Je pense que tu ne sais même pas ce que veut dire : > > Ce n'est pas très grave tout ça, au fond. Parfois, on a la tête dans le > guidon, > > on ne vois pas forcément ce qu'il y a juste devant gros comme un montagne. > > Mais quelques semaines plus tard, on y repense et on y trouve ce que l'on a > > désespérément cherché. > > J'avais déjà posé la question il y a plusieurs mois ici donc c'est avec un > petit > > décalage que j'ai appris plein de trucs grâce à ce sujet. > > Alors s'il n'a pas (encore) servi à celui qui pose la question, il a quand > même > > servi. Mais peut-être sera-t-il utile de poser encore une fois la question. > > Bis repetita placent.
Re: Tentatives possible réussies attaque serveur
Le 13 oct. 2015 à 21:54, andre_deb...@numericable.fr a écrit : > > Je pense que tu ne sais même pas ce que veut dire : Ce n'est pas très grave tout ça, au fond. Parfois, on a la tête dans le guidon, on ne vois pas forcément ce qu'il y a juste devant gros comme un montagne. Mais quelques semaines plus tard, on y repense et on y trouve ce que l'on a désespérément cherché. J'avais déjà posé la question il y a plusieurs mois ici donc c'est avec un petit décalage que j'ai appris plein de trucs grâce à ce sujet. Alors s'il n'a pas (encore) servi à celui qui pose la question, il a quand même servi. Mais peut-être sera-t-il utile de poser encore une fois la question. Bis repetita placent.
Re: Tentatives possible réussies attaque serveur
On Tuesday 13 October 2015 20:53:49 Sylvain L. Sauvage wrote: > Le mardi 13 octobre 2015, 19:41:51 andre a écrit : > > > > ça veut dire quoi "écrire le serveur HTTP" ? > Tu ne comprends pas « écrire le serveur HTTP ». > Tu ne comprends pas « programmer, concevoir le serveur HTTP ». > Je suppose que tu ne comprendras pas non plus « écrire un > programme qui soit un serveur pour HTTP », il faudra que je > t’explique que « serveur » signifie « programme qui propose un > service à d’autres programmes » et « serveur pour HTTP », « un > serveur qui donne des réponses à des requêtes selon le protocole > spécifié par les RFC 1945 ou 7230 ». > Faut-il aussi expliquer « écrire un programme » ? > C’est trop « flou » Je pense que tu ne sais même pas ce que veut dire : "écrire le serveur HTTP" "programmer, concevoir le serveur HTTP" du genre : "ma voiture est en panne" : "c'est le piston moisi qui s'est accroché au pare-choc et qui l'empêche d'écrire la carburation moisie" > On l’aura compris. Ça fait douze fois que tu reposes la même > question. Tout le monde t’a déjà répondu : on n’en sait foutre > rien parce qu’on ne sait pas ce qu’il y a dans ton foutu script. > Mais repose-la encore une fois… > Toi, peut-être, nous non : on ne sait pas comment est faite ta > serrure et tout ce que tu nous répètes inlassablement, c’est > « mon voisin m’a dit qu’il a vu quelqu’un devant ma porte, je > veux savoir s’il est entré ». > > La dernière fois, je t’ai demandé d’essayer d’essayer les URLs > toi-même pour voir ce que tu obtenais. C’est-à-dire, dans la > suite de ton analogie, de « faire les mêmes gestes que le gars > qui était devant ta porte » pour voir si « tu peux entrer et > piquer l’argenterie ». Tu utilises le "nous" : "on te dit que" , "nous te répétons" , "nous non" : c'est qui le "nous" ? C'est surtout que tu es un communicant (cra)moisi. > Mais bon, pas grave, je clos le sujet. > Il n’y a pire sourd… Il n’y a pire sourd et un communicant (cra)moisi... : le sujet était clos. André
Re: Tentatives possible réussies attaque serveur
Le mardi 13 octobre 2015, 19:41:51 andre_deb...@numericable.fr a écrit : >[…] > > > ça veut dire quoi "écrire le serveur HTTP" ? > > > > > Concevoir, programmer. La même chose que «écrire un > > script» : > C'est assez flou. > HTTP n'est pas un langage en soit, c'est un protocole de > communication, une syntaxe pour formuler des requêtes. > On l'utilise via un vrai langage de programmation, le PHP ou > le C, par exemple. Tu ne comprends pas « écrire le serveur HTTP ». Tu ne comprends pas « programmer, concevoir le serveur HTTP ». Je suppose que tu ne comprendras pas non plus « écrire un programme qui soit un serveur pour HTTP », il faudra que je t’explique que « serveur » signifie « programme qui propose un service à d’autres programmes » et « serveur pour HTTP », « un serveur qui donne des réponses à des requêtes selon le protocole spécifié par les RFC 1945 ou 7230 ». Faut-il aussi expliquer « écrire un programme » ? C’est trop « flou » ? > > Que ce membre lise bien les réponses qui lui sont faites > > est tout aussi très important : > Alors le dialogue est aussi (cra)moisi :-) > > Ma question était la suivante : > comment vérifier que les logs d'Apache disant "possible > exploit", soit une attaque, intrusion réussies ? > càd vérifier si les codes de sécurité fonctionne ? On l’aura compris. Ça fait douze fois que tu reposes la même question. Tout le monde t’a déjà répondu : on n’en sait foutre rien parce qu’on ne sait pas ce qu’il y a dans ton foutu script. Mais repose-la encore une fois… > Ma serrure blindée peut avoir résistée ou non, > je peux le constater. Toi, peut-être, nous non : on ne sait pas comment est faite ta serrure et tout ce que tu nous répètes inlassablement, c’est « mon voisin m’a dit qu’il a vu quelqu’un devant ma porte, je veux savoir s’il est entré ». La dernière fois, je t’ai demandé d’essayer d’essayer les URLs toi-même pour voir ce que tu obtenais. C’est-à-dire, dans la suite de ton analogie, de « faire les mêmes gestes que le gars qui était devant ta porte » pour voir si « tu peux entrer et piquer l’argenterie ». Tu ne l’as sans doute toujours pas fait… > Mais bon, pas grave, je clos le sujet. Il n’y a pire sourd… -- Sylvain Sauvage
Re: Tentatives possible réussies attaque serveur
On Sunday 11 October 2015 10:08:35 Sylvain L. Sauvage wrote: > À moins que celui qui a écrit le fichier PHP moisi soit aussi > celui qui a écrit le serveur HTTP > Le vendredi 9 octobre 2015, 23:07:45 andré a écrit : > > ça veut dire quoi "écrire le serveur HTTP" ? > Concevoir, programmer. La même chose que «écrire un script» : C'est assez flou. HTTP n'est pas un langage en soit, c'est un protocole de communication, une syntaxe pour formuler des requêtes. On l'utilise via un vrai langage de programmation, le PHP ou le C, par exemple. > Que ce membre lise bien les réponses qui lui sont faites > est tout aussi très important : Alors le dialogue est aussi (cra)moisi :-) Ma question était la suivante : comment vérifier que les logs d'Apache disant "possible exploit", soit une attaque, intrusion réussies ? càd vérifier si les codes de sécurité fonctionne ? Ma serrure blindée peut avoir résistée ou non, je peux le constater. Mais bon, pas grave, je clos le sujet. André
Re: Tentatives possible réussies attaque serveur
Le vendredi 9 octobre 2015, 23:07:45 andre_deb...@numericable.fr a écrit : >[…] > ça veut dire quoi "écrire le serveur HTTP" ? Concevoir, programmer. La même chose que « écrire un script ». > Qu'en sais tu que mes scripts PHP sont moisis ? >[…] qu'en sais tu ? Je n’en sais rien. J’ai dit « *un* script moisi blabla, *un* script moins moisi blabla ». On ne peut être que général puisqu’on ne connaît pas ton script. > Je ré-explique la problèmatique par comparaison : >[…] > Je voulais donc juste savoir si le fichier "/etc/passwd" a été > téléchargé ou pas, point. Ça fait 25 messages dans ce fil qui t’expliquent qu’on n’en sait rien parce qu’on ne sait pas ce que fait ton script, que la réponse « 200 OK » ne donne aucun indice autre que le script a bien été exécuté et a renvoyé « quelque chose ». Il n’y a que toi qui puisse aller plus loin mais tu sembles bloqué sur la même question générale sans lire ou essayer de comprendre les réponses qui te sont faites. Est-ce que tu as même seulement essayé les URL suspectes toi- même ? Si tu les essaies, tu verras bien si tu récupères le contenu de passwd ou pas. > Bien lire la demande d'un membre de la liste est très > important. Que ce membre lise bien les réponses qui lui sont faites est tout aussi très important. -- Sylvain Sauvage
Re: Tentatives possible réussies attaque serveur
On Friday 09 October 2015 15:39:57 Sylvain L. Sauvage wrote: > Le vendredi 9 octobre 2015, 14:47:01 andre_deb...@numericable.fr > a écrit : > > Merci de la piqûre de rappel ci-dessous concernant les > > langages dynamiques Web. > > Les documents sur la sécurité abondent en ce sens, > > dont surtout la réinjection de codes dans les pages Web. > > La question initiale était : > > /index.php?rev=../../../../../../../../../etc/passwd > > HTTP Response 200, possible tentatives avec succès..." > > Mais rien n'empêche de taper directement ceci : > > "www.monsite.com/../../../../... /etc/passwd > > Le fait d'avoir une page d'index ou non, > > "/index.php?rev=../../../../../../../../../etc/passwd" > > ne doit pas changer grand chose... > Ok, donc, malgré tout ce qui a été dit dans ce fil, tu n’as > pas compris le protocole HTTP : ces requêtes ne sont pas > équivalentes. > Passer par un fichier PHP mal écrit qui va pouvoir lire > n’importe quel fichier sur ta machine si on lui passe un chemin > dans le bon paramètre n’est pas équivalent à faire une requête > que le serveur va savoir refuser. À moins que celui qui a écrit > le fichier PHP moisi soit aussi celui qui a écrit le serveur > HTTP, ce dernier n’acceptera pas d’aller remonter plus haut que > sa racine (p.ex. /var/www). > celui qui a écrit le fichier PHP moisi soit aussi celui qui a > écrit le serveur HTTP : ça veut dire quoi "écrire le serveur HTTP" ? Qu'en sais tu que mes scripts PHP sont moisis ? (humm, en plus le terme "moisi" ne va pas... plutôt "édulcoré"). Jje me vois répondre par une polémique sur la validité de mes scripts, php, page d'index, variables, écriture HTTP, moisis... ! qu'en sais tu ? Je ré-explique la problèmatique par comparaison : je monte dans ma voiture la matin qui possède un logwatch de sécurité. Il m'annonce "qu'une tentative d'intrusion" a eu lieu à 03h40, code 200. Je pose la question : y a t-il eu "une tentative d'intrusion" ou "une intrusion" ? Si "tentative d'intrusion", la sécurité de ma voiture n'est pas moisie, si "intrusion réussie" : oui, elle est moisie (scripts édulcorés). Je voulais donc juste savoir si le fichier "/etc/passwd" a été téléchargé ou pas, point. Bien lire la demande d'un membre de la liste est très important. André
Re: Tentatives possible réussies attaque serveur
Sylvain L. Sauvage wrote on Fri, Oct 09, 2015 at 05:03:48PM +0200 > Le vendredi 9 octobre 2015, 16:24:00 Dominique Asselineau a > écrit : > >[???] > > > D???un point de vue réponse HTTP, ces deux scripts vont > > > générer un 200 de la part du serveur HTTP : le fichier > > > 'index.php' a été exécuté et renvoie un contenu. > > > > Un script peut tout à fait retourner une réponse HTTP autre > > que 200. C'est ce que je fais lorsqu'on demande une ressource > > qui n'existe pas ou qui n'est pas autorisée pour la requête. > > Oui. Je donnais juste l???exemple de ces deux scripts : moisi et > moins-moisi. > On pourrait aller plus loin dans les détails et les > possibilités, p.ex. les redirections, les réécritures, ce que > veut dire « exécuter un script », etc. Mais bon, vu la longueur > du fil, les multiples explications, pour arriver à > « index.php?bla et /bla, c???est pareil », on se dit qu???il vaut > mieux rester simple??? > > > Quant aux scripts qui font des includes sur des fichiers dont > > l'adresse est passée en paramètre et sans vérification... ça > > me laisse pantois. Il y en a même qui laissent faire des > > includes sur des URL... Ce qui permet à un spameur de faire > > tourner un moulin à spams chez vous avec votre bande passante > > et surtout votre responsabilité. > > > > Faire vraiment attention aux gentils scripts qui veulent vous > > rendre mille services sans vous dire ce que fait le mille et > > unième. > > J???aimais bien l???époque des premiers CGI, en shell, c???était si > facile de se pendre avec ;o) Détrompe-toi Sylvain ! C'est arrivé il y a quelques années avec un script PHP justement, trouvé sur le web bien que l'auteur du méfait n'a jamais voulu le reconnaître. Dans l'affaire il y a eu 2 pendus : celui qui a récupéré le script, probablement à Troie... et celui qui a configuré le php.ini en oubliant d'interdire l'inclusion d'URL car en effet, ça peut se configurer au niveau de PHP. Comme quoi il n'y a pas besoin de remonter au siècle dernier avec des CGI en shell pour voir ça. dom --
Re: Tentatives possible réussies attaque serveur
Eric Degenetais wrote on Fri, Oct 09, 2015 at 04:46:54PM +0200 > Le 9 octobre 2015 16:24, Dominique Asselineau > a écrit : > > Un script peut tout à fait retourner une réponse HTTP autre que 200. > > C'est ce que je fais lorsqu'on demande une ressource qui n'existe pas > > ou qui n'est pas autorisée pour la requête. > > Certes...mais il y a des cas où il vaut mieux retourner 200 tout le > temps. Après tout, index.php existe, l'URL est donc correcte, donc 404 > n'est pas tout à fait une réponse adaptée. Si l'opération est de faire du téléchargement, la pertinence n'est pas le script mais la ressource demandée. Du coup, ça n'est pas du tout absurde de répondre relativement à la ressource. > Quand un robot fait du > sondage en masse, lui retourner un code d'erreur sauf si ça tappe > juste peut l'aider à trouver. > Par exemple, renvoyer un 200 uniquement en cas de succès de login est > de nature à faciliter les attaques en force... Ah oui, enfin on parse la page et ça revient à peu près au même. C'est comme souvent : tout dépend de l'enjeu. Perso, je n'aime pas que les mots de passe soient demandés au niveau des scripts, je préfère que ce soit le serveur qui s'en charge. Ça paraît plus prudent. dom --
Re: Tentatives possible réussies attaque serveur
Le vendredi 9 octobre 2015, 17:02:52 Philippe Gras a écrit : >[… du “bon” code de retour …] > Dans le deuxième cas, non et je suis d'accord avec Sylvain. Euh, j’ai rien dit là-dessus, moi. J’ai juste donné deux exemples de scripts, moisi et moins-moisi, qui renverraient 200 (cas de la question initiale et pour rester simple). Mais si vous voulez mon avis, il n’y a pas de réponse générale. Un script qui renvoie une erreur, ça sert. Un script qui ne renvoie jamais d’erreur, ça sert aussi. Bon, le mieux, c’est un script qui renvoie un code tiré au hasard. Un coup ça marche, un coup ça marche pas. À bas REST ! (Eh, c’est vendredi !) -- Sylvain Sauvage
Re: Tentatives possible réussies attaque serveur
Le vendredi 9 octobre 2015, 16:24:00 Dominique Asselineau a écrit : >[…] > > D’un point de vue réponse HTTP, ces deux scripts vont > > générer un 200 de la part du serveur HTTP : le fichier > > 'index.php' a été exécuté et renvoie un contenu. > > Un script peut tout à fait retourner une réponse HTTP autre > que 200. C'est ce que je fais lorsqu'on demande une ressource > qui n'existe pas ou qui n'est pas autorisée pour la requête. Oui. Je donnais juste l’exemple de ces deux scripts : moisi et moins-moisi. On pourrait aller plus loin dans les détails et les possibilités, p.ex. les redirections, les réécritures, ce que veut dire « exécuter un script », etc. Mais bon, vu la longueur du fil, les multiples explications, pour arriver à « index.php?bla et /bla, c’est pareil », on se dit qu’il vaut mieux rester simple… > Quant aux scripts qui font des includes sur des fichiers dont > l'adresse est passée en paramètre et sans vérification... ça > me laisse pantois. Il y en a même qui laissent faire des > includes sur des URL... Ce qui permet à un spameur de faire > tourner un moulin à spams chez vous avec votre bande passante > et surtout votre responsabilité. > > Faire vraiment attention aux gentils scripts qui veulent vous > rendre mille services sans vous dire ce que fait le mille et > unième. J’aimais bien l’époque des premiers CGI, en shell, c’était si facile de se pendre avec ;o) -- Sylvain Sauvage
Re: Tentatives possible réussies attaque serveur
Le 9 oct. 2015 à 16:46, Eric Degenetais a écrit : > Le 9 octobre 2015 16:24, Dominique Asselineau > a écrit : >> Un script peut tout à fait retourner une réponse HTTP autre que 200. >> C'est ce que je fais lorsqu'on demande une ressource qui n'existe pas >> ou qui n'est pas autorisée pour la requête. > > Certes...mais il y a des cas où il vaut mieux retourner 200 tout le > temps. Après tout, index.php existe, l'URL est donc correcte, donc 404 > n'est pas tout à fait une réponse adaptée. Quand un robot fait du > sondage en masse, lui retourner un code d'erreur sauf si ça tappe > juste peut l'aider à trouver. … et inversement ! > Par exemple, renvoyer un 200 uniquement en cas de succès de login est > de nature à faciliter les attaques en force… Ce n'est pas garanti. J'ai des milliers de requêtes en 403 sur mes pages de login, et cela ne les dérange pas plus que ça. Sur le principe, la page c'est "/index.php" ou "/index.php?login=machin&passwd=bidule" ? Dans le premier cas, le serveur doit renvoyer un code 200 quels que soient les arguments passés en variable. Dans le deuxième cas, non et je suis d'accord avec Sylvain. Mais alors… il n'y aurait qu'un login et un mot de passe ? Bon, en fait quel que soit le code de réponse renvoyé, et vu que ça n'affecte pas les chieurs, je crois que c'est un faux problème. Les seuls qui vaillent la peine que l'on s'attarde de façon pratique, c'est de bien vérifier que les variables demandées ne s'affichent pas sur la page et de créer un fichier dans Fail2Ban pour envoyer les demandeurs aux pelotes. > > __ > Éric Dégenètais > Henix > > > http://www.henix.com > http://www.squashtest.org >
Re: Tentatives possible réussies attaque serveur
Le 9 octobre 2015 16:24, Dominique Asselineau a écrit : > Un script peut tout à fait retourner une réponse HTTP autre que 200. > C'est ce que je fais lorsqu'on demande une ressource qui n'existe pas > ou qui n'est pas autorisée pour la requête. Certes...mais il y a des cas où il vaut mieux retourner 200 tout le temps. Après tout, index.php existe, l'URL est donc correcte, donc 404 n'est pas tout à fait une réponse adaptée. Quand un robot fait du sondage en masse, lui retourner un code d'erreur sauf si ça tappe juste peut l'aider à trouver. Par exemple, renvoyer un 200 uniquement en cas de succès de login est de nature à faciliter les attaques en force... __ Éric Dégenètais Henix http://www.henix.com http://www.squashtest.org
Re: Tentatives possible réussies attaque serveur
Sylvain L. Sauvage wrote on Fri, Oct 09, 2015 at 03:39:57PM +0200 > Le vendredi 9 octobre 2015, 14:47:01 andre_deb...@numericable.fr > a écrit : > > Merci de la piqûre de rappel ci-dessous concernant les > > langages dynamiques Web. > > > > Les documents sur la sécurité abondent en ce sens, > > dont surtout la réinjection de codes dans les pages Web. > > > > La question initiale était : > > /index.php?rev=../../../../../../../../../etc/passwd > > HTTP Response 200, possible tentatives avec succès..." > > > > Mais rien n'empêche de taper directement ceci : > > "www.monsite.com/../../../../... /etc/passwd > > > > Le fait d'avoir une page d'index ou non, > > "/index.php?rev=../../../../../../../../../etc/passwd" > > ne doit pas changer grand chose... > > Ok, donc, malgré tout ce qui a été dit dans ce fil, tu n’as > pas compris le protocole HTTP : ces requêtes ne sont pas > équivalentes. > > Passer par un fichier PHP mal écrit qui va pouvoir lire > n’importe quel fichier sur ta machine si on lui passe un chemin > dans le bon paramètre n’est pas équivalent à faire une requête > que le serveur va savoir refuser. À moins que celui qui a écrit > le fichier PHP moisi soit aussi celui qui a écrit le serveur > HTTP, ce dernier n’acceptera pas d’aller remonter plus haut que > sa racine (p.ex. /var/www). > > La requête '/index.php?rev=../../etc/passwd' signifie > « exécuter le script 'index.php' en lui passant la variable > 'rev' à '../../etc/passwd' ». Le script fait ce qu’il veut avec > son paramètre 'rev'. Un script moisi va s’en servir pour aller > ouvrir le fichier et l’inclure dans la réponse sans > vérification. Un script moins moisi va vérifier la valeur du > paramètre et ne pas s’en servir. > D’un point de vue réponse HTTP, ces deux scripts vont générer > un 200 de la part du serveur HTTP : le fichier 'index.php' a été > exécuté et renvoie un contenu. Un script peut tout à fait retourner une réponse HTTP autre que 200. C'est ce que je fais lorsqu'on demande une ressource qui n'existe pas ou qui n'est pas autorisée pour la requête. Quant aux scripts qui font des includes sur des fichiers dont l'adresse est passée en paramètre et sans vérification... ça me laisse pantois. Il y en a même qui laissent faire des includes sur des URL... Ce qui permet à un spameur de faire tourner un moulin à spams chez vous avec votre bande passante et surtout votre responsabilité. Faire vraiment attention aux gentils scripts qui veulent vous rendre mille services sans vous dire ce que fait le mille et unième. dom > > La requête '/../../../etc/passwd', en général, n’est pas > valide, et va donc générer une réponse 404. > (On peut avoir un serveur web qui renvoie toutes ou certaines > URL comme paramètre à l’exécution d’un script, lequel peut être > plus ou moins moisi, mais il faut lui demander.) > > Il est beaucoup plus fréquent de trouver un script PHP moisi > que de trouver un serveur web qui va aller chercher n’importe > quel fichier sur la machine, ne serait-ce que parce qu’il y a > beaucoup plus de scripts PHP que serveurs web… > > -- > Sylvain Sauvage > --
Re: Tentatives possible réussies attaque serveur
Le vendredi 9 octobre 2015, 14:47:01 andre_deb...@numericable.fr a écrit : > Merci de la piqûre de rappel ci-dessous concernant les > langages dynamiques Web. > > Les documents sur la sécurité abondent en ce sens, > dont surtout la réinjection de codes dans les pages Web. > > La question initiale était : > /index.php?rev=../../../../../../../../../etc/passwd > HTTP Response 200, possible tentatives avec succès..." > > Mais rien n'empêche de taper directement ceci : > "www.monsite.com/../../../../... /etc/passwd > > Le fait d'avoir une page d'index ou non, > "/index.php?rev=../../../../../../../../../etc/passwd" > ne doit pas changer grand chose... Ok, donc, malgré tout ce qui a été dit dans ce fil, tu n’as pas compris le protocole HTTP : ces requêtes ne sont pas équivalentes. Passer par un fichier PHP mal écrit qui va pouvoir lire n’importe quel fichier sur ta machine si on lui passe un chemin dans le bon paramètre n’est pas équivalent à faire une requête que le serveur va savoir refuser. À moins que celui qui a écrit le fichier PHP moisi soit aussi celui qui a écrit le serveur HTTP, ce dernier n’acceptera pas d’aller remonter plus haut que sa racine (p.ex. /var/www). La requête '/index.php?rev=../../etc/passwd' signifie « exécuter le script 'index.php' en lui passant la variable 'rev' à '../../etc/passwd' ». Le script fait ce qu’il veut avec son paramètre 'rev'. Un script moisi va s’en servir pour aller ouvrir le fichier et l’inclure dans la réponse sans vérification. Un script moins moisi va vérifier la valeur du paramètre et ne pas s’en servir. D’un point de vue réponse HTTP, ces deux scripts vont générer un 200 de la part du serveur HTTP : le fichier 'index.php' a été exécuté et renvoie un contenu. La requête '/../../../etc/passwd', en général, n’est pas valide, et va donc générer une réponse 404. (On peut avoir un serveur web qui renvoie toutes ou certaines URL comme paramètre à l’exécution d’un script, lequel peut être plus ou moins moisi, mais il faut lui demander.) Il est beaucoup plus fréquent de trouver un script PHP moisi que de trouver un serveur web qui va aller chercher n’importe quel fichier sur la machine, ne serait-ce que parce qu’il y a beaucoup plus de scripts PHP que serveurs web… -- Sylvain Sauvage
Re: Tentatives possible réussies attaque serveur
> Mais rien n'empêche de taper directement ceci : > "www.monsite.com/../../../../... /etc/passwd > Le fait d'avoir une page d'index ou non, > "/index.php?rev=../../../../../../../../../etc/passwd" > ne doit pas changer grand chose... bonjour, En principe, le serveur est conçu pour limiter l’arborescence exposée. Pour peu que le paramétrage par défaut soit correct et n'ai pas été altéré imprudemment, il offre une bonne protection. Cependant les pages PHP peuvent contourner cette protection si elles sont écrites imprudemment, car le moteur d'exécution PHP a beaucoup plus de latitude pour accéder à des fichiers que le serveur Web...d'où l'apparition de failles qui n'existe pas dans les sites statiques. cordialement __ Éric Dégenètais Henix http://www.henix.com http://www.squashtest.org Le 9 octobre 2015 14:47, a écrit : > Merci de la piqûre de rappel ci-dessous concernant les > langages dynamiques Web. > > Les documents sur la sécurité abondent en ce sens, > dont surtout la réinjection de codes dans les pages Web. > > La question initiale était : > /index.php?rev=../../../../../../../../../etc/passwd > HTTP Response 200, possible tentatives avec succès..." > > Mais rien n'empêche de taper directement ceci : > "www.monsite.com/../../../../... /etc/passwd > > Le fait d'avoir une page d'index ou non, > "/index.php?rev=../../../../../../../../../etc/passwd" > ne doit pas changer grand chose... > > André > > On Friday 09 October 2015 14:30:54 Sébastien NOBILI wrote: >> Le vendredi 09 octobre 2015 à 13:27, andre_deb...@numericable.fr a écrit : >> > Je ne sais plus qui, je ne sais plus quand (ça a été tronqué) a écrit : >> > > 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 a une très mauvaise réputation de nid à failles. Cette réputation n'est > pas >> forcément très objective mais parmi les arguments qui l'ont faite, on > trouve : >> - que l'API n'est pas très rigoureuse; >> - qu'on peut développer un site en PHP sans trop de connaissances (et > donc >> sans forcément trop de sécurité non plus). >> >> > "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 ? >> >> Ma réponse est indépendante du langage utilisé et vaut autant pour PHP que > pour >> tout autre langage utilisé pour créer des sites dynamiques (et même d'une >> manière large des programmes client/serveur) : >> >> Ne _jamais_ faire confiance à ce qui arrive du client ! >> >> Tu considères que tout est douteux et tu vérifies _scrupuleusement_ tout ce > qui >> arrive : >> - est-ce que le nombre que tu attends est bien seulement un nombre; >> - est-ce que la chaîne que tu attends ne contient pas de quoi faire de >> l'injection SQL; >> - est-ce que la chaîne que tu attends ne contient pas de quoi faire du > XSS; >> - etc. >> >> Pour ça, les expressions rationnelles sont un très bon allié. >> >> Sébastien >> >> >
Re: Tentatives possible réussies attaque serveur
Merci de la piqûre de rappel ci-dessous concernant les langages dynamiques Web. Les documents sur la sécurité abondent en ce sens, dont surtout la réinjection de codes dans les pages Web. La question initiale était : /index.php?rev=../../../../../../../../../etc/passwd HTTP Response 200, possible tentatives avec succès..." Mais rien n'empêche de taper directement ceci : "www.monsite.com/../../../../... /etc/passwd Le fait d'avoir une page d'index ou non, "/index.php?rev=../../../../../../../../../etc/passwd" ne doit pas changer grand chose... André On Friday 09 October 2015 14:30:54 Sébastien NOBILI wrote: > Le vendredi 09 octobre 2015 à 13:27, andre_deb...@numericable.fr a écrit : > > Je ne sais plus qui, je ne sais plus quand (ça a été tronqué) a écrit : > > > 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 a une très mauvaise réputation de nid à failles. Cette réputation n'est pas > forcément très objective mais parmi les arguments qui l'ont faite, on trouve : > - que l'API n'est pas très rigoureuse; > - qu'on peut développer un site en PHP sans trop de connaissances (et donc > sans forcément trop de sécurité non plus). > > > "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 ? > > Ma réponse est indépendante du langage utilisé et vaut autant pour PHP que pour > tout autre langage utilisé pour créer des sites dynamiques (et même d'une > manière large des programmes client/serveur) : > > Ne _jamais_ faire confiance à ce qui arrive du client ! > > Tu considères que tout est douteux et tu vérifies _scrupuleusement_ tout ce qui > arrive : > - est-ce que le nombre que tu attends est bien seulement un nombre; > - est-ce que la chaîne que tu attends ne contient pas de quoi faire de > l'injection SQL; > - est-ce que la chaîne que tu attends ne contient pas de quoi faire du XSS; > - etc. > > Pour ça, les expressions rationnelles sont un très bon allié. > > Sébastien > >
Re: Tentatives possible réussies attaque serveur
Le vendredi 09 octobre 2015 à 13:27, andre_deb...@numericable.fr a écrit : > Je ne sais plus qui, je ne sais plus quand (ça a été tronqué) a écrit : > > 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 a une très mauvaise réputation de nid à failles. Cette réputation n'est pas forcément très objective mais parmi les arguments qui l'ont faite, on trouve : - que l'API n'est pas très rigoureuse; - qu'on peut développer un site en PHP sans trop de connaissances (et donc sans forcément trop de sécurité non plus). > "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 ? Ma réponse est indépendante du langage utilisé et vaut autant pour PHP que pour tout autre langage utilisé pour créer des sites dynamiques (et même d'une manière large des programmes client/serveur) : Ne _jamais_ faire confiance à ce qui arrive du client ! Tu considères que tout est douteux et tu vérifies _scrupuleusement_ tout ce qui arrive : - est-ce que le nombre que tu attends est bien seulement un nombre; - est-ce que la chaîne que tu attends ne contient pas de quoi faire de l'injection SQL; - est-ce que la chaîne que tu attends ne contient pas de quoi faire du XSS; - etc. Pour ça, les expressions rationnelles sont un très bon allié. Sébastien
[HS] Re: Tentatives possible réussies attaque serveur
-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 > ".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 connais
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 ".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 re
Re: Tentatives possible réussies attaque serveur
-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. >>>
Re: Tentatives possible réussies attaque serveur
Le vendredi 02 octobre 2015 à 12:33, BERTRAND Joël a écrit : > andre_deb...@numericable.fr a écrit : > >Y a t-il un danger que les mots de passe soient connus... ? > > Les mots de passe, non, mais les logins et les mots de passe chiffrés. > Sans > indiscrétion, quel est ce index.php moisi ? Les mots de passe chiffrés ne sont plus dans le fichier « /etc/passwd » depuis un petit paquet d'années. Ce fichier est devenu accessible à tous les utilisateurs car il ne contient plus grand chose de vraiment sensible. Il peut cependant renseigner sur l'existence ou non d'un compte utilisateur pour orienter des attaques type force brute, mais rien de plus. Sébastien
Re: Tentatives possible réussies attaque serveur
Le 02/10/2015 13:38, BERTRAND Joël a écrit : J'ai bien compris. 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. Non. La réponse 200 indique qu'il y a bien un fichier /index.php et que celui-ci a répondu sans se planter, c'est tout. Si le fichier index.php ne s'occupe pas de la "query string", il n'y a absolument pas à s'inquiéter. -- Bernard. 20 ans d'utilisation de Debian. Comme le temps passe...
Re: Tentatives possible réussies attaque serveur
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... ? > > > >> 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. Comment faire autrement ? André
Re: Tentatives possible réussies attaque serveur
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... ? 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"; J'ai bien compris. 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) ? Cordialement, JKB
Re: Tentatives possible réussies attaque serveur
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... ? > 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"; > As tu essayé toi même et regardé les réponses http vues par le > navigateur, par exemple avec l'extension httpheader sur firefox? Comment fait-on avec " l'extension httpheader" ? André
Re: Tentatives possible réussies attaque serveur
Le 2 oct. 2015 à 12:33, BERTRAND Joël a écrit : > andre_deb...@numericable.fr a écrit : >> Bonjour, > > Bonjour, > >> 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... ? >> >> André >> > > 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 J'en ai tous les jours, ce n'est pas grave, en fait. Pour vous rendre compte de ce que ça donne, vous devriez tester une de ces URL. Normalement, ce qui passe dans la query string n'est pas pris en compte. >
Re: Tentatives possible réussies attaque serveur
Salut, andre_deb...@numericable.fr a écrit le 02/10/2015 11:10 : > Bonjour, > > 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... ? As tu essayé toi même et regardé les réponses http vues par le navigateur, par exemple avec l'extension httpheader sur firefox? -- Stéphane
Re: Tentatives possible réussies attaque serveur
andre_deb...@numericable.fr a écrit : Bonjour, Bonjour, 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... ? André 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