Réémission requête GET sur serveur Apache

**aquafiestas** · 15/09/2006, 14h07

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) ?

**ovh** · 17/09/2006, 12h54

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...

**aquafiestas** · 18/09/2006, 09h23

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.

**_solo** · 19/09/2006, 15h59

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.

**aquafiestas** · 21/09/2006, 10h29

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 !

**aquafiestas** · 22/09/2006, 08h42

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

**aquafiestas** · 22/09/2006, 11h09

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 !!!

**_solo** · 22/09/2006, 13h50

Envoyé par aquafiestas

La seul explication que nous avons , un équipement de niveau 3 (TCP) corrigent les paquets...(ou ethereal est buggé)

NON!!!! papa noel n'existe pas meme sur les routeurs lol.

Envoyé par aquafiestas

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 !

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

**aquafiestas** · 22/09/2006, 14h14

Citation:
aquafiestas a écrit :
La seul explication que nous avons , un équipement de niveau 3 (TCP) corrigent les paquets...(ou ethereal est buggé)
NON!!!! papa noel n'existe pas meme sur les routeurs lol.

Tu as raison, nous avons trouvé la raison de ce phénomène :
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 !

**aquafiestas** · 22/09/2006, 14h15

est-il possible que certains de tes clients soit corrompus avec un rootkit/trojan/etc....

C'est possible mais tous les anti-"machins" qu'on a passé sur les XP n'ont strictement rien trouvé....

**_solo** · 22/09/2006, 14h17

...de quoi devenir dingue tout ca....

**aquafiestas** · 26/09/2006, 09h15

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...

**aquafiestas** · 26/09/2006, 09h18

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 !!

**_solo** · 26/09/2006, 15h33

ce bug est-il referencer

=> On passe à Firefox !!

a quand son grand frere

**aquafiestas** · 27/09/2006, 09h50

1er problème : Le bug est plus ou moins référencé (!!!):
http://channel9.msdn.com/wiki/defaul...etExplorerBugs
Voir

HTTP/1.1 Compression and Entity Tags

On passe à Firefox le temps pour prouver que le 2ème problème vient de IE6 : Si il n'y a pas de soucis avec Firefox alors le problèmes vient de IE.

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

**aquafiestas** · 03/10/2006, 09h28

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...

**_solo** · 03/10/2006, 13h26

Envoyé par aquafiestas

Bon le problème a recommencé avec Firefox

mais faut pas le dire a la direction sinon il vont t'obliger a le desinstaller

.

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

**aquafiestas** · 04/10/2006, 12h13

mais faut pas le dire a la direction sinon il vont t'obliger a le desinstaller

Trop tard, il passe tous les jours pour voir et savoir...

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 ??