Denyhosts, fail2ban, iptables : le meilleur moyen d'empêcher les connexions par force brute ?

Le meilleur moyen d'empêcher les connexions par force brute ?

Ne les laissez pas accéder à votre machine ! Il existe de nombreux moyens de stopper les tentatives de force brute avant qu'elles n'atteignent votre hôte, ou même au niveau de SSH.

Cela dit, protéger votre système d'exploitation avec quelque chose comme fail2ban est une excellente idée. Fail2ban est légèrement différent de DenyHosts, bien qu'ils jouent dans le même espace. Fail2ban utilise iptables.

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 les 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 prendre en compte pour empêcher les connexions par force brute :

SSH :

• Ne pas permettre à root de se connecter
• Ne pas autoriser les mots de passe ssh (utiliser l'authentification par clé privée)
• N'écoutez pas sur chaque interface
• Créez une interface réseau pour SSH (par exemple eth1), qui est différente de l'interface à partir de laquelle vous répondez aux demandes (par exemple eth0).
• N'utilisez pas de noms d'utilisateur courants
• Utilisez une liste d'autorisation et n'autorisez que les utilisateurs qui ont besoin d'un accès SSH.
• Si vous avez besoin d'un accès Internet... Limitez l'accès à un ensemble limité d'adresses IP. Une IP statique est idéale, mais il vaut mieux la verrouiller sur x.x.0.0/16 que sur 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 trafic Internet pour SSH (par exemple, avec AWS, vous pouvez obtenir une connexion directe qui contourne Internet, c'est ce qu'on appelle Direct Connect).
• Utilisez un logiciel comme fail2ban pour détecter toute attaque par force brute.
• Assurez-vous que le système d'exploitation est toujours à jour, en particulier les paquets de sécurité et ssh.

Application :

• Assurez-vous que votre application est toujours à jour, en particulier les paquets de sécurité.
• Verrouillez les pages d'administration de votre application. La plupart des conseils ci-dessus s'appliquent également à la zone d'administration de votre application.
• Protégez votre zone d'administration par un mot de passe, quelque chose comme htpasswd pour la console Web permettra de projeter toutes les vulnérabilités de l'application sous-jacente et de créer une barrière supplémentaire à l'entrée.
• Verrouillez les autorisations de fichiers. Les "dossiers de téléchargement" sont connus pour être des points d'entrée pour toutes sortes de choses désagréables.
• Envisagez de placer votre application derrière un réseau privé et de n'exposer que votre équilibreur de charge frontal et une jumpbox (il s'agit d'une configuration typique dans AWS utilisant les VPC).

UN AUTRE EXCELLENT MOYEN DE PROTÉGER SSH (Je l'utilise depuis une dizaine d'années ou plus) est d'utiliser les bibliothèques récentes d'iptables de manière native (en fonction de votre distro).
Fondamentalement, il peut être utilisé comme un knocking de port qui est construit dans iptables. Cela vous évitera bien des maux de tête. Tant que vous pouvez vous connecter en tcp (telnet est un moyen). J'ai également utilisé des clients ssh et les ai dirigés vers le port. Tout ce qui peut faire une connexion tcp à un numéro de port spécifié. Je vous regarde Putty !) à partir du client qui initie la connexion ssh, vous pouvez l'utiliser.

Voici un exemple dans lequel iptables ouvrira le port 22 à votre hôte lorsque vous vous connecterez par telnet depuis votre hôte au serveur sur le port 4103. Vous pouvez ensuite utiliser un telnet vers le port 4102 ou 4104 pour fermer l'ouverture sed. La raison d'être des ports 4102 et 4104 est d'empêcher un simple scan tcp d'ouvrir le port 22. Seule une connexion tcp (telnet) au port 4103 vous permettra d'entrer.

Profitez-en !

Oh et je favorise Fail2Ban. Plus de flexibilité et j'aime que le bannissement se fasse dans iptables plutôt que dans tcpwrappers.

SSH PORTKNOCKING

iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -m recent --rcheck --name SSH -j ACCEPT
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 4102 -m recent --name SSH --remove -j DROP
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 4103 -m recent --name SSH --set -j DROP
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 4104 -m recent --name SSH --remove -j DROP

Une autre différence entre Fail2ban et Denyhosts est que Denyhosts peut partager la liste de blocage avec d'autres utilisateurs de Denyhosts. Avec Fail2ban, vous ne pouvez bloquer que les IP que votre serveur a déjà vues. Avec Denyhosts, une tentative de force brute peut même ne jamais atteindre votre serveur, si quelqu'un d'autre l'a vue et si la liste de blocage est téléchargée sur votre serveur avant que l'attaquant n'atteigne votre ordinateur.

Une autre différence encore est que Fail2ban utilise iptables, alors que Denyhosts utilise tcpwrappers. D'autres ont déjà mentionné cette différence, mais il y a quelques notes secondaires qui valent la peine d'être mentionnées.

iptables est limité dans le nombre d'adresses IP que vous pouvez bloquer efficacement. C'est probablement l'une des raisons pour lesquelles Fail2ban ne dispose pas d'un mécanisme permettant de partager les listes de blocage.

Un autre effet est que lorsque iptables est remplacé par nftables, Fail2ban cessera probablement de fonctionner ou devra être réécrit. Denyhosts continuera probablement à fonctionner.

Les deux ont donc des avantages et des inconvénients. J'aime les deux ; pour ma part, j'utilise Denyhosts parce que je ne veux généralement protéger que SSH, et j'aime partager la liste de blocage.

J'utilise les règles iptables pour limiter le débit des nouvelles connexions provenant de la même adresse IP (SSH principalement, mais cela fonctionnerait aussi pour FTP). L'avantage, tel que je le vois, par rapport à "fail2ban" et d'autres outils de ce type, est que la route iptables se produit totalement en mode noyau et ne dépend pas d'outils en mode utilisateur pour filtrer / analyser les fichiers journaux.

Des centaines d'échecs de connexion ssh

Si vous pouvez le faire, limiter les adresses sources qui peuvent accéder aux protcols en question sera évidemment utile aussi.

Avec SSH, vous devriez vraiment utiliser l'authentification par certificat et ne pas accepter de mots de passe de toute façon.