Je suis tombé sur une
discussion il y a trois mois sur la nécessité de porter le port SSH. De nombreux participants à la discussion sont convaincus qu'il n'est pas nécessaire de transférer le port vers un port non standard.
Il suffit de passer à l'autorisation de clé et d'installer Fail2ban, et ce sera déjà une garantie de sécurité. Malheureusement, nous vivons dans un monde réel et en constante évolution et les mesures de sécurité proposées ne sont plus toujours suffisantes.
Voyons voir - l'autorisation de clé a laissé deux clés ssh relativement sécurisées - RSA-4096 et ED25519, les clés DSA ne sont plus incluses dans les dernières versions d'OpenSSH. Dans ce cas, il faut tenir compte de la présence sur Internet de quelques doutes sur la fiabilité de l'ED25519, Google pour aider, si quelqu'un est intéressé.
En plus des clés, une phrase de passe assez longue est recommandée pour vos clés à partir de caractères aléatoires dans des cas et des numéros différents, au moins.
Attaques par force brute - voyons brièvement ce qui se passe si votre hôte est attaqué à dessein.
Étape 1 - collecte d'informations sur l'hôte, y compris les ports ouverts
Cette collecte d'informations est loin d'être toujours reflétée dans vos journaux, par exemple, l'analyse des ports peut aller sans établir de connexion. Fail2ban est inutile ici, il ne fonctionne que sur les entrées de journal. Au premier stade, les systèmes de protection installés peuvent également être surveillés. Par exemple, le nombre de tentatives d'autorisation avant le blocage, le temps de blocage est déterminé.
Étape 2 - tente d'accéder au système en piratant SSH
Des botnets avec des milliers d'adresses sont utilisés pour le piratage, et l'analyse dans le cas simple va contourner les paramètres par défaut de Fail2ban à partir de centaines et de milliers d'adresses, avec une analyse sérieuse prenant en compte les paramètres du système de protection des victimes. Fail2Ban est également inutile ici, surtout si SSH est sur le port 22 et que les paramètres Fail2Ban sont laissés par défaut.
Sur mon périmètre externe de l'un des serveurs, tous les ports sont fermés, mais dans quelques jours, plusieurs milliers d'hôtes tentent d'établir une connexion avec des ports standard. De plus, l'analyse prend en compte les protections possibles, les paquets d'une même adresse vont, en règle générale, avec un intervalle de plusieurs minutes.
Bien sûr, Fail2ban peut être efficace pour protéger certains autres services avec des paramètres non standard pour vos hôtes et services.
Pour une raison quelconque, il semble toujours que la deuxième étape est la plus dangereuse, en fait, la première étape recherche des vulnérabilités possibles sur l'hôte, elles peuvent être beaucoup plus dangereuses qu'un simple SSH à force brute. Pourquoi casser SSH quand il y a une porte ouverte avec vulnérabilité à proximité.
En ce qui concerne le changement de port standard, il existe un récent examen
BestPractic sur la sécurité SSH , où le changement du port standard coûte 8 points, l'autorisation de clé est le premier élément et l'installation de Fail2ban ou analogues 10 points.
Les 20 meilleures pratiques de sécurité du serveur OpenSSH .
La commutation du port SSH sur non standard vous permet d'utiliser des ports standard comme piège pour le suivi des tentatives de scan et de bloquer les adresses IP reçues pendant longtemps et pour tous les ports, c'est 11 points dans l'article BestPractic. Naturellement, il est nécessaire de spécifier des adresses blanches afin de ne pas obtenir un verrou aléatoire, ce sont 7 et 8 points dans l'article BestPractic.
Ainsi, nous augmentons le coût de la collecte d'informations sur notre système. Les informations sur les ports ouverts coûteront plusieurs milliers d'adresses IP ou des mois pour analyser notre système. Si mon port SSH n'est pas connu de l'attaquant potentiel, même si une vulnérabilité apparaît, il ne pourra pas l'utiliser.