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.)
@+
Bonjour,
Je n'ai pas eu personnellement affaire à ce genre de cas, néanmoins certains de mes enseignement pourrons t'être utile.
Pour caricaturer, Il faut voir le management de la sécurité comme un mauvais filme d'espionnage. Il faut toujours avoir un coup sur son adversaire.
Dans tout cas, ton système à été compromis il faut que tu évalue les informations suivante : - le cout de la compromission du serveur (qu'il soit financier ou d'image) ; - le cout des mesures de protections à mettre en place.
De plus, Il reste potentiellement sur ton infra des failles non encore exploité. Il faudrait réaliser un audit de l'infra pour mieux la sécurité, voir installé un système de détection d'intrusion ou un honeypot.
Cordialement Alexis Lameire
Le 28 juillet 2014 10:14, Fernando Lagrange fernando+frsag@demo-tic.org 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:
- 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:
- 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 ;)
- 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.)
@+
Fernando Lagrange Demo-TIC - Outils En Ligne http://www.demo-tic.org Jabber/XMPP: fernando@im.apinc.org _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour.
On Mon, 2014-07-28 at 10:14 +0200, Fernando Lagrange wrote:
h. je vais faire monter la réinstallation de ce serveur vers le haut de la pile des choses à faire ;)
C'est _TOUJOURS_ une bonne idée si tu as le temps, de re-installer au propre une machine ayant été compromise.
Le fait de maintenir des scripts php opensource a jour que tu ne déploies pas toi même a toujours été le gros soucis de notre métier.
L'adminsys doit s'assurer que le serveur ne peut pas se faire trouer.
(je prends wordpress en exemple, mais vous pouvez remplacer ca par n'importe quel projet opensource, ca peut être phpmyadmin, qui a la palme d'or du trouage)
Les développeurs déploient un wordpress d'il y a 4 ans, (modifié par leurs petites mains) et donc ce wordpress n'est plus "mainline". On ne peut plus mettre ce wordpress a jour en suivant la méthode proposée par les développeurs du logiciel.
Et la il va en résulter une bataille des responsabilités entre dev et sysadmin.
Pour se prémunir de soucis plus grand et gros qu'un script php opensource hack via une requête POST a la con, nous avons en tant qu'adminsys une potion magique. Ca s'appelle chroot() + php-fpm + nginx. Le script php ne sera executé qu'avec les droits de l'utilisateur spécifique de ce vhost, et ne pourra pas sortir de sa prison. Ainsi si le site se fait trouer, tu es peinard, l'utilisateur est cloisonné. La seule responsabilité du hack est donc sur les épaules des déployeurs de scripts opensource troués non a jour ;)
La, dans ton cas, tu vérifies si ton /etc a été modifié, ainsi que ton kernel afin de voir si tu as un rootkit, mais tu ne pourras jamais en être certain. Tu ne devrais jamais avoir a te mettre dans une telle position, si tu veux mon avis :)
Avec la méthode cité ci-avant, tu es plus peinard.
avec les bon contextes selinux/cgroups, tu dois même pouvoir limiter l’envoie des mails. Sa peut être utile en cas de nouvelle compromission.
Cordialement Alexis Lameire
Le 28 juillet 2014 10:47, Alexandre Legrix alex@bragonux.net a écrit :
Bonjour.
On Mon, 2014-07-28 at 10:14 +0200, Fernando Lagrange wrote:
h. je vais faire monter la réinstallation de ce serveur vers le haut de la pile des choses à faire ;)
C'est _TOUJOURS_ une bonne idée si tu as le temps, de re-installer au propre une machine ayant été compromise.
Le fait de maintenir des scripts php opensource a jour que tu ne déploies pas toi même a toujours été le gros soucis de notre métier.
L'adminsys doit s'assurer que le serveur ne peut pas se faire trouer.
(je prends wordpress en exemple, mais vous pouvez remplacer ca par n'importe quel projet opensource, ca peut être phpmyadmin, qui a la palme d'or du trouage)
Les développeurs déploient un wordpress d'il y a 4 ans, (modifié par leurs petites mains) et donc ce wordpress n'est plus "mainline". On ne peut plus mettre ce wordpress a jour en suivant la méthode proposée par les développeurs du logiciel.
Et la il va en résulter une bataille des responsabilités entre dev et sysadmin.
Pour se prémunir de soucis plus grand et gros qu'un script php opensource hack via une requête POST a la con, nous avons en tant qu'adminsys une potion magique. Ca s'appelle chroot() + php-fpm + nginx. Le script php ne sera executé qu'avec les droits de l'utilisateur spécifique de ce vhost, et ne pourra pas sortir de sa prison. Ainsi si le site se fait trouer, tu es peinard, l'utilisateur est cloisonné. La seule responsabilité du hack est donc sur les épaules des déployeurs de scripts opensource troués non a jour ;)
La, dans ton cas, tu vérifies si ton /etc a été modifié, ainsi que ton kernel afin de voir si tu as un rootkit, mais tu ne pourras jamais en être certain. Tu ne devrais jamais avoir a te mettre dans une telle position, si tu veux mon avis :)
Avec la méthode cité ci-avant, tu es plus peinard.
-- Alexandre Legrix alex@bragonux.net
Liste de diffusion du FRsAG http://www.frsag.org/
Le Mon, Jul 28, 2014 at 10:47:11AM +0200, Alexandre Legrix [alex@bragonux.net] a écrit: [...]
Le fait de maintenir des scripts php opensource a jour que tu ne déploies pas toi même a toujours été le gros soucis de notre métier.
L'adminsys doit s'assurer que le serveur ne peut pas se faire trouer.
(je prends wordpress en exemple, mais vous pouvez remplacer ca par n'importe quel projet opensource, ca peut être phpmyadmin, qui a la palme d'or du trouage)
Meme pas besoin de restreindre a "projet opensource". J'ai vu aussi plein de trucs mal foutus se faire compromettre aussi. Même si c'est plutot moins courant que de voir passer des bots/rootkits qui ciblent des failles repandues dans Joomla/Wordpres/etc.
[...]
Ca s'appelle chroot() + php-fpm + nginx. Le script php ne sera executé qu'avec les droits de l'utilisateur spécifique de ce vhost, et ne pourra pas sortir de sa prison.
Apache, mpm-itk, open_basedir ;-)
Limiter les accès "réseau" en sortie, ça peut permettre de restreindre les effets (par exemple un bot de DDOS ne pourra pas faire de degat). Passer les mails sortant de PHP via mail() dans un wrapper, qui permette de tracer d'où un mail sortant est envoyé, pour identifier l'origine d'un spamotron, aussi
On Mon, 2014-07-28 at 10:59 +0200, Dominique Rousseau wrote:
Apache, mpm-itk, open_basedir ;-)
T'es plus 20eme siecle, et moi 21eme ;P
Sinon, effectivement, le wrapper sur la fonction mail() est clairement la "killer feature", a mettre en place.
On 28 juil. 2014, at 12:26, Manu manu@formidable-inc.net wrote:
Le 28/07/2014 12:03, Alexandre Legrix a écrit :
Sinon, effectivement, le wrapper sur la fonction mail() est clairement la "killer feature", a mettre en place.
- un rkhunter qui peut aider à déterminer ce qui pourrait être compromis dans un système.
Manu Jacquet
Question, quest ce qu'il y connaît aux femmes rkhunter? Réponse : RIEN ! Il y connaît rien aux femmes rkhunter.
Désolé.
Le 28/07/2014 12:03, Alexandre Legrix a écrit :
On Mon, 2014-07-28 at 10:59 +0200, Dominique Rousseau wrote:
Apache, mpm-itk, open_basedir ;-)
T'es plus 20eme siecle, et moi 21eme ;P
Sinon, effectivement, le wrapper sur la fonction mail() est clairement la "killer feature", a mettre en place.
Je rebondis sur le wrapper mail. J'en ai fait un avec deux objectifs : - corriger les return path, reply to, from mal formaté ou pas formaté du tout et qui du coup donne des champs en nomdutilisateur@fqdnduserveur.tld - pouvoir justement prévenir tout envoie de mail non désiré mais sur ce point je bloque.
Je pensais pouvoir récupérer l'uid qui déclenche le wrapper et éventuellement l'url demandée mais je n'y suis pas arrivé. Je me suis branché dans le php.ini avec l'instruction sendmail_path vers mon wrapper. sendmail_path = /usr/local/bin/mail-wrapper
Vous procédez pareil et j'ai mal cherché comment récupérer l'uid ou je me branche pas au bon endroit dans PHP?
Merci
Le 28 juil. 2014 à 10:47, Alexandre Legrix a écrit :
Le fait de maintenir des scripts php opensource a jour que tu ne déploies pas toi même a toujours été le gros soucis de notre métier.
L'adminsys doit s'assurer que le serveur ne peut pas se faire trouer.
(je prends wordpress en exemple, mais vous pouvez remplacer ca par n'importe quel projet opensource, ca peut être phpmyadmin, qui a la palme d'or du trouage)
Les développeurs déploient un wordpress d'il y a 4 ans, (modifié par leurs petites mains) et donc ce wordpress n'est plus "mainline". On ne peut plus mettre ce wordpress a jour en suivant la méthode proposée par les développeurs du logiciel.
Et la il va en résulter une bataille des responsabilités entre dev et sysadmin.
J'ai eu le cas d'un wordpress troué également. Pour la bonne raison qu'il n'était pas à jour. L'attaquant a commencé à uploader de quoi exécuter de manière arbitraire ses scripts, puis il a uploadé un shell codé en php capable de récupérer tout ce qui peut être intéressant sur le système (passwd, conf, logiciels installés, etc), puis il a mis en place ses petites pages de pub pour produits pharmaceutiques revigorants. L'une des choses qui avait aidé à l'époque était le fait que les droits des fichiers et dossiers étaient très permissifs. J'enfonce des portes ouvertes mais la première vérification à faire est de s'assurer que les droits sont en r--r----- ou r--r--r-- par défaut (hormis sur des dossiers particuliers comme l'upload). Cela peut ralentir considérablement une attaque.
Pour se prémunir de soucis plus grand et gros qu'un script php opensource hack via une requête POST a la con, nous avons en tant qu'adminsys une potion magique. Ca s'appelle chroot() + php-fpm + nginx. Le script php ne sera executé qu'avec les droits de l'utilisateur spécifique de ce vhost, et ne pourra pas sortir de sa prison.
Je ne peux que plussoyer php-fpm. Très pratique pour isoler les applications, et performant. Éventuellement lxc pour parfaire l'isolation (en s'assurant de dropper toutes les capabilities inutiles). Si tu as le temps, tu peux aussi jouer avec suhosin ou disabled_functions.
Cordialement Emmanuel Thierry
Le Mon, Jul 28, 2014 at 10:14:57AM +0200, Fernando Lagrange [fernando+frsag@demo-tic.org] a écrit: [...]
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.
Comme Bragon l'a dit, le "mieux", mais pas toujours faisable, c'est réinstaller le système et remettre à partir de sauvegardes.
Sinon, la relative chance qu'on a, c'est que dans la très grande majorité des cas, le casse-pied qui a troué le site ne cherchait que un lieu confortable pour envoyer du spam ou autre bricole du genre. On peut dans ce cas limiter la "réinstallation" aux applicatifs web.
Sinon, pour faire la chasse aux fichiers compromis, recherche tous les fichiers PHP contenant l'inistruction eval() Il y a certaines utilisations legitimes, mais des eval(base64decode($POST['_xyz13'])) c'est un bon signe de trou :)
Le 28 juil. 2014 à 10:14, Fernando Lagrange fernando+frsag@demo-tic.org 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:
- 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:
- 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 ;)
- 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.
bonjour
Il faut effectivement éplucher les logs et surtout les logs web access et error (tous les ../../%20... , url bizarre). Il faut également faire quelques recherches sur google sur l'IP du serveur, les pages web qui ont permis de faire l'intrusion et chercher en utilisant les google dorks. Ainsi vous pourrez trouver s'il existe des traces sur le net de l'intrusion et de surtout comment les "pirates/bot" ont fait pour trouver la faille. Normalement, quand cela arrive, il ne faut surtout pas réinstaller ou mettre à jour dans l'urgence, il faut faire l'audit avant sinon vous perdez de nombreuses traces et vous risquez de passer à coté d'informations pouvant être utiles.
Cordialement
Florent NOLOT Université de Reims Champagne-Ardenne
Le 28/07/2014 10:14, Fernando Lagrange 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:
- 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:
- 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 ;)
- 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.)
@+
Juste pour dire, au niveau réglementaire français: - http://www.cnil.fr/documentation/fiches-pratiques/fiche/article/la-notificat... dans le cas où des données personnelles ont été compromises - les opérateurs en charge d'activités vitales pour l’État ont une obligation de notification vers l'autorité de tutelle - dans le cas où l'infra compromise participe à des activités de recherche, il peut aussi avoir des dispositifs un peu spécifiques (protection du patrimoine scientifique et technique) - pour les autres, pas d'obligations envers les autorités
Juste... Peut-être Au niveau contractuel, si le client l'a spécifié.
Enfin, une compromission est une intrusion dans un système automatisé de données (un STAD dans le jargon), article L323 et suivant du code pénal. Il est possible (et recommandé) de porter plainte. La brigade d'enquête sur les fraudes aux technologies de l'information est le service à joindre.
Je pense que ça été dit plus haut, mais le réflexe n°1 en cas d'intrusion: snapshots. Faut pas saboter la scène de crime :)
++ Stéphane
Le 28/07/2014 10:14, Fernando Lagrange 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:
- 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:
- 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 ;)
- 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.)
@+
-
Alexandre Legrix -
Alexis Lameire -
Dominique Rousseau -
Emmanuel Thierry -
Fernando Lagrange -
Florent Nolot -
Frederic de Villamil -
Manu -
stephane.martin -
Wallace