bonjour
suite à un commentaire qui me l'a encouragé (je jette la pierre à personne), je pense qu'une première réflexion (par rapport à ce journal) peut être utile et indispensable, pour que les petits gros sysadmin qui prennent le truc "un peu trop à la légère" ou dispenseraient d'un droit légitime à l'ignorance sur ces systèmes, puissent s'inquiter un peu.
généralement il s'agit d'une négiligence de ports ouverts (dans mon cas)
cela pourrait également etre le cas d'une personne découvrant linux et ne sachant pas que le ssh juste activé (avec user/user) puisse amener certaines surprises.
le post initial, est là :
https://linuxfr.org/nodes/123507/comments/1902786
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 studioslien complémentaire :
https://askubuntu.com/questions/1100467/re-what-is-dhpcd-command-and-how-to-disable-it
et je me permets de lier les quelques prérogatives des observateurs :
https://linuxfr.org/nodes/123507/comments/1902322
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.
https://linuxfr.org/nodes/123507/comments/1902370
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
donc là, je me dis :
sur certaines distribs, ssh est désactivé ; sur d'autres (lmde5 par ex), il n'st pas installé. Sachant qu'openssh reste une fonctionnalité phare et quotidienne pour beaucoup de monde, ne serait-il pas appréciable de crééer une sorte de label/standardisation/whatever pour "obliger/encourager/imposer" le passage aux clés, l'abandon de mdp, etc.. vu les risques soulevés?
pour moi, c'est quelque chose qui nécessite sensibilisation, et qui à moyen ou long terme devra faire un peu électrochoc dans le monde du libre.
C'est mon avis, mais si le peu-averti que je suis, ou le débutant qu'est mon voisin, ne sommes pas si avisés, ne vaut-il mieux pas prévenir que guerir?
je vous remercie de vos observations :)
# nice -n19
Posté par PR . Évalué à 2.
Parce qu’il n’y a pas de raison pour que seul le piraté apprenne quelque chose et comme ca le pirate saura se faire plus discret la prochaine fois. Parce que limite on pourrait plaider pour la bonne foi du pirate là : y’a pas eu effraction si t’as laissé la porte grande ouverte…
Mort aux cons !
[^] # Re: nice -n19
Posté par aiolos . Évalué à 2.
Sauf que…
https://www.lepetitjuriste.fr/laffaire-bluetouff-condamne-pour-vol-de-donnees-librement-accessibles/
[^] # Re: nice -n19
Posté par tkr . Évalué à 0.
un mot de passe n'est pas une porte grande ouverte, meme laisser la clé sous le paillasson, ou encore le pot de fleurs ou la poutre :
pour comparer ca à une maison, la plupart n'iront pas chercher sous ces endroits, soit parce que ca parait trop simple, soit parce .. qu'ils ne savent pas.
n'oublions pas qu'il y a encore quelques années (une certaine époque), certains fabricants fournissaient des appareils sur lesquels il fallait se connecter en telnet, sans aucun mdp.
# Paramètres par défaut des distributions
Posté par geegeek . Évalué à 2.
Les paramètres (et logiciels) par défaut des distributions pourraient être revus:
- interdire le log par mot de passe dans ssh,
- suggérer fail2ban à l'installation de sshd,
- ou peut-être d'autres choses basées sur le port-knocking.
En attendant, le logiciel t'as sûrement averti que "test" n'est pas un mot de passe fort mais tu as trouvé le moyen de le mettre quand même…
[^] # Re: Paramètres par défaut des distributions
Posté par Zatalyz (site web personnel) . Évalué à 3.
En effet. J'ai mis des années à trouver comment comprendre les infos pour paramétrer SSH d'une façon qui me semble sécurisée. Ce qui veut dire des années où globalement c'était ouvert à tous les vents. En particulier le mot de passe… très très mauvaise chose. D'un autre côté, il est facile de se bloquer l'accès au serveur si on se plante ; mais, si on est son possesseur légitime, il y a toujours moyen de débloquer (et ça aussi, j'ai mis un temps fou à le comprendre…).
[^] # Re: Paramètres par défaut des distributions
Posté par barmic 🦦 . Évalué à 2.
C'est tout. Tout le reste c'est du bonus qui va être plus ou moins discuté. S'il y a un truc à apprendre c'est interdire la connexion par mot de passe.
S'il y a un truc a marteler il est tout trouvé.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Paramètres par défaut des distributions
Posté par claudex . Évalué à 4.
Comment tu fais en configuration par défaut ? Tu demande à l'utilisateur de copier à la main durant l'installation ? On va voir moins de clef RSA 4096bits circuler.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Paramètres par défaut des distributions
Posté par Psychofox (Mastodon) . Évalué à 4. Dernière modification le 31 décembre 2022 à 16:29.
En local c'est relativement facile. Pour une machine distante les installeurs supportant cloud-init te permettent de fournir une clé publique pour le premier compte utilisateur. La plupart des services clouds et hébergements vps ou bare-metal aussi et souvent ils peuvent aussi te générer automatiquement des certificats.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Paramètres par défaut des distributions
Posté par barmic 🦦 . Évalué à 2.
Jamais rencontré de cas de besoin de mot de passe. L'usage de clef n'est pas simplement immensément plus sécurisé que n'importe quel mot de passe dit fort, il est aussi infiniment plus pratique à l'usage.
Je suis d'accord avec toi sur le principe, mais dans la pratique les seuls cas que j'ai vu c'est une crainte quant à la mise en place, mais une fois c'est très confortable.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Paramètres par défaut des distributions
Posté par Cyril Chaboisseau (Mastodon) . Évalué à 4.
Pour ma part, je peux avoir besoin exceptionnellement de me connecter sur ma machine depuis un ordinateur occasionnel (chez un ami par exemple), et dans ce cas j'ai mis en place un 2FA (Google Authenticator) ce qui m'apporte une tranquillité quant au risque de laisser un port ssh ouvert.
En plus, c'est pas pour faire la promotion aveugle d'un accès ssh par MdP + 2FA, mais j'ai plus confiance dans cette approche pour des postes qui ne sont pas forcément sous mon contrôle total (par exemple ordi professionnel à partir duquel quelqu'un de mal intentionné pourrait récupérer ma clé ssh privée depuis les sauvegardes)
Bien sûr, ça se rajoute à tout un tas d'autres durcissement et blocages tels que
- fail2ban (auparavant j'utilisais denyhosts)
- limitation des cnx ssh uniquement à certains utilisateurs (directive
AllowUsersde la config sshd)- verrouillage des comptes ssh utilisés pour des sauvegardes via les restrictions du fichier
authorized_keys(limitation à l'aide defrom=, de la commande à lancer ou encore en empêchant le pouvoir lancer un shell à l'aide derestrict)- sécurisation de la configuration d'OpenSSH (chercher "ssh hardening" pour trouver tout un tas de tutos sur le sujet)
- surveillance des connexions suspectes (surtout celles qui ont réussies)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4. Dernière modification le 31 décembre 2022 à 09:57.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Paramètres par défaut des distributions
Posté par barmic 🦦 . Évalué à 2.
Je connais pas d'appli sftp qui ne soient pas en mesure de gérer des clefs.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Paramètres par défaut des distributions
Posté par Psychofox (Mastodon) . Évalué à 6.
Tu les authentifie par certificat que tu leur fournis. Ils n'ont pas besoin de générer quoique ce soit.
[^] # Re: Paramètres par défaut des distributions
Posté par Misc (site web personnel) . Évalué à 4.
Ça augmente les appels au support, donc les sous que tu dépenses.
[^] # Re: Paramètres par défaut des distributions
Posté par Psychofox (Mastodon) . Évalué à 4.
Bof, je ne suis pas convaincu.
[^] # Re: Paramètres par défaut des distributions
Posté par barmic 🦦 . Évalué à 4.
J'entends (de la part de l'utilisateur) "viens pas nous embêté avec ton truc que je connais pas. On a toujours fais comme ça et c'est pas toi qui va me faire changer". C'est le même genre d'arguments qu'on a vu pour expliquer que c'était inacceptable que Firefox ne supporte plus FTP. L'utilisateur veut pas.
Il faut l'accompagner, mais il faut vraiment que l'utilisateur comprenne qu'il n'est pas seul sur Internet et que les pratiques se doivent d'évoluer. C'est l'une des fonctions des gens de la tech de faire ce devoir de conseil.
D'autant qu'il y a d'autres apports à l'usage de clefs. Tu peux supprimer une clef sans impact sur les autres usages et tu n'a pas de secret partagé.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Paramètres par défaut des distributions
Posté par Zatalyz (site web personnel) . Évalué à 3.
Je plussoie et j'en rajoute. Les seuls cas que j'ai croisé où un mot de passe semblait mieux, il s'est avéré ensuite que ce "mieux" était uniquement lié à mon incompétence ; quand on apprend à se servir des clés, c'est mille fois plus sécurisé et puissant, et cela ne complexifie même pas vraiment la tâche (passée la phase d'apprentissage). Une bonne politique sur les mots de passe demande de toute façon aussi un sacré apprentissage ; typiquement sur l'accès ssh, tu peux bien mettre un mot de passe de 25 caractères, mais si tu ne fais que ça, tu garde un risque assez élevé de te faire trouer le serveur. Et comme derrière, l'utilisateur par défaut est probablement "root", ça sera tout de suite du vrai dégât (vu comme les bots tentent de rentrer en utilisant "root" comme utilisateur, il doit y avoir une raison statistique). Après, si quelqu'un as des exemples concrets où le mot de passe est plus pertinent, je suis ouverte à revoir ma copie… Mais il me faudra des cas concrets où une clé ssh n'aurais pas été pertinente.
On peut aussi faire des bêtises avec des clés (être sur une distribution où les options par défaut sont faibles, la générer sans mot de passe, stocker la clé privée de façon non sécurisée, etc) mais comme cela demande de comprendre un peu ce qu'on fait, il y a plus de chance de faire "suffisamment bien".
Tiens d'ailleurs autre point de sécurité par défaut : interdire formellement la connexion ssh via l'utilisateur root… Oui oui, si on a une connexion par clé, fail2ban, etc, la connexion via root n'est pas tant un souci, mais c'est quand même augmenter un peu les risques, pour un confort mineur. Et la combo des config par défaut root+connexion par mot de passe, c'est juste terrible.
Tout ce qui va à l'encontre des pratiques statistiques améliore les chances de résister aux crackbots de base et des script-kiddies, qui représentent la majorité des attaques. Donc au moins pousser l'utilisateur à se choisir un nom d'utilisateur et un mot de passe associé pour accéder au sésame "sudo" (ce qui est le cas sur pas mal de distributions de bureau), puis interdire "root" à se connecter en ssh, c'est déjà pas mal.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Paramètres par défaut des distributions
Posté par moi1392 . Évalué à 2. Dernière modification le 31 décembre 2022 à 12:41.
Et pourquoi ne pas créer un utilisateur spécifique, mettre tes scripts sur la machine client et mettre soit
1) tes scripts en suid root
2) voir si tu peux t'en sortir avec les droits de fichiers/capabilities du noyau ?
[^] # Re: Paramètres par défaut des distributions
Posté par PR . Évalué à 2.
Les scripts ne peuvent pas être mis en suid. C’est Linux qui l’interdit, pour des raisons plus ou moins légitimes d’ailleurs, mais qui font sens. Dans tous les cas, même si c’était possible, ce serait une mauvaise pratique car trop dangereux.
Mort aux cons !
[^] # Re: Paramètres par défaut des distributions
Posté par Elfir3 . Évalué à 4.
Par contre, si je ne me trompe pas, sudo permet de limiter son autorisation à certaines commandes bien précises, il est donc trivial de créer un script executable via sudo pour l'utilisateur en question, ce qui n'est pas loin d'un setuid mais limite déjà les risques.
[^] # Re: Paramètres par défaut des distributions
Posté par PR . Évalué à 2. Dernière modification le 01 janvier 2023 à 19:08.
Tiens ce serait à creuser d’ailleurs. Est-ce que les failles de sécurité sont les mêmes avec sudo qu’avec un setuid sur un script.
Voir par exemple :
https://unix.stackexchange.com/questions/364/allow-setuid-on-shell-scripts#2910
La discussion n’a pas l’air de trancher totalement (même si tout le monde a l’air de s’accorder sur le fait que sudo c’est beaucoup mieux).
Au passage on apprend que les *BSD semblent avoir un mécanisme de protection pour permettre les setuid scripts.
Mort aux cons !
[^] # Re: Paramètres par défaut des distributions
Posté par totof2000 . Évalué à 4. Dernière modification le 31 décembre 2022 à 12:53.
Je n'ai plus installé de serveurs dont l'acces root était ouvert pour root depuis des années (se compte sur plus de deux mains).
Tous les scripts qui ont besoin d'un accès privilégié tournent avec un user non root, qui a la possibilité de faire du sudo sur certaines commandes. J'ai une seule exception: le compte utilisé par ansible pour le déploiement des infras et l'exécution des taches d'admin, qui lui ne se connecte pas en root, mais doit comme tu dis avoir les droits root pour faire ce qu'il a à faire. Pour le reste (actions automatisées liées à un framework ou un applicatif), je pense que les droits sudoers sur root sont accordés par confort et qu'on pourrait s'en passer dans beaucoup de cas.
[^] # Re: Paramètres par défaut des distributions
Posté par moi1392 . Évalué à 4.
j'ai eu besoin d'acceder à ma machine (je ne sais plus pour quelle raison) de l'extérieur une fois, j'ai installé une appli ssh sur mon ordiphone et me suis connecté en ssh.
Sans mot de passe j'aurais été coincé.
Je ne suis pas d'accord là dessus.
Dans mon ancien boulot, je me connectais de temps en temps chez moi par ssh, et je n'ai pas envie qu'une personne qui utilise "ma" machine, car oui, il m'arrivait de laisser ma machine à un collegue sans être derrière lui, puisse se loguer sans soucis chez moi.
Et ceci est valable du coup pour nimporte qui qui aurait eu acces à cette machine, de façon légitime ou pas.
Au final la bonne solution est un compromis.
Chez moi je n'ai qu'un utilisateur auquel je peux me connecter par ssh avec mot de passe. Il est assez fort pour tenir une attaque brute force, si tant est que l'on connaisse le login, du coup indirectement ça "augmente" le force du mot de passe car il me semble qu'openssh ne donne pas de réponse différente pour mot de passe ou login incorrect (corrigez moi si je me trompe) et je n'ai pas vu de side attack qui puisse aider là dessus (genre temps de réponse, etc…)
je couple à un fail2ban "renforcé" (banni plusieurs jours au bout de 2 erreurs) et j'ai une blacklist (longue comme un bras de la voie lactée…) dans laquelle je mets régulièrement le log des ip de fail2ban.
Dans le temps il me semble que j'avais aussi trouvé le moyen de dire à ssh (ou à pam ?) d'ajouter un lag de 1 seconde entre chaque tentative d'authentification (ce qui démoli d'office le brute force, sans être gênant à l'utilisation, 1 seconde c'est rien quand je me trompe), mais je n'arrive plus à mettre la main dessus.
[^] # Re: Paramètres par défaut des distributions
Posté par barmic 🦦 . Évalué à 3.
Ton ordiphone peu utiliser une clef, surtout si tu as des besoins irrésistibles de te connecter n'importe où.
Je ne comprends pas. Comment pourrait-il accéder à ta clef ? Ça fait longtemps que ça ne m'est pas arrivé, mais si c'était le cas d'une je coupe tous les shell ssh et de 2 je vire toutes les entrées de mon agent. Comme tu dois de toute manière faire l'un ajouter l'autre ne demande pas plus de rigueur. Il est même possible que tu fasse déjà quelque chose de suffisant avec un
pkill ssh. Perso je préfère garder mon agent en vie, mais c'est un détail.Faut faire attention avec ce genre de sentiment. Personnellement je ne m'autorise pas ce genre d'hypothèse sans qu'un gars un minimum plus sérieux que moi en sécurité le confirme.
Oui, interdire l'accès par mot de passe sauf si tu as une bonne raison.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Paramètres par défaut des distributions
Posté par moi1392 . Évalué à 3.
Quand tu le prévois à l'avance oui. C'était pas mon cas.
Alors oui, si on supprime le besoin de se connecter, tu peux même virer le serveur ssh c'est encore plus sécure, et ce, sans l'avis d'un expert :p
JE suis d'accord sur le fond, et j'ai bien précisé qu'à ma connaissance il n'y a pas de moyen de faire la différence depuis une tentative de connexion à distance. Mais je me comporte comme si les login étaient connus, tout en ne les dévoilant pas.
C'est toujours ça de pris comme disait l'autre.
Alors on ne parle peut-être pas de la même chose quand on parle de clé. Moi je parle d'une paire de clés publique/privé générée sans mot de passe.
Et pour ce qui est de mes collegues, je pouvais leur filer un shell sur ma machine de travail sous mon login sans soucis.
En sachant que ça n'est pas "ma" machine, mais celle de mon employeur que j'utilisais quotidiennement, j'aurais pu faire mon puriste, mais je n'y voyais pas d'inconvénients vu que je m'en servait quasi exclusivement pour bosser et qu'il n'y avait rien de perso dessus. Du coup j'allais au plus pratique quand c'était arrangeant pour bosser.
De toute façon les sysadmin avaient les mots de pass root sur toutes les machines, donc là encore ils auraient pu accéder à ma clé privée très simplement.
[^] # Re: Paramètres par défaut des distributions
Posté par barmic 🦦 . Évalué à 3.
Pour ne pas la chiffrer il faut avoir bien ignoré ton logiciel qui t'a dit que ce serait bien que tu mette une passphrase. Je comprends que dans certains cas, on puisse trouver contraignant de chiffrer sa clef (avoir un agent ssh lancé avec ta session demande un peu de configuration), mais s'il est admis que c'est une machine partagée je ne vois pas comment on peut se dire que c'est une bonne idée. Sans mettre en cause la probité de tes collègues, ça évite aussi des maladresses.
C'est les mêmes qui ont l'accès root aussi sur les serveurs en question ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Paramètres par défaut des distributions
Posté par moi1392 . Évalué à 2.
D'accord, on ne parlait pas de la même chose alors.
Mais du coup en quoi est-ce différent (dans le sens plus sécurisé) que de mettre un mot de passe très long (genre une clé rsa en base64) avec un gestionnaire de mots de passes ?
ça après techniquement c'est plus mon problème…
Non, mon utilisation était de me connecter de temps en temps CHEZ MOI depuis mon boulot pour des raisons persos. Genre récupérer des vidéos à partager avec les collègues (il n'était pas rare que le temps de la pause de midi on se fasse un épisode ou deux d'une série quelconque en mangeant au bureau)
Utilisation complètement illégitime, j'en conviens :)
[^] # Re: Paramètres par défaut des distributions
Posté par barmic 🦦 . Évalué à 2. Dernière modification le 01 janvier 2023 à 16:50.
Dans ce que je vois rapidement :
Typiquement le genre de cas où le chiffrement de clef me paraît évident.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Paramètres par défaut des distributions
Posté par gUI (Mastodon) . Évalué à 4. Dernière modification le 31 décembre 2022 à 14:57.
Lors de l'installation sur un serveur distant, ça va être coton mais pas impossible : va falloir prévoir ça dans l'installateur.
Ça par contre, ça pourrait en effet faire partie du package, surtout si par défaut il a un paramétrage assez sympa (style 1mn de ban après 3 échecs : ça tue toute brute force sans punir l'étourdi). Un peu comme
logrotate, on a quand même compris un jour que c'était la base de la survie d'un serveur dans le temps :)En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Paramètres par défaut des distributions
Posté par barmic 🦦 . Évalué à 4. Dernière modification le 02 janvier 2023 à 15:06.
Aucune méthode est insensible au brute force. La question c'est uniquement quelle est l'espérance de l'attaquant pour passer. L'entropie d'un mot de passe c'est l'estimation du log en base 2 du nombre de tentatives nécessaires pour trouver le bon.
Un mot de passe de 8 caractères avec un alphabet de 62 symboles (majuscules, minuscules, chiffres) a une entropie de 48bits, il est considéré comme très faible par l'ANSII et il faut 281 474 976 710 656 tentatives pour le trouver.
Sans trop te poser de question (utilisation de cartes graphiques, fpga, etc) tu peux tenter plusieurs milliards de mot de passe par seconde. Tu met moins d'une semaine pour passer au travers? Mais ça c'est quand tu as un fichier à déchiffrer. Si tu dois faire un accès réseau et qu'un fail2ban te ban 1s toutes les 15 tentatives1, tu en a pour un paquet d'années si je ne m'abuse.
Je ne crois pas que les attaques autres que par dictionnaires soient fonctionnelles sur ssh.
J'aime pas fail2ban et je ne m'en sert pas, mais on peut pas lui reprocher de ne pas être un outil de sécurité.
évidement un attaquant très motivé aura un paquet d'IPs pour limiter cette gêne. ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2. Dernière modification le 02 janvier 2023 à 15:51.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Paramètres par défaut des distributions
Posté par Psychofox (Mastodon) . Évalué à 6.
fail2ban ne sert pas que pour ssh. Ça aide à bannir des ips qui pouraient aussi attaquer quelconque autre service qui tournent sur ta machine (l'un pourrait avoir un 0day sans que tu aies eu le temps d'en être informé). Bien que ça apporte peu à une attaque ciblée, ça apporte réllement aux attaques automatisées.
[^] # Re: Paramètres par défaut des distributions
Posté par barmic 🦦 . Évalué à 3.
Tu as lu ce que j'ai écris ?
Le coût calculatoire n'a plus aucun sens quand tu as une requête réseau obligatoire.
C'est un peu comme quand tu dis a un gars qui utiliserait un mot de passe de 13 caractères (plutôt que ta recommandation à 12) que ça ne sert à rien d'un point de vu sécurité.
Note que ta recommandation est d'utiliser ce que l'ANSII considère comme un mot de passe faible (une entropie inférieure à 80bits).
C'est une expérience. Moi je n'ai jamais vu de serveur ssh compromis, j'ai donc pas besoin de désactiver la connexion root et de me poser des questions sur l'utilisation de mot de passe ou de clef ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Paramètres par défaut des distributions
Posté par gUI (Mastodon) . Évalué à 5.
Donc pendant 281 474 976 710 656 tentatives le mec il va tranquillement te pourrir ton daemon SSH et tes logs.
L'intérêt de fail2ban est aussi d'éviter du DDoS (au sens large).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Paramètres par défaut des distributions
Posté par barmic 🦦 . Évalué à 2.
C'est à dire ?
Une rotation avec compression et il se fatiguera avant toi.
Mais bon c'était surtout pour dire que personne ne tente un brute force réseau.
Ça il faut voir. Je serais pas surpris qu'il soit possible de DDoS via fail2ban.
Là où SSH va juste ouvrir/fermer des connexions. fail2ban doit parser les logs, mettre ) jour les règles iptables pour ban et pour unban. Il me semble avoir vérifié récemment les configurations récentes d'iptables utilisent bien des set d'IP pour ne pas avoir à décharger/recharger tout le parfeu, mais ça n'a pas toujours était le cas. Et bon le principe des DDoS c'est d'avoir pleins d'ip et d'agréger les bandes passantes. Si tu as pris le temps d'analysé le comportement du fail2ban adverse tu peut potentiellement le charger dans une boucle de ban/unban.
Tout ça pour dire que c'est pas magique et qu'il faut faire attention à sa configuration.
Soyons clair si fail2ban peu très bien ajouter de la sécurité, je suis convaincu qu'il doit tout son succès à ceux qui réagissent mal à ceux genre de photos : https://i.redd.it/8pldpxudj7h01.jpg (par sympathie pour les concernés je met juste le lien :) )
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Paramètres par défaut des distributions
Posté par fearan . Évalué à 4.
Si le but est de pas les lires, autant ne pas les écrire :)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Paramètres par défaut des distributions
Posté par barmic 🦦 . Évalué à 2.
C'est bien vrai mais le principe des lois c'est de les écrire en continue au cas où, un jour, tu ai besoin de comprendre un comportement. Comme ça n'est pas prédictible, il n'y a pas vraiment le choix.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Paramètres par défaut des distributions
Posté par Kwiknclean . Évalué à 1.
Fail2Ban, c'est à mon humble avis, la pire solution que l'on ai trouvé pour sécuriser ssh.
C'est au mieux de la bricole pour mettre à la maison ou un VPS lambda, mais à coup sur une belle preuve d'amateurisme lorsque trouvé en entreprise, ou le signe d'un réel manque de moyen.
Ca peut à la rigueur faire sens sur pour d'autres applications type server web et encore.
Mais ça reste de l'analyses de logs, donc c'est long, lent et chiant à configurer.
Le bruteforcing ssh est une protection qui devrait être gérer directement sur par le deamon ssh ou directement sur la couche réseau.
Un firewall moderne devrait être capable de gérer ça correctement, si ce n'est pas le cas, changer de firewall ou changer de distribution .. changez d'OS.
[^] # Re: Paramètres par défaut des distributions
Posté par chimrod (site web personnel) . Évalué à 4.
Pas vraiment. J’ai le sentiment qu’il y a des plages d’IP qui prennent la relève successivement dès que la première est bloquée. Je pense que fail2ban est impuissant face un réseau de botnet un peu organisé :
Tu peux changer les règles pour empêcher ça (tu fais une méta-règle qui parse les logs de fail2ban, et si la même IP est présente 10 fois en 3j tu la ban à vie), mais tu auras toujours un train de retard.
[^] # Re: Paramètres par défaut des distributions
Posté par barmic 🦦 . Évalué à 4.
Quand tu commence à réfléchir comme ça tu peux en arriver à te dire que tu veux seulement une allow list d'ips. Pour tes ips fixes pas de problème et pour les autres le plus classique c'est le port knocking, mais tout est imaginable.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Paramètres par défaut des distributions
Posté par tkr . Évalué à 0.
il n'y a eu aucun avertissement…
# Recommandations de sécurité relatives à un système GNU/Linux de l'Anssi
Posté par Samuel (site web personnel) . Évalué à 7.
C'est beaucoup plus large que la configuration SSH, mais les recommandations de sécurité relatives à un système GNU/Linux proposées par l'Anssi (agence de l'État français pour la sécurité informatique) ont plein de recommandations chouettes, et classent les 80 recommandations en 4 niveaux de durcissement (minimal, intermédiaire, renforcé et élevé).
HS : Sur le port knocking comme méthode d'authentification, j'avais lu (en anglais) quelqu'un qui expliquait que ça revenait à encoder un mot de passe, éventuellement tournant (façon TOTP ou HOTP) sous forme d'une suite d'octets, et que pour gérer ça on avait rudement plus efficace que le port knocking, dans les protocoles eux-mêmes (= les modes d'authentification à clé publique proposée par SSH, ou par mot de passe pour certaines applications - mots de passe auxquels il convient de donner la longueur adéquate, cela va de soi). Je ne retrouve plus la source, si quelqu'un me lit et l'a sous le coude, je suis preneur !
(note : le commentaire cité dans l'article parle du port knocking comme d'une méthode ayant pour effet de limiter le bruit dans les logs, pas comme d'une mesure apportant une sécurité supplémentaire … donc la remarque au paragraphe précédent ne s'y oppose pas).
[^] # Re: Recommandations de sécurité relatives à un système GNU/Linux de l'Anssi
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2.
Heureusement qu’on est encore en 2022, sinon un quidam aurait pu être troublé en lisant la recommandation de désactiver IPv6 (parce que ce n’est généralement pas exploité). :-)
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Recommandations de sécurité relatives à un système GNU/Linux de l'Anssi
Posté par tkr . Évalué à 1.
la problématique c'est que les jeunes, nouvelles générations et autres étudiants/passionnés/nerds/ ou amateurs qui découvrent, ne savent pas ce qu'est l'anssii, et sans forcément en toucher un mot à d'autres admins ou pro, ils ont peu de chances de s'informer à ce sujet : un mdp reste une protection certaine, car omniprésente sur les outils numériques au quotidien.
ce pourquoi, une sorte de labellisation pourrait encourager à la fois le publci libre de ces nouvelles précautions, et à la fois encourager les distros nux/bsd à serrer la vis au sujet du ssh et de la cybersécu associée..
enfin c'est que mon avis..
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.