Sondage Quel port ouvert pour le SSH ?

Posté par  (Mastodon) . Licence CC By‑SA.
Étiquettes :
7
20
sept.
2022
  • TOC ! TOC !
  • Qui est là ?
  • C'est moi
  • Prouve-le !

Pour entrer dans votre domaine depuis les Internets sauvages et hostiles, quel port utilisez-vous pour votre service SSH ?

  • 22, parce c'est le standard :
    772
    (43.7 %)
  • 22, mais avec du port knocking pour le réveiller :
    48
    (2.7 %)
  • 2222, mais chuuut c'est un secret :
    124
    (7.0 %)
  • 443, pour contourner les proxy d'entreprise :
    87
    (4.9 %)
  • 993, le 443 est déjà utilisé pour HTTPS :
    13
    (0.7 %)
  • une valeur random, pour la sécurité :
    231
    (13.1 %)
  • une combinaison de tout ça, je détaille dans les commentaires :
    38
    (2.2 %)
  • aucun, je n'ai pas de SSH ouvert :
    169
    (9.6 %)
  • 23, SSH est trop risqué, je reste sur Telnet :
    57
    (3.2 %)
  • 65536, je n'ai encore détecté aucune tentative d'intrusion :
    61
    (3.5 %)
  • 3615, car j'utilise un minitel comme terminal :
    167
    (9.5 %)

Total : 1767 votes

La liste des options proposées est volontairement limitée : tout l’intérêt (ou son absence) de ce type de sondage réside dans le fait de forcer les participants à faire un choix. Les réponses multiples sont interdites pour les mêmes raisons. Il est donc inutile de se plaindre au sujet du faible nombre de réponses proposées ou de l’impossibilité de choisir plusieurs réponses. 76,78 % des personnes sondées estiment que ces sondages sont ineptes.

  • # fail2ban

    Posté par  (site web personnel) . Évalué à 10.

    Chez moi c'est le 22 mais avec fail2ban, ce n'est peut être pas top mais ça ralentit pas mal les attaques

    S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.

    • [^] # Re: fail2ban

      Posté par  . Évalué à 3.

      Pareil, et au bout de 2 erreurs je banni 3 jours (d'ailleurs je devrais bannir à vie…)
      en cas d'erreur de ma part, j'attends de rentrer me reconnecter en direct pour unban

    • [^] # Re: fail2ban

      Posté par  . Évalué à 3.

      Ca marche comment fail2ban avec IPV6 ?
      Si quelqu'un a un /64, il peut quand même tenter pas mal de fois en changeant après chaque blocage.

  • # port 4321

    Posté par  . Évalué à 3.

    j'utilise le port 4321, mais surtout j'utilise xtables-addons et je n'autorise que les tranches ip françaises.

  • # port 22

    Posté par  (Mastodon) . Évalué à 10.

    Port 22, fail2ban, authentification par mot de passe désactivée.

    Il est plus important de désactiver l'authentication par password et passer par des clés et certificats que de changer de port. Changer de port ne fait que limiter le bruit dans les logs. J'utilise fail2ban essentiellement pour cela et pour que l'ip qui fait ces tentatives soit aussi bannie des autres ports réseaux.

    • [^] # Re: port 22

      Posté par  . Évalué à 4.

      Même si ce n'est pas un gage de sécurité, ça permet d'éliminer la grande majorité des bots qui font que du 22. Si c'est pour recevoir 15 mails f2b par jour, pi au final ne plus en lire aucun, et passer à côté d'un truc important.

    • [^] # Re: port 22

      Posté par  (site web personnel) . Évalué à 6.

      Et changer de port, c'est aussi le risque de se faire bloquer par un parefeu mal luné.

    • [^] # Re: port 22

      Posté par  (Mastodon) . Évalué à 0.

      clés et certificats?

      avec des certificats, il faut donc se les "trimbaler", peut etre en les stockant dans un endroit virtuel?

      avec des clés, comme pour valider un virement?
      car jme vois très mal me trimballer un papier sur moi (ni un doc')

      l'énorme avantage du pass, c'est qu'il est dans la tete..

      • [^] # Re: port 22

        Posté par  . Évalué à 4.

        Je conserve une copie de sauvegarde de la clé privée sur le serveur, qui est chez un hébergeur.
        Comme ça si je perds ma clé privée locale, je n'aurais qu'à me connecter au serveur pour retrouver la clé privée qui me permet de me connecter de… oh… flûte!

        • [^] # Re: port 22

          Posté par  . Évalué à 3.

          Certains hébergeurs proposent une console d'urgence accessible depuis leur site web.

    • [^] # Re: port 22

      Posté par  (Mastodon) . Évalué à 1.

      hello

      le port knocking :
      https://linuxfr.org/nodes/123507/comments/1902370

      aussi :

      Port 22, fail2ban, authentification par mot de passe désactivée.
      Il est plus important de désactiver l'authentication par password et passer par des clés et certificats que de changer de port
      https://linuxfr.org/nodes/123507/comments/1902322

      pensez pas que mettre ces quatre recommandations relatives au ssh sous une dénomination particulière (un peu comme les standardisations/labellisation) de manière à encourager et déterminer/repérer le bon réflexe pour les futurs admins?
      enfin c'est une idée qui me parait cohérente..
      d'ailleurs le "pourquoi ce n'est pas activé sur tous les linux et bsd par défaut" m'étonne aussi..

  • # 6666 !

    Posté par  (site web personnel) . Évalué à 8.

    6666, parce que les premières cartes 3G d'Orange ne laissaient passer que : FTP, TELNET, DNS, HTTP, SMTP/IMAP et… IRC.

    Ensuite, constatant que ça faisant quand même vachement moins de bruit dans les logs, j'ai gardé, par habitude.

    Mais j'ai aussi un bastion en 443 pour certains hôtels à la con.

    alf.life

  • # Port knocking !

    Posté par  . Évalué à 10.

    Le Port knocking c’est quand même super efficace. J’ai zéro tentative de connexion et zéro bruit depuis que je l’ai activé.
    Y a des solutions juste avec Iptables qui fonctionne bien sans être trop compliqué. J’utilise ICMP comme toc-toc, c’est simple et disponible sur n’importe quel système.

    Et j’ai mis un tarpit sur le port 22, ça fera les pieds à ces scanneurs ! https://github.com/skeeto/endlessh

    • [^] # Re: Port knocking !

      Posté par  . Évalué à 2.

      Mais du coup, t'as un seul process peu importe le nombre de tentatives de connexions sur le honeypot ?

    • [^] # Re: Port knocking !

      Posté par  . Évalué à 4.

      Je découvre le principe du port knocking grâce à ce sondage et aux commentaires et je trouve ça excellent !
      Merci pour la découverte.

  • # OTP

    Posté par  . Évalué à 4.

    Port 22 mais avec un mot de passe fort sur un compte user sans privilèges et quelque règles qui utilise de la geoip pour limiter les tentatives + un fail2ban.
    Mais je me posais la question de l'OTP. Jusqu'à présent, je l'ai jamais déployé par flemme de tester etc .. (on vieilli pfff…), mais je sais qu'il y a des implémentations.

    Y en a qui l'utilisent ici ?

    Faut pas gonfler Gérard Lambert quand il répare sa mobylette.

  • # fail2ban au moins

    Posté par  . Évalué à 4.

    Mon seul serveur accessible par tout le monde ( sans passer par un VPN) est un serveur Yunohost sans modification de la configuration ssh.
    Donc c'est effectivement un serveur avec le port 22 et avec fail2ban.

    Par contre le serveur proxmox accessible seulement via vpn et est sur un autre port que le 22 avec fail2ban et connexion avec mot de passe désactivée.

    Autre pistes d'améliorations:
    - clefs ssh / clef de sécurité
    - CrowdSec

  • # Une petite question pour les plus pro' que moi

    Posté par  (site web personnel) . Évalué à 5.

    Si on configure son serveur ssh pour accepter uniquement les connexions via échange de clés et donc pour refuser les login/mdp à l'ancienne, est-ce que ça rime vraiment à quelque chose de changer de port ?

  • # Attention publicité (mais pour un projet libre alors bon)

    Posté par  . Évalué à 5.

    J'ai codé ça un jour: https://fail2band.com/ … utile que si vous avez plusieurs serveurs, c'est auto-hébergeable, c'est libre, et si vous ne voulez pas vous prendre la tête à vous auto-héberger il y a une offre "clé en main".

    Le but est de permettre de mutualiser facilement ses ip blacklistées et de gérer tout le parc d'un coup.

    Résultat mes ssh se "couvrent" les uns les autres, un scan sur un serveur et boum quelques secondes/minutes plus tard tous les autres sont couverts. Bon le hic c'est qu'on commence à avoir des blacklistes TRES TRES longues et ça doit forcément avoir un impact !

    eric.linuxfr@sud-ouest.org

    • [^] # Re: Attention publicité (mais pour un projet libre alors bon)

      Posté par  . Évalué à 5.

      j'ai aussi une balcklist que je récupère de temps en temps du log fail2ban et que j'ajoute dans mes regles de parefeu.
      je garde la liste complete des ip dans une coin, et j'ai un petit bout de code qui les lis et fusionne dans une ip de classe supérieure à partir d'un certain nombre de classe inférieur (configurable, j'utilise 5, quand j'ai 5 ips dans la même classe qui me foutent la merde, je banni toute la classe sans pitié)
      ça réduit la taille de la blacklist.

  • # figurez vous que..

    Posté par  (Mastodon) . Évalué à 4.

    hello

    j'ai pendant quelques semaines hésité à proposer comme "journal" le fruit d'une bétise, d'un moment d'égarement ou de baisse d'attention et de prudence.

    Donc j'ai hésité quelques semaines à en faire un petit "journal" ici meme, cependant n'étant pas suffisamment "assidu" à l'exercice libriste je me suis abstenu, ayant interprété que le journal sert à l'apprentissage/pédagogie, là où mon avis sur le forum reste l'assistance, l'aide, l'accompagnement. Ce pourquoi c'est plutot sur le forum que j'ai voulu évoquer le sujet, important, mais qui reflète plutot d'un manque de bon sens ponctuel (ou d'un espoir d'utopie?) que d'une véritable leçon. Peut être des deux.

    Préambule:
    "As tu fait une sauvegarde?" <= c'est de la même augure, quand on a perdu un support de données (ou accès à un service cloud).
    J'ai été donc concerné par cette aventure quelques mois après avoir testé un OS libre non linux, et m'être viandé en lors d'une réinstallation, pensant que l'équivalent des "partitions" telles quelles (seulement réassignées à leur point de montage) allaient être épargnées. Et je m'étais planté bien comme il faut, tout ayant été effacé. J'ai perdu deux mois de boulot, je m'en suis (presque) partiellement remis (je sauvegardais les trucs importants/légers régulièrement).

    Ici, ma toute petite mésaventure est beaucoup moins grave, quoique se résume à circuler en vélo sans casque (ou surtout sans freins), en voiture sans phares… il y a quelques semaines, plusieurs mois après le premier incident résumé au § précédent, je me suis donc trouvé dans la nécessité de transférer des fichiers au travers de l'internet, via deux ordinateurs distants. Le plus simple pour moi fut d'ouvrir les ports de la box d'un de ces deux ordinateurs, ce qui me prit un petit premier temps : le second ordinateur était derrière un accès cellulaire, donc pas de redirection de port.

    Et c'est ici que le rapport avec la choucroute intervient : j'ai fait le transfert en scp. Mais bien comme un bleu hein, en me disant que cela prendrait peut etre quelques heures tout au plus ; port 22 bien comme il faut. Sauf que j'avais un peu zappé que quelques semaines avant ce transfert, j'utilisais encore dans le cadre d'une expérimentation un utilisateur test:test (moquez vous, sur pebkac certains croisaient admin:admin en AD); c'est bien mal voyez vous, sauf à titre perso sur réseau local protégé, bien que pas très prudent quand meme. Un peu comme laisser votre balcon grand ouvert l'été au huitième étage : rare seront les spiderman prêts à passer à l'action. Ben là, avec la redirection de port effective pendant quelques jours, Peter Parker s'est bien introduit dans mon ordi. Je l'ai pas détecté tout de suite, étant à distance sur l'appareil.

    Comment? tout simplement parce que l'ordi distant (via logiciel de controle) semblait lent, mais j'ai tout mis sur le dos de la petite 3/4G locale. Donc j'ai laissé faire quelques jours, n'arrivant plus à faire ce que je voulais "en face", j'ai fini par abdiquer, qu'une question de jours avant d'être de retour devant physiquement. Et c'est là que j'ai découvert l'impact de laisser un 22 ouvert sur les ternets avec un utilisateur "facile" à deviner. Je savais qu'il y a dix ans c'était très risqué mais je pensais pas que moi, petit naïf (ou flemmard), je serais dans les statistiques ciblées de ces gentils hackers, qui parient sur ma mégarde dans le sens où cela pourrait leur servir. J'ai donc fait un "top" pour comprendre, pourquoi the feck sur (maintenant) le meme réseau local que lui, il tourne toujours comme un escargot?
    .dhpcd
    La réponse tient en cinq lettres, précédées d'un point. Un processus trompeur, ogrivore, qui explose à platte coutures la consommation cpu, selon top.
    Je me dis que c'est vachement bizarre pour un process réseau, notamment à l'acronyme ébréché, je connaissais les guerres de chapelles du libre comme partout mais pas au point de nommer les process de services un vendredi soir après soixante douze heures d'uptime en codant.. Soit, je fais un tour rapide sur le net, je dégaine mon firefox et m'aperçois assez rapidement que jme suis fait bouffer, et que c'est pas du tout le réseau, mais bien l'ordi lui meme qui tourne au ralenti : ce petit malware ne sert pas à chiffrer mes données (bien que c'est une install fraiche de quelques semaines, sans données importantes dessus) mais à miner du BTC pour un autre !

    De fil en aiguille, ma petite enquête, au travers de différents forums, m'apportera une nouvelle conscience sur le port ssh, une nouvelle admiration pour ces pirates, qui m'ont surpris une fois de plus (et m'ont pas bouffé mes données), et une vision sous un autre angle d'un programme asiatique visant à faire du pognon par tous les moyens.. quels as! on croirait les cryptolockers qui bossent pour l'argent, ca paye mieux que les millenials qui se montrent en photo. Tout ca pour dire qu'au final ouvrir le port ssh sans précautions, pour avoir refait le test par la suite sur ce meme LMDE5 (réinstallé plusieurs fois depuis), les attaques sont bien réelles, surtout permanentes.

    Après coup, j'avais meme envisagé observer dans le log ssh (en faisant une sorte de pot de miel-pops "honeypot") pour relever les différentes IP et les transmettre à qui de droit (un spécialiste cyber aurait pu me renseigner), cependant leur grande quantité d'ip différentes et d'attaques à la minute font qu'il serait impossible de sourcer l'attaquant initial, passant sans doute par moult vpn et serveurs à l'étranger sous de fausses identités… ma dernière idée expérimentée fut de tenter la même sous l'os que j'estime le plus sécurisé (et pur) qu'est openbsd, je n'en ai pas trouvé le temps, bien que je doute d'un succès, à savoir si l'échec viendrait d'une incohérence d'intrusion (niveau login/pass) ou d'une incompatibilité du malware sous le diodon. Ni haiku d'ailleurs. Pendant une nuit, j'ai envisagé à tester sous 9front, mais j'en ai pas la maitrise :O

    désolé de m'être égaré..
    merci d'avoir lu, à vous les studios

    lien complémentaire :
    https://askubuntu.com/questions/1100467/re-what-is-dhpcd-command-and-how-to-disable-it

    • [^] # AllowUsers

      Posté par  . Évalué à 3.

      Le premier truc que je met en place dans ma conf sshd:
      AllowUsers Les_seuls_users_qui_peuvent_se_connecter_en_ssh

    • [^] # Re: figurez vous que..

      Posté par  . Évalué à 3.

      test/test sur un port ouvert, j'ai aussi expérimenté cela en … 2001 si je me souviens bien. Un compte créé rapidement pour une personne de passage et pas supprimé ensuite, un ordi ouvert sur internet quelques mois plus tard…

      A priori, j'ai détecté le problème assez vite. L'accès avait été découvert dans l'après-midi et utilisé le soir (probablement le temps d'une intervention manuelle). Ce n'était pas du bitcoin, mais il lançait de nouvelles attaques SSH vers d'autres ordis. Ce qui m'a mis la puce à l'oreille : le CPU qui était monté à 100% pendant que je tapais dans emacs. J'avais beau avoir une vitesse de frappe raisonnable, de là à occuper le CPU à 100%… Heureusement que j'avais du boulot à faire ce soir là.

      • [^] # Re: figurez vous que..

        Posté par  (Mastodon) . Évalué à 1.

        hello… je me demande si mon petit pavé devrait faire l'objet d'un journal pour mieux "sensibiliser" les nouveaux arrivants aux bonnes habitudes de sécurité sur linux?
        (je le trouve un peu "enfoui" là :o )

  • # 4224

    Posté par  . Évalué à 3.

    Parce que 4224 contient 42 à l'endroit et à l'envers, et que ça contient 22 pour se souvenir que c'est du ssh. Mais j'utilise quand même fail2ban et le login est exclusivement par clé privée.

  • # Endlessh + fail2ban

    Posté par  (site web personnel, Mastodon) . Évalué à 3.

    J'utilisais simplement un port aléatoire pour SSH mais les bots russes et chinois finissaient toujours par revenir. Alors j'ai installé endlessh sur le port 22 et depuis ça va beaucoup mieux, je n'ai quasiment plus de notifications fail2ban concernant le "vrai" port SSH.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.