Intérêt du changement de port SSH

Pause Café
#1

Bonjour à tous,

Je viens de lire un article relativement intéressant intitulé “Pourquoi faire écouter SSH sur un autre port que 22 est une mauvaise idée” : adayinthelifeof.nl/2012/03/ … -bad-idea/ (en anglais)

L’article manque un peu d’objectivité (l’auteur est à la limite d’attaquer les personnes au lieu du principe), mais les argumnents sont quasiment tous bons. Je citerais :
[ul][li] changer le port d’écoute est de la sécurité par l’obfuscation (là, je ne suis pas d’accord, le port d’écoute n’est pas caché, il est juste mis hors d’atteinte des script kiddies) ;[/li]
[li] ça enquiquine le monde de devoir toujours préciser le port de destination (pas d’accord, enquiquiner le monde pour de la sécurité, c’est valable, et il y a des moyens d’automatiser ça) ;[/li]
[li] le port 35666 est souvent bloqué par les entreprises / cybercafés ou autres, rendant impossible la connexion au serveur SSH (le port 22 est lui aussi souvent bloqué) ;[/li]
[li] les attaques sur le port 22 sont des attaques automatisées à deux balles, et une sécurité correcte (authentification par clef publique, pas de root login, fail2ban et une surveillance des logs) suffit à contrer les attaques basiques, alors qu’une attaque réussie serait aussi passée sur un autre port que le 22 (c’est un argument pour dire qu’il n’est pas intéressant de déplasser le port, mais pas que c’est une mauvaise idée) ;[/li]
[li] les ports en-dessous de 1024 demande les droits root pour être ouverts, rendant difficile, en cas d’intrusion avec des droits restreints, de créer un processus qui imite SSH pour capturer les données envoyées par l’utilisateur (c’est cet argument qui m’intéresse, et le seul que je trouve vraiment valable).[/li][/ul]

Qu’en pensez-vous ?
Dans un autre fil, mimosa m’a parlé de SSLH, mais l’objectif est différent. Je parle ici uniquement de déplacer le port d’écoute de SSH vers un autre port (supérieur à 1024). J’ai cherché un fil à ce sujet dans le forum, mais n’en ai pas trouvé. C’est certainement une question déjà traitée de maintes fois, alors pardonnez mon potentiel re-post.

J’attends vos arguments :slightly_smiling:
A+
Duna

#2

Je suis d’accord avec lui et ne change pas le port ssh. Mettre un serveur ssh derrière un https permet de contourner quelques parefeux. Pour fail2ban, cf virus-t52037-25.html#p517409

#3

Même si je suis en accord avec le principe de laisser un service sur son port dédié il faut avouer que déplacer ssh sur un port élevé procure une tranquillité sans égal.
J’ajoute également que fail2ban ne fait pas dans la sécurité, c’est juste une sourdine.

#4

bonsoir.

depuis des années j’utilise ssh sur un port déporté avec un mot de passe à rallonge ne figurant dans aucun dictionnaire,composé de caractères spéciaux,de combinaisons de touches et de chiffres et mes logs n’ont jamais relevé de tentatives d’intrusions ni d’attaques en force brute.A1lors que sur le port 22 c’était plutôt agité mais toujours blindé.Je crois que la sécurité consiste essentiellement dans la solidité du mot de passe (quand on utilise pas de clés)et bien sûr “PermitRootLogin no”

#5

Merci pour vos réactions. Pour le moment, j’ai remis SSH sur le port 22 en suivant la logique de l’auteur (et de François). Le force-brute, ça ne me fait pas peur, j’ai désactivé la connexion par mot de passe. Par contre, l’usurpation du service SSH, ça me fait plus peur ^^

Et merci pour l’info sur fail2ban François. Je prenais vraiment ce service comme une sécurité en plus, mais je me fourrais le doigt dans l’œil :116

#6

Perso je n’utilise jamais le n° de port conventionnel. J’ai juste une règle qui me permet rapidement de savoir qui fait quoi sur quel port. en sécu il faut être ou on t’attend pas :033

#7

Les avis divergent sur la question, pour compléter l’article que tu as déjà lu, j’avais relevé :

Et un article du Linux Journal sur les basiques de la sécurisation d’SSH : linuxjournal.com/content/tighten-ssh

#8

Merci pour tes liens seb-ksl :slightly_smiling:

Par contre, tes deux derniers liens sont les même. Il manque l’article du journal Linux.

#9

Woups, c’est édité !

#10

Hum, c’est de l’obfuscation ça, non ?

#11

On peut en faire plein comme ça, je préfère les 7 samourais avec «Toute forteresse doit présenter une faiblesse pour savoir où l’ennemi va frapper.», etc.

#12

J’aime beaucoup ^^

#13

Il n’y a pas d’intérêt concret à changer le port du démon SSH, sinon faire chier les utilisateurs (qui doivent configurer spécialement ssh, ou se faire suer avec les -p et les -P qui changent pour ssh et scp)

Tu utilises des clefs SSH, tu installes fail2ban, tu te rends compte que l’intrusion ne peut se faire que via brute force.
Tu considères la chance nécessaire pour bruteforce avec un fail2ban, tu te rends compte que l’ajout d’une variable supplémentaire (le port, 65k valeurs possibles) ne change rien.
Et comme tu es gentil, tu ne fais pas souffrir tes utilisateurs gratuitement.

Ou alors, tu es sadique et névrosé, et tu écrit un cron pour changer le port à interval régulier avec un algo deterministe, afin de faire chier le plus de monde de la manière la plus efficace possible
Chacun sa méthode :079

#14

[quote=“haleth”]Il n’y a pas d’intérêt concret à changer le port du démon SSH, sinon faire chier les utilisateurs (qui doivent configurer spécialement ssh, ou se faire suer avec les -p et les -P qui changent pour ssh et scp)

Tu utilises des clefs SSH, tu installes fail2ban, tu te rends compte que l’intrusion ne peut se faire que via brute force.
Tu considères la chance nécessaire pour bruteforce avec un fail2ban, tu te rends compte que l’ajout d’une variable supplémentaire (le port, 65k valeurs possibles) ne change rien.
Et comme tu es gentil, tu ne fais pas souffrir tes utilisateurs gratuitement.

Ou alors, tu es sadique et névrosé, et tu écrit un cron pour changer le port à interval régulier avec un algo deterministe, afin de faire chier le plus de monde de la manière la plus efficace possible
Chacun sa méthode :079[/quote]

Le port knocking est aussi un moyen assez marrant de faire chier le monde tout en permettant d’activer le port SSH quand il est utile, mais adieu l’IPV6 dans ce cas là :whistle:

#15

Pour le coup du port non privilégié, pour mettre un service qui imiterait SSH, il faut que SSH ne soit pas déjà en écoute sur le port. Ça reste possible si sshd crashe, mais c’est assez rare.
Par ailleurs, il faudrait faire l’attaque lors de la première connexion, sinon le client va signaler qu’il ne reconnait pas la clé.
Là où ça peut être drôle, c’est de mettre un service de ce type sur un serveur ou SSH est sur le port 22, et écouter ceux qui se connectent sur un port non privilégié par habitude.

Pour le reste, je suis tout de même d’accord avec l’article : changer le port ça n’arrêtera que les stupides bots (un attaquant un peu motivé trouvera le port SSH d’un coup de nmap) et il y a d’autres moyens de les contourner (mots de passe robustes et/ou authentification par clé + fail2ban pour soulager le service et les logs).

#16

Perso en externe le port 22 est bloqué, mais ouvert sur le réseau interne. Quand j’accède depuis l’extérieur je passe par le 443 avec sslh.

Et du coup tu vas le repérer plus vite s’il fait un scan de ta machine, tu lui bloque tous les accès et il ne trouvera pas tout de suite le bon port pour le ssh.

Changer le port est intéressant si l’on met en place tout une batterie de défense, déplacer le port pour juste déplacer le port comme il est recommander dasn les manuel je ne trouve pas ça très pertinent. Mais si tu déplace le port en mettant un IDS en place, tu force l’attaquant a faire plus d’opérations ce qui te permet de le détecter et bloquer plus en amont. Pour moi c’est là l’intérêt ; ralentir l’attaquant pour te laisser le temps de l’identifier et le bloquer.

#17

[quote=“haleth”]Il n’y a pas d’intérêt concret à changer le port du démon SSH (…)
tu te rends compte que l’intrusion ne peut se faire que via brute force.[/quote]
Ou via l’exploitation d’une faille 0-day dans sshd. En utilisant un port non standard, on se donne une chance supplémentaire d’échapper au ratissage automatique.

#18

PascalHambourg, je suis moyennement convaincu par ton argument. La sécurité restante dans le cas que tu présentes est de la pure chance. (Tu le dis toi-même.)
Je préfère me baser sur des éléments sûrs (comme la séparation des droits). Si quelqu’un parvient à se connecter à mon serveur, il se retrouve avec un accès qui ne permet que de changer d’utilisateur via su (et grâce à un mot de passe, évidemment). Dans le cas d’un 0-day simultanné dans su ou sh permettant l’escalade de privilèges, c’est sûr que ça gêne un peu. Mais là, on frôle la catastrophe internationale.

#19

Je parle d’une bonne grosse faille 0 day qui permet de faire exécuter du code arbitraire à sshd (qui tourne en tant que root), pas d’ouvrir une session en tant qu’utilisateur quelconque en contournant l’authentification.

#20

Un intérêt que j’y vois c’est qu’on évite de pourrir ses logs avec des dizaines de milliers de lignes à cause des bots qui tentent des attaques à l’aveugle.

Un autre intérêt étant qu’on n’est jamais à l’abri d’une faille pas encore patchée (faille 0-day ou parce que le système ne s’est pas encore mis à jour, quelques minutes peuvent suffire pour se prendre un vers) et qu’on se laisse un sursit au cas où.

Enfin, tout le monde n’est pas expert en sécurité et ça reste une bonne précaution à prendre pour commencer.

Pour conclure, à défaut d’augmenter la sécurité du système en tant que telle, ça ralentit a minima les attaquants car ils doivent scanner tous les ports pour trouver le bon. Si on est la cible particulière d’un pirate, évidemment qu’il ne lui faudra pas beaucoup de temps. Mais si le pirate scanne des IP à l’aveugle sur le port 22 (quitte à vouloir ensuite attaquer SSH manuellement, ce qui fait tomber l’argument des bots qui utilisent des attaques merdiques), alors on passe à travers. Avec plus de 65.000 ports, il doit scanner jusqu’à 65.000 fois plus de ports, ce qui le ralentit jusqu’à 65.000 fois (en moyenne ce sera donc 65.000 / 2 = 32.500 fois). Ce n’est vraiment pas négligeable ! S’il lui faut habituellement 1 min pour trouver un port 22 ouvert, il lui faudra 541h, soit 23 jours pour le même résultat…

Selon moi c’est donc une bonne habitude à prendre. Il y a quelques inconvénients, mais comparé aux avantages je trouve que ça vaut le coup. Ceci étant dit, il est clair que ça ne sert strictement à rien si on est face à un pirate qui a décidé d’avoir la peau de notre machine. Mais au moins on écume une très grosse partie du trafic potentiellement dangereux. Rien que pour les logs, yabon.