Question:
Comment répondre à une attaque par force brute SSH sur un seul VPS?
Aage Torleif
2017-01-01 07:34:37 UTC
view on stackexchange narkive permalink

Je me suis connecté à mon VPS ce matin pour trouver des millions de tentatives de connexion infructueuses pour l'utilisateur root et d'autres utilisateurs qui n'existent même pas. J'ai pris les mesures ci-dessous pour essayer de masquer les efforts des attaquants qui (se poursuivent depuis des mois).

Question (s)

  1. Est-ce une réponse appropriée?
  2. Que peut-on faire de plus?
  3. Puis-je faire quelque chose de précieux avec une liste de ces adresses IP?

Informations système pour un vps Centos7 

  uname - ainux vm01 3.10.0-327.22.2.el7.x86_64 # 1 SMP Thu Jun 23 17:05:11 UTC 2016 x86_64 x86_64 x86_64 GNU / Linux

étape 1

Création d'un script pour récupérer toutes les adresses IP qui n'ont pas réussi à se connecter à partir du journal sécurisé. ( / var / log / secure ) 

  # get_ips.shgrep "Échec du mot de passe pour" / var / log / secure \ | grep -Po "[0-9] + \. [0-9] + \. [0-9] + \. [0-9] +" \ | trier \ | uniq -c

étape 2

Ecrivez un script pour créer des règles de pare-feu afin de bloquer l'adresse IP qui se trouve à partir du script à l'étape 1. Ce script est ip_list_to_rules.sh 

  #! / bin / bash # ip_list_to_rules.sh # script pour analyser la sortie de get_ips.sh et créer des règles de pare-feu # pour bloquer les requêtes sshif [-z $ 1 ]; then echo "arg1 doit être le chemin vers une liste de la forme <COUNT> <IP> \ n" exitfiLIST = $ (readlink -f $ 1) SSH_IP = $ (echo $ SSH_CLIENT | head -n1 | awk ') La lecture des IP à partir de $ {LIST} "echo" L'IP du client SSH sera ignorée ($ {SSH_IP}) "lors de la lecture de COUNT IP; do echo "Création d'une règle pour $ {IP}" firewall-cmd --direct --add-rule filtre ipv4 INPUT 1 -m tcp --source $ IP -p tcp --dport 22 -j REJECT firewall-cmd --direct --add-rule filtre ipv4 INPUT 1 -m tcp --source $ IP / 24 -p tcp --dport 22 -j REJECTdone<<< "$ (cat $ {LIST} | grep -v $ {SSH_IP})"

étape 3

Exécutez tout et enregistrez les règles. 

  ./get_ips.sh > attack_ips.list./ip_list_to_rules.sh attack_ips.listfirewall-cmd --reload

Update

Voici les mesures que j'ai prises à partir des réponses.

  1. Connexions root désactivées
  2. Changé Port SSH
  3. Installer & configuré fail2ban
  4. Désactiver l'authentification par mot de passe & activer l'authentification par clé publique

Je n'ai pas fait 4 parce que je me connecte habituellement via client Chrome Secure Shell et AFAIK, il n'y a pas de support de clé publique.

Il y a un geste beaucoup plus simple que vous pouvez faire pour calmer la grande majorité des attaques automatiques de devinettes de mot de passe SSH: changer votre numéro de port SSH.Maintenant, * bien sûr *, cela ne suffira pas en soi à arrêter tout type d'attaquant déterminé;vous devez également mettre en place des mesures de sécurité substantielles.(Et il semble que vous comprenez cela).Mais cela désencombrera vos journaux du trafic des innombrables robots automatisés qui analysent le net à la recherche de ports communs ouverts contre lesquels lancer des suppositions de nom d'utilisateur / mot de passe.Vous permettant une meilleure visibilité par rapport aux types de menaces potentiellement plus préoccupants.
Je suggère fortement d'utiliser un outil SSH approprié comme Bitvise, PuTTy, ... et d'activer l'authentification par clé publique au lieu d'utiliser une extension dans un navigateur pour effectuer des actions pour lesquelles un navigateur n'est pas destiné et ne peut pas fournir une sécurité suffisante pour.
Vous voulez lire [Secure Secure Shell] (https://stribika.github.io/2015/01/04/secure-secure-shell.html).
Pour Chrome Secure Shell, essayez l'application Termius.Il prend en charge les clés privées.
Cette question semble mieux convenir à [SF].
Huit réponses:
Xiong Chiamiov
2017-01-01 08:05:09 UTC
view on stackexchange narkive permalink

Oui, c'est une approche parfaitement raisonnable et courante. Cependant, vous avez réinventé fail2ban. Vous voudrez probablement utiliser cela à la place pour ne pas avoir à déboguer des problèmes avec votre script et utiliser les filtres existants pour ssh, apache et d'autres services courants.

vous ne pouvez pas faire grand chose avec ces adresses IP. Vous pouvez essayer de signaler l'activité au contact d'abus répertorié pour son blocage IP, mais cela ne vaut pas vraiment la peine de passer votre temps à moins qu'il ne fasse quelque chose de plus sérieux.

Vous devriez également faire le durcissement ssh standard, comme la désactivation du mot de passe -based et connexions root sauf si vous en avez absolument besoin.

Le blocage temporaire comme ce que fait fail2ban est acceptable pour une solution à court terme, mais généralement un blocage permanent n'est pas souhaitable car ces IP font généralement partie d'un botnet et un grand nombre est probablement émis par des FAI avec une allocation IP dynamique ou de grands réseaux avec NAT où de nombreux utilisateurspartager une seule adresse IP publique.Si vous bloquez trop de ces adresses IP, vous pouvez également bloquer accidentellement des clients légitimes.
fail2ban ou similaire devrait être l'une des premières choses à ajouter à un VPS.Juste après avoir changé le port SSH par défaut!Comme le dit Lie, utilisez des interdictions temporaires puisque les attaques évoluent très rapidement.Habituellement, 10 minutes suffisent, je pense que j'utilise une heure.
fail2ban peut également envoyer des rapports d'abus automatisés, je pense ... je ne l'ai jamais activé.
Lie Ryan
2017-01-01 14:04:32 UTC
view on stackexchange narkive permalink

Le moyen le plus efficace de sécuriser le système SSH est de se connecter en utilisant uniquement la clé privée ssh. Vous devez désactiver l'authentification par mot de passe et interdire la connexion directe à la racine. Après cela, vous obtiendrez toujours de nombreuses tentatives d'authentification échouées, mais il n'y a aucune chance en enfer que l'attaquant par force brute réussisse.

Si vous voulez garder vos journaux propres après cela, vous devez déplacer votre port SSH vers un autre numéro de port.

Ou désactivez simplement la journalisation des tentatives de connexion infructueuses, car elles n'ont aucun sens si l'authentification par mot de passe n'est pas activée.
Quoi qu'il en soit +1 car c'est la bonne approche.D'autres sont des exercices à divers degrés de futilité / perte de temps.
CaffeineAddiction
2017-01-01 14:33:56 UTC
view on stackexchange narkive permalink

Il peut être intimidant de voir un million de tentatives de connexion infructueuses, mais honnêtement, la bande passante et la puissance de traitement que ces tentatives utilisent ... sont triviales.

La vraie question devient donc, votre système est-il sécurisé:

  • Avez-vous désactivé la connexion root?
  • Avez-vous désactivé l'authentification par mot de passe en faveur de la clé pub?
  • Avez-vous changé le port par défaut du sshd service sur votre VPS?

toutes ces modifications peuvent être effectuées dans le fichier / etc / ssh / sshd_config (assurez-vous de redémarrer sshd après avoir effectué vos modifications)

Vous pouvez utiliser fail2ban, ou un script personnalisé pour bloquer ces adresses IP sur le pare-feu, mais l'authentification sshd en elle-même est suffisamment sécurisée en elle-même ... ajouter plus de complexité n'est pas nécessairement plus sécurisé et vous fera probablement vous verrouiller accidentellement hors des vps.

Ce n'est pas vraiment la bande passante ou la puissance de traitement qui est le problème avec ces attaques.C'est le fait qu'il inonde les journaux et masque ainsi d'autres problèmes ou attaques.
Zeta Two
2017-01-01 11:07:10 UTC
view on stackexchange narkive permalink

Comme d'autres l'ont mentionné. Fail2ban avec des règles assez strictes (par exemple: 3 mauvais mot de passe ou tentative de connexion avec un utilisateur inexistant) peut être très efficace.

Je suggérerais également de déplacer SSH vers un port non standard. Bien sûr, cela n'aide pas du tout contre tout type d'attaque intelligente, mais cela élimine les scanners automatisés les plus basiques, dont il y en a plusieurs.

Si vous combinez cela avec quelque chose qui détecte l'analyse des ports et connectez cela avec fail2ban, vous pouvez même gérer une assez grande partie des scanners, des botnets et autres conneries.

Tomáš Pánik
2017-01-02 02:28:52 UTC
view on stackexchange narkive permalink

Vous pouvez définir des tables IP qui ne verrouillent pas l'intégralité de votre serveur, mais ralentissent les attaques par force brute au point qu'elles deviennent inefficaces .

Restreindre l'accès SSH par adresses IP est la méthode la plus sûre. Changer de port SSH peut annuler les analyses de bots mais ne fait pas grand-chose contre les attaques ciblées.

Dans le terminal, saisissez 

  / usr / sbin / iptables -I INPUT -p tcp --dport 22 -i eth0 -m état --state NEW -m recent --set / usr / sbin / iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP

Cela bloquera la nouvelle adresse IP s'il se connecte plus de 3 fois par minute . Les connexions établies aboutissent à une authentification réussie. Vous pouvez également enregistrer ce qui est fait ici en définissant une règle de journalisation 

  / sbin / iptables -N LOGDROP / sbin / iptables -A LOGDROP -j LOG / sbin / iptables -A LOGDROP -j DROPiptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --setiptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent - -update --seconds 60 --hitcount 4 -j LOGDROP
Slim-Jay1
2017-01-01 10:34:07 UTC
view on stackexchange narkive permalink

Vous pouvez essayer d'installer fail2ban, ou vous pouvez faire des choses comme désactiver la connexion directe à la racine ou changer le port ssh par défaut

danofsatx
2017-01-02 09:22:46 UTC
view on stackexchange narkive permalink
  1. Désactiver l'authentification par mot de passe & activer l'authentification par clé publique

Je n'ai pas fait 4 parce que je me connecte généralement via le client Chrome Secure Shell et AFAIK, il n'y a pas de prise en charge de clé publique.

J'utilise le client Chrome Secure Shell sur mon Chromebook, et il prend en charge l'authentification par clé publique. J'ai désactivé l'authentification par mot de passe sur tous mes systèmes et je n'ai aucun problème pour y accéder à partir du Chromebook ou de mon téléphone à l'aide de Juice.

@grochmal, il ne posait pas de question, il répondait à une petite partie de la question initiale.danofsatx, votre réponse pourrait être améliorée en ajoutant une capture d'écran de l'endroit où vous avez configuré Chrome Secure Shell Client pour utiliser les clés.
@gowenfawr - bon point, avec la citation je le vois.Merci.
@danosatx, bonne prise.Je n'ai jamais pu faire fonctionner "import ...", j'ai supposé que le support était juste en cours de développement.
Danny Duval
2017-01-01 20:32:09 UTC
view on stackexchange narkive permalink

Configurez ssh pour vous connecter via un autre port.

Ceci est une suggestion en double de plusieurs autres réponses, et fournit * moins * d'informations que toutes.


ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...