web-dev-qa-db-fra.com

Quelqu'un essaie de forcer l'accès SSH par force à mon serveur

Par coïncidence, j'ai regardé le journal ssh de mes serveurs (/var/log/auth.log) et j'ai remarqué que quelqu'un essayait constamment d'accéder:

Sep  7 13:03:45 virt01 sshd[14674]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=116.31.116.42  user=root
Sep  7 13:03:48 virt01 sshd[14674]: Failed password for root from 116.31.116.42 port 13423 ssh2
Sep  7 13:03:52 virt01 sshd[14674]: message repeated 2 times: [ Failed password for root from 116.31.116.42 port 13423 ssh2]
Sep  7 13:03:52 virt01 sshd[14674]: Received disconnect from 116.31.116.42: 11:  [preauth]

Cela se produit plusieurs fois par minute et dure depuis longtemps sans que je le sache.

Question Dois-je m'en préoccuper, si oui: que dois-je faire?

sshhacking
20
Vingtoft

Malheureusement, c'est absolument normal et quelque chose que chaque serveur SSH connaît. Bienvenue sur Internet.

Tant que vous sécurisez correctement votre serveur (par exemple, maintenez-le à jour, autorisez uniquement la connexion par clé, désactivez l'accès SSH racine), cela ne devrait pas être un problème, mais vous pouvez limiter cela encore plus avec quelque chose comme fail2ban et d'autres approches comme la liste blanche IP, la modification des ports et des trucs comme celui-ci lorsque cela est possible et approprié.

62
Sven
  1. Bloquez l'adresse IP à l'aide de votre pare-feu (iptables ou tout autre service fourni). Oui, ils peuvent changer les IP, mais leur faire faire le travail
  2. Si vous avez un pare-feu externe (c'est-à-dire que la console AWS vous permet de définir des règles d'accès via une page Web), envisagez de limiter le port 22 à JUST your IP. Pas besoin de jouer avec fail2ban dans ce cas
  3. Comme mentionné dans les commentaires, passez à authentification par clé et désactivez l'authentification par mot de passe

  4. Désactiver les connexions root . Ajoutez ceci à /etc/ssh/sshd_config

    PermitRootLogin no

    Laissez-les marteler à la racine tout ce qu'ils veulent. Ils n'arriveront jamais ainsi.

22
Machavity

En plus de sécuriser le serveur comme le souligne Sven, l'une des meilleures choses à faire (surtout si ssh est là pour vous, l'administrateur) est simplement de changer le port sshd par défaut 22.

Non seulement c'est simple (surtout lorsque vous mettez un nouveau port dans votre ~/.ssh/config pour que vous n'ayez pas à le taper à chaque fois) et cela arrêtera 99% de ces analyses automatisées de sorte que vous ne les verrez même pas, mais cela vous aidera également quelque peu même si une vulnérabilité ssh de 0 jour est découverte pour donner vous plus de temps, ou votre clé a fui, etc.

10
Matija Nalis

Ce comportement assez normal. J'en reçois plusieurs milliers chaque jour, et je suppose même que c'est minuscule par rapport à ce que les grandes entreprises font face.

Mais avez-vous besoin de vous inquiéter?

  • Avez-vous installé fail2ban?
  • Avez-vous désactivé la connexion root ssh?
  • Avez-vous bloqué l'utilisateur www-data de la connexion ssh?
  • (facultatif) Avez-vous connexion par mot de passe désactivée en faveur de la connexion par clé publique?
  • (facultatif) Avez-vous changé le port SSH de 22 en autre chose?
  • (facultatif) Avez-vous ajouté un module pam TOTP pour la connexion?

Si oui, alors vous n'avez pas à vous inquiéter. Ces attaques sont généralement des attaques par dictionnaire sur les noms d'utilisateur Unix courants. Par exemple, je vois souvent ces "utilisateurs" essayer de se connecter:

  • root
  • www-data
  • tester
  • administrateur

Je vraiment recommande d'installer fail2ban, car il limitera le taux de tout utilisateur essayant de se connecter en fonction de son adresse IP, cela seul devrait filtrer la plupart du trafic malveillant. Contrairement à ce que disent les autres, je ne suis pas un partisan du blocage basé sur IP. Cela semble être une solution très grossière à un problème très fin. De plus, ces attaquants contrôlent généralement plusieurs IPS, donc même si vous en bloquez plusieurs (ou même plusieurs IP), il n'y a aucune garantie que vous les bloquerez tous. Fail2ban est cependant très flexible pour ces scénarios.

7
RemusKaos