Securiser mon dédié#1 Usage sécurisé d’(Open)SSH
::TOC::
Introduction
J'ai récemment réinstallé le serveur qui héberge entre autres ce blog (il me reste à finaliser la protection de la messagerie, et peaufiner quelques réglages).
A peu près dans le même temps, je redécouvrais les guides de bonnes pratiques de l'ANSSI La majorité des documents sont très bien faits, précis, techniques et parfois m’apprennent des choses.
L'idée m'est venu de faire une série de billets sur la sécurisation de mon serveur en suivant les recommandations de l'ANSSI.
Mon serveur dédié (Debian 9, 32Go de RAM) a les fonctions suivantes:
| Serveur web | Nginx + PHP7-fpm + MariaDb |
|---|---|
| Serveur de messagerie | Postfix + Dovecot + Amavisd-new + spamassassin + dspam + clamav |
| Containerisation | Docker, pour le moment un seul container: collabora Online |
Sécurisons le SSH en suivant les recommandations de l'ANSSI.
Le document de référence pour ce premier billet est Usage sécurisé d’(Open)SSH pour la suite je reprends le chapitrage du document en question.
Dans la suite, à chaque fois qu'on modifiera le fichier /etc/ssh/sshd_config, il faudra relancer le service ssh pour que ce soit pris en compte.
service sshd restart
Par prudence, en supposant que le SSH soit votre seul moyen d"accès au serveur. Avant de faire les manipulations, je vous invite à ouvrir une connexion ssh vers celui-ci et laisser le terminal dans un coin de votre PC. Si jamais vous faisiez une erreur et plantiez sshd, normalement cette connexion restera ouverte et vous permettra de corriger.
Protocole SSH
Afin d'être sûr que seul ssh 2 est utilisé [1], on ajoute
Protocol 2
dans le fichier /etc/ssh/sshd_config.
Authentification du serveur
Je ne changerai rien de mon coté, par défaut openssh a le comportement Trust On First Use (TOFU), puis utilise le knowHost pour prévenir si le serveur présente une identité incorrecte.
Cryptographie
Types de clefs
En résumé: (dixit l'ANSSI)
- Clefs DSA à bannir
- Clefs RSA OK à partir de 2048bits minimum
- Clefs ECDSA OK et à préférer à partir de 256bits
Appliquons, sur le(s) pc clients, on remplace les clefs par des ECDSA
#Creer une clef (les longueurs possibles sont 256, 384 or 521, ne me demandez pas pourquoi) #Par défaut il met la clef publique dans /home/yourUser/.ssh/id_ecdsa.pub # et la clef privée /home/yourUser/.ssh/id_ecdsa ssh-keygen -t ecdsa -b 521
Envoyer la clef sur le serveur (en utilisant le mot de passe ou l'ancienne clef), Depuis votre client; en remplaçant gnieark@serveur.domaine.com par ce qu'il faut:
ssh-copy-id -i ~/.ssh/id_ecdsa.pub gnieark@serveur.domaine.com
Choix des algorithmes symétriques
J'ajoute dans le fichier /etc/ssh/sshd_config du serveur
Ciphers aes256-ctr,aes192-ctr,aes128-ctr MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
afin d'écarter les algorithmes faibles.
Après avoir fait ça, ça fonctionne depuis mon PC, mais depuis mon téléphone portable avec l'application JuiceSSH:
Que faire? le document de l'ANSSI qui date de 2015 dit:
Les HMAC SHA-256 et SHA-512 ne sont supportés que depuis la version 5.9 d’OpenSSH. Les systèmes d’exploitation utilisant des versions antérieures doivent alors reposer sur un HMAC SHA-1.
On pourrait ajouter le SHA-1 dans la liste, JuiceSSH semble le supporter.Mais très récemment, les chercheurs de Google ont réussi à créer une collision en SHA1[2] Au final pour résoudre ce problème, j'ai ajouté l'algo hmac-sha2-256 dans la directive MACs, comme ceci:
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-256
Durcissement du système
Concernant cette partie des recommandations, Je saute le passage concernant l'isolement des utilisateurs et le mode "sandbox" d'openssh. parce que je suis seul à administrer ce serveur [3] [4].
SFTP et Chroot
Il est possible de "chrooter"[5] les users sftp. Et ça ça m'arrange, car les rares utilisations du sftp que je fais sont pour les données des sites web. Mais ça, je l'aborderai dans le billet à venir sur la sécurisation des sites web #teasing
Bloquer les tentatives de force brute
Ajouter au sshd_config
MaxAuthTries 2 LoginGraceTime 30
Au bout de 2 essais ratés, le client (ou attaquant) devra attendre 30s.
Bon, ok, du brute force sur l'authentification par clef, ça fait sourire. Mais c'est toujours un durcissement, et il m'arrivera, (et vous arrivera) de temps en temps de repermettre l'authentification par mot de passe. Le temps d'ajouter une nouvelle clef par exemple.
Et tant qu'à faire, autant laisser openssh gérer ça nativement à priori, que le faire gérer par fail2ban à postériori[6]
Authentification et contrôle d’accès utilisateurs
Afficher la précédente connexion,Interdire l'accès à root et les mots de passe:
PrintLastLog yes PasswordAuthentication no PermitRootLogin no
Sortons du cas de mon serveur personnel. Il est aussi possible d'assouplir les règles. Imaginez un serveur pour lequel un acces SSH est utile depuis l'extérieur, mais depuis le LAN vos collègues tiennent à utiliser windows. La gestion des clefs avec Putty est galère.
De cette manière les users provenant du LAN (et pas depuis internet) et du groupe downstairs pourront quand même se connecter, tout en laissant l'authentification par clef obligatoire depuis l'extérieur.
Match Address 192.168.0.0/16 Group downstairs
PasswordAuthentication yes
[7]
Un peu de la même manière, dans les tutos, AllowUsers est généralement présenté avec simplement la liste des utilisateurs autorisés. Mais on peut aussi préciser leur subnet. Par exemple:
AllowUsers admin@192.168.17/24 user@10.127/16
Faire des rebonds ssh.
Faire des rebonds vous obligera à laisser des identifiants dans les serveurs intermédiaires. l'idéal est d'encapsuler les connexions ssh les unes dans les autres. Le programme assh écrit par Manfred sert justement à ça.
Protocole et accès réseaux
Idéalement l'acces SSH pour l'administration se fait via un autre acccès (la carte réseau et l'IP du serveur dédiée à l'administration). Dans le cas de mon serveur personnel, ce n'est pas faisable.
X11Forwarding
Le danger se situerait plutot dans l'autre sens, si le serveur a été corrompu, le x11forwarding pourrait permettre de faire fuiter des données de votre PC client.[8]
Le désactiver:
X11Forwarding no
D'autant que mon serveur n'ayant pas d'interface graphique, ce serait idiot.
Conclusion
Ça me parait plus rigoureux à présent ma gestion d'openssh. Je vous invite à nouveau à lire le document de l'ANSSI, car il y a quelques parties sur lesquelles j'ai fait l'impasse.
Prochain billet dans cette thématique (sécuriser son serveur dédié) à venir d'ici deux semaines je pense.
Notes
[1] Changement de standard pour le protocole ssh, la version 1 présentait des vulnérabilités
[2] Il me semble peu probable qu'une collision trouvée, avec l'aide de datacenters entiers représente réellement une faille dans le sha1 concernant le ssh, mais bon par principe c'est obsolète. SHA1 : Google provoque une collision et signe l’arrêt de mort de la fonction
[3] le seul à avoir l’accès système, mais plusieurs admin sur la plateforme Dotclear et sur Nextcloud.
[4] Il m'est déjà arrivé d'enregistrer temporairement dans le fichier authorized_keys la clef ssh publique d'un ami, ou d'un membre du hackerspace. A chaque fois, quelqu'un de confiance que je connais IRL et administrateur systèmes ou dev ops dans sa vraie vie, manipulant au quotidien des données beaucoup plus sensibles que ce qu'il y a sur mon serveur. C'est arrivé pendant mes vacances dans des coins sans 3G ou encore pour une aide sur l'optimisation du serveur. Moins d'une fois par an
[5] meilleure traduction: encager?
[6] Fail2Ban analyse les logs pour créer des règles iptables, il y a donc toujours un petit décalage entre l'évènement et l'action.
[7] Voir ce thread sur le forum ubuntu
[8] J'ai la flegme de faire un POC. En résumé, Celui qui a corrompu le serveur fait un alias d'une commande classique pour la transformer en service X window, qui pourra enregistrer vos frappes clavier.