Dois-je changer le port SSH par défaut sur les serveurs Linux?
Y a-t-il un avantage à changer le port SSH, j'ai vu des gens le faire, mais je n'arrive pas à trouver la raison.
Si vous avez un mot de passe fort et/ou un certificat, est-il utile pour quelque chose?
Éditer:
Je dois également mentionner que j'utilise des règles iptables pour limiter les attaques par forçage brut, seules 5 tentatives de connexion sont autorisées par minute et par adresse IP.
Internet est un endroit sauvage et effrayant, plein de mécontents dont les motivations vont de la curiosité à l'entreprise criminelle. Ces désavantages recherchent constamment des ordinateurs exécutant des services qu'ils espèrent exploiter; généralement les services les plus courants tels que SSH, HTTP, FTP, etc. Les analyses se classent généralement dans l'une des deux catégories suivantes:
- Recon scanne pour voir quelle adresse IP ces services sont ouverts.
- Exploiter les analyses contre les adresses IP qui se sont avérées exécuter un service spécifique.
Compte tenu de la taille d'Internet, il est généralement impossible de regarder sur chaque port de chaque adresse IP pour trouver ce qui écoute partout. C'est l'essentiel des conseils pour changer votre port par défaut. Si ces individus mécontents veulent trouver des serveurs SSH, ils commenceront à sonder chaque adresse IP sur le port 22 (ils peuvent également ajouter des alternatives courantes telles que 222 ou 2222). Ensuite, une fois qu'ils auront leur liste d'adresses IP avec le port 22 ouvert, ils commenceront leur force brute de mot de passe pour deviner les noms d'utilisateur/mots de passe ou lanceront leur kit d'exploitation de choix et commenceront à tester les vulnérabilités connues (au moins pour eux) sur le système cible.
Cela signifie que si vous changez votre port SSH en 34887, ce balayage vous passera, ce qui vous empêchera probablement d'être ciblé par le rodage de suivi.
Semble rose à droite? Il y a cependant quelques inconvénients.
- Support client: toute personne qui se connecte à votre serveur devra connaître et utiliser le port modifié. Si vous êtes dans un environnement fortement géré, cette configuration peut être transmise aux clients, ou si vous avez peu d'utilisateurs, elle devrait être facile à communiquer.
- Exceptions de la documentation: la plupart des périphériques réseau, tels que les pare-feu et les IDS, sont préconfigurés pour que les services communs soient exécutés sur des ports communs. Toutes les règles de pare-feu liées à ce service sur cet appareil devront être inspectées et éventuellement modifiées. De même, les signatures IDS seront modifiées afin de n'effectuer l'inspection SSH que sur le port 22. Vous devrez modifier chaque signature, à chaque mise à jour, avec votre nouveau port. (En tant que point de données, il existe actuellement 136 signatures de snort VRT et ET impliquant SSH).
- Protections du système: les Linux modernes sont souvent livrés avec des systèmes MAC et/ou RBAC de couche noyau (par exemple SELinux sur RedHat ou AppAmor sur Debian) et qui sont conçus pour permettre uniquement aux applications de faire exactement ce qu'elles sont censées faire. Cela peut aller de l'accès au
/etc/hostsfichier, pour écrire dans un fichier spécifique ou envoyer un paquet sur le réseau. Selon la configuration de ce système, il peut, par défaut, interdire àsshdde se lier à un port non standard. Vous auriez besoin de maintenir une politique locale qui le permettrait. - Surveillance par une autre partie: si vous avez une division externe de la sécurité de l'information ou que vous externalisez la surveillance, alors ils devront être informés du changement. Lorsque j'effectue une évaluation de la sécurité ou analyse des journaux à la recherche de menaces de sécurité, si je vois un serveur SSH s'exécuter sur un port non standard (ou un serveur SSH sur un non-UNIX/Linux d'ailleurs), je le traite comme une porte dérobée potentielle et invoquer la partie système compromise de la procédure de traitement des incidents. Parfois, il est résolu en 5 minutes après avoir appelé l'administrateur et se faire dire que c'est légitime, auquel cas je mets à jour la documentation, d'autres fois c'est vraiment la méchanceté qui est prise en charge. En tout état de cause, cela peut entraîner des temps d'arrêt pour vous ou, au moins, un appel de nerf lorsque vous répondez à votre téléphone et entendez: "Bonjour, voici Bob du bureau de la sécurité de l'information. J'ai quelques questions à vous poser. . "
Avant de changer de port, vous devez prendre tout cela en compte afin de savoir que vous prenez la meilleure décision. Certains de ces inconvénients peuvent ne pas s'appliquer, mais certains le seront certainement. Pensez également à ce contre quoi vous essayez de vous protéger. Souvent, il est tout simplement plus facile de simplement configurer votre pare-feu pour n'autoriser l'accès à 22 qu'à partir d'hôtes spécifiques, par opposition à l'ensemble d'Internet.
Oui, ce n'est pas possible en augmentant la sécurité, mais vous pouvez réduire le nombre de tentatives de connexion infructueuses sur votre serveur. Je change toujours mon ssh par défaut pour réduire les avertissements que je reçois d'ossec. De plus, si vous utilisez un port vraiment aléatoire et que quelqu'un essaie toujours d'accéder à votre machine, il est plus probable qu'il s'agisse d'une attaque ciblée plutôt que d'un scanner aléatoire.
Comme d'autres l'ont dit, mettre SSH sur un port autre que 22 rendra plus improbable d'être touché par un scan aléatoire. Vous serez ciblé si l'attaquant tente d'obtenir votre serveur, pas n'importe quel serveur.
J'ai un serveur avec ssh lié à un port haut aléatoire. Et j'ai un pot de miel ssh sur le port 22, qui répondra à chaque tentative de connexion avec un message "accès refusé".
Je ne pense pas que ce soit un défense par obscurité, mais défense en profondeur: pour attaquer mon serveur, l'attaquant doit d'abord trouver le port. Si j'ai quelques faux pots de miel (beaucoup de ports redirigeant vers le même pot de miel), l'attaquant frappera beaucoup de faux et n'aura aucun moyen de savoir s'il a atteint le vrai ssh ou non.
Mais ce n'est que la défense. J'ai portsentry actif aussi, donc si quelqu'un essaie un scan de port, il sera bloqué pendant une heure. S'ils brutalisent le mot de passe sur le bon ssh, ils recevront "accès refusé" pendant une heure. S'ils réussissent à deviner le mot de passe, une invite PAM leur sera présentée pour demander le jeton Google Auth.
Le coût du changement de port est très faible, et je pense que les inconvénients sont justifiés par les avantages.
Puisque la plupart des gens parlent principalement de désavantages (qui sont réels), je voudrais partager plusieurs avantages ici:
vous voulez vraiment éviter les attaques automatisées. À moins que vous ne soyez un utilisateur de haut niveau, la grande majorité des attaques ne seront pas ciblées sur vous, mais des attaques automatisées au mieux qui essaieraient simplement les ports par défaut. Les éviter aide de plusieurs manières:
- vous réduisez la surface d'attaque (la plupart des attaques automatisées)
- vous réduisez votre exposition en raison de bogues dans les bibliothèques sshd ou crypto qu'il utilise
- certains bugs comme heartbleed permet d'exploiter vos serveurs simplement en se connectant à un port ouvert, même sans connaître aucun mot de passe ou clé. En utilisant des ports non standard, vous évitez cela.
- certains bogues comme clés privées faibles permettent à des attaques automatisées de 0wn sur votre serveur avant d'appliquer les correctifs. L'utilisation de ports non standard évite à nouveau ces premières vagues d'attaquants et vous donne plus de temps pour patcher.
- vous réduisez l'encombrement dans vos journaux, ce qui vous fait gagner beaucoup de temps d'administration lors de l'examen des journaux, vous permettant de concentrer vos efforts sur des attaques ciblées plus problématiques
- il offre une meilleure protection avec moins de travail que kludge que vous mentionnez dans la mise à jour (blocage d'IP après 5 connexions incorrectes - ce qui permettra certaines des attaques surtout si IP continue de changer; en particulier dans le monde IPv6 où chaque attaquant aura des milliards à épargner; et le kludge peut produire des faux positifs bloquant les utilisateurs légitimes et produisant plus d'appels de support)
- parfois, même les bons mots de passe seront compromis (via d'autres bogues ailleurs, peut-être, ou des utilisateurs imprudents qui les saisiront sur des machines enregistreuses de frappe) et stockés dans des dictionnaires utilisés pour les attaques plus tard. Encore une fois, le port aléatoire évitera la grande majorité de cette classe d'attaques automatisées (la plupart des enregistreurs de frappe n'enregistreront que les paires nom d'utilisateur/mot de passe, et n'iront pas à la recherche de ports dans les configurations).
quoi que l'attaquant ne s'attende pas, cela le désactive toujours complètement, crée plus de travail pour lui ou fait de vous une cible moins intéressante. Et cela augmente également votre temps de détection et de défense contre les attaques.
l'exécution sur le port> 1024 ne nécessite pas que sshd s'exécute en tant que root, ce qui permet de l'exécuter n'est qu'un seul utilisateur pour lequel il est nécessaire, en évitant une classe entière de bogues (vrai même lorsque certaines implémentations sshd prennent un soin particulier à s'exécuter avec des privilèges réduits lorsqu'il n'est pas nécessaire).
Je suppose que cela dépend de la vitesse à laquelle vous allez patcher votre serveur et si vous avez un type de pare-feu devant le serveur.
Si vous laissez le serveur ouvert au monde et que vous n'avez rien configuré pour vous alerter ou pour installer automatiquement les correctifs OpenSSH, je suggérerais de déplacer le serveur vers des ports aléatoires de numéro élevé.
En fin de compte, bien que le simple fait de déplacer le numéro de port ne dissuade pas tout le monde, bien sûr, cela dissuade les script kiddies qui vérifient simplement les ports 80, 22, 23, etc., mais pas si quelqu'un doit effectuer une analyse 1-65535.
Changer le port arrête uniquement les attaques automatiques contre votre SSH et certains script kiddies. Si quelqu'un vous visait, il pourrait infliger une amende au nouveau port SSH. L'avantage est qu'il arrête les tentatives de connexion infructueuses dans vos journaux. J'ai généralement quelque chose comme Logwatch et SSH sur un autre port fonctionnant avec PasswordAuthentication défini sur no dans mon sshd_config.
Comme d'autres l'ont déjà noté, la modification du port SSH par défaut ne vous apporte pas grand-chose du point de vue de la sécurité. Cependant, il peut toujours être avantageux de le faire si vous avez l'intention de vous connecter à la machine à partir d'un réseau où les administrateurs ont verrouillé le port 22. (De nombreuses écoles, lieux de travail et hotspots WiFi gratuits bloquent tout le trafic sortant, sauf celui par défaut Ports DNS, HTTP et HTTPS.) Dans ce cas, changer votre port SSH en 53, 80 ou 443 (ou faire en sorte que votre routeur transfère l'un de ces ports à 22) vous permettra généralement d'accéder à votre machine lorsque vous étudiez/travaillez/en voyageant.
Dans de rares cas, ces réseaux ne bloquent pas simplement les ports, mais inspectent également le trafic pour filtrer les connexions ssh. Pour cette situation, vous devez rechercher d'autres alternatives .
Il s'agit d'une question philosophique: "le contrôle X est-il utile?" Et comme la meilleure réponse l'a souligné, vous devriez également considérer "quels sont les coûts (support client, exemptions doc, support système, support de surveillance, et je mettrais dans les coûts directs, les coûts de licence, etc.) du contrôle X?"
Tout est utile dans certains contextes. C'est une bonne idée de vous demander dans quel contexte vous vous trouvez. Parfois, le contexte est celui de la conformité - vous déployez le contrôle X pour répondre à une exigence particulière. "Je dois déplacer mon port ssh parce que la stratégie système interdit les écouteurs sur le port 22." Ensuite, faites-le, déposez une exception ou travaillez pour modifier la stratégie. [Ce serait, à mon humble avis, une politique imprudente.]
Ici, le contexte est probablement "je suis un gars au hasard, avec un hôte sur un réseau non contrôlé, et je ne veux pas perdre le contrôle de ma box." Les attaques ont toujours une phase d'enquête - si l'enquête est "envoyez un SYN sur le port 22 et voyez qui répond", alors vous vous protégez contre ce vecteur de menace spécifique. (Si l'enquête est "effectuez un balayage de port, collectez des bannières et voyez si quelque chose d'intéressant apparaît", votre contrôle est sans effet.) Mais maintenant, vous avez fait beaucoup de travail pour vous-même - si vous utilisez un outil pour vous connecter au serveur, vous devez comprendre comment travailler sur ce port non standard - et avec certains outils, cela pourrait même ne pas être possible. Dans l'ensemble, et dans ce contexte, je ne recommanderais pas de changer de port.
Un des avantages notés était la réduction des événements de journal associés aux faux positifs. En fait, je trouve ça négatif! Le flux constant d'attaques entrantes sur le port 22 peut en fait être utile - si elles s'arrêtent, vous savez qu'il y a un problème avec votre flux Internet. Je pense que l'avantage perçu est faux - la bonne réponse est de régler votre système de détection d'anomalies pour filtrer les tentatives de connexion infructueuses des réseaux externes.