Le 28 juil. 2014 à 10:14, Fernando Lagrange <[email protected]> a écrit :
> Bonjour, > > Je suis un peu vert: un serveur que j'administre a été compromis ! :-X > J'ai été alerté car une page web de phishing a été mise en place, à cause > d'une application que je n'avais pas mise à jour. > > En y regardant de plus près, j'ai trouvé aussi une page pour envoyer du SPAM. > De fait: il y avait plus de 200 pourriels en cours d'envoi sur le serveur d'à > côté. Là, j'ai été trop rapide et tout effacé, maintenant je me dis que j'y > aurais bien jeté un œil à ces pourriels… :-/ > > Mes recherches sur le net arrivent surtout sur comment se prémunir (mettre en > place la sécurité), je n'ai pas trouvé grand-chose sur « l'après ». L'après > non-technique, j'entends. > > Du coup, comment vous faites: > 1. pour vérifier que tout va bien techniquement ? > et surtout: > 2. est-ce qu'il faut suivre des démarches pour se prémunir au cas où une > plainte tomberait dans X temps ? > > > Personnellement, après avoir coupé les accès aux pages concernées: > 1. a. J'ai regardé l'arborescence des htdocs dans l'historique des > sauvegardes (et retrouvé depuis quand c'est arrivé) > b. vérifié les courriels metche de surveillance de l'arborescence /etc (pas > vu de modifs de ce côté-là) > c. j'ai installé rkhunter (on n'est jamais trop prudent, mais est-ce utile à > postériori ?) > d. j'ai mis à jour (et je suis en négociation avec ma hiérarchie pour garder > les serveurs à jour, mais c'est pas simple) > e. Je continue à éplucher les logs de la période, j'hésite à installer > logwatch > f. je vais baisser les alertes munin sur le nombre de courriels par seconde > (mais j'imagine que ça va me faire des faux-positifs et une bonne attaque > passera inaperçue) > h. je vais faire monter la réinstallation de ce serveur vers le haut de la > pile des choses à faire ;) > > > 2. Je suis en train d'envoyer un message à FRSAG. ;) > Plus sérieusement, je me demande s'il ne faut pas que je déclare quelque > chose quelque part ? (Je sais pas trop si je pourrai fournir des infos > précises d'ici 2, 5 ou 10 ans…) > > > Et vous, si ça vous est arrivé, avez-vous fait quelque chose ? Que s'est-il > passé ensuite ? > (J'accepte les messages en privé si vous pensez que c'est trop sensible en > public, n'hésitez-pas à me renvoyer sur des discussions similaires.) > > @+ Hello, 1- Isoler Isole le serveur du reste de ton parc le temps de faire une analyse post mortem à tête reposée. Le plus simple, c’est de couper le serveur du réseau, et de monter le disque en NFS ou autre sur une machine saine depuis laquelle tu pourras regarder ce qu’il s’est passé, et voir si les données sont récupérables sans des scripts compromis. Rien de pire que de réinstaller un truc vérolé parce qu’on n’a pas (au hasard) vérifié que tous les répertoires d’images de son Wordpress ne contiennent que ce qu’ils sont sensés contenir. Le montage du disque en NFS te permet d’éviter les rootkits qui vont te cacher des processus / fichiers au runtime / redéployer des saloperies alors que tu pensais être propre. J’insiste donc pas mal dessus :-) 2- Alerter Préviens le(s) client(s) concernés par la compromission en leur expliquant ce qui a causé la compromission de leur compte / script (et qui est responsable des mises à jour). Préviens ton département juridique qui te dira s’il faut entreprendre des démarches pour éviter de te faire pourrir. 3- Réinstaller Réinstalle le serveur sur un disque propre (quitte à backuper le contenu du serveur ailleurs si tu n’as pas de spare. Virer les scripts vérolés ne sert à rien si tu ne réinstalles pas en même temps. Et pas de rsync bête et méchant des confs / data users. C’est (très) long, mais c’est nécessaire. D’où l’utilité d’utiliser chef / puppet / cfengine / whatever. 4- Documenter Documente tout ce qui s’est passé : la compromission (qui, quoi, quand, comment, où, quel périmètre) et les actions entreprises pour réparer / réinstaller. Ajoute les gens qui ont été prévenus, ceux qui ont été mis dans la boucle. 5- Prévenir Comme ça va certainement arriver de nouveau mais d’une manière différente, vois comment tu peux limiter les effets de la compromission (escalade de privilèges, utilisation de scripts en dehors du scope direct du script utilisateur etc…) Vois comment tu peux installer des sondes dans ta supervision pour être alerté si des comportements louches sont détectés (un peu comme un développeur ajoute un test unitaire sur un bug en particulier) Bonne journée.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
