Mot-clé - fail2ban

Fil des billets - Fil des commentaires

mardi 13 janvier 2015

Hardened SSH server

I strongly suggest that you heed the advice from stribika’s page on securing the Secure Shell (SSH), the aim of which is to make your SSH server safe from the NSA; or so they say…

Cet article est aussi disponible en français.

Lire la suite...

lundi 12 janvier 2015

Un serveur SSH endurci

Je vous conseille vivement de suivre les recommandations de la page de stribika sur le « Secure Secure Shell », ou « Secure SSH », qui visent à rendre le serveur SSH suffisamment sécurisé pour résister à la NSA, disent-ils…

This article has been translated to English.

Lire la suite...

dimanche 2 novembre 2014

Migrate from DenyHosts to Fail2ban

A new version of OpenSSH has been released and is bound to be quickly integrated into our preferred Linux distributions; good news! But…

sshd(8): Support for tcpwrappers/libwrap has been removed.

This may look rather inoffensive. But this means, that the SSH server will not use the /etc/hosts.allow and /etc/hosts.deny files to decide wether the IP address of a machine that is attempting to connect should be allowed to, or not.

My problem is that DenyHosts is relying on these files to protect the SSH port on my server. I fear this will be the death of the DenyHosts project. For instance, the Debian Linux distribution removed it from its software repositories. Thus I have to find an alternative software.

The two most common suggestions for replacing DenyHosts are Fail2ban and Sshguard. I choose Fail2ban because the latest version of Sshguard is a few years old (2011), and because Fail2ban allows for more personalization.

Cet article existe aussi en français.

Lire la suite...

jeudi 30 octobre 2014

Migration de DenyHosts à Fail2ban

La nouvelle version d’OpenSSH vient de sortir et sera rapidement intégrée à nos distributions Linux préférées ; excellente nouvelle ! Mais…

sshd(8): Support for tcpwrappers/libwrap has been removed.

Cela peut, à première vue, sembler inoffensif. Mais concrètement, cela signifie que le serveur SSH ne va plus consulter les fichiers /etc/hosts.allow et /etc/hosts.deny pour autoriser ou interdire l’accès au serveur en fonction de l’adresse IP de la machine qui se connecte.

Or DenyHosts utilise ce mécanisme pour protéger le port SSH du serveur. Cela marque, je le crains, la mort du projet DenyHosts. La distribution Debian l’a d’ailleurs retiré de sa logithèque. Il faut donc trouver une alternative.

Deux propositions reviennent régulièrement lorsqu’il s’agit de remplacer DenyHosts : Fail2ban et Sshguard. J’ai choisi Fail2ban car la dernière version de Sshguard date de quelques années (2011) et que Fail2ban est plus souple dans ses options de configuration.

This article has been translated to English.

Lire la suite...