Bonjour à tous,
J'ai un Virtual Private Server (VPS) Debian7 chez OVH qui héberge du mail (postfix+dovecot) et du web (apache2). Je n'ai pas vraiment de connaissance pour administrer ce genre de service et j'ai configuré le bouzin en suivant les divers tutos sur le net.
J'ai reçu une alerte de ovh qui m'a signalé une activité anormale de mon vps. Par précaution, Ovh l'a alors mis en quarantaine. Du coup, j'ai fait un reset et j'ai réinstallé le bazard avec une config plus secure. J'ai récupéré un back-up complet de l'ancien système et j'aimerais bien investiguer les logs pour savoir Comment-pourquoi-quand-… le pirate est entré de mon système.
Je ne sais pas trop par où commencer !
Quelqu'un pourrait-il m'aider à démarrer ?
Merci !
# Logs
Posté par ptit_poulet . Évalué à -1.
Bonjour,
Il faudrait commencer par fouiller un peu dans les logs : firewall, accès ssh, système…
[^] # Re: Logs
Posté par NeoX . Évalué à 2.
c'est un peu le sens de sa question :
[^] # Re: Logs
Posté par chimrod (site web personnel) . Évalué à 7.
Faisons l'hypothèse que le pirate est entré par une faille d'un site php, et qu'il a utilisé ton système pour spammer le monde.
Tu n'auras rien dans les logs ssh, rien dans les logs système : et pour cause, le système tourne comme a son habitude, sauf que le code exécuté n'est plus le même.
Par contre, tu auras des traces dans le serveur mail (envoi des mails depuis la machine locale) et dans les logs du serveur web (mais qui peuvent être plus compliquée à identifier).
Tu devrais également avoir des traces dans /tmp (téléchargement d'un code perl ou php stocké sur place).
As tu plus d'info sur cette « activité anormale » ?
[^] # Re: Logs
Posté par Adrien . Évalué à 3.
Autre hypothèse: si le pirate a trouvé le mot de passe d'un compte, il a pu se connecter par exemple en SSH… On pourrait peut-être retrouver des traces dans /var/log/auth.log… sauf si le pirate a effacé ces traces.
[^] # Re: Logs
Posté par ptit_poulet . Évalué à 0.
Ah oui autant pour moi…
Donc autre question, qu'aviez-vous en place comme sécurité sur votre système ?
[^] # Re: Logs
Posté par omc . Évalué à 1. Dernière modification le 07 novembre 2014 à 15:03.
Honnêtement, j'ai fait ça à minima avec juste un firewall. C'est juste un serveur de test qui n'héberge aucune données sensibles mais j'aimerais bien savoir comment l'intru est passé et ce qu'il a fait.
[^] # Re: Logs
Posté par gouttegd (site web personnel) . Évalué à 3.
La plupart des attaquants ne sont pas intéressés par les données qui peuvent se trouver sur une machine ; c’est la machine elle-même qui les intéresse.
# Solution [enfin... je crois]
Posté par omc . Évalué à 2.
Bonjour,
Merci pour vos conseils. J'ai vérifié les mails (les logs de postfix) puis les authentifications (/var/log/auth).
Je pense avoir trouvé la façon dont l'intru a pénétré le serveur. Le pirate a dû intercepter un mail où je communique à un utilisateur son mot de passe. Il ne restait alors plus qu'au pirate de trouver le bon login. Avec les indices contenus dans le mail, le pirate a essayé une série de logins possibles… Jusqu'à tomber sur le bon !
En ce moment même le pirate des caraïbes continue son cirque mais j'ai changé les mots de passe de tous les utilisateurs.
Grrrrrrr….. C'est une bonne leçon !
[^] # Re: Solution [enfin... je crois]
Posté par chimrod (site web personnel) . Évalué à 3.
Une des premières choses que je fait sur un nouveau serveur :
Ça limite déjà les risques…
[^] # Re: Solution [enfin... je crois]
Posté par KiKouN . Évalué à 3.
D'ailleurs, s'il a eu accès à un compte, il faut vérifier s'il n'a pas lui aussi laisser un clé publique. Ce qui lui permetterait de se reconnecter malgrès le changement de mots de passe.
Les clés publiques sont contenues dans le fichier $HOME/.ssh/authorized_keys .
# Pas forcément une intrusion
Posté par Pulco . Évalué à 1.
Es tu certain qu'il s'agit d'une intrusion ?
Quand OVH t'envois ce genre de message c'est parce qu'ils on découvert une activité suspecte sur la bande passante, tu devrais avoir un extrait des logs dans le mail qui aide à l'investigation.
Je suggère plutôt une mauvaise configuration de postfix qui serait en open relay permettant à n'importe qui d'envoyer massivement du spam via ton serveur.
Comme tu précise avoir configuré ton serveur sans trop en maîtriser les subtilités, c'est sur ce point que j'investiguerais en premier, sans pour autant exclure les autres pistes citées ci-dessus.
tu peux faire un test rapide ici : mxtoolbox
Ce principe de configuration "permissive" n'est pas valable uniquement pour postfix, j'ai par exemple récemment eu ce genre de problème avec une instance elasticsearch qui autorisait l'utilisation de l'API publiquement, ce qui à servit de maillon amplificateur dans une attaque DDOS.
Quand à ton scénario d'un email intercepté et d'une déduction du couple login / mot de passe par l’attaquant à partir du contenu de ce mail, mise à part une attaque ciblée spécifiquement contre toi, j'en doute franchement.
Pour tes logs ssh, c'est normal pour un serveur ssh autorisant la connexion par mot de passe et qui tourne sur le port 22 de voir de nombreuse tentative de connexion.
Il n'est pas impossible non plus qu'une attaque par brute force ssh durant des jours / semaines ai fonctionné avec un mot de passe faible.
Installe fail2ban pour envoyer aux oubliettes les nuisibles qui grattent à ta porte.
Tu peux également configurer fail2ban grâce aux nombreux filtres par défaut ou en créer des personnalisés pour protéger ton serveur web et mail des attaques les plus courantes.
[^] # Re: Pas forcément une intrusion
Posté par omc . Évalué à 1. Dernière modification le 08 novembre 2014 à 09:27.
Non en effet, je ne suis sûr de rien.
Voila la notification que j'ai reçu d'ovh : http://pastebin.com/PyzWezyE (les "xxxxxx" représentent l'ip du serveur).
J'avoue ne pas trop comprendre de quoi il s'agit. Est-ce des tentatives de login ssh ?
Non j'ai fait attention à ça. Le smtp est interdit, seul le smtp par TLS avec authentification est autorisé. J'ai regardé les logs du mail et je n'ai rien détecté d'anormal.
C'est vrai que ce scénario fait un peu théorie du complot. Mais ce qui me fait pencher sur ce scénario c'est cela : http://pastebin.com/RXzgKmD0 (extrait du /var/log/auth).
J'héberge sur ce serveur mon petit neveu Ernest. Étant donné son âge, il est impossible qu'il se soit loggé par ssh à 4h du matin. Par contre, le robot semblait connaître le mot de passe à l'avance puisqu'il a réussi à se connecter dés la première tentative.
Bien sûr, ce ne sont que des suppositions et je ne suis sûr de rien.
PS : Merci pour le conseil fail2ban !
[^] # Re: Pas forcément une intrusion
Posté par NeoX . Évalué à 2.
si tu regardes les logs,
c'est ta machine (srcIp:srcPort) qui tente de se connecter sur les autres (dstIp:dstPort) sur le port 22
c'est donc ta machine qui scanne les autres et tente d'entrer chez elles.
il y a donc quelqu'un qui scanne les machines voisinnes.
tu peux limiter cela en bloquant avec le parefeu la destination du port 22 en sortie de ta machine,
evidemment cela devient contraignant si tu utlises toi meme cette machine pour faire du SSH vers d'autres machines (celle de tes clients par exemple)
[^] # Re: Pas forcément une intrusion
Posté par omc . Évalué à 1.
Merci,
J'ai compris le truc de travers.
Alors quelqu'un s'est bien introduit dans ma machine et s'en sert de relais pour scanner les machines voisines.
Du coup, comment puis-je avoir (à partir des logs de ma machine) plus d'informations sur ces tentatives de connection (utilisateur, date, etc…) ?
Encore merci pour votre aide.
[^] # Re: Pas forcément une intrusion
Posté par NeoX . Évalué à 2.
ben dans les logs de ta machine, tu as les infos, il faut juste filtrer.
tu peux deja regarder de ce coté là.
regarde dans cette sauvegarde quels seraient les fichiers utilisés lors de cette attaque,
s'il le faut tu reinstalles la sauvegarde dans une machine virtuelle avec un reseau bidon sur lequel il n'y a rien d'autre,
avec de la chance, les scripts d'attaque se lanceront quand meme, tu pourras alors investiguer avec
ps,top(enfin si ceux-ci n'ont pas été modifiés), tu vas alors trouver des noms de programmes/scripts.ils vont avoir une date, generalement celle de la depose du fichier sur ta machine
avec cette date tu sauras quand l'attaque de ta machine a eu lieu.
enfin tout ca en esperant que l'attaque entrante n'ait pas eu lieu y 6 mois (sauf serveur critique, on garde rarement 6 mois de logs)
[^] # Re: Pas forcément une intrusion
Posté par gouttegd (site web personnel) . Évalué à 3.
Si tu regardes le reste de l’extrait de /var/auth/log, tu peux constater que juste avant, la même adresse (185.25.151.145 — qui n’est probablement pas celle de la machine de ton petit neveu, tu peux essayer un whois dessus pour voir à qui elle appartient) a essayé successivement "erling", "erma", "ermolaev" (sans succès puisque ta machine n’a pas de comptes utilisateurs avec ces noms). Après avoir réussi à se connecter avec "ernest", elle a d’ailleurs continué avec "ernest21" et "ernestina"…
Ça ressemble donc beaucoup plus à un scan bête et méchant avec un dictionnaire de noms d’utilisateurs qu’à une attaque ciblée.
Quant à savoir comment l’attaquant a pu trouver le mot de passe de "ernest" à la première tentative de connexion avec ce nom-là : es-tu sûr que c’est la première tentative ? Je soupçonne que tu si tu remontes plus loin dans les logs, tu en verras beaucoup d’autres.
Pour éviter que la même chose ne se reproduise, fail2ban est effectivement une bonne solution. Éviter les mots de passe trop faibles serait aussi une bonne chose, et se passer de mots de passe pour n’utiliser que l’authentification par clefs en serait une encore meilleure.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.