Sécuriser un serveur Ubuntu OpenSSH contre les attaques par force Brute, mais sans pare-feu ni paire de clés SSH?

Question

J'utilise Ubuntu 16.04 et cherche à renforcer mon authentification SSH de manière particulière.

La situation présente:

J'ai une machine avec un serveur minimal Ubuntu que j'utilise principalement pour transférer des fichiers vers via son serveur local OpenSSH serveur. Maintenant, je n'ai pas de pare-feu sur cette machine pour plusieurs raisons et j'évite également d'utiliser une paire de clés, donc je n'utilise qu'un mot de passe. L'un des seuls moyens qu'il me reste de défendre contre les attaques par force brute, et celui que je souhaite le plus pour le moment, consiste à utiliser un mécanisme qui bloque un utilisateur pendant un nombre d'heures, après un nombre d'essais de connexion.

La situation souhaitée:

Je souhaite disposer d’un mécanisme autonome (c’est-à-dire ne faisant pas partie d’un pare-feu) qui bloque un utilisateur pendant un nombre d'heures X, après que le nombre de connexions Y a été tenté comme moyen de se défendre contre les attaques par force brutale.

Ma question:

Connaissez-vous un utilitaire (et une configuration spécifique) qui me permettra de réaliser la situation souhaitée?

Answer 1

Vous pouvez le faire avec Fail2ban:

Sudo apt-get install fail2ban

Ensuite:

Sudo vim /etc/fail2ban/jail.conf

éditez bantime pour régler l'heure d'interdiction souhaitée

edit maxretry pour définir le nombre maximal de tentatives d’échec

comme mentionné par d'autres commentaires, fail2ban requiert iptables.

---

Option séparée - coup de port:

Cela nécessite seulement iptables, pratiquement 0 mémoire et cachera efficacement votre service des analyses de ports

Vous ne répondez pas directement à votre question, mais vous pouvez peut-être utiliser le portage pour cacher la disponibilité de votre service au lieu d'interdire les tentatives répétées.

une recherche rapide sur Google révèle ceci: https://www.digitalocean.com/community/tutorials/how-to-configure-port-knocking-using-only-iptables-on-an-ubuntu-vps =

Vous avez cependant besoin d'iptables.

P.S .: Je sais que la sécurité par l'obscurité n'est pas une sécurité, mais combinée à d'autres pratiques, elle peut contribuer à faire de vous une cible plus difficile.

Answer 2

Cette réponse vise à donner un moyen possible de répondre à la question principale: Sécuriser un serveur Ubuntu OpenSSH contre les attaques par force Brute, mais sans pare-feu ni paire de clés SSH?

En fait, je préfère utiliser la paire de clés Firewall/SSH et j'ai trouvé la réponse fournie par Doug Smythies pour vraiment utile.

Protégez SSH avec l'authentification à deux facteurs

L’authentification à deux facteurs (2FA) est un type de authentification à plusieurs facteurs . Dans cet exemple, 2FA confirme l'identité déclarée d'un utilisateur en utilisant une combinaison de ces deux composants différents:

• Code de jeton à six chiffres basé sur le temps - code d'authentification. Par défaut, ces jetons durent 30 secondes, auxquels s’ajoutent 60 secondes supplémentaires afin de compenser le décalage temporel possible.

• Le mot de passe de l'utilisateur, qui devrait lui-même être suffisamment sécurisé .

En fait, lorsque vous avez défini PermitRootLogin no et que les noms d'utilisateur sont bien choisis, cette méthode peut être appelée 3FA.

En outre, si l'ordinateur auquel vous vous connectez n'est pas protégé contre les tentatives de connexion brutales, vous pouvez activer la limitation de débit pour le module d'authentification.

Commençons:

1. Installer des dépendances

Sudo apt-get install libpam-google-authenticator

2. Editez les fichiers de configuration

• Éditez /etc/pam.d/sshd et ajoutez cette directive:

  # Google Authenticator
  auth required pam_google_authenticator.so
  

  Ajoutez-le au début du fichier. De cette façon, le système demandera le premier code d’authentification et ensuite seulement le mot de passe. Ajoutez-le à la fin du fichier - le système vous demandera le premier mot de passe.

• Éditez /etc/ssh/sshd_config et modifiez ou ajoutez ces directives:

  ChallengeResponseAuthentication yes
  UsePAM yes
  PasswordAuthentication no           # You can leave this 'yes' it doesn't matter.
  

3. Activer l'authentification à deux facteurs pour un utilisateur

Basculez vers l'utilisateur qui doit utiliser l'authentification à deux facteurs et tapez le terminal:

 $ google-authentator Enter
 
 Souhaitez-vous que les jetons d'authentification soient basés sur le temps (y/n) yEnterhttps://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/user@host%3Fsecret%3DE3CY3TNSNBXXXXXX
 Votre nouvelle clé secrète est: E3CY3TNSNBXXXXXX
 Votre code de vérification est 229999 
 Vos codes de grattage d'urgence sont: 
 19999711 
 ... 
 
 Voulez-vous que je mettre à jour votre fichier "/home/user/.google_authenticator" (y/n) yEnter
 
 Souhaitez-vous interdire plusieurs utilisations du même jeton d'authentification? Cela vous limite à une connexion environ toutes les 30 secondes, mais augmente vos chances de remarquer ou même d'empêcher les attaques de type "homme du milieu" 
 (Y/n) yEnter
 
 Par défaut, les jetons ont une durée de validité de 30 secondes. Afin de compenser le décalage possible entre le client et le serveur, nous autorisons un jeton supplémentaire avant et après l'heure actuelle. Si vous rencontrez des problèmes de synchronisation temporelle médiocre, vous pouvez augmenter la fenêtre de sa taille par défaut de 1: 30 min à environ 4 min. Voulez-vous le faire 
 (Y/n) yEnter
 
 Si l'ordinateur auquel vous vous connectez n'est pas durci contre les tentatives de connexion brute-force, vous pouvez activer la limitation de débit pour le module d'authentification. Par défaut, les attaquants ne doivent pas dépasser 3 tentatives de connexion toutes les 30 secondes. Voulez-vous activer la limitation de débit 
 (Y/n) yEnter

Ce dialogue générera un fichier d'authentification appelé .google_authenticator placé dans le répertoire de base de l'utilisateur. Ce fichier peut également être utilisé pour les comptes d'autres utilisateurs si vous souhaitez qu'ils utilisent tous les mêmes jetons. En outre, ce fichier peut être personnalisé et également utilisé pour 2FA dans Apache2 , mais c’est une autre histoire.

4. Générer des codes d'authentification

La clé secrète - E3CY3TNSNBXXXXXX - générée à l'étape ci-dessus est utilisée pour la génération de codes d'authentification dans certaines applications, notamment:

• Authentificateur de ligne de commande
• Ces applications de bureau mentionnées ici
• Extensions pour les navigateurs Web décrits ici
• Google Authenticator pour Android
• Google Authenticator pour iPhone/iPad

5. Exemple d'utilisation

Dans cet exemple, l'extension Authenticator utilisée pour Chromium/Chrome est utilisée:

6. Lectures complémentaires

• La source principale de cette réponse: Comment protéger SSH avec une authentification à deux facteurs ;
• Authentification multifactorielle - Comment activer l'authentification SSH à l'aide d'un application OATH-TOTP (la méthode décrite ici) en plus d'un paire de clés SSH .

---

EDIT:

Dans certains cas, il pourrait y avoir une différence entre l'horloge de Google et celle du serveur. Voici quelques astuces selon ce problème:

• Quelle est la commande pour mettre à jour l'heure et la date depuis Internet

• Date: impossible de définir la date: opération non autorisée

• Linux: Ajouter x secondes à la date actuelle

Malheureusement : S'il s'agit d'un SMV, vous n'avez peut-être pas l'autorisation de le faire ... Si vous utilisez un SMV, contactez votre fournisseur pour le gérer à votre place.

^{Si votre fournisseur ne souhaite pas répondre à vos besoins, la configuration ci-dessus fonctionnera mais avec un décalage temporel. Tapez date dans la console de votre serveur et mesurez ce décalage. Il vous suffit ensuite de travailler avec ce décalage temporel entre le moment de la génération du code d’authentification et celui de son utilisation.}

Answer 3

Vous n'avez rien à installer pour une telle protection - Ajoutez simplement les règles pertinentes dans votre système iptables .

1. Règle préalable:

Au début de votre jeu de règles, autorisez tout trafic associé à revenir sur le serveur:

Sudo iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

2. Règles de détection et de blocage:

Définir une liste dynamique de Badguy. Détectez et supprimez les adresses IP incorrectes qui attaquent par mot de passe sur SSH. Une fois sur la liste BADGUY, le système rejette tous leurs paquets:

Sudo iptables -A INPUT -i eth0 -m recent --update --hitcount 3 --seconds 90000 --name BADGUY_SSH -j LOG --log-prefix "SSH BAD:" --log-level info
Sudo iptables -A INPUT -i eth0 -m recent --update --hitcount 3 --seconds 90000 --name BADGUY_SSH -j DROP
Sudo iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m recent --set --name BADGUY_SSH -j ACCEPT

• Dans le code ci-dessus, 90000 secondes (25 heures) correspond au temps de blocage.

• Toute tentative à partir d'une adresse IP bloquée, même non liée à SSH (en fonction d'autres règles que vous pouvez éventuellement avoir et de la commande), réinitialise le temporisateur de blocage.

3. Durcir les détections:

Limitez le nombre de mots de passe incorrects par connexion à 2. La valeur par défaut est 6.

Comme Sudo, éditez /etc/ssh/sshd_config, et définissez:

    MaxAuthTries 2