Auteur Sujet: Capture wireshark d'un bug / attaque qui génére des 408 Request Time-out  (Lu 4173 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 47 185
    • Twitter LaFibre.info
Si vous voyez des codes HTTP 408 (Request Time-out) dans vos log Apache2, vous vous posez peut-être la question de ce que c'est...

Voici la capture wireshark, pendant une "attaque" 1200 à 1300 requêtes par minutes.
=> 201809_code_http_408_request_time-out.pcap.gz
Le fichier .pcap.gz est directement lisible avec Wireshark.
La capture est certifiée sans aucun paquet supprimé (drop=0 affiché après la capture)
La capture a été réalisée vers la fin de l'attaque : une partie des connexions capturées les 30 premières secondes sont incomplètes (il manque le début), mais les autres sont complètes.

Les paquets tagués DSCP CS4 sont ceux émis par l'attaquant, les paquets DSCP CS0 sont ceux émis par le serveur.
On remarque que l’attaquant èmet ACK pour des paquets qui n'ont jamais été émis.


Ci dessous les log Apache2, sans l'IP.
1ère colonne : port TCP source
2ème colonne : port TCP destination
4ème colonne : date
6ème colonne : code HTTP
7ème colonne : taille

60578 80 [02/Sep/2018:12:25:56 +0200] "-" 408 0 "-" "-"
60582 80 [02/Sep/2018:12:25:56 +0200] "-" 408 0 "-" "-"
60586 80 [02/Sep/2018:12:25:56 +0200] "-" 408 0 "-" "-"
60592 80 [02/Sep/2018:12:25:56 +0200] "-" 408 0 "-" "-"
60596 80 [02/Sep/2018:12:25:56 +0200] "-" 408 0 "-" "-"
60834 80 [02/Sep/2018:12:25:58 +0200] "-" 408 0 "-" "-"
60840 80 [02/Sep/2018:12:25:58 +0200] "-" 408 0 "-" "-"
60844 80 [02/Sep/2018:12:25:58 +0200] "-" 408 0 "-" "-"
60848 80 [02/Sep/2018:12:25:58 +0200] "-" 408 0 "-" "-"
60854 80 [02/Sep/2018:12:25:58 +0200] "-" 408 0 "-" "-"
60984 80 [02/Sep/2018:12:25:59 +0200] "-" 408 0 "-" "-"
32778 80 [02/Sep/2018:12:25:59 +0200] "-" 408 0 "-" "-"
32780 80 [02/Sep/2018:12:25:59 +0200] "-" 408 0 "-" "-"
32786 80 [02/Sep/2018:12:25:59 +0200] "-" 408 0 "-" "-"
32792 80 [02/Sep/2018:12:25:59 +0200] "-" 408 0 "-" "-"
32796 80 [02/Sep/2018:12:25:59 +0200] "-" 408 0 "-" "-"
32800 80 [02/Sep/2018:12:25:59 +0200] "-" 408 0 "-" "-"
32806 80 [02/Sep/2018:12:25:59 +0200] "-" 408 0 "-" "-"
32812 80 [02/Sep/2018:12:25:59 +0200] "-" 408 0 "-" "-"
32822 80 [02/Sep/2018:12:25:59 +0200] "-" 408 0 "-" "-"
32826 80 [02/Sep/2018:12:25:59 +0200] "-" 408 0 "-" "-"
32832 80 [02/Sep/2018:12:25:59 +0200] "-" 408 0 "-" "-"
32838 80 [02/Sep/2018:12:25:59 +0200] "-" 408 0 "-" "-"
32840 80 [02/Sep/2018:12:25:59 +0200] "-" 408 0 "-" "-"
32846 80 [02/Sep/2018:12:25:59 +0200] "-" 408 0 "-" "-"
32848 80 [02/Sep/2018:12:25:59 +0200] "-" 408 0 "-" "-"
32854 80 [02/Sep/2018:12:25:59 +0200] "-" 408 0 "-" "-"
32856 80 [02/Sep/2018:12:25:59 +0200] "-" 408 0 "-" "-"

On remarque que le port source va du port 32768 au port 60999 => cela permet d'identifier le système qui attaque comme un Linux.

Les ports clients sont normalement dans la plage suivante :
- Windows 2000 / XP (sortie en 2001) : du port 1025 au port 5000
- Windows modernes (à partir de 2007) : du port 49152 au port 65535
- Linux avant 2001 (noyaux 2.2.x) : du port 1024 au port 4999
- Linux à partir de 2001 (noyaux 2.4.x à 3.13) : du port 32768 au port 61000
- Linux à partir de 2015 (noyaux 3.19 et suivants) : du port 32768 au port 60999
- MacOS X / FreeBSD modernes : du port 49152 au port 65535

Chaque connexion se termine après li timeout de 30 secondes, vous voyez l’Intérêt de diminuer le timeout par défaut de 300 secondes à 30 secondes.

Modification du timeout de 300 secondes à 30 secondes pour Apache2 :
sed -i -e "s/Timeout 300/Timeout 30/g" /etc/apache2/apache2.conf

L'impact vue coté Apache :

Légende :
"_" Waiting for Connection
"S" Starting up
"R" Reading Request => Les connexions 408 restent bloqués en "R"
"W" Sending Reply
"K" Keepalive (read)
"D" DNS Lookup
"C" Closing connection
"L" Logging
"G" Gracefully finishing
"I" Idle cleanup of worker
"." Open slot with no current process

alain_p

  • Abonné Free fibre
  • *
  • Messages: 16 247
  • Delta S 10G-EPON sur Les Ulis (91)
Capture wireshark d'un bug / attaque qui génére des 408 Request Time-out
« Réponse #1 le: 02 septembre 2018 à 18:06:36 »
Et quel est l'intérêt, faire du Denial of Service (DOS) ?

numer!s

  • Abonné SFR THD (câble)
  • *
  • Messages: 182
  • Neuilly Sur Seine
Capture wireshark d'un attaque qui génére des 408 Request Time-out
« Réponse #2 le: 02 septembre 2018 à 19:24:03 »
Et quel est l'intérêt, faire du Denial of Service (DOS) ?

S'agit-il d'une attaque par intention nuisible ? Denial Of Service ?

Marin

  • Client Bbox vdsl
  • Modérateur
  • *
  • Messages: 2 804
  • 73
Capture wireshark d'un bug / attaque qui génére des 408 Request Time-out
« Réponse #3 le: 02 septembre 2018 à 19:41:13 »
Le code 408 est émis normalement par Apache quand une connexion est ouverte sans émission de requête HTTP dans un délai normal (ici, les connexions ne contiennent aucune donnée TCP).

Qu'est-ce qui permet de parler d'attaque avec cette capture ? J'ai l'impression de voir du trafic qui provient soit d'un client défaillant, soit d'une capture incomplète. Est-ce que cette activité d'un seul client a occasionné des downtimes ou ralentissements ?

vivien

  • Administrateur
  • *
  • Messages: 47 185
    • Twitter LaFibre.info
Capture wireshark d'un bug / attaque qui génére des 408 Request Time-out
« Réponse #4 le: 02 septembre 2018 à 21:44:30 »
La capture est complète (tous les paquets d'une même IP)
Je ne pense pas que le but soit de nuire, mais c'est peut être des tests ou un bug.

Pour moi envoyer 1200 à 1300 requêtes par minutes cela peut être considéré comme une attaque, non ?

J'ai eu des problèmes quand j'ai ouvert le miroir. Depuis, j'ai réduit par 10 les timeout et augmenté le nombre de slots possibles et je ne plus jamais en famine.

Quelques minutes après le démarrage du serveur, j'ai d'ailleurs systématiquement un "TCP: request_sock_TCP: Possible SYN flooding on port 80. Sending cookies.  Check SNMP counters."

Je ne sais pas si c'est le déclenchement qui est mal réglé (je n'ai trouvé que on/off) ou si c'est véritablement du SYN flooding.

Marin

  • Client Bbox vdsl
  • Modérateur
  • *
  • Messages: 2 804
  • 73
Capture wireshark d'un bug / attaque qui génére des 408 Request Time-out
« Réponse #5 le: 02 septembre 2018 à 22:52:43 »
Pour moi envoyer 1200 à 1300 requêtes par minutes cela peut être considéré comme une attaque, non ?

Non vu qu'il n'y a pas de requêtes (requête est de la terminologie HTTP), pas de trafic de données ou même de trafic couche transport valide.

Une attaque c'est quelque chose qui a pour but de nuire, là c'est 200 % plus de la maladresse que de la malveillance à première vue.

Si ça se trouve c'est quelqu'un qui a fait un tcpreplay d'une capture filtrée à l'arrache vers ton hôte (il y a des handshakes SYN->SYN/ACK->ACK complets, mais est-ce que les ACK répondent vraiment aux SYN/ACK et ne sont pas rejoués ?)

On pourrait aussi penser à une mauvaise règle iptables qui duplique incorrectement du trafic. Enfin vu que tu héberges un serveur de test de débit je pense que n'importe qui peut avoir l'idée de faire n'importe quoi avec (ça n'arrive pas fréquemment et c'est normal aussi)

vivien

  • Administrateur
  • *
  • Messages: 47 185
    • Twitter LaFibre.info
Capture wireshark d'un bug / attaque qui génére des 408 Request Time-out
« Réponse #6 le: 03 septembre 2018 à 06:41:13 »
Là c'est sur le serveur qui distribue les mises à jour Ubuntu pour la France.
=> http://fr.archive.ubuntu.com/stats/stats_server.html

700 000 PC par jour l'utilisent et il y en a quelques un avec des configuration un peu bizard.
Je me souvient qu’après avoir changé d'IP, pendant des mois je recevais des requêtes sur l'ancienne IP : visiblement des personnes qui avaient mis en dur l'ip dans /etc/hosts

L'impact sur Apache : (pic vert dimanche à 12h00)