OVH Community, votre nouvel espace communautaire.

Aide pour comprendre un dump TCP


janus57
01/06/2015, 15h57
Bonjour,

Une faille dans l'appli qui est stockée dans owncloud/index.php/apps/files/ajax/download.php ?
Si oui c'est une 0days alors car owncloud est maintenu à jour (via les packages comme recommandé par owncloud) et owncloud et la seule application PHP.

En gros l'ip distante fait une request sur cette faille et le serveur vps répond via l'exploit... Je ne sais pas trop ce qu'ils ont l'air de s'échanger mais bon.... Je vois que ça...
l'ip cliente/visiteur/membre fait partie de l'association et voulait simplement téléchargé le fichier, au même moment le monitoring m'annonce un dow (ping + SSH) et le membre me signale que son téléchargement ne fonctionne pas.

Après j'ai juste montrer le logs apache à l'hébergeur et ils ont débloqué le VPS...
Je suis aussi tombé sur google sur un réponse qui disait que ce phénomène pouvait se produit si le client rencontre un protocole avec le certificat SSL (mismatch du CN, association.ovh à la place de www.association.ovh ), j'avais un warning dans la config apache (qui après recherche n’impacte pas) que j'ai rectifié.

Les fichier sont normalement pris en charge par le "mod_xsendfile" (sinon avec owncloud c'est pris en charge par PHP, ce qui consomme pas mal).

Et visiblement le blocage était au niveau du prestataire et non du VAC de OVH (qui détecte les (D)DoS aussi bien sortant que entrant).
Donc c'est du faux-positif de leur script anti-DoS sortant ? c'est le clients (waterfox 35) qui a un petit problème avec l'utilisation couplé de TLS et mod_xsendfile ?
Ou alors c'est bien une faille dans owncloud ?

EDIT :
d'après les graphs munin le membre à fait un "pic" à 110pps (pour un débit de +/- 0.23Mo/s) juste avant le dump et la coupure du VPS par ""l'hébergeur"".

Cordialement, janus57

sich
01/06/2015, 15h36
Une faille dans l'appli qui est stockée dans owncloud/index.php/apps/files/ajax/download.php ?
En gros l'ip distante fait une request sur cette faille et le serveur vps répond via l'exploit... Je ne sais pas trop ce qu'ils ont l'air de s'échanger mais bon.... Je vois que ça...

janus57
01/06/2015, 14h55
Bonjour,

contexte : petit VPS chez un sous-traitant de OVH qui sert à du stockage de donné (via owncloud en HTTPS only) + hébergement d'un serveur mumble, le tout sous Debian 7(.8) à jour.

Hier le prestataire (ou OVH) à visiblement coupé le trafic sur cette IP à cause de ce dump :
18:21:57.129561 IP 176.31.199.xxx.443 > 92.144.10.xxx.63486: Flags [.], seq 3993957464:3993958916, ack 979876090, win 134, length 1452
18:21:57.129573 IP 176.31.199.xxx.443 > 92.144.10.xxx.63486: Flags [.], seq 0:1452, ack 1, win 134, length 1452
18:21:57.129619 IP 176.31.199.xxx.443 > 92.144.10.xxx.63486: Flags [.], seq 1452:2904, ack 1, win 134, length 1452
18:21:57.129624 IP 176.31.199.xxx.443 > 92.144.10.xxx.63486: Flags [.], seq 1452:2904, ack 1, win 134, length 1452
18:21:57.129678 IP 176.31.199.xxx.443 > 92.144.10.xxx.63486: Flags [.], seq 2904:4356, ack 1, win 134, length 1452
18:21:57.129687 IP 176.31.199.xxx.443 > 92.144.10.xxx.63486: Flags [.], seq 2904:4356, ack 1, win 134, length 1452
18:21:57.129738 IP 176.31.199.xxx.443 > 92.144.10.xxx.63486: Flags [.], seq 4356:5808, ack 1, win 134, length 1452
18:21:57.129744 IP 176.31.199.xxx.443 > 92.144.10.xxx.63486: Flags [.], seq 4356:5808, ack 1, win 134, length 1452
18:21:57.129799 IP 176.31.199.xxx.443 > 92.144.10.xxx.63486: Flags [.], seq 5808:7260, ack 1, win 134, length 1452
18:21:57.129802 IP 176.31.199.xxx.443 > 92.144.10.xxx.63486: Flags [.], seq 5808:7260, ack 1, win 134, length 1452
18:21:57.129878 IP 176.31.199.xxx.443 > 92.144.10.xxx.63486: Flags [.], seq 7260:8712, ack 1, win 134, length 1452
18:21:57.129884 IP 176.31.199.xxx.443 > 92.144.10.xxx.63486: Flags [.], seq 7260:8712, ack 1, win 134, length 1452
18:21:57.129919 IP 176.31.199.xxx.443 > 92.144.10.xxx.63486: Flags [.], seq 8712:10164, ack 1, win 134, length 1452
18:21:57.129979 IP 176.31.199.xxx.443 > 92.144.10.xxx.63486: Flags [.], seq 10164:11616, ack 1, win 134, length 1452
18:21:57.129990 IP 176.31.199.xxx.443 > 92.144.10.xxx.63486: Flags [.], seq 10164:11616, ack 1, win 134, length 1452
18:21:57.130040 IP 176.31.199.xxx.443 > 92.144.10.xxx.63486: Flags [.], seq 11616:13068, ack 1, win 134, length 1452
18:21:57.130047 IP 176.31.199.xxx.443 > 92.144.10.xxx.63486: Flags [.], seq 11616:13068, ack 1, win 134, length 1452
18:21:57.130099 IP 176.31.199.xxx.443 > 92.144.10.xxx.63486: Flags [.], seq 13068:14520, ack 1, win 134, length 1452
18:21:57.130104 IP 176.31.199.xxx.443 > 92.144.10.xxx.63486: Flags [.], seq 13068:14520, ack 1, win 134, length 1452
18:21:57.130159 IP 176.31.199.xxx.443 > 92.144.10.xxx.63486: Flags [.], seq 14520:15972, ack 1, win 134, length 1452
18:21:57.130164 IP 176.31.199.xxx.443 > 92.144.10.xxx.63486: Flags [.], seq 14520:15972, ack 1, win 134, length 1452
18:21:57.130219 IP 176.31.199.xxx.443 > 92.144.10.xxx.63486: Flags [.], seq 15972:17424, ack 1, win 134, length 1452
18:21:57.130223 IP 176.31.199.xxx.443 > 92.144.10.xxx.63486: Flags [.], seq 15972:17424, ack 1, win 134, length 1452
18:21:57.130279 IP 176.31.199.xxx.443 > 92.144.10.xxx.63486: Flags [.], seq 17424:18876, ack 1, win 134, length 1452
18:21:57.130285 IP 176.31.199.xxx.443 > 92.144.10.xxx.63486: Flags [.], seq 17424:18876, ack 1, win 134, length 1452
18:21:57.130339 IP 176.31.199.xxx.443 > 92.144.10.xxx.63486: Flags [.], seq 18876:20328, ack 1, win 134, length 1452
18:21:57.130346 IP 176.31.199.xxx.443 > 92.144.10.xxx.63486: Flags [.], seq 18876:20328, ack 1, win 134, length 1452
18:21:57.130398 IP 176.31.199.xxx.443 > 92.144.10.xxx.63486: Flags [.], seq 20328:21780, ack 1, win 134, length 1452
18:21:57.130404 IP 176.31.199.xxx.443 > 92.144.10.xxx.63486: Flags [.], seq 20328:21780, ack 1, win 134, length 1452
18:21:57.130459 IP 176.31.199.xxx.443 > 92.144.10.xxx.63486: Flags [.], seq 21780:23232, ack 1, win 134, length 1452
Au vu du port source j'ai tout de suite orient mes recherche vers un accès apache en SSL et bingo :
root@association:/# grep -Hnr "18:21:5" /var/log/
/var/log/apache2/ssl_access_association.ovh.log:711:
92.144.10.xxx - - [31/May/2015:18:21:53 +0200] "GET /owncloud/index.php/apps/files/ajax/download.php?dir=%2Fjt_ma&files=%5B%2208%22%5D HTTP/1.1" 200 51170937 "https://www.association.ovh/owncloud/index.php/apps/files/?dir=%2Fjt_ma" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:35.0) Gecko/20100101 Firefox/35.0 Waterfox/35.0"
Les IP SRC + Destination + NDD ont été masqué partiellement.

Donc sachant que je n'y connait pratiquement rien je me suis un peu documenté et de ce que j'arrive à comprendre c'est que :
le VPS (176.31.199.xxx) via le port 443 (https donc) à envoyé des données ou fait un échange (à cause de la présence de "ACK") avec le membre (92.144.10.xxx) sur le port privé 63486 via le protocol IP.

Jusque là normalement je dit pas de conneries, après les 2 ont communiqué avec un fenêtre TCP de taille 134 (bytes?) et un message de 1452 bytes de longueur, ce qui d'après une recherche google semble +/- normale.

Donc avis aux "expert" ou à ceux qui ont des connaissance beaucoup plus poussé que moi dans ce domaine, mais pour vous est-ce que ceci pose un problème ?
Est-ce un (D)DoS envoyé par le VPS ou simplement une communication (a)normle entre un navigateur et un serveur le tout en SSL/TLS (normalement non pour SSL par j'ai désactivé SSLv2 +SSLv3 dans le VHost).

P.S. c'est les seule infos que j'ai à ma disposition.
P.S.2 au moment ou j’écris ce post visiblement le prestataire à débloquer l'ip... (monitoring up).

Cordialement, janus57