Je vous ai récem­ment expli­qué les choix qui vous reviennent dans le choix de votre héber­ge­ment. Dans les faits, ces choix concernent direc­te­ment votre infra­struc­ture tech­nique, depuis votre OS et son para­mé­trage jusqu’à l’ensemble de votre archi­tec­ture. Cela signi­fie que vous devez ajus­ter le cur­seur entre gérer vous-même cer­tains aspects ou les confier à un par­te­naire. Tout est affaire de confiance, et de coûts.

Sécuriser l’accès à dis­tance est l’un de ces élé­ments tech­niques à prendre en compte. Certains points sont tri­viaux ; d’autres néces­sitent des com­pé­tences impor­tantes en sécu­ri­té et cryp­to­gra­phie. Cet article est ici pour vous don­ner un aper­çu des mesures à mettre en place pour bien sécu­ri­ser son accès dis­tant. Il est par­se­mé de liens vers des conte­nus plus avan­cés vers cer­taines tech­niques pour vous per­mettre d’aller plus loin si vous le sou­hai­tez1)2).

Cat GIF @Giphy

TL;DR : la sécu­ri­té est un vaste domaine de connais­sances où il est facile de se perdre. Si vous sou­hai­tez seule­ment savoir com­ment bien confi­gu­rer votre accès dis­tant aux ser­veurs d’always­da­ta, inté­res­sez-vous sim­ple­ment à la sec­tion concer­nant la sécu­ri­sa­tion des méthodes d’accès.


Ne laissez pas n’importe qui s’introduire chez vous

Votre appli­ca­tion s’exécute sur des machines dis­tantes, pour vous per­mettre d’offrir un accès à votre ser­vice de n’importe où. Vous n’avez géné­ra­le­ment pas d’accès phy­sique à ces machines3). Vous uti­li­sez donc un accès dis­tant pour y avoir accès. La plu­part du temps, vous pas­se­rez par un shell dis­tant : SSH. SSH vous four­nit un accès à la fois à une invite de com­mande et à un navi­ga­teur de fichiers bas niveau sur la machine. Vous pou­vez le voir comme une porte don­nant sur votre salon. Ne pas vous en sou­cier est dan­ge­reux, voire incons­cient.

Un point impor­tant en matière de sécu­ri­té est la manière dont vous sécu­ri­sez cet accès à vos ser­veurs de pro­duc­tion. Là encore, vous pou­vez vou­loir le faire par vous-même, ou vous pou­vez pré­fé­rer vous appuyer sur l’expertise d’un par­te­naire qui sau­ra le faire pour vous. Chez always­da­ta, nous res­tons convain­cus que cette seconde solu­tion est presque tou­jours la meilleure, mais il reste mal­gré tout cer­tains points que vous devrez gérer seuls. Parce que ces points sont encore par­fois obs­curs, voi­ci quelques conseils pour bien pro­té­ger votre accès dis­tant.

Un bon niveau de sécu­ri­té est un niveau que vous com­pre­nez, et que vous pou­vez admi­nis­trer seul·e. Pour être cer­tains que vous dis­po­se­rez de l’expertise de base néces­saire à la bonne com­pré­hen­sion de ces enjeux, nous allons voir ensemble quelques bases. Mon objec­tif n’est pas de faire de vous un expert en sécu­ri­té, seule­ment de vous don­ner de bonnes bases.

La plu­part des ser­veurs SSH sont par défaut confi­gu­rés avec un niveau de sécu­ri­té cor­rect. C’est le cas d’OpenSSH, qui est le ser­veur SSH le plus cou­ram­ment uti­li­sé. Cependant, dis­tri­buer une confi­gu­ra­tion par défaut signi­fie que les main­te­neurs des paquets sur les dis­tri­bu­tions doivent gérer le plus de cas d’usages pos­sible, plu­tôt que de main­te­nir un niveau de sécu­ri­té maxi­mal. Ces confi­gu­ra­tions par défaut per­mettent pro­ba­ble­ment de reje­ter 90% des intru­sions. Considérez ça comme ins­tal­ler une porte robuste à votre mai­son ; mieux que rien, mais pas une porte blin­dée non plus. Voyons com­ment ren­for­cer ce niveau par défaut.

Be Safe, Be Smart

Sécuriser son accès dis­tant implique de s’occuper d’hygiène numé­rique, notam­ment pour la par­tie client, qui reste à votre charge. Même si votre ser­veur est bien sécu­ri­sé, vous pou­vez avoir des pro­blèmes si vous n’avez pas une pro­tec­tion suf­fi­sante côté client.

Utilisez une clef SSH pour vous connecter

Nous vous recom­man­dons d’utiliser une clef SSH pour vous connec­ter plu­tôt qu’un mot de passe. De cette façon, vous pour­rez plus faci­le­ment gérer qui se connecte à votre ser­veur, depuis quel appa­reil, et révo­quer fine­ment les accès en cas d’urgence4). Une bonne pra­tique consiste à avoir une paire de clefs5) par uti­li­sa­teur et par appa­reil. Cela vous don­ne­ra la flexi­bi­li­té néces­saire à la révo­ca­tion de l’appareil si celui-ci est per­du, volé, ou mis hors ser­vice, plu­tôt que révo­quer l’accès com­plet de l’utilisateur.

Pour savoir com­ment géné­rer une clef sécu­ri­sée à jour, repor­tez-vous à la sec­tion concer­nant le for­mat ed25519.

Ne vous connectez pas via un mot de passe

Les mots de passe ne pré­sentent pas une robus­tesse de pro­tec­tion suf­fi­sante pour évi­ter à vos accès dis­tants une poten­tielle com­pro­mis­sion. Vous devriez uti­li­ser une authen­ti­fi­ca­tion par clefs pour vous assu­rer que votre uti­li­sa­teur dis­tant est pro­té­gé contre une attaque par force brute qui ten­te­ra de trou­ver le mot de passe de votre uti­li­sa­teur.

Chez always­da­ta, la connexion SSH par mot de passe est désac­ti­vée par défaut, et seules les connexions par clefs SSH sont auto­ri­sées. Vous devez entrer vous-même votre clef publique dans le fichier ~/.ssh/authorized_keys6). Si vous avez besoin d’activer la connexion par mot de passe mal­gré tout (par exemple, pour trans­fé­rer votre clef publique la pre­mière fois), vous pou­vez le faire en cochant la case idoine dans la sec­tion SSH de votre inter­face d’administration. Gardez à l’esprit que cette méthode est peu sécu­ri­sée et ne devrait pas être acti­vée en per­ma­nence.

Si vous confi­gu­rez votre ser­veur per­son­nel, après avoir copié votre clef publique sur le ser­veur, désac­ti­vez la connexion par mot de passe dans le fichier de confi­gu­ra­tion sshd.

Certains uti­li­sa­teurs et admi­nis­tra­teurs semblent croire que ne pas uti­li­ser de mot de passe pour pro­té­ger l’accès à leur compte est une bonne pra­tique. Je pense per­son­nel­le­ment que même un mot de passe très faible est une meilleure idée que pas de mot de passe du tout. Quoi qu’il en soit, inter­di­sez à ces uti­li­sa­teurs sans mot de passe de se connec­ter à dis­tance sans aucune pro­tec­tion.

Les mots de passe vides sont reje­tés en SSH chez always­da­ta.

Utilisez des phrases de sécurité

Utiliser des clefs robustes est essen­tiel, mais vous ne pou­vez garan­tir leur sécu­ri­té sans les pro­té­ger. Cela signi­fie que chaque clef SSH doit avoir une phrase de sécu­ri­té unique et solide. Cela s’applique aus­si à vos mots de passe uti­li­sa­teur, j’utilise la même tech­nique pour les géné­rer.

Il existe (au moins) deux façons de géné­rer des phrases aléa­toires en ligne de commande7) :

Vous devriez dis­po­ser de openssl rand ou de gpg (voire des deux) sur votre sys­tème d’exploitation. Je vous conseille de tes­ter la robus­tesse de votre mot de passe ain­si géné­ré avec l’outil How Secure Is My Password. Vous ne vou­driez pas qu’un mot de passe un peu faible com­pro­mette toute votre sécu­ri­té, n’est-ce pas ?

Utilisez des clefs de chiffrement physique

Si vous êtes vrai­ment sou­cieux de la sécu­ri­té de votre accès dis­tant, vous devriez consi­dé­rer l’utilisation d’un cer­ti­fi­cat client pour vous connec­ter, cou­plé à une clef phy­sique. De cette façon, vous conser­ve­rez le cer­ti­fi­cat en sécu­ri­té. Vous pou­vez uti­li­ser une clef de chif­fre­ment phy­sique comme les Nitrokey Pro ou YubiKey 4 pour sto­cker vos clefs et cer­ti­fi­cats d’authentification client.

@Giphy

Restez à jour

Gardez votre serveur SSH à jour

Des failles SSH sont régu­liè­re­ment décou­vertes (per­sonne n’est jamais exempt de bogues) et cor­ri­gées rapi­de­ment par les contri­bu­teurs des pro­jets et dis­tri­bu­tions. C’est donc tou­jours une bonne idée de gar­der votre ser­veur à jour. Ceci implique éga­le­ment de conser­ver votre client SSH à jour. Au moment où j’écris ces lignes, la der­nière ver­sion d’OpenSSH est la 7.6 sor­tie le 3 oct. 2017 en. Vous pou­vez véri­fier votre ver­sion faci­le­ment :

Utilisez le protocole SSH v2

SSH dis­pose de deux ver­sions de son pro­to­cole en. La ver­sion moderne cou­rante est la v2. Elle est plus sûre, plus robuste, plus souple, et uti­lise des méthodes de chif­fre­ment plus récentes et plus fiables. La plu­part des clients sup­portent la v2 depuis un bon moment main­te­nant, donc pen­sez à désac­ti­ver le sup­port de la v1 sur votre propre ser­veur :

Pour des rai­sons de com­pa­ti­bi­li­té, nous pro­po­sions encore le sup­port de la v1 chez always­da­ta. Depuis la sor­tie d’OpenSSH 7.6, celle-ci est désor­mais tota­le­ment reti­rée du code source (elle n’est plus acti­vable même par le biais d’une com­pi­la­tion per­son­na­li­sée), véri­fiez donc que vous êtes à jour.

Utilisez des clefs SSH ED25519 robustes

Il existe plu­sieurs for­mats de clefs SSH. De pré­fé­rence, uti­li­sez un algo­rithme ED25519, puisqu’il pré­sente le meilleur choix actuel­le­ment en en termes de sécu­ri­té en. Il est rela­ti­ve­ment récent, mais assez bien sup­por­té en en pro­duc­tion à pré­sent, et si vous gérez votre ser­veur (ou pas­sez par un pres­ta­taire de qua­li­té), assu­rer son sup­port côté ser­veur reste tri­vial.

Cette com­mande va :
– géné­rer une nou­velle paire de clefs
-a en réglant le nombre de cycles de la fonc­tion de déri­va­tion employée à 1000, pour aug­men­ter le niveau de sécu­ri­té et le temps de déchif­fre­ment. Si la vitesse d’authentification est cru­ciale pour vous, vous pou­vez dimi­nuer cette valeur (par défaut à 16 ; 100 offrant une pro­tec­tion suf­fi­sam­ment robuste contre des attaques de force brute)
-t régler le for­mat à uti­li­ser sur l’algorithme ed25519
-C iden­ti­fier cette clef sur le modèle « nom d’utilisateur »/« appa­reil »

La protection réseau

Cette sec­tion contient des méthodes prin­ci­pa­le­ment à des­ti­na­tion des sysad­mins qui sou­haitent un haut niveau de sécu­ri­sa­tion. Elles peuvent, ou pas, s’appliquer selon vos contextes et votre modèle de menaces. Dans les faits, les deux par­ties ci-des­sus doivent suf­fire pour sécu­ri­ser pro­pre­ment la plu­part de vos accès dis­tants. Mais vous pou­vez avoir besoin d’augmenter votre sécu­ri­té d’un cran encore.

Filtrez l’accès au port TCP avec votre pare-feu

Si vous vous connec­tez tou­jours à vos ser­veurs depuis un parc d’IP dédié, il est inutile (voire dan­ge­reux) de lais­ser n’importe quelle connexion entrante ten­ter des authen­ti­fi­ca­tions. N’hésitez pas à res­treindre l’authentification SSH aux adresses connues dans vos règles de pare-feu.

Ici, nous auto­ri­sons seule­ment l’IP 10.111.111.10 (évi­dem­ment, sub­sti­tuez la vôtre) à se connec­ter au port 22 en TCP sur l’adresse locale de la machine (192.168.1.12) en uti­li­sant iptables en8). La ges­tion d’un pare-feu est sou­vent com­pli­quée, mais c’est une de vos défenses les plus robustes contre les attaques que vous aurez à subir.

Certaines de nos machines always­da­ta, qui sont en charge de sec­tions pri­vées de notre archi­tec­ture, ont leur accès public fil­tré de cette façon. Si vous avez un VPS ou un ser­veur dédié, vous pou­vez acti­ver ce fil­trage IP dans l’interface d’administration pour vous assu­rer que seules vos IPs sont auto­ri­sées à se connec­ter à vos ser­veurs.

Rejetez les attaquants SSH

L’un des pro­blèmes pro­vo­qués par des atta­quants qui ten­te­raient de péné­trer votre sys­tème est le nombre impor­tant de requêtes qu’ils vont géné­rer vers votre infra­struc­ture. Même s’ils ne par­viennent pas à obte­nir un accès, ces ten­ta­tives vont sur­char­ger votre ser­veur SSH, pro­ba­ble­ment ralen­tir votre sys­tème, et peut-être abou­tir à un DDoS. Pour évi­ter cela, vous pou­vez uti­li­ser votre pare-feu pour blo­quer les IPs des machines atta­quantes. Bien enten­du, il n’est pas ques­tion de les blo­quer manuel­le­ment. Vous devriez plu­tôt vous appuyer sur des outils comme fail2ban, DenyHosts, ou sur des règles de pare-feu avec iptables ou ufw pour un ban­nis­se­ment tem­po­raire auto­ma­tique.

Chez always­da­ta, les ser­veurs SSH sont pro­té­gés par un fil­trage fail2ban.

Modifiez le port SSH par défaut

OpenSSH écoute sur le port 22 par défaut. Ce réglage le rend vul­né­rable dans le sens où les atta­quants vont d’abord essayer ce port pour ten­ter de cibler des failles SSH. Si vous n’avez pas besoin d’une com­pa­ti­bi­li­té avec des clients externes, vous devriez chan­ger ce port par défaut et les inter­faces réseau sur les­quelles le ser­veur SSH écoute pour réduire sa sur­face d’attaque.

Port knocking

C’est l’une des tech­niques de pré­ven­tion les plus amu­santes.

Cette méthode consiste à for­cer l’utilisateur qui sou­haite se connec­ter au ser­veur SSH à se connec­ter avant à une série de ports dans un ordre pré­cis pour déclen­cher une règle de pare-feu qui ouvri­ra alors tem­po­rai­re­ment l’accès au port SSH pour votre IP. En uti­li­sant l’outil dédié knock, vous contac­te­rez votre ser­veur sur une séquence de ports. Si la séquence est cor­recte, le pare-feu est mis à jour et une nou­velle règle est ajou­tée pour votre IP vers le port SSH. Vous pou­vez alors vous connec­ter. Simple, sobre, élé­gant9)). Cette tech­nique uti­lise kno­ckd en.

Divers

C’est la der­nière sec­tion. Félicitations d’avoir lu cet article jusqu’ici ! Elle pré­sente des astuces pour aug­men­ter encore un peu votre sécu­ri­té. Elles sont sou­vent super­flues, mais il est tou­jours bon de les connaître.

Validez les empreintes de clefs SSH du serveur

Pour s’authentifier auprès du client, un ser­veur SSH pré­sente l’empreinte de sa clef pour pou­voir être recon­nu. Cette clef est géné­rée auto­ma­ti­que­ment et appar­tient à une unique ins­tance de ser­veur SSH. Il y a une clef par algo­rithme sup­por­té, et elles sont toutes pré­sen­tées au client selon ses pré­fé­rences. Vous pou­vez com­pa­rer cette empreinte de clef à votre pre­mière connexion avec celle indi­quée dans votre inter­face d’administration SSH pour vous assu­rer que vous contac­tez bien le bon ser­veur.

Les clients modernes sup­por­tant tous ED25519 en, vous pou­vez uni­que­ment ser­vir cette clef ser­veur et désac­ti­ver les autres clefs / méthodes sur votre ser­veur :

Chez always­da­ta, pour d’évidentes rai­sons de com­pa­ti­bi­li­té, nous conti­nuons de pré­sen­ter tous les for­mats dis­po­nibles.

Désactivez l’accès root

L’utilisateur root de votre machine est le super admi­nis­tra­teur de votre sys­tème Unix. Cet uti­li­sa­teur a tous les droits sur votre machine, y com­pris l’effacer complètement10). La plu­part du temps, vous n’avez pas besoin d’être roo­té pour vos actions cou­rantes sur votre machine, et vos per­mis­sions sys­tème sont là pour vous per­mettre d’exécuter vos com­mandes en toute sécu­ri­té. Désactiver l’accès dis­tant à l’utilisateur root est donc un bon réflexe, tout comme le fait de le désac­ti­ver loca­le­ment et tou­jours uti­li­ser sudo pour exé­cu­ter des com­mandes root. Ainsi, même si un uti­li­sa­teur mal­veillant réus­sit à avoir accès au ser­veur, il ne pour­ra pas s’octroyer faci­le­ment les pri­vi­lèges root.

Diminuez le temps de déconnexion en cas d’inactivité

Limiter le temps d’inactivité d’un uti­li­sa­teur est un bon moyen de pré­ve­nir l’utilisation mali­cieuse qui pour­rait être faite de son compte. Diminuez le nombre maxi­mum de connexions inac­tives simul­ta­nées et le temps maxi­mum d’inactivité pour vous assu­rer que per­sonne ne reste plus long­temps dans le sys­tème que néces­saire.

Enfermez les utilisateurs (chroot)

Les uti­li­sa­teurs authen­ti­fiés via SSH peuvent accé­der à l’intégralité du sys­tème de fichiers dis­tant. Ils sont iso­lés par les contraintes du sys­tème et les per­mis­sions des fichiers. Les enfer­mer dans leur espace uti­li­sa­teur peut être une bonne idée. Malheureusement, ce n’est pas tou­jours facile à mettre en pra­tique et cela requiert sou­vent de s’appuyer sur des outils comme rssh en. C’est une confi­gu­ra­tion com­plexe, mais si votre modèle de menaces implique des risques de fuites de don­nées mal pro­té­gées, c’est sans doute à consi­dé­rer.

wonder woman shield GIF @Giphy

J’espère que ce long billet de blog vous a per­mis de mieux com­prendre les enjeux liés à la pro­tec­tion des accès à dis­tance. Gérer l’ensemble de la sécu­ri­té de sa pile tech­nique néces­site des com­pé­tences avan­cées, notam­ment en cryp­to­gra­phie. Les conseils de cet article sont des­ti­nés à mieux vous équi­per, mais ne sous-esti­mez pas la dif­fi­cul­té de sécu­ri­ser tout votre sys­tème. Travailler avec des par­te­naires ayant plus d’expertise reste la meilleure façon d’assurer votre pro­tec­tion. C’est ce que nous fai­sons chez always­da­ta : nous nous assu­rons de gérer au mieux l’arbitrage flexi­bi­li­té / sécu­ri­té.

Si vous avez envie de dis­cu­ter de cyber­sé­cu, je serai au Breizhcamp de Rennes ven­dre­di pour par­ler de cryp­to­gra­phie et de déve­lop­pe­ment. Faites signe !

Notes   [ + ]

1. duck­duck­going/qwan­ting les res­sources qui vous manquent est éga­le­ment une bonne option
2. n’hésitez pas à poser vos ques­tions dans les com­men­taires éga­le­ment 🙂
3. et heu­reu­se­ment : vous ne vou­lez cou­rir le monde pour mettre à jour vos machines une par en vous y connec­tant phy­si­que­ment
4. ou quand vos col­la­bo­ra­teurs partent
5. publique et pri­vée
6. nous vous per­met­trons bien­tôt de sai­sir dans votre inter­face d’administration votre clef publique direc­te­ment
7. veillez à bien les sto­cker ensuite dans un ges­tion­naire de mots de passe
8. vous pou­vez jeter un œil à ufw en éga­le­ment pour écrire vos règles de pare-feu
9. because we can :
10. pour rap­pel, on ne rm -fr / jamais à l’aveugle