Comment arrêter / empêcher la force brute SSH [fermé]

22

Je suis très nouveau dans l'administration des réseaux, veuillez donc noter que je ne suis pas encore expérimenté.

J'ai un serveur racine Ubuntu avec panneau plesk.

Hier, mes amis et moi avons remarqué que la qualité de la parole sur notre TS3 était très mauvaise. J'ai envoyé des pings au serveur et il y a eu une perte de paquets très élevée. Après cela, j'ai googlé un peu et découvert qu'il y en avait un auth.log. Je l'ai téléchargé et j'ai fait défiler un peu, puis j'ai trouvé ceci:

May 13 10:01:27 rs204941 sshd[9351]: input_userauth_request: invalid user student [preauth]
May 13 10:01:27 rs204941 sshd[9351]: pam_unix(sshd:auth): check pass; user unknown
May 13 10:01:27 rs204941 sshd[9351]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=112.220.198.102 
May 13 10:01:29 rs204941 sshd[9351]: Failed password for invalid user student from 112.220.198.102 port 39806 ssh2
May 13 10:01:29 rs204941 sshd[9351]: Received disconnect from 112.220.198.102: 11: Bye Bye [preauth]
May 13 10:01:31 rs204941 sshd[9353]: Invalid user student from 112.220.198.102

Il semble que quelqu'un ait essayé de se connecter à plusieurs reprises via SSH. J'ai fait défiler un peu et j'ai vu que cette personne essayait d'utiliser de nombreux noms d'utilisateur différents:student, tech, psi, news,...

Des centaines de ces connexions ont été affichées dans le fichier.

J'ai recherché les statistiques de trafic sur le site Web de mon centre de données. Ce n'était qu'à 17 Mo par heure. J'ai une dorsale 100Mbit, donc le transfert de données lui-même ne semble pas être le problème.

Pour le moment, je ne peux en aucun cas accéder au serveur.

Ma question est: comment puis-je obtenir à nouveau l'accès, comment puis-je supprimer cette attaque et empêcher les attaques suivantes?


la source
J'apprends encore mes affaires dans ce département ... Mais ne serait-ce pas une bonne utilisation pour le portage?
mjrider

Réponses:

37

Comment y accéder?

La raison pour laquelle vous ne pouvez pas accéder à votre compte n'est pas claire.

Si votre ordinateur est attaqué ou soumis à une charge élevée, vous devez parler à votre fournisseur de la restriction d'accès (restrictions IP) ou de la mise hors ligne du serveur (se déconnecter d'Internet).

Vous pourriez également avoir besoin d'un accès hors bande avec lequel votre fournisseur pourra vous aider.

Si quelqu'un a compromis votre serveur, vous devrez peut-être restaurer à partir de sauvegardes ou utiliser une image de récupération.

Comment empêcher les attaques sur votre serveur, en particulier SSH

meilleure façon d'empêcher les ouvertures de session par force brute?

Ne les laissez pas accéder à votre machine en premier lieu! Il existe de nombreuses façons d'arrêter les tentatives de force brute avant qu'elles n'atteignent votre hôte, ou même au niveau SSH.

Cela dit, protéger votre système d'exploitation avec quelque chose comme fail2ban est une excellente idée. http://en.wikipedia.org/wiki/Fail2ban

Fail2ban est similaire à DenyHosts ... mais contrairement à DenyHosts qui se concentre sur SSH, fail2ban peut être configuré pour surveiller tout service qui écrit des tentatives de connexion dans un fichier journal, et au lieu d'utiliser /etc/hosts.deny uniquement pour bloquer les adresses IP / hôtes , fail2ban peut utiliser Netfilter / iptables et TCP Wrappers /etc/hosts.deny.

Il existe un certain nombre de techniques de sécurité importantes que vous devez envisager pour empêcher les connexions par force brute:

SSH:

  • Ne pas autoriser root à se connecter
  • Ne pas autoriser les mots de passe ssh (utiliser l'authentification par clé privée)
  • N'écoutez pas sur toutes les interfaces
  • Créez une interface réseau pour SSH (par exemple eth1), qui est différente de l'interface à partir de laquelle vous servez les demandes (par exemple eth0)
  • N'utilisez pas de noms d'utilisateur courants
  • Utiliser une liste d'autorisation et autoriser uniquement les utilisateurs qui nécessitent un accès SSH
  • Si vous avez besoin d'un accès Internet ... Restreignez l'accès à un ensemble fini d'adresses IP. Une IP statique est idéale, mais la verrouiller à xx0.0 / 16 est meilleure que 0.0.0.0/0
  • Si possible, trouvez un moyen de vous connecter sans accès à Internet, de cette façon, vous pouvez refuser tout le trafic Internet pour SSH (par exemple, avec AWS, vous pouvez obtenir une connexion directe qui contourne Internet, elle s'appelle Direct Connect)
  • Utilisez un logiciel comme fail2ban pour attraper toutes les attaques par force brute
  • Assurez-vous que le système d'exploitation est toujours à jour, en particulier les packages de sécurité et ssh

Application:

  • Assurez-vous que votre application est toujours à jour, en particulier les packages de sécurité
  • Verrouillez les pages «admin» de votre application. La plupart des conseils ci-dessus s'appliquent également à la zone d'administration de votre application.
  • Mot de passe Protégez votre zone d'administration, quelque chose comme htpasswd pour la console Web projettera toutes les vulnérabilités sous-jacentes des applications et créera une barrière supplémentaire à l'entrée
  • Verrouillez les autorisations de fichier. Les «dossiers de téléchargement» sont connus pour être des points d'entrée de toutes sortes de choses désagréables.
  • Pensez à placer votre application derrière un réseau privé et à exposer uniquement votre équilibreur de charge frontal et un jumpbox (il s'agit d'une configuration typique dans AWS à l'aide de VPC)
Drew Khoury
la source
1
J'ai installé Fail2ban via help.ubuntu.com/community/Fail2ban Il semble être très puissant et convivial (notifications par courrier, ...)
J'ai reçu un message de mon centre de données: il y a eu une inondation (qu'est-ce que c'est?) Et cela a rendu la connexion très mauvaise pour de nombreux serveurs. Ce n'était pas une attaque sur mon serveur en particulier.
1
Intéressant. Il semble donc que mon datacenter ait été la cible de l'attaque. Mais savoir que je me suis fait brutaliser en plus de ça, c'est très bien aussi. Et Fail2ban est vraiment un bon outil. Je vais lire sur Iptables et SSH Config les prochains jours et essayer de le rendre beaucoup plus sûr.
3
Configurez openssh pour écouter un port autre que 22 et configurez iptables pour supprimer tout ce qui arrive sur le port 22. Si vous ne vous attendez pas à entrer en ssh depuis un autre pays que votre pays d'origine, créez une liste de blocage à countryipblocks.net/country_selection. php et l'utiliser avec iptables.
ThoriumBR
4

comment puis-je supprimer cette attaque et empêcher les attaques suivantes

Habituellement, je change le port ssh par défaut de 22 en un autre comme 1122. Cela empêche de nombreuses attaques automatiques du bot, mais une simple analyse de port peut le détecter. En tous cas:

vi /etc/ssh/sshd_config

et éditez le port 22 vers le port 1122 , mais cela ne suffit pas.

Règles IPTables automatiques sur bruteforce

j'utilise log2iptables https://github.com/theMiddleBlue/log2iptables à la place Fail2ban, car c'est un simple script Bash qui analyse tout fichier journal avec une expression régulière et exécute iptables. Par exemple, lorsque 5 correspondances se produisent, log2iptables supprime l'adresse IP spécifique. C'est cool car utilisez l'API Telegram et pouvez m'envoyer un message sur mon téléphone quand il trouve un problème :)

j'espère que cela vous aidera!

le milieu
la source
8
Je suppose, d'après la corrélation entre l'URL du projet et votre identifiant SF, que vous êtes impliqué dans ce projet. Veuillez consulter nos directives sur le référencement de vos propres produits, en notant en particulier l'exigence selon laquelle " vous devez divulguer votre affiliation dans vos réponses ".
MadHatter prend en charge Monica
1

Je viens de mettre cela ensemble, d'exécuter toutes les 15 minutes en tant que cronjob, etc.:

for z in `grep Invalid /var/log/auth.log | awk '{ print $NF }' | sort | uniq`
do
  count1=`grep $z /etc/hosts.deny | wc -l`
  count2=`grep Invalid /var/log/auth.log | grep $z | wc -l`
  if [ $count1 -eq 0 -a $count2 -gt 10 ] ; then
    current=`egrep "^ssh" /etc/hosts.deny | sed 's/sshd[ :,]*//'`
    sudo cp /etc/hosts.deny.bak /etc/hosts.deny
    sudo chmod 666 /etc/hosts.deny
    if [ $current ] ; then
      echo "sshd : $current , $z" >> /etc/hosts.deny
    else
      echo "sshd : $z" >> /etc/hosts.deny
    fi
    sudo chmod 644 /etc/hosts.deny
  fi
done
marque
la source
0

Ceci est ma solution alternative pour les attaques SSH. L'idée est de continuer à fermer le démon SSH s'il n'est pas utilisé. Pas de port ouvert, pas d'attaque. Tu peux l'essayer. Il est open source https://github.com/indy99/nnet_port_guard

indy99
la source
1
Bienvenue dans Server Fault! Votre réponse suggère qu'une solution pratique à la question est disponible via un autre site Web. La famille de sites Web de questions et réponses de Stack Exchange désapprouve généralement ce type de réponse car d'autres sites Web peuvent se déplacer, être supprimés ou modifiés. Veuillez lire Comment écrire une bonne réponse? et envisagez de réviser votre réponse pour inclure les étapes requises pour résoudre le problème. Et n'oubliez pas de faire le tour du site .
Paul
0

Solution automatisée pour Centos / RHEL pour bloquer les mauvais acteurs

Voici un script pour Centos pour vérifier les échecs de connexion ssh pour les comptes d'utilisateurs non valides et les mauvais mots de passe pour les comptes valides. Si l'IP source nous a frappé plus de 3 fois et n'est pas déjà sur la liste de refus, elle est ajoutée à la liste de refus. Je l'exécute toutes les 15 minutes depuis le crontab de root. J'ai également interdit les connexions root via ssh, donc la combinaison garde les choses assez silencieuses.

     #/bin/bash
     # Save a copy of the existing hosts.deny file for safety
     cp /etc/hosts.deny /etc/hosts.deny.bak
     # Get a list of the offending IP addresses and process them
     for z in `grep "Invalid\|Failed" /var/log/secure | awk '{ print $NF }' | sort | uniq`
     do
     # Get the number of times this IP hit us
     hits=`grep "Invalid\|Failed" /var/log/secure* | grep $z | wc -l`
     # Check whether this IP is already blocked
     blocked=`grep $z /etc/hosts.deny | wc -l`
     # If they hit us more than 3 times and are not already on the deny list
     # add them to the deny list
     if [ $hits -gt 3 -a $blocked -eq 0 ]
     then
          echo "sshd : $z" >> /etc/hosts.deny
     fi
     done
David Lash
la source
1
Regardez un fail2banqui fait la même chose et qui est testé au combat.
Patrick Mevzek