SSH est un protocole utilisé pour sécuriser et crypter la transmission de données sur un réseau. Il est largement utilisé dans le cercle linux administrateurs pour gérer le serveur distant. Le serveur de connexion Internet est très souvent attaqué par le service SSH afin d'accéder au serveur. Le plus courant est la sélection du mot de passe d'un utilisateur avec des droits d'administrateur. Dans ce guide, nous allons passer en revue quelques conseils de sécurité de base. SSH Connexions.
Définir un mot de passe complexe
Votre serveur peut être attaqué par des intrus essayant de deviner le mot de passe du serveur en SSH pour réduire le risque de piratage - nous vous recommandons de définir des mots de passe pour les comptes de serveur qui correspondent aux paramètres suivants :
- Au moins 8 caractères
- Utiliser des caractères majuscules et minuscules (AaBb)
- Utilisez des lettres - des chiffres et des signes ( [courriel protégé])
Un mot de passe fort ne protégera pas seulement contre le piratage SSH protocole, mais améliorera généralement la sécurité du serveur.
Utiliser les clés SSH
Une protection supplémentaire pour votre serveur sera l'utilisation d'une clé pour se connecter au serveur via SSH, vous devez générer une clé sur l'ordinateur/serveur à partir duquel vous allez vous connecter :
Comment créer SSH touche enfoncée Système d'exploitation Windows:
Pour créer une clé dans linux tapez la commande :
ssh-keygen -t rsa
Pour installer cette clé sur le serveur auquel vous allez vous connecter, tapez la commande suivante :
ssh-copy-id -p 22 [courriel protégé]
- -p 22- port du serveur sur lequel il fonctionne SSH protocole (sujet à changement, plus de détails ci-dessous)
- administrateur- Connectez-vous depuis votre serveur
- 192.168.1.1 - Adresse IP de votre serveur
Si tout a été fait correctement, vous pouvez maintenant vous connecter au serveur par clé et vous n'avez pas besoin de saisir un mot de passe à chaque fois.
Utiliser un port non standard
Standard SSH le service en cours d'exécution sur le serveur écoute 22 ports pour se connecter / transférer des données, cela peut être utilisé par des attaquants, en s'appuyant sur le fait que la plupart des utilisateurs ne changent pas le port standard pour se connecter au serveur. Par conséquent, nous allons changer le port, réduisant ainsi une fois de plus le risque de piratage de notre serveur.
Pour cela, ouvrez le fichier de configuration SSH sur serveur :
sudo nano /etc/ssh/sshd_config
Trouvez-y une ligne commentée comme celle-ci :
# Port 22
Supprimer le symbole # - pour supprimer l'option de commentaire et modifier 22 à n'importe quel nombre de 11060 et par ordre croissant, on utilisera par exemple 11 060 , la ligne devrait maintenant ressembler à ceci :
Port 11060
Enregistrer la configuration " ctrl+O" et quitter l'éditeur " ctrl+X".
Besoin de redémarrer SSH service - pour accepter les nouveaux paramètres, exécutez la commande :
redémarrage du service sudo sshd
Ainsi, nous avons changé le port de connexion, à partir de maintenant - pour vous connecter au serveur, vous devez spécifier un port non standard avec l'option -p 11060 , Par exemple:
ssh-p 11060 [courriel protégé]
Ne laisser l'accès qu'à une partie des utilisateurs
SSH la connexion peut être limitée pour des comptes individuels, par exemple, si le serveur a trois comptes : administrateur , Sergey , Alexandre- Vous avez la possibilité d'autoriser la connexion à distance uniquement pour certains d'entre eux. Pour cela, ouvrez le fichier de configuration SSH:
Dans ce fichier, descendez avec des flèches jusqu'à la dernière ligne et ajoutez-en une nouvelle avec le contenu suivant :
Autoriser les utilisateurs administrateur alex
Enregistrer la configuration " ctrl+O" et quitter l'éditeur " ctrl+X".
Recharger le service SSH:
redémarrage du service sudo sshd
En faisant cela, vous avez autorisé l'accès à distance pour les utilisateurs administrateur Et Alexandre, tandis que l'utilisateur Sergey ne peut plus se connecter à distance.
Activer le protocole SSH 2
Selon la norme SSH fonctionne en mode version 1, cette version est obsolète et comporte de nombreuses vulnérabilités, mais pour une meilleure sécurité, nous vous conseillons de passer en mode version 2. Pour cela, ouvrez le fichier de configuration SSH:
sudo nano /etc/ssh/ssh_config
Trouvez la ligne :
#Protocole 2
Supprimer le symbole # - pour supprimer l'option de commentaire et utiliser cette ligne, cela devrait ressembler à ceci :
Protocole 2
Enregistrer la configuration " ctrl+O" et quitter l'éditeur " ctrl+X".
Recharger le service SSH:
redémarrage du service sudo sshd
Désactiver les mots de passe vides
Défaut SSH le service interdit aux utilisateurs sans mot de passe de se connecter, mais cette option peut être désactivée sur votre serveur, alors ouvrez le fichier de configuration SSH:
sudo nano /etc/ssh/ssh_config
Trouvez la ligne Autoriser les mots de passe vides et assurez-vous que la valeur est "Non".
PermitEmptyPasswords non
Activer la journalisation détaillée
Pour servir SSH conservé un journal des connexions échouées indiquant les adresses IP, ouvrez le fichier de configuration SSH:
sudo nano /etc/ssh/ssh_config
Trouvez la ligne LogLevel et plutôt INFO spécifier VERBEUX, la ligne devrait ressembler à ceci :
LogLevel VERBOSE
Enregistrez le fichier " ctrl+O" et quitter l'éditeur " ctrl+X".
Recharger le service SSH:
redémarrage du service sudo sshd
Vous pouvez vérifier en entrant la commande :
chat /var/log/sécurisé
Le système affichera des informations comme ceci :
21 juin 13:06:28 centos sshd : échec du mot de passe pour root à partir du port 118.212.143.47 48263 ssh2
Autrement dit, selon cette entrée, nous voyons qu'il y a eu une tentative infructueuse de pénétrer dans le serveur à partir de l'adresse spécifiée.
Merci pour votre attention, c'est tout.
Une attaque courante sur un service SSH est une attaque par force brute, où un attaquant distant essaie sans cesse de se connecter avec différents mots de passe. Bien sûr, il existe des arguments contre l'authentification par mot de passe pour SSH, et il existe d'autres mécanismes d'authentification, les options existantes telles que l'authentification par clé publique ou l'authentification à deux facteurs annuleront une attaque par force brute. Sans entrer dans une discussion sur les avantages et les inconvénients des diverses méthodes d'authentification, considérons une situation où l'authentification par mot de passe est nécessaire. Comment protégez-vous votre serveur SSH contre les attaques par force brute ?
fail2ban est un cadre de prévention des intrusions open source bien connu pour Linux qui surveille divers fichiers journaux système (par exemple /var/log/auth.log ou /var/log/secure) et applique automatiquement diverses défenses contre les activités suspectes détectées. En fait, fail2ban peut être très utile pour se protéger contre les attaques par force brute sur un serveur SSH.
Dans ce tutoriel, je vais démontrer comment installer et configurer fail2ban pour protéger le serveur SSH contre les attaques par force brute à partir d'adresses IP distantes.
Installation de Fail2ban sous Linux
Pour installer fail2ban sur CentOS ou RHEL, installez d'abord le référentiel EPEL, puis exécutez la commande suivante.
Pour installer fail2ban sur Fedora, exécutez simplement :
$ sudo yum installer fail2banPour installer fail2ban sur Ubuntu, Debian ou Linux Mint :
$ sudo apt-get install fail2banConfiguration de Fail2ban pour le serveur SSH
Vous êtes maintenant prêt à configurer fail2ban pour renforcer votre serveur SSH. Vous devez modifier le fichier de configuration dans /etc/fail2ban/jail.conf. Le fichier de configuration contient une section "DEFAULT" dans laquelle vous définissez les paramètres par défaut pour tous les services surveillés, et une section spécifique au service dans laquelle vous définissez les jails spécifiques au service (par exemple, SSH, Apache, etc.) pour remplacer les paramètres par défaut.
Dans la section jails spécifiques au service (quelque part après la section), vous devez définir une section dans laquelle vous définirez des paramètres spécifiques pour les jails SSH. L'interdiction actuelle des adresses IP est effectuée par iptables.
L'exemple suivant se trouve dans /etc/fail2ban/jail.conf qui contient le paramètre jail "ssh-iptables". Bien sûr, il peut y avoir d'autres prisons pour différentes applications, selon vos besoins.
$ sudo vi /etc/fail2ban/jail.local # liste d'adresses IP, de préfixes CIDR ou de noms d'hôte DNS séparés par des espaces # pour contourner la sécurité fail2ban ignoreip = 127.0.0.1 172.31.0.0/24 10.10.0.0/24 192.168.0.0/24 # nombre de secondes pendant lesquelles un client est bloqué bantime = 86400 # nombre de tentatives infructueuses après lesquelles un blocage se produit maxretry = 5 # nombre de secondes pendant lesquelles les tentatives infructueuses sont cumulées findtime = 600 mta = sendmail enabled = true filter = sshd action = iptables sendmail -whois # pour les distributions basées sur Debian logpath = /var/log/auth.log # pour les distributions basées sur Red Hat logpath = /var/log/secure # seuil maximal de tentatives spécifique à ssh maxretry = 3
Avec la configuration ci-dessus, fail2ban bannira automatiquement toutes les adresses IP distantes qui ont au moins 3 tentatives infructueuses au cours des 10 dernières minutes. Une fois bannie, l'IP incriminée restera bannie pendant 24 heures. La notification de cet événement sera envoyée par courrier.
Une fois le fichier de configuration prêt, redémarrez le service fail2ban comme indiqué ci-dessous.
Sur Debian, Ubuntu ou CentOS/RHEL 6 :
$ sudo service fail2ban redémarrage
Sur Fedora ou CentOS/RHEL 7 :
$ sudo systemctl redémarrage fail2ban
Pour vérifier si fail2ban a démarré avec succès, exécutez la commande fail2ban-client avec l'argument « ping ». Si le service fail2ban fonctionne normalement, vous devriez voir une réponse "pong".
$ sudo fail2ban-client ping Le serveur a répondu : pong
Tester la protection avec Fail2ban sur SSH contre une attaque par force brute
Pour tester si fail2ban fonctionne, essayez de vous connecter au serveur SSH en utilisant le mauvais mot de passe pour simuler une attaque par force brute. En attendant, vérifiez /var/log/fail2ban.log qui enregistre tous les événements intéressants qui se produisent dans fail2ban.
$ sudo tail -f /var/log/fail2ban.log
Selon le journal ci-dessus, fail2ban a interdit l'adresse IP 192.168.1.8 car il a trouvé plusieurs erreurs en essayant de se connecter en SSH à cette adresse IP.
Vérification du statut Fail2ban et déblocage des adresses IP bloquées
La prison "ssh-iptables" dans fail2ban utilise iptables pour bloquer les adresses IP incriminées, vous pouvez facilement vérifier l'interdiction en consultant les règles iptables actuelles, comme indiqué ci-dessous.
$ sudo iptables --list -n Chain INPUT (policy ACCEPT) target prot opt source destination fail2ban-SSH tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 Chain FORWARD (policy ACCEPT) target prot opt source destination Chaîne OUTPUT (policy ACCEPT) target prot opt source destination
Si vous souhaitez débannir les adresses IP de fail2ban, vous pouvez également exécuter la commande iptables :
$ sudo iptables -D fail2ban-SSH -s 192.168.1.8 -j DROP
Bien que vous puissiez vérifier et gérer manuellement la liste d'adresses IP bloquées de fail2ban à l'aide des commandes iptables, comme indiqué, la bonne méthode consiste en fait à utiliser l'outil de ligne de commande ail2ban-client. Cet outil vous permet de gérer non seulement la prison « ssh-iptables », mais également tout autre type de prison fail2ban dans une interface de ligne de commande unifiée.
Pour vérifier le statut de fail2ban (qui affichera une liste des prisons actuellement actives) :
$ sudo fail2ban-état du client
Pour vérifier l'état d'une prison particulière (par exemple, ssh-iptables):
$ sudo fail2ban-état du client ssh-iptables
La commande ci-dessus affichera une liste d'adresses IP interdites.
Pour débloquer une adresse IP spécifique :
$ sudo fail2ban-client set ssh-iptables unbanip 192.168.1.8
Notez que si vous arrêtez fail2ban, toutes les adresses IP bannies seront débannies. Lorsque vous redémarrez fail2ban, il trouvera la liste des adresses IP incriminées dans /var/log/secure (ou /var/log/auth.log) et ré-interdire ces adresses IP si l'interdiction n'a pas expiré.
Configuration de Fail2ban pour le chargement automatique et l'activation
Après avoir testé avec succès fail2ban, la dernière étape pour activer fail2ban consiste à démarrer automatiquement lorsque le serveur est sous tension. Sur les distributions basées sur Debian, le démarrage automatique fail2ban est activé par défaut. Sur les distributions basées sur Red Hat, activez le démarrage automatique de la manière suivante.
Sur CentOS/RHEL 6 :
$ sudo chkconfig fail2ban sur
Sur Fedora ou CentOS/RHEL 7 :
$ sudo systemctl activer fail2ban
Résultat
Dans ce tutoriel, j'ai montré comment installer et configurer fail2ban pour sécuriser un serveur SSH. Bien que fail2ban puisse atténuer une attaque par force brute, rappelez-vous qu'il ne peut pas protéger les serveurs SSH contre les campagnes de force brute complexes (distribuées) où les attaquants contournent fail2ban en utilisant des milliers d'adresses IP contrôlées par des bots.
Dans cet article, nous examinerons la méthode de base pour protéger SSH contre masse attaques par force brute. Dans ce cas, une attaque massive par force brute ne signifie pas une devinette de mot de passe ciblée, spécifiquement pour votre SSH, mais une capture étendue d'une gamme de serveurs, pour l'identification ultérieure des paires login-mot de passe qui sont instables à la sélection d'un mot de passe.
Les principales caractéristiques d'une attaque par force brute en masse SSH sont une analyse approfondie des plages d'adresses IP sur le port 22 ouvert et l'utilisation de noms d'utilisateur et de mots de passe couramment utilisés (par exemple, root:passwd123, admin:server123, etc.).
Pour afficher les statistiques des fichiers journaux des tentatives d'autorisation SSH infructueuses sur votre serveur, saisissez la commande :
Chat /var/log/secure* | grep "Echec du mot de passe" | grep sshd | awk "(imprimer $1,$2)" | trier -k 1,1M -k 2n | unique -c
Cette capture d'écran fournit des statistiques sur le nombre d'autorisations échouées par jour. Si vous volez des données similaires, vous devez prendre des mesures pour protéger votre SSH contre la force brute de masse.
1. Si vous n'utilise pas les noms d'utilisateur couramment utilisés pour l'autorisation, tels que root, admin, administrator, user, etc. et utilisez un mot de passe complexe pour l'autorisation, vous pouvez alors immédiatement passer à la deuxième étape. Pour changer le mot de passe en un mot plus complexe, entrez la commande :
Mot de passe #votre_login#
Où #votre_identifiant#- Ton nom d'utilisateur.
Lors de la saisie d'un nouveau mot de passe, le mot de passe ne s'affiche pas, le curseur sera au même endroit.
Allons sur le serveur via SSH, créons un nouvel utilisateur et définissons-lui un mot de passe, pour cela nous entrerons les commandes :
adduser #newuser# passwd #newuser#
Où #nouvel utilisateur#- Votre nouveau nom d'utilisateur, n'utilisez pas les noms d'utilisateur couramment utilisés, ce n'est pas une mauvaise option votre_nickadmin(par exemple foxadmin, useralex, rootidler).
2. Après cela, nous passons par SSH avec un nouveau login et mot de passe. Et ouvrez la configuration du démon SSH (sshd_config) avec la commande :
Vi /etc/ssh/sshd_config
Ensuite, vous devriez voir quelque chose comme ceci : 
Lignes commençant par # sont commentés.
Pour protéger SSH contre la force brute en masse, décommentez et modifiez ou ajoutez les options suivantes déposer:
un) port- le port sur lequel SSHD accepte et entretient les connexions. Décommenter (supprimer avant le début de la ligne #
) et modifiez la valeur par défaut 22
, à n'importe quel autre de 1024 à 65536, à l'exception des ports réservés - une liste de ports réservés, par exemple :
Port 2022
Supprimer # et changer la valeur port 22, appuyez d'abord sur le clavier je, après avoir édité la ligne souhaitée, appuyez sur la touche ESC
b) ConnexionGraceTime— temps d'attente pour l'enregistrement de l'utilisateur dans le système. Si l'utilisateur n'a pas eu le temps de se connecter au système pendant le temps imparti par cette directive, la session est terminée. Diminuons cette valeur :
ConnexionGraceTime 1m
c) PermitRootLogin- autoriser l'utilisateur racine connexion via le protocole SSH. Passer à Non.
PermitRootLogin non
d) Autoriser les utilisateurs— noms d'utilisateurs autorisés à se connecter via le protocole SSH, séparés par un espace. Ici, au lieu de #votre_login#, nous indiquons le nom d'utilisateur nouvellement créé.
Autoriser les utilisateurs #votre_login#
e) MaxAuthTries- Le nombre de tentatives de connexion par session. Lorsque le nombre maximal de tentatives autorisé est atteint, la session est terminée.
MaxAuth essaie 2
En conséquence, nous obtiendrons :
Port 2022 LoginGraceTime 1m PermitRootLogin non AllowUsers #your_login# MaxAuthTries 2
Dans cet article, nous terminerons la configuration SSH se protéger de la masse force brutale. Après l'édition , appuyez sur le clavier :
, une ligne apparaît en dessous puis entrez dedans wq et appuyez sur la touche Entrer. Dans ce cas, toutes les modifications apportées seront enregistrées. 
Si vous avez fait quelque chose de mal (par exemple, supprimé accidentellement quelque chose), quitter sans sauvegarder utiliser à la place du raccourci clavier wq, clés Q !
Une fois la configuration SSH terminée, redémarrez le démon avec la commande :
redémarrage du service sshd
Maintenant, lors de la connexion via le protocole SSH, utilisez le nouveau port 2022 (ou celui que vous avez spécifié dans les paramètres) au lieu de port standard 22.
Dans le prochain article sur la configuration de SSH, je voudrais vous dire que nous interdirons l'autorisation par mot de passe et n'autoriserons l'autorisation qu'à l'aide d'une clé SSH privée, nous protégeant ainsi autant que possible de la devinette de mot de passe.
En contact avec
Dès qu'un service est « éclairé » sur un réseau public, il devient immédiatement l'objet d'attaques. L'un des problèmes est une tentative d'accès à l'aide de la force brute de mot de passe (force brute). Et SSH ne fait pas exception dans ce cas.
Une analyse du fichier journal d'authentification /var/log/auth.log ou analogues montre qu'une tentative de deviner un mot de passe est généralement effectuée à partir de plusieurs adresses IP à la fois et s'étire dans le temps.
Protection contre les forces brutes SSH
Vous pouvez vous en protéger de différentes manières :
- Utilisation des options de configuration du démon SSH
- filtre de paquets
- Applications spéciales
- port qui frappe
Le moyen le plus simple et le plus efficace consiste à modifier le port par défaut 22, par exemple, en 2002, si cela n'interfère pas avec d'autres tâches. Nous faisons une entrée dans /etc/ssh/sshd_config :
Après cela, les tentatives de deviner les mots de passe s'arrêtent pratiquement. Il y a des moments où le port ne peut pas être changé. Alternativement, vous pouvez restreindre l'accès SSH à certains utilisateurs (en particulier, root) ou à un groupe. Un certain nombre de paramètres sont responsables de cela dans sshd_config : AllowUsers, AllowGroups, DenyUsers et DenyGroups. Il est pratique que vous puissiez spécifier une adresse IP ou un sous-réseau avec une connexion. Par exemple, autorisons l'accès à l'utilisateur admin et à l'utilisateur, ce dernier à partir d'une seule IP :
Une autre option efficace de protection contre la force brute est l'utilisation de certificats pour l'authentification. De plus, en utilisant le paramètre match spécial, vous pouvez créer un bloc conditionnel dans lequel redéfinir les paramètres de la section globale. Par exemple, désactivons la connexion SSH avec un mot de passe pour l'utilisateur root, permettant à tous les autres :
# autoriser tout le monde à accéder par mot de passe
Authentification par mot de passe oui
# root n'utilisera que le certificat
correspondre à la racine de l'utilisateur
Authentification par mot de passe non
KbdInteractiveAuthentication non
En utilisant TCP Wrapper, nous pouvons également restreindre l'accès à n'importe quel service uniquement à partir de certaines adresses IP, pour cela, il vous suffit d'écrire la règle nécessaire dans le fichier /etc/hosts.allow ou /etc/hosts.deny. Autorisons l'accès dans /etc/hosts.allow uniquement depuis le sous-réseau requis :
sshd : 192.168.1.0/24 : autoriser
Ou dans /etc/hosts.deny :
sshd:ALL:refuser
sshd : TOUS SAUF 192.168.1.0/24 : autoriser
Le filtre de paquets vous permet de définir très précisément les paramètres de connexion, en supprimant les paquets inutiles. Avec son aide, il est facile de restreindre l'accès au 22e port uniquement à certaines adresses. Exemple simple :
iptables -A ENTRÉE -s !192.168.0.1 -p tcp -m tcp --dport 22 ↵
-j REJETER -rejeter-avec icmp-port-unreachable
Le filtrage de paquets par ports et adresses IP n'est pas très efficace si l'administrateur n'est pas lié au lieu de travail. Dans ce cas, des utilitaires spéciaux vous aideront: Fail2ban, Sshguard. Fail2ban a été initialement conçu pour sécuriser SSH. Bien qu'aujourd'hui, il s'agisse déjà d'un cadre qui peut être facilement personnalisé pour n'importe quelle application. Le principe de fonctionnement est très simple. Le démon vérifie périodiquement les journaux pour toute activité suspecte. L'adresse IP suspecte est ensuite bloquée par iptables ou TCP Wrapper. Après le temps spécifié dans les paramètres, le blocage est généralement supprimé afin de ne pas bloquer accidentellement un nœud légal. Lorsque la règle est déclenchée, un événement est écrit dans le journal /var/log/fail2ban.log et un e-mail peut être envoyé.
Un seul processus peut contrôler plusieurs services à la fois, et le package est fourni avec des paramètres prêts à l'emploi pour les applications Linux courantes. Par défaut, seul SSH est protégé.
Sur Ubuntu et Debian, installez avec la commande :
$ sudo apt-get install fail2ban
Tous les réglages sont effectués dans plusieurs fichiers situés dans le répertoire /etc/fail2ban. Fail2ban.conf stocke les paramètres de lancement du démon lui-même, jail.conf décrit les services contrôlés (dans la section SSH).
activé=vrai
port=22
filtre=sshd
logpath=/var/log/auth.log
maxretry = 3
Les filtres et les actions sont écrits dans des fichiers situés dans les sous-répertoires filter.d et action.d. Par défaut, tous les fichiers ont l'extension .conf, il vaut mieux ne pas y toucher (y compris jail.conf). Toutes les modifications doivent être apportées à un fichier avec une extension .local (par exemple, jail.local), dont les paramètres remplacent les paramètres du premier et ne seront pas perdus lors de la mise à niveau. Vous pouvez utiliser l'utilitaire fail2ban-regex pour vérifier si le filtre fonctionne.
Secure Shell est présent partout. Depuis sa sortie en 1995, SSH a été largement accepté comme un puissant protocole d'accès à distance pour Linux.
Cependant, comme vous le savez, un grand pouvoir s'accompagne d'une grande responsabilité. Un démon SSH mal configuré peut être plus une menace qu'une aide. Dans cet article, nous examinerons cinq étapes pour renforcer la sécurité SSH.
1. Désactivez la connexion root.
L'étape la plus simple. De toute évidence, il existe peu de raisons d'autoriser la connexion root via SSH. La désactivation de cet accès est assez simple et cela renforcera la sécurité.
Trouvez /etc/ssh/sshd_config (il peut se trouver dans un répertoire différent, cela dépend de la distribution). Dans celui-ci, nous définissons la place de PermitRootLogin et remplaçons la valeur par "no":
PermitRootLogin non
Bien sûr, cela n'empêchera personne de s'introduire dans le système sous un utilisateur normal, cependant, cela servira toujours de barrière supplémentaire à la domination du système.
Après avoir lu tout ce qui est écrit ci-dessus et l'avoir mis en pratique, nous obtiendrons éventuellement les clés d'autorisation sur le serveur. Après vous être assuré que tout fonctionne, vous pouvez désactiver la saisie interactive :
Authentification par mot de passe non
ChallengeResponseAuthentication non
À l'aide de ce script Python, l'administrateur peut automatiquement mettre sur liste noire les hôtes en cas de connexion infructueuse, les bannissant pour toujours. La manière la plus simple d'installer :
Europe ~ # emerge -pv denyhosts
Voici les packages qui seraient fusionnés, dans l'ordre :
Calcul des dépendances... c'est fait !
app-admin/denyhosts-2.5 0 kB
Taille totale des téléchargements : 0 Ko
europa ~ # émergent denyhosts
Il n'y a pas beaucoup de documentation sur le programme (s'il y en a, par exemple), cependant, toutes les options de configuration sont normalement décrites dans le fichier de configuration.
Europe $ nano -w /etc/denyhosts.conf
Je ne pense pas que la configuration de DenyHosts causera des problèmes particuliers - il suffit de lire attentivement la configuration.
Après la configuration, vous pouvez exécuter le programme en tant que démon ou via un planificateur. Sur le démon Gentoo :
rc-update ajouter denyhosts par défaut
Via cron, disons toutes les 10 minutes :
Python /usr/bin/denyhosts -c /etc/denyhosts.conf
La joie de DenyHost n'est pas seulement de bloquer les hôtes essayant d'atteindre votre serveur SSH, mais aussi dans le fait que vous pouvez synchroniser votre liste noire avec les serveurs DenyHost. Cela crée une liste collective d'hôtes contenant tous les attaquants. Cela empêchera l'attaque à la racine.
4. Modifiez le numéro de port.
La plupart des tentatives de piratage proviennent de scripts automatisés qui analysent le réseau à la recherche de démons SSH. Dans la grande majorité des cas, ils essaient de s'introduire dans le port 22, ce qui ne fait que jouer en notre faveur. En changeant le port, nous couperons automatiquement la plupart des tentatives d'accès non autorisées.
Vous devriez le changer dans la configuration.