Réponses:
Cela n’est pas aussi utile que le prétendent certaines personnes, mais au moins, cela réduira au minimum l’impact sur vos fichiers journaux, car de nombreuses tentatives de connexion brutale utilisent uniquement le port par défaut au lieu d’analyser pour voir si SSH écoute ailleurs. Certaines attaques vont rechercher SSH ailleurs, alors ce n’est pas une solution miracle.
Si votre serveur doit être un hôte partagé, plutôt que de simplement répondre aux besoins de vos projets, l’utilisation d’un port autre que celui par défaut peut s'avérer difficile, car vous devrez l'expliquer encore et encore à vos utilisateurs. terminé quand ils oublient et que leurs programmes clients ne parviennent pas à se connecter au port 22!
Un autre problème possible avec SSH sur un port non standard est le cas où vous rencontrez un client avec un ensemble de filtres sortant restrictif, qui ne peut pas se connecter à votre port personnalisé car son filtre autorise uniquement, par exemple, les ports 22, 53 et 80. et 443 comme destination pour les nouvelles connexions sortantes. Ceci est rare, mais certainement pas inouï. De même, certains FAI peuvent voir le trafic chiffré sur un port autre que ceux sur lesquels il est généralement prévu (port 443 ou HTTPS, 22 pour SSH, etc.) comme tentative de masquage d'une connexion P2P et limitation (ou blocage) la connexion de manière incommode.
Personnellement, je garde SSH sur le port standard pour plus de commodité. Tant que les précautions habituelles sont prises (mot de passe fort / stratégie de clé, restriction des connexions à la racine, ...), il n’ya pas lieu de s’inquiéter et le problème de croissance du fichier journal lorsque vous êtes victime d’une attaque par force brute peut être atténué à l’aide d’outils tels que en tant que fial2ban pour bloquer temporairement les hôtes qui fournissent un trop grand nombre de mauvais identifiants d'authentification dans un laps de temps donné.
Quel que soit le port que vous avez choisi, si vous vous éloignez de 22, assurez-vous qu'il est inférieur à 1024. Sous la plupart des configurations de type Unix-a-a dans leur configuration par défaut, seuls les utilisateurs racine (ou les utilisateurs du groupe racine) peuvent écouter sur les ports inférieurs à 1024, mais tout utilisateur peut écouter sur les ports les plus élevés. L'exécution de SSH sur un port supérieur augmente le risque qu'un utilisateur malhonnête (ou piraté) parvienne à bloquer votre démon SSH et à le remplacer par son propre proxy ou par un autre.
C'est une forme simple (mais étonnamment efficace) de sécurité par l'obscurité .
Si votre serveur SSH n'est pas sur le port 22, les personnes qui parcourent Internet tout entier sont moins susceptibles de trouver des mots de passe faibles pour les comptes par défaut. Si vous analysez tout le réseau, vous ne pouvez pas vous permettre de vérifier tous les 64k ports possibles pour trouver le serveur SSH.
Cependant, si quelqu'un vous cible activement, cela ne présente aucun avantage, puisqu'un simple nmapbalayage unique révélera le port sur lequel il est exécuté.
Pour vraiment éviter les attaques par force brute, il est toujours important de suivre certaines étapes:
Oui, c'est utile car cela permet d'éviter les attaques par force brute et de garder les journaux clairs :)
en ce qui concerne le numéro de port qui vous appartient, j’ai vu des entreprises en utiliser 1291 assez souvent. J'utilise quelque chose de plus élevé, juste pour éviter certains scripts.
Ne pas autoriser les connexions root ssh et changer le numéro de port et peut-être quelque chose comme fail2ban et vous devriez être en or. ajoutez iptables pour faire bonne mesure et tenez-vous au courant, vous ne devriez pas avoir de problèmes.
L'utilisation d'un port ssh non standard nécessiterait davantage d'explications et de documentation, et la réponse aux courriers électroniques "Je ne peux pas me connecter".
Je considère que les avantages suivants de l'exécution de sshd sur un port non standard sont plus importants que les problèmes qu'il crée:
De plus, si vous voulez être vraiment méchant, vous pouvez toujours exécuter un faux sshd (avec DenyUsers * ) sur le port standard 22, alors que votre sshd habituel fonctionne sur le port 54321. Cela vous assurera que tous les robots et les intrus faramineux resteront à jamais. essayez de vous connecter à un service qui refuse toutes les connexions, car personne ne songe à essayer de trouver votre vrai service sshd.
Mes 2 centimes
Faire cela pour une raison de "sécurité" est faux. C'est le meilleur exemple de sécurité par obscurité qui n'est pas sécurité.
Si vous voulez garder vos journaux un peu plus légers et plus propres, alors oui, c’est utile, car vous n’obtiendrez pas autant de tentatives de frappe de port / script-kiddy bruteforce.
Parce qu'il y a beaucoup de personnes mal intentionnées qui analysent toutes les adresses IP de serveur à la recherche de ports ouverts dans le but d'exploiter. J'avais des attaques de marteau sur mon port SSH toute la journée, jusqu'à ce que je le déplace sur un autre port et sur une adresse IP qui n'était plus liée à aucun de mes sites Web.
C'est utile en ce que les script-bots qui tentent des attaques par force brutale de deviner le mot de passe se concentrent généralement sur le port 22, donc changer les ports les jette généralement. Vous devrez équilibrer la valeur d'atténuer ce risque avec la difficulté de configurer les clients ssh pour qu'ils se connectent au port non standard (ce n'est pas très pénible si de nombreux utilisateurs ne se connectent pas, il est vrai).
Vous pouvez également limiter le risque de force brute en désactivant l'authentification par mot de passe et en exigeant une authentification par clé RSA.
En général, je ne change pas le port sur SSHD, je ne peux donc pas suggérer un autre numéro, mais consultez la liste des ports couramment utilisés pour trouver un autre numéro (c'est-à-dire un numéro qui n'est pas utilisé par autre chose et qui pourrait donc être scanné). .
Je change toujours mon disque SSH pour utiliser le port 2222, tout le monde qui aurait besoin d'entrer dans mes serveurs le sait et ce n'est pas un secret. Cela n'apporte absolument aucun gain de sécurité (à moins que le pirate informatique potentiel ne soit un imbécile absolu).
Le seul avantage que je tire de cela est que le journal d'authentification n'a pas un million de tentatives de connexion infructueuses pour 'root', 'alice', 'bob', 'sally', 'admin', etc.
La sécurité par l’obscurité s’est avérée inutile. En général, je configure l’accès ssh avec le port standard pour toutes les raisons mentionnées ci-dessus (problèmes de client lors de la reconfiguration, problèmes de pare-feu et de proxy, etc.).
En plus de cela, je désactive toujours les identifiants root et les authentifications par mot de passe et, en dernier lieu, j'utilise fail2ban pour me débarrasser de ces messages gênants dans le syslog. Dans Debian / Ubuntu, c'est aussi simple que de taper aptitude install fail2ban. La configuration par défaut fonctionne plutôt bien, mais je règle généralement certains paramètres pour qu'ils soient plus restrictifs, avec un délai d'interdiction plus long (au moins un jour) et seulement deux tentatives d'authentification ayant échoué comme déclencheur de l'interdiction.
Je dirais que la chose contre laquelle vous vous protégez le plus lorsque vous changez le port SSH sont des analyses automatisées qui tenteront d’obtenir un accès en utilisant des noms d’utilisateur / mots de passe standard. Si vos règles de mot de passe sont strictes, vous ne devriez pas avoir à vous soucier de leur.
Si vous désactivez les connexions par mot de passe sur votre serveur (ce qui est vivement recommandé), la modification du port SSH est totalement inutile. En désactivant les connexions par mot de passe (et en exigeant une authentification basée sur une clé), vous éliminez la possibilité de tentatives de mot de passe brutales. Vous ne gagnez donc rien en utilisant des numéros de port.
Si vous continuez à autoriser l'authentification par mot de passe, vous vous exposez à la possibilité d'une tentative de force brute réussie ou - plus communément, d'après mon expérience - votre mot de passe est compromis parce que vous le tapez lors de l'utilisation d'un système en cours d'exécution. un keylogger.
man ssh-keygenpour beaucoup d'informations.
Pas une réponse, mais trop longue pour un commentaire, je vais donc faire cette CW.
Je réfléchis à celui-ci depuis un moment et j'en suis venu à la conclusion qu'il y a beaucoup de vérité dans ce que Juliano dit dans les commentaires sur la réponse d'Alnitak. Néanmoins, je trouve qu'en exécutant SSH sur le port 22, il est beaucoup trop facile de lancer des attaques de toutes sortes contre celui-ci.
Pour résoudre ce problème, j'exécute mes serveurs SSH internes sur le port 22 et utilise le pare-feu pour transférer le port haut sur 22 sur les ordinateurs cibles. Cela donne une certaine sécurité grâce à l'obscurité tout en maintenant la sécurité d'un port bas, comme l'a souligné Juliano.
La sécurité par l'obscurité n'est pas un principe auquel je souscris normalement et il est souvent souligné qu'un simple scan de port révélera le port cible, rendant ainsi l'obscurité sans valeur. Pour résoudre ce problème, mes pare-feu (Smoothwall Express), au travail et à la maison, utilisent un script appelé Guardian Active Response, déclenché par des alertes Snort. D'après les observations, je peux vous dire que lorsque vous frappez plus de 3 ports différents de la même source, vos paquets sont perdus jusqu'à l'heure de réinitialisation prédéfinie. Cela rend assez difficile et prend beaucoup de temps pour exécuter une analyse de port, rendant l'obscurité vraiment utile. En fait, cela m'a fait taire tellement de fois dans le passé que j'ai défini une exclusion pour mon adresse IP source (à la maison ou au bureau).
Le problème que vous avez, c'est que le pare-feu est configuré pour autoriser uniquement certaines adresses IP à se connecter, et le patron en a assez d'ouvrir d'autres adresses IP lorsqu'il est en déplacement. Si vous verrouillez certaines adresses IP au niveau du pare-feu, cela peut être pénible.
Deux choses que je pense ici. Changer le port protège contre les attaques automatisées. C'est à peu près tout, mais cela représente une grande partie du trafic d'attaque moyen… des scripts automatisés analysant les réseaux. Si vous modifiez le port par défaut, ces attaques devraient disparaître. Cela a donc du sens à cet égard. Mais cela ne fait rien contre une attaque dirigée, l’attaquant pouvant simplement scanner à partir de Nessus ou de NMAP pour déterminer le ou les ports que vous utilisez si vous avez un petit ami spécial qui vous hait suffisamment.
Deuxièmement, si vous utilisez des serveurs de type UNIX, vous pouvez installer un utilitaire tel que Denyhosts pour arrêter les attaques. Si vous installez denyhosts, il surveille les tentatives de connexion incorrectes et après (quel que soit le nombre que vous déterminez) a échoué, il interdira l'IP pendant une période de temps que vous spécifiez. Denyhosts peut également parler à d'autres hôtes de denyhost et transmettre des listes d'interdiction. Ainsi, si un attaquant est verrouillé hors du système Linux de Fred au Montana, votre système obtiendra également cette adresse IP pour interdiction. Très utile tant que vos utilisateurs se souviennent de leurs mots de passe.
Tout dépend de vos scénarios d'utilisation. Combien de programmes avez-vous qui sont "pénibles" pour changer le port de connexion pour SSH / SCP (et s’ils ne le permettent pas ou ne gênent pas, vous devez vraiment envisager de changer de fournisseur, personnellement). S'il ne s'agit que d'une peur potentielle, je dirais que ce n'est pas un problème. Et voici votre patron, qui demande quelque chose qui n’est pas complètement farfelu, car beaucoup d’administrateurs système basculent le port SSH (avec un flak de ceux qui détestent tout ce qui sent la sécurité même à travers l’obscurité ... mais cela réduit vraiment la le bruit de fond cruft des balayages automatisés.)
En bouleversant - changer les ports bloque les scripts automatisés et la plupart du trafic. Ne pas arrêter les attaquants dirigés. Pensez également à installer un utilitaire d'interdiction automatique. La sécurité dans les couches ne vous fait pas mal si c'est bien fait et changer de ports aide plus que ça fait mal dans la plupart des situations.
J'utilise SSH sur le port> 1024 depuis plus de 5 ans maintenant. Depuis lors, je n'ai vu aucune tentative d'analyse de port dans mon fichier journal (sauf de ma propre initiative). Il y a mes serveurs que j'administre qui utilisent le port> 1024.
Beaucoup de serveurs SSH qui fonctionnent sur le port> 1024 ont leurs propres sites Web, ce qui est assez populaire.
Si le serveur SSH fonctionne dans ma propre entreprise, j'ai peut-être déjà posté l'adresse IP de ce serveur ici afin que vous puissiez essayer de pirater le serveur. Malheureusement, le serveur SSH n'est pas le mien. ;-)
Mais il y a d'autres choses que vous devez configurer pour le rendre sécurisé. SSH> 1024 ne suffirait pas. Le numéro de port ne doit pas être dans le fichier / etc / services, il faut utiliser le transfert de port (par exemple, le port 1124-> 22), l'accès direct à la racine doit être désactivé et autre.
Donc, si vous voulez vous disputer, utilisez SSH sur le port> 1024 pendant quelques années.
p / s: 1124 n'est pas mon numéro de port SSH. Haha.
Bien déplacer SSH vers un autre port n'a pas de sens, cela contribue à la sécurité mais pas énormément. Bien sûr, pour ce faire, vous devez contrôler vos pare-feu, mais ce n’est pas un problème pour vous. Ce qui annule l’avantage de déplacer le port, c’est l’ouverture de la gamme acceptée. En fait, je dirais qu’elle annule l’avantage et vous expose plus loin que ce que vous êtes aujourd’hui. Je suis sûr que vous pouvez le convaincre de déplacer le port ET de réduire considérablement la plage entrante en compilant une liste de points d'entrée probables au lieu de simplement les ouvrir.
Changer de port ssh est un exercice inutile qui ne vous rapporte qu'une sécurité limitée. Il vaut mieux désactiver simplement l’authentification par mot de passe, ce qui élimine le risque de tentatives de mot de passe brutales, et se fier exclusivement à l’authentification basée sur la clé ssh. Si votre environnement nécessite une authentification par mot de passe, adoptez un mécanisme à deux facteurs, tel que SecurID ou Wikid.
Ces deux solutions vous apportent une réelle augmentation de la sécurité, tandis que la modification du port ssh ne vous donne que l’illusion de sécurité.
C'est pratique: j'ai utilisé des serveurs ssh privés publiquement visibles pendant plus de quatre ans avec un port SSH modifié et je n'avais aucune tentative d'analyse de mot de passe. Par souci d’assurance qualité, je viens d’activer 22 l’un d’entre eux pour une journée. En conséquence, j'ai été scanné environ toutes les 10 minutes avec une fréquence de tentative de mot de passe d'environ 5 par seconde. De plus, "scan kiddies" recherche également des serveurs avec certaines vulnérabilités OpenSSH.
Bien sûr, c’est la sécurité par l’obscurité qui n’aide en rien si vous avez l’ennemi.
Cela fonctionne très bien, indépendamment des gémissements de la foule "sécurité par l'obscurité".
Lapins stupides, TOUTES la sécurité est la sécurité à travers l'obscurité. Ce n'est pas parce que vous croyez que l'obscur protocole de cryptographie Z [nécessitant une combinaison d'échantillons d'ADN, de clés partagées et impossible à saisir avec des mots de passe humains] est réellement sécurisé. La vérité est que toute mesure de sécurité repose sur des probabilités et des hypothèses formulées par les utilisateurs. Tant pis pour vous si je sais comment exploiter cette hypothèse, mais voilà.
En tous cas,
Nous le faisons depuis des années, avec a) un nombre limité de tentatives de connexion (cependant, je ne sais pas comment nous l’avons configuré, quelque chose dans la configuration ssh), et b) un script pour interdire tout hôte exécutant une attaque par dictionnaire avec plus de X devine mal en Y minutes. Nous interdisons à l'hôte d'établir la connexion pendant un certain temps, ce qui facilite son adaptation à la topologie des réseaux en évolution.
Si vos mots de passe sont suffisamment complexes et qu'ils ne peuvent faire que 3 tentatives en 15 minutes, il n'y a pas grand chose à craindre. Il n’est pas si difficile de surveiller les attaques distribuées, nous le faisons habituellement par sous-réseau et ip pour exclure ce genre de chose.
Enfin, tout ce dont vous avez besoin, c’est d’une méthode secrète en écureuil pour permettre les connexions à votre port en modifiant les règles f / w. Cela peut être n'importe quoi ... smtp, web, requêtes dns magiques. Des produits tels que SecurID ou Wikid donnent simplement plus d’informations à des tiers. Et ne me lancez pas sur des certificats sécurisés par des tiers.