[Nowwhat]

....
Une idée pour trouver d'ou pourrait venir l'origine de la compromission ?

Remonter un par un les PROXMOX chez toi dans un PC/serveur isolé et étudier chaque instance pour voir laquelle se comporte suspect.
Trouver "la faille" n'est pas un science exacte.

T'as qu'UN certitude : la faille (un script, un programme) existe.
Le "je ne trouve rien" va t'ammener droit dans le mur - il faut :
1) le trouver - et encore, ça, c'est relativement simple.
2) trouver comment il a pu s'introduire sur ton serveur / instance proxmox - plus compliqué.

PS : Un container PROXMOX "de base" n'a pas de services activé - ne communique à peine sur le net (sauf DNS et un accès SSH probablement).
La faille => c'est ce que t'a introduit après ....

[leodom]

Mais si OVH t'a mis en rescue FTP c'est que ton serveur a déjà été pris en flag et que tu n'as rien fait ...

Ben la, je n'ai eu aucune notice auparavant, juste trouvé cet email ce matin (je suis en Polynésie).
J'espère que le serveur PROXMOX configuré automatiquement par OVH doit avoir les protections nécessaires.
Apres, j'avais 6 serveurs vituels qui tournaient dessus, sur DEBIAN, dont 1 avec WP et un avec Joomla, versions a jour

Une idée pour trouver d'ou pourrait venir l'origine de la compromission ?

[buddy]

Donc d'après OVH, qui a analysé le traffic réseau, c'est son serveur (aaa.bbb.ccc.ddd) qui a attaqué le serveur ZZZ.YYY.XXX.WWW en envoyant des "SYN" sur le port 80.

Ton serveur a pu répondre à une attaque par amplification ... Si ton serveur est "attaqué" et qu'il répond par amplification oui, il est coupé, car un serveur bien configuré ne répond pas à l'amplification. (il ne répond que très très légèrement et pas avec plusieurs requêtes en moins d'une seconde comme le montre le mail ci-dessus).

Non, une ip fil over ne règle pas le soucis, car il me semble qu'OVH coupe le serveur associé. Il faut juste configurer et limiter le serveur pour ne pas qu'ils répondent de manière exagérée ..

Mais si OVH t'a mis en rescue FTP c'est que ton serveur a déjà été pris en flag et que tu n'as rien fait ...

[leodom]

Merci Janus, dans le mail, on me dit :

Votre serveur nsXXXXX représentant une trop grande menace pour notre réseau, nous n'avons eu d'autre choix que de le placer dans le mode 'rescue FTP'. Un identifiant et un mot de passe vous ont été communiqués par email afin que vous puissiez récupérer simplement vos données encore présente sur son espace de stockage.
N'hésitez pas à vous rapprocher du support technique afin que cette situation ne devienne pas critique.
Vous pourrez retrouver ci-dessous les logs remontés par notre système quiont conduit à cette alerte.

- DEBUT DES INFORMATIONS COMPLEMENTAIRES -

Attack detail : 12Kpps/93Mbps
dateTime srcIp:srcPort dstIp:dstPort protocol flags bytes reason

2016.08.29 15:47:19 CEST aaa.bbb.ccc.ddd:64401 zzz.yyy.xxx.www:80 TCP SYN 1010 ATTACK:TCP_SYN
2016.08.29 15:47:19 CEST aaa.bbb.ccc.ddd:56020 zzz.yyy.xxx.www:80 TCP SYN 1010 ATTACK:TCP_SYN
2016.08.29 15:47:19 CEST aaa.bbb.ccc.ddd:63148 zzz.yyy.xxx.www:80 TCP SYN 1010 ATTACK:TCP_SYN
2016.08.29 15:47:19 CEST aaa.bbb.ccc.ddd:13993 zzz.yyy.xxx.www:80 TCP SYN 1010 ATTACK:TCP_SYN
2016.08.29 15:47:19 CEST aaa.bbb.ccc.ddd:48826 zzz.yyy.xxx.www:80 TCP SYN 1010 ATTACK:TCP_SYN
2016.08.29 15:47:19 CEST aaa.bbb.ccc.ddd:32741 zzz.yyy.xxx.www:80 TCP SYN 1010 ATTACK:TCP_SYN
2016.08.29 15:47:19 CEST aaa.bbb.ccc.ddd:24472 zzz.yyy.xxx.www:80 TCP SYN 1010 ATTACK:TCP_SYN
2016.08.29 15:47:19 CEST aaa.bbb.ccc.ddd:26685 zzz.yyy.xxx.www:80 TCP SYN 1010 ATTACK:TCP_SYN
2016.08.29 15:47:19 CEST aaa.bbb.ccc.ddd:53710 zzz.yyy.xxx.www:80 TCP SYN 1010 ATTACK:TCP_SYN
2016.08.29 15:47:19 CEST aaa.bbb.ccc.ddd:11364 zzz.yyy.xxx.www:80 TCP SYN 1010 ATTACK:TCP_SYN
2016.08.29 15:47:19 CEST aaa.bbb.ccc.ddd:16448 zzz.yyy.xxx.www:80 TCP SYN 1010 ATTACK:TCP_SYN
2016.08.29 15:47:19 CEST aaa.bbb.ccc.ddd:22216 zzz.yyy.xxx.www:80 TCP SYN 1010 ATTACK:TCP_SYN
2016.08.29 15:47:19 CEST aaa.bbb.ccc.ddd:29097 zzz.yyy.xxx.www:80 TCP SYN 1010 ATTACK:TCP_SYN
2016.08.29 15:47:19 CEST aaa.bbb.ccc.ddd:19099 zzz.yyy.xxx.www:80 TCP SYN 1010 ATTACK:TCP_SYN
2016.08.29 15:47:19 CEST aaa.bbb.ccc.ddd:30140 zzz.yyy.xxx.www:80 TCP SYN 1010 ATTACK:TCP_SYN
2016.08.29 15:47:19 CEST aaa.bbb.ccc.ddd:34417 zzz.yyy.xxx.www:80 TCP SYN 1010 ATTACK:TCP_SYN
2016.08.29 15:47:19 CEST aaa.bbb.ccc.ddd:52023 zzz.yyy.xxx.www:80 TCP SYN 1010 ATTACK:TCP_SYN
2016.08.29 15:47:19 CEST aaa.bbb.ccc.ddd:1703 zzz.yyy.xxx.www:80 TCP SYN 1010 ATTACK:TCP_SYN
2016.08.29 15:47:19 CEST aaa.bbb.ccc.ddd:20179 zzz.yyy.xxx.www:80 TCP SYN 1010 ATTACK:TCP_SYN
2016.08.29 15:47:19 CEST aaa.bbb.ccc.ddd:34370 zzz.yyy.xxx.www:80 TCP SYN 1010 ATTACK:TCP_SYN

L'addresse IP zzz vient de chine, selon un reverse ip...

A mon niveau, rien ne me prouve que le serveur ai été compromis, et selon le contrat KS, il y a une protection anti-DDOS

Par contre il est bien important de savoir que si mon IP fait l'objet d'une attaque, l'on coupe mon serveur et rende indisponible son contenu !

Je dois remonter un cluster HA avec promox4, sur 2 serveurs SYS et 1 KS (referee), est-ce que le fait d'avoir une IP fail over permet d'éviter ce genre de problème ?
(Si une IP est attaquée, et le serveur bloqué par ovh, le serveur mirroir sur une autre IP ne sera pas bloqué ?)

EDIT
Après recherche sur le net, ca semble dire que mon ip aaa a été utilisée pour envoyer des requetes sur l'ip zzz, ce qui voudrait donc dire qu'un script malveillant aurait été installé quelque part...

[janus57]

Bonjour,

Thanks buddy !
Effectivement, j'ai retrouvé mes fichiers, et je comprends bien qu'en Ks il faut que je me débrouille seul, mais si le support stoppe mon serveur sous prétexte de hack, j'aimerais quand même en savoir plus pour me protéger au cas ou, ou trouver la faille éventuelle...

vous avez la raison dans le mail normalement, quant à la recherche de faille/exploit c'est à vous de le faire et avant de re-mettre les VM en route car sinon cela va recommencer ailleurs jusqu’à ce que OVH vous ferme l'autre serveur aussi.
En générale les coupure pour hack c'est du DoS/Scan/bruteforce ou abuse sur votre IP qui est détecté par OVH et les VAC./sécurités.

Cordialement, janus57

[buddy]

beh non, KS tu n'as aucune garanti de délai (même en cas de pannes matérielles).

Si tu as un DD à moitié mort sur ton serveur vendredi, tu peux le "garder" jusqu'a mardi ou mercredi .. (le temps qu'un technicien lise le ticket et programme une intervention).

L'intervention n'est lancée que si le DD est complètement mort et que le serveur dit "disque introuvable".

Si il est mourant avec des fichiers corrompus, beh tu diagnostiques, puis attend la réponse du support puis tu es planifié après OVH puis après SYS.

[leodom]

désolé, mais c'est kimsufi donc c'est "logique" que le support ne répondent pas, il n'y en a pas sur kimsufi - contrairement à la gamme SoYouStart ou OVH)
Sinon, oui, normalement vous y avez accès, avez vous bien parcouru tous les dossiers ?

Thanks buddy !
Effectivement, j'ai retrouvé mes fichiers, et je comprends bien qu'en Ks il faut que je me débrouille seul, mais si le support stoppe mon serveur sous prétexte de hack, j'aimerais quand même en savoir plus pour me protéger au cas ou, ou trouver la faille éventuelle...

[leodom]

Merci pour cette réponse rapide Janus !

en Read Only vous avez accès aux fichier a travers les identifiants FTP transmis

Effectivement, j'ai accès a un répertoire, mais je ne trouvais pas l'arborescence de mon serveur, je pensais qu'il fallait monter un DD,
mais je viens de trouver mes dossiers sur /mnt !

Le bout du tunnel est en vue (Mais bien loin quand même...)

Merci encore !

[buddy]

Bonjour,

désolé, mais c'est kimsufi donc c'est "logique" que le support ne répondent pas, il n'y en a pas sur kimsufi - contrairement à la gamme SoYouStart ou OVH)

Sinon, oui, normalement vous y avez accès, avez vous bien parcouru tous les dossiers ?

[janus57]

Bonjour,

si vous êtes en FTP Read Only cela ne semble pas bon (deuxième mise en rescue ?).

Normalement en Read Only vous avez accès aux fichier a travers les identifiants FTP transmis avec la suspension.

Cordialement, janus57

[leodom]

Bonjour,

un de mes serveurs kimsufi aurait été hacké hier,
(Serveur OVH ProxMox 3.4)
il a été mis en mode rescue-ftp par le support
sous motif de HACKED
(le suport ne me répond pas, je trépigne depuis qqes heures)

j'y ai un certain nombre de containers proxmox que je veux transferer
sur un autre serveur KS le temps de voir c qui c'est passé,
mais je ne peux pas monter le DD depuis le mode rescue ftp read only

Une idée pour que je puisse accéder a mes fichiers ?
je peux me connecter en telnet mais pas en SSH sur le serveur

merci d'avance