web-dev-qa-db-fra.com

Comment répondre à une attaque par force brute SSH sur un seul VPS?

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 brouiller les efforts des assaillants qui (se poursuivent depuis des mois).

Des questions)

  1. Est-ce une réponse appropriée?
  2. Que peut-on faire de plus?
  3. Y a-t-il quelque chose de précieux que je puisse faire avec une liste de ces IP?

Informations système pour un Centos7 vps

uname -a
inux 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éé un script pour récupérer toutes les adresses IP qui n'ont pas pu se connecter à partir du journal sécurisé. (/var/log/secure)

# get_ips.sh
grep "Failed password for" /var/log/secure \
| grep -Po "[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+" \
| sort \
| uniq -c

étape 2

Écrivez un script pour créer des règles de pare-feu pour bloquer l'adresse IP qui se trouve dans le script à l'étape 1. Ce script est ip_list_to_rules.sh

#!/bin/bash
# ip_list_to_rules.sh
# script to parse output of get_ips.sh and create firewall rules
# to block ssh requests

if [ -z $1 ]; then
  echo "arg1 must be path to a list of the form <COUNT> <IP>\n"
  exit
fi

LIST=$(readlink -f $1)
SSH_IP=$(echo $SSH_CLIENT | head -n1 | awk '{print $1;}')

echo "Reading IPs from ${LIST}"
echo "SSH Client IP will be ignored (${SSH_IP})"

while read COUNT IP; do

  echo "Creating rule for ${IP}"
  firewall-cmd --direct --add-rule ipv4 filter INPUT 1 -m tcp --source $IP -p tcp --dport 22 -j REJECT
  firewall-cmd --direct --add-rule ipv4 filter INPUT 1 -m tcp --source $IP/24 -p tcp --dport 22 -j REJECT

done<<<"$(cat ${LIST} | grep -v ${SSH_IP})"

étape 3

Exécutez tout cela et enregistrez les règles.

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

Mise à jour

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

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

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

firewallssshbrute-forceincident-response
25
Aage Torleif

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

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

Vous devez également effectuer le durcissement ssh standard, comme désactiver les connexions par mot de passe et root, sauf si vous en avez absolument besoin.

53
Boycott SE for Monica Cellio

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

Si vous souhaitez conserver vos journaux propres après cela, vous devez déplacer votre port SSH vers un numéro de port différent.

23
Lie Ryan

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 est donc de savoir si votre système est sécurisé:

  • Avez-vous désactivé la connexion root?
  • Avez-vous désactivé l'authentification par mot de passe en faveur de la clé de publication?
  • Avez-vous changé le port par défaut du service sshd 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 ... l'ajout de plus de complexité n'est pas nécessairement plus sécurisé et vous causera très probablement un verrouillage accidentel hors des vps.

6
CaffeineAddiction

Vous pouvez définir tables IP qui ne verrouillera pas votre serveur entier, mais ralentit les attaques par force brute au point où elles deviennent inefficaces .

Restreindre l'accès SSH par des adresses IP est la méthode la plus sûre. Changer le port SSH peut vaincre les analyses de bot mais fait peu contre les attaques ciblées.

Dans le terminal, saisissez

/usr/sbin/iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --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 si elle se connecte plus de 3 fois par minute. Les connexions établies permettent une authentification réussie. Vous pouvez également consigner ce qui se fait ici en définissant une règle de consignation

/sbin/iptables -N LOGDROP
/sbin/iptables -A LOGDROP -j LOG
/sbin/iptables -A LOGDROP -j DROP
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j LOGDROP
3
Tomáš Pánik

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

Je suggère également de déplacer SSH vers un port non standard. Bien sûr, cela n'aide pas du tout contre toute sorte d'attaque intelligente, mais cela élimine les scanners automatisés les plus basiques dont il existe un certain nombre.

Si vous combinez cela avec quelque chose qui détecte la numérisation de port et que vous vous connectez avec fail2ban, vous pouvez même repousser une grande partie des scanners, des botnets et autres conneries.

3
Zeta Two
  1. Désactivez l'authentification par mot de passe et activez l'authentification par clé publique

Je n'ai pas vraiment fait 4 car je me connecte généralement via chrome client Shell sécurisé et AFAIK il n'y a pas de support de clé publique.

J'utilise le client Chrome Secure Shell Client 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 à y accéder depuis le Chromebook ou depuis mon téléphone en utilisant Juice.

1
danofsatx

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

1
Slim-Jay1