Comment déterminer si ma box Linux a été infiltrée?

J'ai récemment lu un article sur l'analyse des tentatives de connexion SSH malveillantes. Cela m'a fait réfléchir, les combinaisons de nom d'utilisateur SSH et de mot de passe sur ma boîte Debian sont-elles rares? Avais-je été ciblé par une attaque par dictionnaire de force brute? Jetons un œil à /var/log/auth.log.0 :

Sep 23 07:42:04 SLUG sshd[8303]: Invalid user tyjuan from 210.168.200.190
Sep 23 07:42:09 SLUG sshd[8305]: Invalid user tykeedra from 210.168.200.190
Sep 23 07:42:14 SLUG sshd[8307]: Invalid user tykeem from 210.168.200.190
Sep 23 07:42:19 SLUG sshd[8309]: Invalid user tykeshia from 210.168.200.190
Sep 23 07:42:25 SLUG sshd[8311]: Invalid user tyla from 210.168.200.190
Sep 23 07:42:30 SLUG sshd[8313]: Invalid user tylan from 210.168.200.190
Sep 23 07:42:35 SLUG sshd[8315]: Invalid user tylar from 210.168.200.190
Sep 23 07:42:40 SLUG sshd[8317]: Invalid user tyler from 210.168.200.190
Sep 23 07:42:45 SLUG sshd[8319]: Invalid user tylerfrank from 210.168.200.190
Sep 23 07:42:50 SLUG sshd[8321]: Invalid user tyliah from 210.168.200.190
Sep 23 07:42:55 SLUG sshd[8323]: Invalid user tylor from 210.168.200.190

Donc ça n'a pas l'air bien. Maintenant que je sais que j'ai été ciblé par une attaque et que certaines combinaisons de mon nom d'utilisateur et de mon mot de passe sont faibles, j'aimerais savoir comment puis-je ...

• ... déterminer si ma box Linux a été infiltrée?
• ... réparer les dommages laissés par les auteurs?
• ... empêcher que cela se produise à l'avenir?

MISE À JOUR

Des conseils pour réparer les dommages laissés par les auteurs?

Beaucoup de gens semblent suggérer DenyHosts, mais j'ai vu beaucoup de succès avec Fail2Ban sur mes systèmes. Il recherche un nombre (configurable) d'échecs, puis exécute une action - sur mes serveurs, cette action consiste à utiliser iptables pour supprimer tout le trafic provenant de l'hôte. Après 10 échecs de connexion, ils sont bannis et c'est la fin.

Je l'utilise en combinaison avec Logcheck, pour que je sache toujours ce qui se passe sur mes serveurs.

Si vous avez des preuves que quelqu'un s'est effectivement introduit dans vos systèmes (les journaux que vous avez publiés n'en sont pas la preuve), alors votre seule solution est de sauvegarder toutes les données dont vous avez besoin pour conserver, effacer la machine, réinstaller et restaurer à partir de sauvegardes. Sinon, il n'y a aucun moyen d'en être sûr.

Les tentatives de connexion valides sont également connectées, donc si vous voyez une tentative de force brute suivie d'un succès, c'est une bonne indication que quelque chose de mauvais s'est produit.

J'utilise DenyHosts pour surveiller mes journaux pour le trafic SSH suspect, et je l'ai configuré pour pare-feu automatiquement les hôtes à un certain point.

Notez qu'il existe une variété d'autres façons de surveiller votre machine pour voir si elle est compromise, y compris les modèles de charge, l'activité de connexion, le reniflage périodique du trafic, la surveillance des processus en cours d'exécution et des ports ouverts, et l'assurance de l'intégrité des fichiers avec un outil comme tripwire.

Si vous ne faites qu'un seul, la surveillance de la charge du système est un moyen très efficace de détecter les compromis, car la plupart des machines, lorsqu'elles sont compromises, sont utilisées pour faire des choses comme envoyer des quantités massives de spam ou autrement recevoir beaucoup de trafic. Peut-être pas utile si vous êtes une cible de grande valeur et que les gens essaient de vous pénétrer spécifiquement pour des raisons autres que de transformer votre hôte en zombie, mais néanmoins précieux. De plus, la surveillance de la charge est nécessaire pour le profilage et pour déterminer quand vous devez investir dans plus de matériel ou de meilleurs logiciels.

Vous devez également effectuer une analyse complète du journal, en consultant auth.log et d'autres pour les choses inattendues. L'analyse des fichiers journaux est un marché concurrentiel et le problème n'est pas encore résolu, mais il existe des outils gratuits comme logwatch qui peuvent être configurés pour vous envoyer des résumés quotidiennement.

La sécurité à travers les couches!

Oubliez Tripwire, c'est assez cher. Utilisez plutôt AIDE. C'est gratuit, facile à installer (même si cela prend un peu de temps pour décider des répertoires temporaires à exclure et autrement configurer).

vous l'exécutez, il construit une base de données de tous les fichiers. Exécutez-le à nouveau et il vous dira quels fichiers ont changé.

Une autre chose à faire est d'installer CSF, qui a un bloqueur de type denyhost, car les gens ne parviennent pas à se connecter à plusieurs reprises, il les ajoutera à vos règles de pare-feu. Vous pouvez également exiger que les connexions SSH possèdent également une clé publique, les script kiddies peuvent alors essayer autant de connexions qu'ils le souhaitent.

"* ... determine if my Linux box has been infiltrated?"

• recherchez des signes de processus étranges. J'utilise normalement les outils fournis avec chkrootkit ( http://www.chkrootkit.org )
• Effectuez un scan de port avec nmap depuis une autre machine. Si votre box a été compromise, il y a de fortes chances que le pirate ait installé une porte dérobée

"* ... réparer les dommages laissés par les auteurs?"

oubliez-le, s'il y a eu une attaque, le meilleur conseil est de le réinstaller à partir de zéro (assurez-vous de brancher les trous sur la nouvelle installation). Il est très facile de ne pas remarquer une porte dérobée ou un processus furtif, il vaut mieux réinstaller.

"* ... empêcher que cela se produise à l'avenir?"

• mises à jour de sécurité

• pare-feu étanche

• mots de passe forts

• désactiver les services inutiles

jetez un œil à des outils comme logcheck , portsentry et tripwire . c'est très courant pour les tentatives SSH de dictionnaire aléatoire, donc je ne serais pas trop inquiet par ça. vous voudrez peut-être changer le port pour l'obscurcissement aléatoire, mais vous verrez toujours des tentatives aléatoires de temps en temps, c'est la vie d'avoir une machine sur Internet.

Une chose que j'utilise sur mes serveurs pour aider à prévenir ces attaques est DenyHosts . DenyHosts empêchera un utilisateur malveillant de tenter de se connecter. Depuis son installation, mes fichiers journaux ont eu beaucoup moins d'entrées de tentatives de connexion.

Il est recommandé d'utiliser des paires de clés publiques / privées comme authentification supplémentaire; De cette façon, un utilisateur ne peut pas se connecter via SSH sans clé droite; ce qui serait assez impossible à deviner pour un forceur brutal. Un bel article à ce sujet peut être trouvé ici .

Cela seul avec une phrase secrète serait assez solide pour l'authentification SSH; Mais il y a plus de vulnérabilités! Attention à toutes les applications qui utilisent un port ouvert; S'ils contiennent un bug, les exploiteurs pourraient dépasser votre système. Un bon exemple est un bot de spam installé sur notre serveur en raison d'un bogue dans le logiciel Webstats que nous utilisons actuellement.

Fail2ban est un analyseur de journal d'accès en temps réel. Il peut être configuré pour bloquer toute adresse IP avec un certain nombre de tentatives infructueuses de connexion. Cela évite les attaques par dictionnaire sans avoir à déplacer le port ssh. chkrootkit et rootkithunter sont de bons utilitaires pour vérifier l'intrusion. Si l'intrusion a réussi, la meilleure pratique consiste à copier des données (et uniquement des données, pas des exécutables), à les nettoyer et à les réinstaller car il est vraiment difficile d'être sûr à 100% que le système est propre.

Il n'y a rien ici pour suggérer que votre boîte a été compromise. Même si vos mots de passe sont assez faibles, une attaque par dictionnaire qui ne lance qu'une seule tentative de connexion sur chaque nom d'utilisateur a très peu de chances de réussir.

Mais, si vous savez que vos mots de passe sont faibles, alors renforcez-les! Personnellement, j'aime pwgen (qui est empaqueté par Debian). À chaque exécution, il génère un grand nombre de candidats de mot de passe forts, mais relativement prononçables qui (pour moi au moins) sont assez faciles à retenir, tels que yodieCh1, Tai2daci ou Chohcah9.

Cependant, s'il existe d'autres preuves montrant que votre système a été compromis ... Nuke it of orbite. C'est le seul moyen d'en être sûr.

Les données non exécutables sont probablement récupérables, mais tout ce qui a un contenu exécutable (cela inclut potentiellement des éléments tels que des documents MS Office et certains fichiers de configuration) doit disparaître, sauf si vous êtes disposé et capable de l'examiner manuellement pour vous assurer qu'il ne l'a pas '' t devenu hostile ou d'accepter la possibilité qu'il puisse être hostile et soit endommager votre système ou fournir une avenue pour un nouveau compromis si vous le maintenez.

Une petite protection supplémentaire que j'aime est de limiter la fréquence des connexions ssh entrantes pour ralentir les attaques par dictionnaire ou similaires. Ne vous attendez pas à ce que cela vous protège tout seul, mais utilisez-le en plus des suggestions dans les autres réponses, y compris la désactivation de l'authentification par mot de passe.

Utiliser iptables:

$ iptables        -A INPUT      -p tcp --dport 22 -m state --state ESTABLISHED,RELATED -j ACCEPT
$ iptables        -A INPUT      -p tcp --dport 22 -m state --state NEW -m limit --limit 3/min --limit-burst 3 -j ACCEPT
$ iptables        -A INPUT      -p tcp --dport 22 -j DROP

Il y a quelques mauvais conseils sur ce fil, tels que:

• en utilisant un port non standard pour ssh (faux!)
• en utilisant un outil de sécurité tiers (en ajoutant une dépendance / complexité inutile)
• configuration de votre pare-feu pour bloquer ou ajouter à la liste blanche (maux de tête de maintenance)

Ajustez simplement votre à la /etc/ssh/sshd_configplace pour améliorer la sécurité:

• PermitRootLogin no
• Configurer AllowUsers uniquement pour les utilisateurs du système qui ont des comptes ssh
• Envisagez d'utiliser uniquement des clés physiques avec «PasswordAuthentication no»

Si vous êtes la boîte a été infiltrée. Reconstruisez la boîte.

Cela arrivera tout le temps avec ssh activé. Déplacez-le vers un port haut.

Il existe un programme appelé "Tripwire" qui est excellent pour la détection d'intrusion, mais assez difficile à installer. Si rien d'autre, vous devez lire leurs documents afin de comprendre les problèmes.

Vous devez installer la détection d'intrusion avant de connecter la machine à Internet.

Et c'est une bonne idée de mettre sur liste blanche les connexions SSH IP juste pour être sûr que le monde entier ne peut même pas essayer des choses comme ça.

Comment puis-je déterminer si ma box Linux a été infiltrée?

Démarrez un support en lecture seule (livecd) et comparez les fichiers à votre sauvegarde ou au support d'origine.

Il suffit de regarder autour pour un comportement étrange. Bien sûr, cela est plus facile si vous prenez le temps avant un hack pour avoir une bonne idée de ce qui est «normal».

Les erreurs que vous avez signalées n'indiquent aucun compromis. Juste que quelqu'un essaie.

Comment puis-je réparer les dommages laissés par les auteurs?

Réinstallez et restaurez à partir d'une sauvegarde avant que le système ne soit compromis.

Voir:

• /server/6159/aftermath-of-hack
• Réinstaller après un compromis racine?

Comment puis-je empêcher que cela se produise à l'avenir?

Voir:

• Empêcher les attaques par force brute contre ssh?
• Des centaines de connexions ssh échouées
• Serveur Ubuntu SSH
• Quelles mesures prenez-vous pour sécuriser un serveur Debian?

Vous pouvez regarder la boîte pour voir ce qui se passe et chercher quoi que ce soit de suspect. Voir cet article: /programming/124745/sniffing-network-traffic-for-signs-of-virusesspyware

Psad couplé à Shorewall est un bon moyen de compléter vos règles iptables.

J'utilise également Fail2ban pour suivre mes connexions ssh

utilisez rkhunter ou chkrootkit ou les deux; scannez votre box de l'extérieur pour voir quels ports sont ouverts

de toute façon, si tout ce que vous avez est un utilisateur invalide, il n'y a pas lieu de s'inquiéter :)

Quelque chose de très différent: essayez d'utiliser Google sur l'adresse IP! Un pirate informatique qui se fait appeler STARTURK de Turquie a peut-être tenté de pirater votre site.

Bien qu'il ressemble à une attaque par force brute sur votre système, il se pourrait bien que ce pirate informatique n'ait fait qu'un essai et soit maintenant parti sur un autre site.

Comme beaucoup l'ont noté, Tripwire / AIDE sont le meilleur moyen de rechercher les modifications du système. Malheureusement, la vache est sortie de l'étable sur celle-ci car elle doit être configurée sur un système en bon état.

Une chose qui pourrait vous aider au moins à commencer est d'utiliser votre base de données RPM pour vérifier les sommes moyennes de vos fichiers. L'essentiel est le suivant:

rpm -qa | xargs rpm -V

Ce n'est pas parfait pour diverses raisons. Tout d'abord, votre base de données RPM locale aurait théoriquement pu être modifiée. Deuxièmement, la plupart des distributions utilisent la pré-liaison, et RPM n'est pas au courant de la pré-liaison. Les MD5 peuvent sembler avoir été modifiés par rapport à ce processus, ce qui est légitime.

Le meilleur conseil est le suivant: si vous n'êtes pas sûr d'avoir été compromis, il est vraiment temps de reconstruire.

Pour éviter de futurs problèmes de sécurité, vous pouvez jeter un œil à OSSEC , je l'utilise pour faire des vérifications d'intégrité des fichiers et la surveillance des journaux sur nos serveurs, c'est très complet et facile à configurer. Il peut envoyer des notifications par courrier électronique, vous pouvez vérifier les alertes via la ligne de commande ou une interface Web ...

http://www.ossec.net/

extrait du site:

"OSSEC est un système de détection d'intrusion basé sur l'hôte Open Source. Il effectue une analyse des journaux, une vérification de l'intégrité des fichiers, une surveillance des politiques, une détection des rootkits, des alertes en temps réel et une réponse active."

• analyse des journaux Il peut vérifier le fichier journaux sur vos serveurs et vous alerter via des règles (il y en a beaucoup prédéfinies et vous pouvez ajouter les vôtres)

• intégrité des fichiers tripwire / aide comme la fonctionnalité afin que vous puissiez voir si un fichier a été modifié sur votre serveur

• surveillance des politiques: vérifiez quelques règles de sécurité «Meilleures pratiques»

• détection des rootkits: rkhunter, fonctionnalités similaires à chkrootkit

• alertes en temps réel et réponse active: vous pouvez configurer ossec pour qu'il réagisse automatiquement aux alertes (je ne l'utilise pas mais vous pouvez l'utiliser pour bloquer l'accès ssh aux hôtes faisant trop de tentatives de connexion infructueuses)

Très bon produit et très actif

Pour durcir votre boite vous pouvez aussi utiliser du lynis ou de la bastille

• http://www.rootkit.nl/projects/lynis.html

• http://bastille-linux.sourceforge.net/