J'avais awstats (un analyseur de logs) qui tournait sur mon serveur web. Certaines version 6.x ont un trou de sécurité qui permet d'exécuter des commandes avec les droits apache. Cette faille a été exploitée pour télécharger (avec wget) détarrer et executer une sorte de bot IRC dans /tmp/.x exactement comme dans le 3ème bloc de ce journal. Le bot n'a pas pu se connecter à un serveur IRC parce qu'iptables veillait au grain (d'ou l'intérêt de filtrer aussi ce qui sort et pas seulement ce qui rentre). Le log d'iptables était rempli de centaines de tentatives. Il se trouve que j'avais fait une sauvegarde complète du système quelques jours auparavant ce qui m'a permis de remettre le système dans l'état dans lequel il se trouvait avant l'attaque.
J'ai viré les droits en lecture et en exécution pour other sur tous les exécutables du système et modifié leurs groupes pour que les différents utilisateurs ne puissent exécuter que les exécutables qu'ils sont sensés pouvoir exécuter (comme perl pour apache, mais pas wget ou tar ou encore bash). J'avais depuis longtemps ajouté un virtualhost dans la config d'apache pour que les accès direct par l'IP ne puissent pas accéder au site lui même. C'est très pratique pour détecter les tentatives d'intrusions. J'avais malheuresement oublié d'ajouter une section pour les CGIs.
# J'ai subi le même genre d'attaque il y'a une quinzaine de jours ...
Posté par Benoît Déchamps . En réponse au journal A Security Report: Cacti and Consequences. Évalué à 4.
J'avais awstats (un analyseur de logs) qui tournait sur mon serveur web. Certaines version 6.x ont un trou de sécurité qui permet d'exécuter des commandes avec les droits apache. Cette faille a été exploitée pour télécharger (avec wget) détarrer et executer une sorte de bot IRC dans /tmp/.x exactement comme dans le 3ème bloc de ce journal. Le bot n'a pas pu se connecter à un serveur IRC parce qu'iptables veillait au grain (d'ou l'intérêt de filtrer aussi ce qui sort et pas seulement ce qui rentre). Le log d'iptables était rempli de centaines de tentatives. Il se trouve que j'avais fait une sauvegarde complète du système quelques jours auparavant ce qui m'a permis de remettre le système dans l'état dans lequel il se trouvait avant l'attaque.
J'ai viré les droits en lecture et en exécution pour other sur tous les exécutables du système et modifié leurs groupes pour que les différents utilisateurs ne puissent exécuter que les exécutables qu'ils sont sensés pouvoir exécuter (comme perl pour apache, mais pas wget ou tar ou encore bash). J'avais depuis longtemps ajouté un virtualhost dans la config d'apache pour que les accès direct par l'IP ne puissent pas accéder au site lui même. C'est très pratique pour détecter les tentatives d'intrusions. J'avais malheuresement oublié d'ajouter une section pour les CGIs.