Securiser mon dédié#1 Usage sécurisé d’(Open)SSH

randommart.png

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 webNginx + PHP7-fpm + MariaDb
Serveur de messageriePostfix + Dovecot + Amavisd-new + spamassassin + dspam + clamav
ContainerisationDocker, 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:

Screenshot_20180112-220600.png

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 Dotcleår 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.

Annexes

Commentaires

1. Le dimanche, janvier 14 2018, 15:40 par Guillaume

Bonjour,

j'essaie depuis quelques temps d'installer Collabora Online avec Pydio et je n'y arrive pas. Quel tutoriel as-tu utiliser pour installer Collabora ?

Merci

2. Le dimanche, janvier 14 2018, 15:56 par gnieark

Ce tuto tout simplement https://nextcloud.com/collaboraonli...

Par contre, ça déconnait l'autre jour, j ai simplement redémarré Docker et c'etait reparti.

PS Si tu utilises "localhost" dans les paramètres du proxy et que la résolution de localhost se fait en IPV6 (::1) je crois que ça déconne. (Je n'ai pas poussé les tests pour confirmer que c'est systématique)

Comme j'utilise nginx, voici les paramètres du vhost:

upstream collada-office { server 127.0.0.1:9980;
}
server {

   listen 443 ssl;
   server_name office.tinad.fr;
   ssl_certificate /etc/letsencrypt/live/tinad.fr/fullchain.pem;
   ssl_certificate_key /etc/letsencrypt/live/tinad.fr/privkey.pem;
   # static files
   location ^~ /loleaflet {
       proxy_pass [https://collada-office;]
       proxy_set_header Host $host;
   }
   # WOPI discovery URL
   location ^~ /hosting/discovery {
       proxy_pass [https://collada-office;]
       proxy_set_header Host $host;
   }
   # Main websocket
   location ~ /lool/(.*)/ws$ {
       proxy_pass [https://collada-office;]
       proxy_set_header Upgrade $http_upgrade;
       proxy_set_header Connection "Upgrade";
       proxy_set_header Host $host;
       proxy_read_timeout 36000s;
   }
   # Admin Console websocket
   location ^~ /lool/adminws {
       proxy_buffering off;
       proxy_pass [https://collada-office;]
       proxy_set_header Upgrade $http_upgrade;
       proxy_set_header Connection "Upgrade";
       proxy_set_header Host $host;

location ^~ /hosting/discovery {

       proxy_pass [https://collada-office;]
       proxy_set_header Host $host;
       proxy_read_timeout 36000s;
   }
   # download, presentation and image upload
   location ~ /lool {
       proxy_pass [https://collada-office;]
       proxy_set_header Host $host;
   }

}

Ajouter un commentaire

Les commentaires peuvent être formatés en utilisant une syntaxe wiki simplifiée.

La discussion continue ailleurs

URL de rétrolien : https://blog-du-grouik.tinad.fr/trackback/1027

Fil des commentaires de ce billet

Page top