Comment durcir un serveur SSH ?

Voici une chose facile à faire : installez ufw (le "pare-feu simple") et l'utiliser pour limiter le débit des connexions entrantes.

À partir d'une invite de commande, tapez :

$ sudo ufw limit OpenSSH 

Si ufw n'est pas installé, faites-le et réessayez :

$ sudo aptitude install ufw 

De nombreux attaquants tenteront d'utiliser votre serveur SSH pour forcer les mots de passe. Celui-ci ne permet que 6 connexions toutes les 30 secondes à partir de la même adresse IP.

Si je veux avoir une sécurité supplémentaire ou si j'ai besoin d'accéder à des serveurs SSH au plus profond d'un réseau d'entreprise, je configure une service caché en utilisant le logiciel d'anonymisation Tor .

1. Installer Tor et configurer le serveur SSH lui-même.
2. Assurez-vous que sshd n'écoute que sur localhost .
3. Ouvrir /etc/tor/torrc . Set HiddenServiceDir /var/lib/tor/ssh y HiddenServicePort 22 127.0.0.1:22 .
4. Regardez var/lib/tor/ssh/hostname . Il y a un nom comme d6frsudqtx123vxf.onion . Il s'agit de l'adresse du service caché.

5. Ouvrir $HOME/.ssh/config et ajoutez quelques lignes :

   Host myhost
   HostName d6frsudqtx123vxf.onion
   ProxyCommand socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050

De plus, j'ai besoin de Tor sur mon hôte local. S'il est installé, je peux entrer ssh myhost et SSH ouvre une connexion via Tor. Le serveur SSH de l'autre côté ouvre son port uniquement sur localhost. Donc personne ne peut s'y connecter via "l'internet normal".

Il existe un article de l'administration Debian sur ce sujet. Il couvre la configuration de base du serveur SSH ainsi que les règles de pare-feu. Cela peut également être intéressant pour renforcer un serveur SSH.

Voir cet article : Sécuriser l'accès SSH .

Mon approche du durcissement de SSH est... complexe. Les éléments suivants correspondent à la manière dont je procède, de la frontière la plus éloignée de mon ou mes réseaux aux serveurs eux-mêmes.

1. Filtrage du trafic au niveau de la frontière par des IDS/IPS avec des scanners de services connus et des signatures dans la liste de blocage. J'y parviens avec Snort via mon pare-feu frontalier (c'est mon approche, une appliance pfSense). Parfois, je ne peux pas le faire, par exemple avec mes VPS.

2. Pare-feu/filtrage réseau du ou des ports SSH. Je n'autorise explicitement que certains systèmes à accéder à mes serveurs SSH. Cela se fait soit par le biais d'un pare-feu pfSense à la frontière de mon réseau, soit par la configuration explicite des pare-feu sur chaque serveur. Il y a des cas où je ne peux pas le faire, cependant (ce qui n'est presque jamais le cas, sauf dans des environnements privés de pen-testing ou de laboratoire de test de sécurité où les pare-feu n'aident pas à tester les choses).

3. En conjonction avec mon pfSense, ou un pare-feu frontalier NAT-ing le réseau interne et la séparation de l'Internet et les systèmes, Accès aux serveurs uniquement par VPN . Vous devez vous connecter par VPN à mes réseaux pour accéder aux serveurs, car il n'y a pas de ports Internet en tant que tels. Cela ne fonctionne certainement pas pour tous mes VPS, mais en conjonction avec #2, je peux avoir un VPS comme "passerelle" en se connectant par VPN à ce serveur, et ensuite autoriser ses IP aux autres boîtes. De cette façon, je sais exactement ce qui peut ou ne peut pas se connecter en SSH - ma seule boîte qui est le VPN. (Ou, dans mon réseau domestique derrière pfSense, ma connexion VPN, et je suis le seul à avoir un accès VPN).

4. Où le point 3 n'est pas réalisable, fail2ban, configuré pour bloquer après 4 tentatives infructueuses et bloquer les IP pendant une heure ou plus. est une protection décente contre les personnes qui attaquent constamment avec le bruteforcing - il suffit de les bloquer au niveau du pare-feu automatiquement avec fail2ban, et meh. La configuration de fail2ban est cependant pénible...

5. Obfuscation du port en changeant le port SSH. Cependant, Ce n'est PAS une bonne idée de le faire sans mesures de sécurité supplémentaires. - le mantra de la "sécurité par l'obscurité" a déjà été réfuté et contesté dans de nombreux cas. J'ai fait cela en conjonction avec les IDS/IPS et le filtrage réseau, mais c'est toujours une TRÈS mauvaise chose à faire seul.

6. Authentification à deux facteurs OBLIGATOIRE, via Solutions d'authentification à deux facteurs de Duo Security . Chacun de mes serveurs SSH est configuré avec Duo, de sorte que pour entrer, des invites 2FA apparaissent et je dois confirmer chaque accès. (C'est la fonction la plus utile, car même si quelqu'un a ma phrase de passe ou s'introduit par effraction, il ne peut pas passer les plugins PAM de Duo). C'est l'une des plus grandes protections de mes serveurs SSH contre les accès non autorisés - chaque connexion d'utilisateur DOIT être liée à un utilisateur configuré dans Duo, et comme j'ai un ensemble restrictif, aucun nouvel utilisateur ne peut être enregistré dans le système.

Mon avis sur la sécurisation de SSH. Ou, du moins, mes réflexions sur l'approche.

Vous pourriez vouloir vérifier l'application FreeOTP de RedHat au lieu d'utiliser Google Authenticator. Parfois, lors de la mise à jour de l'application, ils vous bloquent ;-)

Si vous voulez utiliser d'autres jetons matériels comme un Yubikey ou un eToken PASS ou NG ou si vous avez beaucoup d'utilisateurs ou de serveurs, vous voudrez peut-être utiliser un backend d'authentification à deux facteurs opensource.

Dernièrement, j'ai écrit un comment faire à ce sujet .