Comme notent d'autres, il existe des méthodes. En fait pleins à différents niveaux. C'est pour ça que je dis dans la news:
Il y a peu de solutions à ce type de problème à l'heure actuelle en fait en tant qu'utilisateur (en tant que développeurs, il y a beaucoup plus).
Car les admins ont quand même pas mal de possibilités de savoir ce qu'il se passe d'anormal sur un serveur en temps réel, et je dois dire que j'ai trouvé ceux de Mint un peu légers sur le coup. Comme je le dis, je ne suis pas du tout expert en sécurité non plus, ni admin de formation, et je ne doute pas une seule seconde que je puisse me faire trouer aussi. Mais je mets tout de même un minimum de sécurité et j'ai pas l'impression qu'ils en aient mis la moindre. J'ai un serveur perso qui me sert à héberger des sites web de projet ou associatifs, des emails, etc.
Bon déjà j'ai fail2ban, que d'autres ont cité. Ça réduit les attaques de type "force brute". J'ai des règles très strictes pour SSH (je sais plus, probablement 3 tentatives seulement. On s'attend à ce que quelqu'un avec un accès SSH ne perde pas son mot de passe. D'ailleurs il devrait plutôt utiliser une clé). Un peu moins strictes (mais un peu quand même) pour IMAP (soyons un peu plus souple avec les utilisateurs IMAP qui peuvent être moins techniciens. Mais pas trop quand même. Au pire, l'utilisateur a son IP bloquée et il me contacte pour me demander de le débloquer). Des règles pour le HTTP (essayer de contenir un peu les DOS et autres bots un peu insistants), des règles sur les POSTs, des règles spécifiques Wordpress (tentatives de connexion répétées...), etc. On peut déjà pas mal limiter la casse avec fail2ban.
Ensuite ça limite pas tout, par exemple si quelqu'un connaît déjà une faille particulière sur une plateforme (Wordpress ou autre) et n'a donc pas besoin de tester des injections SQL sur tous les formulaires avec un bot, etc. alors il ne sera pas détecté par fail2ban. Par contre si ça lui permet disons de changer des fichiers sur le serveur, on peut avoir un script qui surveille les fichiers du site web et envoie une alerte au moindre changement de fichiers. On pourrait d'ailleurs imaginer la même chose pour les pages vitales (comme la page de download) en base de donnée: chaque modif du texte envoie un email à l'admin (le seul qui aurait le droit de toucher la page). Si c'est lui qui vient de l'effectuer, il ignore l'email. S'il n'a pas touché à la page, il sait immédiatement qu'il y a un problème.
Pour revenir sur les connexions SSH, car c'est un des nerfs du système, je reçois un email à chaque connexion SSH réussie (donc si je me suis pas connecté et que je reçois un email, je sais immédiatement qu'il y a un problème, puisque je suis le seul avec un accès). Bien sûr, je suis le seul admin sur mon petit serveur. S'il y avait 5 personnes avec accès au serveur (je ne parle pas d'un serveur avec accès simple-utilisateur, mais bien d'un serveur vital, genre pour les emails, le site, etc. Y aura jamais beaucoup de personnes autorisées sur celui-là) on peut imaginer alors un système un peu plus complexe en 2 temps, comme la réception d'un email automatique par cette personne seulement et l'obligation d'y répondre en moins de 5 minutes sinon tous les admins reçoivent une alerte à leur tour.
Ensuite root: je reçois aussi un email à chaque login root, avec le nom de l'utilisateur d'origine (y a plusieurs moyens de connaître cette info, comme logname, etc. Aussi je précise que la connexion SSH en root direct doit toujours être interdite sur un serveur. Ça permet notamment de savoir qui est l'utilisateur de base, par exemple pour détecter les montées de privilèges). Même une connexion sudo pourrait générer des emails automatiques.
Quant à un dump de base de données, je n'y ai jamais pensé et me rend compte que je n'ai rien fait, mais je suis sûr qu'il doit y avoir aussi moyen aussi de générer une alerte automatique à chaque tentative de dump. Vous pouvez ignorer votre message hebdomadaire (ou quotidien, pour un gros service) de backup, mais si vous recevez un message hors du créneau habituel, vous savez que quelque chose de louche est en train de se passer sur votre serveur.
Etc. etc. Les idées ne manquent pas au niveau administrateur pour détecter des choses qui ne devraient pas se produire sur un serveur. Le fait est qu'on n'est pas trop censé toucher un serveur en production. Donc dès qu'il y a une activité un peu inhabituelle, c'est assez facile à détecter, et envoyer des alertes à chaque mouvement n'est pas overkill selon moi. Surtout lorsqu'on a juste quelques serveurs, comme c'est probablement le cas de Mint (je doute qu'ils aient 1000 serveurs en production). Ensuite oui si vous avez des centaines de serveur, vous ferez les choses différemment (enfin probablement similaire, mais vous voudrez pas recevoir des emails pour un oui ou pour un non. À ce moment, vous pouvez avec des scripts un peu plus ciblés, des interfaces de gestion de votre parc pour gérer les alertes, etc.).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Comment détecter une intrusion ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Linux Mint a été compromise. Évalué à 9.
Comme notent d'autres, il existe des méthodes. En fait pleins à différents niveaux. C'est pour ça que je dis dans la news:
Car les admins ont quand même pas mal de possibilités de savoir ce qu'il se passe d'anormal sur un serveur en temps réel, et je dois dire que j'ai trouvé ceux de Mint un peu légers sur le coup. Comme je le dis, je ne suis pas du tout expert en sécurité non plus, ni admin de formation, et je ne doute pas une seule seconde que je puisse me faire trouer aussi. Mais je mets tout de même un minimum de sécurité et j'ai pas l'impression qu'ils en aient mis la moindre. J'ai un serveur perso qui me sert à héberger des sites web de projet ou associatifs, des emails, etc.
Bon déjà j'ai fail2ban, que d'autres ont cité. Ça réduit les attaques de type "force brute". J'ai des règles très strictes pour SSH (je sais plus, probablement 3 tentatives seulement. On s'attend à ce que quelqu'un avec un accès SSH ne perde pas son mot de passe. D'ailleurs il devrait plutôt utiliser une clé). Un peu moins strictes (mais un peu quand même) pour IMAP (soyons un peu plus souple avec les utilisateurs IMAP qui peuvent être moins techniciens. Mais pas trop quand même. Au pire, l'utilisateur a son IP bloquée et il me contacte pour me demander de le débloquer). Des règles pour le HTTP (essayer de contenir un peu les DOS et autres bots un peu insistants), des règles sur les POSTs, des règles spécifiques Wordpress (tentatives de connexion répétées...), etc. On peut déjà pas mal limiter la casse avec fail2ban.
Ensuite ça limite pas tout, par exemple si quelqu'un connaît déjà une faille particulière sur une plateforme (Wordpress ou autre) et n'a donc pas besoin de tester des injections SQL sur tous les formulaires avec un bot, etc. alors il ne sera pas détecté par fail2ban. Par contre si ça lui permet disons de changer des fichiers sur le serveur, on peut avoir un script qui surveille les fichiers du site web et envoie une alerte au moindre changement de fichiers. On pourrait d'ailleurs imaginer la même chose pour les pages vitales (comme la page de download) en base de donnée: chaque modif du texte envoie un email à l'admin (le seul qui aurait le droit de toucher la page). Si c'est lui qui vient de l'effectuer, il ignore l'email. S'il n'a pas touché à la page, il sait immédiatement qu'il y a un problème.
Pour revenir sur les connexions SSH, car c'est un des nerfs du système, je reçois un email à chaque connexion SSH réussie (donc si je me suis pas connecté et que je reçois un email, je sais immédiatement qu'il y a un problème, puisque je suis le seul avec un accès). Bien sûr, je suis le seul admin sur mon petit serveur. S'il y avait 5 personnes avec accès au serveur (je ne parle pas d'un serveur avec accès simple-utilisateur, mais bien d'un serveur vital, genre pour les emails, le site, etc. Y aura jamais beaucoup de personnes autorisées sur celui-là) on peut imaginer alors un système un peu plus complexe en 2 temps, comme la réception d'un email automatique par cette personne seulement et l'obligation d'y répondre en moins de 5 minutes sinon tous les admins reçoivent une alerte à leur tour.
Ensuite root: je reçois aussi un email à chaque login root, avec le nom de l'utilisateur d'origine (y a plusieurs moyens de connaître cette info, comme
logname, etc. Aussi je précise que la connexion SSH en root direct doit toujours être interdite sur un serveur. Ça permet notamment de savoir qui est l'utilisateur de base, par exemple pour détecter les montées de privilèges). Même une connexion sudo pourrait générer des emails automatiques.Quant à un dump de base de données, je n'y ai jamais pensé et me rend compte que je n'ai rien fait, mais je suis sûr qu'il doit y avoir aussi moyen aussi de générer une alerte automatique à chaque tentative de dump. Vous pouvez ignorer votre message hebdomadaire (ou quotidien, pour un gros service) de backup, mais si vous recevez un message hors du créneau habituel, vous savez que quelque chose de louche est en train de se passer sur votre serveur.
Etc. etc. Les idées ne manquent pas au niveau administrateur pour détecter des choses qui ne devraient pas se produire sur un serveur. Le fait est qu'on n'est pas trop censé toucher un serveur en production. Donc dès qu'il y a une activité un peu inhabituelle, c'est assez facile à détecter, et envoyer des alertes à chaque mouvement n'est pas overkill selon moi. Surtout lorsqu'on a juste quelques serveurs, comme c'est probablement le cas de Mint (je doute qu'ils aient 1000 serveurs en production). Ensuite oui si vous avez des centaines de serveur, vous ferez les choses différemment (enfin probablement similaire, mais vous voudrez pas recevoir des emails pour un oui ou pour un non. À ce moment, vous pouvez avec des scripts un peu plus ciblés, des interfaces de gestion de votre parc pour gérer les alertes, etc.).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]