|
|
|
Publicité ' | |||||||||||||||||||||||
15/09/2006, 14h07
|
#1 |
|
Invité régulier
 Inscription : juillet 2006 Messages : 24  |
Réémission requête GET sur serveur Apache
Bonjour,
Je possède un serveur web apache (version 2.0.52)  sous linux RedHat dont la charge augmente considérablement (load average à 50 sur 1 min) sur de très courte période... En regardant les logs d'apache (access.log) on voit apparaître des raffales de GET url_Y sur un laps de temps très court. Comme 100 GET url_Y sur en 4 secondes partant de la même IP. Ce GET sollicite un cgi avec tous ces paramètres... Je précise qu'il s'agit de la même url (Y) qui est demandée par le même client (même adresse IP). Je connais la personne utilisant le PC client (MSIE 6.0, Windows XP). Nous avons passé des anti-virus, anti-spy et il n'y a rien pour l'instant de méchant.. Je suis dans un réseau "quasi-privé" et très (mais alors très) bien protégé de l'internet et le DOS ne me semble pas à privilégier. Avez-vous une (des) hypothèse(s) ? 
|
|
00
|
|
17/09/2006, 12h54
|
#2 |
   
  Ingénieur développement logiciels Inscription : mai 2002 Messages : 3 725 |
Il faudrait que tu nous donnes précisément l'URL qui est GETée, qu'on puisse faire une recherche sur google pour voir si ça correspond à un type d'attaque connu...
__________________
Tutoriels sur les UPS, e-commerce, PHP, critiques de livres... Ce forum est fait pour vous et surtout par vous, merci d'en respecter les règles. Je n'ai rien à voir avec la société www.ovh.com ! |
|
|
00
|
|
18/09/2006, 09h23
|
#3 |
|
Invité régulier
Inscription : juillet 2006 Messages : 24 |
hum hum ...
Le phénomène s'est reproduit avec 2 autres machines qui sont des machines connues dans notre réseau...
Nous avons analysé en profondeur les logs d'apache et ce sont des urls différentes pour chaque machine : Machine 1 envoie en rafale la demande de l'url X Machine 2 envoie en refale la demande de l'url Y ..Etc... Les urls sont "propriétaires", elles ne correspondent à rien de connu sur le net. Elles sont de type : http://@_IP_privé/mon_appli/mon_cgi....=voir_ma_table [Ce ne sont pas des urls standards comme index.cgi] On a mis en place des captures tcpdump sur le serveur pour surveiller ces 3 machines... On pense à un vers ou virus qui repérerait des requêtes en partance vers un serveur web, et qui les utiliseraient pour faire du Dos...Mais les différents anti-virus n'ont rien trouvés !! S'agit-il d'un disfonctionnement des clients, des serveurs, de ré-émission réseaux....Le mystère reste entier ! Si vous avez une hypothèse, je suis preneur. 
|
|
|
00
|
|
19/09/2006, 15h59
|
#4 |
|
Membre Expert
 
Inscription : juin 2006 Messages : 889 |
HTTP REQUEST SMUGGLING( voir aussi HTTP REPONSE SPLLITING ).
le but faire du cache poisonning pour avoir acces a d'autres ressources interne ou alors rediriger les visiteurs de ton site vers un site 'qui piegera les visiteurs'. Dans tes logs regarde si il y a des requetes 'normal' de personne qui visite et compare les aux IPs qui t'envoie les requetes. ou alors le client est possiblement infecter par un bot/virus/worms infecter qui automatise cela . biensur ce la reste des hypotheses. |
|
|
00
|
|
21/09/2006, 10h29
|
#5 |
|
Invité régulier
Inscription : juillet 2006 Messages : 24 |
Bon
On a les dumps, voici ce que l'on observe :
Dans le cas ou ça va bien :: Le client demande son GET -> Le serveur ACK et envoi les données ::: GET /mon_appli/mon_cgi.cgi HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */* Referer: http://@IP/mon_appli/mon_autre_cgi.cgi Accept-Language: fr Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322) Host: @_IP Connection: Keep-Alive Cookie: mon_appli=2b081c31655bc92d83c0ada3f630e101 HTTP/1.1 200 OK Date: Wed, 20 Sep 2006 14:51:00 GMT Server: Apache/2.0.52 (Red Hat) Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=ISO-8859-1 <html> <head> .<meta http-equiv="Refresh" content="298"> .<meta http-equiv="Pragma" content="no-cache"> .... .... .... </body> </html> Dans le cas ou ça plante -> Le client demande son GET -> Le serveur ACK ::: GET /mon_appli/mon_cgi.cgi HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */* Referer: http://@IP/mon_appli/mon_autre_cgi.cgi Accept-Language: fr Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322) Host: @_IP Connection: Keep-Alive Cookie: mon_appli=2b081c31655bc92d83c0ada3f630e101 Mais là le serveur n'a pas le temps d'envoyer les données, le client RST tout de suite !!  Les deux GET sont identiques, le paquet semble bien formé, le paquet d'ACK a l'air correct aussi... Je vois pas ce qui cloche... HELP !
|
|
|
00
|
|
22/09/2006, 08h42
|
#6 |
|
Invité régulier
Inscription : juillet 2006 Messages : 24 |
Aujourd'hui, plusieurs avancées (si on peut dire
 ):Quand on observe les Dump côté serveur et côté clients, on voit apparaître des anomalies :: Par exemple, les paquets qui partent du serveur web suite à un GET du client ont des checksums invalides (d'après ethereal...) dès le premier paquet chuncked. Tenez-vous bien... : Quand les paquets arrivent sur le client, les checksums sont bons !! si si !!La seul explication que nous avons , un équipement de niveau 3 (TCP) corrigent les paquets...(ou ethereal est buggé) 2- En sniffant le réseau des clients, nous voyons des paquets arrivant du serveur web qui n'ont rien à faire dans ce réseau ! 3- Les fameux RST sur certains postes clients en grand nombre... Nous pensons à des problèmes d'un routeur. Mais comment expliquer les problèmes de checksum en partance du serveur... Et comment expliquer les RST dui client....  On va calculer les checksum "à la main"...pour voir .... HELP
|
|
|
00
|
|
22/09/2006, 11h09
|
#7 |
|
Invité régulier
Inscription : juillet 2006 Messages : 24 |
Sur les RST, on a une hypothèse qui tient la route :
Le client demande des documents au serveur pour savoir si ils ont été modifiés. Le serveur répond 200 et envoie des documents qui n'ont pas été modifié. Le serveur aurait dû répondre 304... Du coup, le client IE6 , emet des RST !!! 
|
|
|
00
|
|
22/09/2006, 13h50
|
#8 | ||
|
Membre Expert
Inscription : juin 2006 Messages : 889 |
Citation:
Citation:
est-il possible que certains de tes clients soit corrompus avec un rootkit/trojan/etc....d'ailleurs a ce propos la version de ton apache possede une faille qui permet de faire un D.O.S. en tout cas ton probleme a l'air interessant 
|
||
|
|
00
|
|
22/09/2006, 14h14
|
#9 | |
|
Invité régulier
Inscription : juillet 2006 Messages : 24 |
Citation:
Le checksum est calculé pour les paquets qui contiennent de la data. Ce checksum est calculé et ajouter par la carte réseau... Notre dump sur le serveur prélève les paquets avant la carte réseau, du coup c'est normal qu'ethereal ni comprennent rien. Quand on arrive sur le client le checksum est bon, ya plus de problèmes...normal quoi ! 
|
|
|
|
00
|
|
22/09/2006, 14h15
|
#10 | |
|
Invité régulier
Inscription : juillet 2006 Messages : 24 |
Citation:
|
|
|
|
00
|
|
22/09/2006, 14h17
|
#11 |
|
Membre Expert
Inscription : juin 2006 Messages : 889 |
...de quoi devenir dingue tout ca....
|
|
|
00
|
|
26/09/2006, 09h15
|
#12 |
|
Invité régulier
Inscription : juillet 2006 Messages : 24 |
1er problème :
Le poste client ferme systématiquement les requetes HTTP demandant un fichier .css ou .js par un reset avant de recevoir les datas, alors que le serveur lui renvoie un code 200. Ceci est dû à un bug Internet Explorer !! Pour éviter d'avoir à télécharger plusieurs fois le même fichier web, IE s'appuie sur la date de dernière modification du fichier et sur un champ appelé ETag. Lors de sa requête au serveur web, il envoie ces deux informations au serveur web. Si ces deux champs sont identiques pour le fichier dont dispose le serveur web, ce serveur ne lui renvoie pas le fichier et lui envoie un code HTTP 304. Le champ ETag est composé du numéro d'inode du fichier sur le serveur web, sa date de dernière modification au format unix et de sa taille. Or sur le poste client, IE dispose du fichier téléchargé la veille sur le serveur de secours. Son ETag est donc différent de celui dont dispose le serveur web (inode différent). Le serveur web renvoie donc le fichier avec la même date de dernière modification et le nouveau ETag. Cette envoi utilise une compression des données conformément à la requête émise par le navigateur du client. Or, le bug d'Internet Explorer est de ne pas tenir compte du champ ETag lorsque l'envoi est compressé. Il tente alors de mettre fin à la connexion en émettant un paquet RST à chaque paquet envoyé par le serveur. Sur le poste client, le champ ETag du fichier n'est pas mis à jour et le problème survient de nouveau au prochain téléchargement... 
|
|
|
00
|
|
26/09/2006, 09h18
|
#13 |
|
Invité régulier
Inscription : juillet 2006 Messages : 24 |
2ème problème :
Le poste client ouvre une nouvelle connexion TCP qui s'établit normalement avec le serveur web. Il émet alors une requête HTTP contenant une demande différente de celles fermées précedemment. Dès que le serveur web a acquitté cette requête d'un point de vue TCP, le client ferme brutalement la connexion avec un paquet TCP Reset. Il recommence immédiatement cette tentative de connexion et la répète un certain nombre de fois ( entre 20 et 400 fois). D'un point de vue réseau, tous les paquets sont ok et les réponses du serveur Web sont totalement normales. Le problème est donc situé avec une quasi-certitude sur les postes clients. => On passe à Firefox !! 
|
|
|
00
|
|
26/09/2006, 15h33
|
#14 | |
|
Membre Expert
Inscription : juin 2006 Messages : 889 |
 ce bug est-il referencer Citation:
|
|
|
|
00
|
|
27/09/2006, 09h50
|
#15 | |
|
Invité régulier
Inscription : juillet 2006 Messages : 24 |
1er problème : Le bug est plus ou moins référencé (!!!):
http://channel9.msdn.com/wiki/defaul...etExplorerBugs Voir Citation:
Là où je bosse, IE est La Norme et les chefs sont pas content quand on change La Norme....  Ils pense ouvrir un bug chez Maxisoft, c'est dire ...Passage à linux, impossible pour les utilisateurs de base. Ce qui n'est pas mon cas, j'ai la chance de faire tourner une ArchLinux
|
|
|
|
00
|
|
03/10/2006, 09h28
|
#16 |
|
Invité régulier
Inscription : juillet 2006 Messages : 24 |
p'tain
Bon le problème a recommencé avec Firefox
Donc ça ne vient pas de IE6...Reste un problème de conf. d'apache, un problème sur nos cgi...ou...ou... 
|
|
|
00
|
|
03/10/2006, 13h26
|
#17 | |
|
Membre Expert
Inscription : juin 2006 Messages : 889 |
Citation:
 .C'est peut-etre des librairies reseaux ou la couche reseaux qui deconne ( un peu difficile a croire ) , apres faut voir a quel niveau si c'est NDIS ou TDI .NB: donc mon idee de l'autre n'etait pas si mauvaise
|
|
|
|
00
|
|
04/10/2006, 12h13
|
#18 | |
|
Invité régulier
Inscription : juillet 2006 Messages : 24 |
Citation:
Linux en test chez 2 ou 3 utilisateurs, pourquoi pas... A noter que chez nous, les developpeurs (in ArchLinux we trust (pas toujours )) (qui nous servons aussi de l'appli mais moins intensément) pour l'instant nous n'avons pas générer ce type de problème...C'st quoi TDI ?? |
|
|
|
00
|
|
04/10/2006, 14h28
|
#19 |
|
Membre Expert
Inscription : juin 2006 Messages : 889 |
Une photo sera plus parlant que mes explications
, cette couche gere les protocoles de niveau 4 (typiquement TCP , UDP ) bien sure je te parle de tes clienst win32 |
|
|
00
|
Copyright © 2000-2012 - www.developpez.com