Je vois que les serveurs pour cruncher sont à la mode, donc voici une Histoire de l’Oncle Bob pour pouvoir en profiter en toute sérénité. C’est comme une histoire du Père Castor, mais avec un lapin
Je pars du principe que votre serveur est sous Linux parce que c’est gratuit, et plus précisément sous Debian parce que c’est un OS très documenté et dont l’optique est la stabilité au détriment de la nouveauté (et vu que vous ne vous en servez que pour cruncher, vous n’avez pas envie qu’une mise à jour foireuse vous flingue l’OS).
C’est un serveur distant, donc vous ne pouvez vous y connecter qu’à distance (merci capitaine). Le moyen le plus simple à mettre en place et le plus économe en ressource est de loin le bon vieux SSH.
Sauf que par défaut, c’est un peu
open-bar.
I) Les packagesIl y a quelques packages bien pratiques pour commencer à sécuriser son accès. J’en citerai particulièrement deux :
fail2ban, qui fait office de videur de boite-de-nuit, et
unattended-upgrades qui maintient votre système à jour.
I-a) fail2banFail2ban est un service qui va blacklister une IP qui se planterait trop de fois pour se loguer pendant un cours laps de temps. Par défaut, c’est trois erreurs en 10 minutes qui conduisent à un ban de 10 minutes. Je vous conseille de laisser ça ainsi, personne n’a envie de s’auto-ban pendant un an sans possibilité de se connecter physiquement à la machine pour retirer sa propre IP de prison
(Notez cependant que votre fournisseur de serveur peut avoir prévu un « Rescue mod » qui peut permettre de reprendre la main quand tout est planté. Il me semble que c’est le cas chez Kimsufi par exemple).
Vous pouvez modifier le comportement de fail2ban et/ou ajouter des prisons supplémentaires en copiant le fichier
/etc/fail2ban/jail.conf en
/etc/fail2ban/jail.local puis en éditant ce dernier. On évite d’éditer directement jail.conf car si on se plante, c’est fichu. Alors que si vous plantez un jail.local, il suffira de le supprimer et de recopier jail.conf pour avoir de nouveau un jail.local fonctionnel. Jail.local prend TOUJOURS le pas sur jail.conf.
apt install fail2ban
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
nano /etc/fail2ban/jail.local
Enfin, assurez-vous que fail2ban tourne bien :
systemctl restart fail2ban
systemctl enable fail2ban
Quelques commandes utiles (remplacez le texte entre < > par ce qui est demandé) :
- Voir les prisons :
fail2ban-client status
- Voir les IP bannies d’une prison :
fail2ban-client status <jail_name>
- Retirer une IP de prison :
fail2ban-client set <jail_name> unbanip <ip_address>
- Mettre une IP en liste blanche :
fail2ban-client set <JAIL_NAME> addignoreip <IP_Address>
Attention, il faut que ça soit votre IP publique, pas votre IP locale qui commence par le classique 192.168…
- Mettre une IP en liste blanche en éditant directement le fichier de configuration : ajouter (ou complétez) la ligne suivante dans le paragraphe concernant la prison visée (ici celle pour le SSH : sshd) :
ignoreip = 127.0.0.1/8 <IP_TO_BE_WHITELISTED>
- Retirez une IP de la liste blanche : soit vous éditez votre fichier de configuration, soit vous entrez la commande suivante (suivant la façon dont vous avez whitelisté l’IP en question) :
fail2ban-client set <JAIL_NAME> delignoreip <IP_Address>
I-b) unattended-upgradesA venir, je ne maitrise pas encore
Unanttended-upgrades installe automatiquement les mises-à-jour de sécurité.
I-c) Packages divers-
htop : permet de voir les processus qui tournent et leur conso CPU/mémoire.
- lm-sensors : une fois installé, lancez
sensors-detect pour détecter les sondes présentes sur la machine (à faire une seule fois). Il va vous demandez plusieurs fois si vous voulez scanner tel ou tel trucs, vous pouvez répondre oui partout. Une fois terminé, il vous suffira de taper
sensors pour remonter les infos des diverses sondes trouvées, les plus intéressantes pour nous étant celles de température CPU. Attention, des sondes peuvent être foireuses ou mal lues et renvoyer des résultats aberrants (températures négatives ou bien au-delà de 100°C, par exemple).
-
smartmontools : permet de faire des testdisk et monitorer les données SMART. Il me semble intéressant de lancer régulièrement et automatiquement des tests via un cron.
II) Sécuriser son accès SSH (parce que fail2ban ne fait pas tout).Il va falloir éditer le fichier de configuration du ssh :
/etc/ssh/sshd_configCertaines lignes existent déjà, mais sont commentées (elles commencent par un #). Dans ce cas, décommentez les et modifiez leur valeur comme indiqué.
Si vous éditez votre fichier via
nano (c’est l’éditeur le plus simple), et que vous ne savez pas utiliser la recherche avec, je vous renvoie vers cette page =>
https://askubuntu.com/questions/47515/any-way-to-search-for-text-within-nanoCes recommandations ne sont pas exhaustives (cherchez « secure SSH » sur internet pour en trouver plein d’autres), mais me semblent les plus intéressantes à mettre en place dans notre usage.
- Changer de port (facultatif) : Par défaut c’est le 22, mettez un port non utilisé. Un truc dans les 40 000 ira bien. Ça sert juste à diminuer un peu les tentatives de connexions par des bots mal codés, mais ça se fait en 2 secondes et ça ne mange pas de pain, pourquoi s’en priver ?
- N’utiliser que le protocole 2 (
obligatoire, le protocole 1 a des failles de sécurité) :
Protocol 2
En général cette ligne est déjà présente.
- Interdire le log en root (
obligatoire) : c’est de très loin le login le plus tenté par les bots, car il existe obligatoirement ET il donne les pleins pouvoirs.
PermitRootLogin no
Rappelons que si vous n’avez que l’utilisateur root sur votre système, vous pouvez créer un utilisateur avec les commandes suivantes (disons « tonton » dans mon cas) :
adduser tonton
- Autoriser seulement certains utilisateurs à se connecter (facultatif) :
AllowUsers tonton tata
Par défaut je ne mets qu’un utilisateur qui n’est pas sudoer (dans cet exemple il y a deux utilisateurs autorisés à se connecter en SSH : tonton et tata).
- Ne pas autoriser de mot de passe vide (facultatif) :
PermitEmptyPasswords no
Enfin, quittez le fichier de config et redémarrez le service :
service ssh restart
III) Se loguer avec une clef.La clef, ou plutôt les clefs puisqu’on parle d’un couple clef privée-clef publique, va permettre un autre type d’authentification. La machine qui souhaite se connecter au serveur devra obligatoirement posséder une des clefs référencées sur le serveur pour pouvoir se connecter, ce qui rend inopérant le brute-force classique sur les couples login/mot de passe (c'est-à-dire tenter toutes les combinaisons possibles jusqu’à tomber sur le bon couple login/mot de passe).
Pour cela, il va falloir créer un couple clef privée/clef publique sur votre machine locale puis envoyer la clef publique sur le serveur.
Il faut bien comprendre que chaque machine « locale » a une paire de clefs différente, et que le serveur sur lequel on veut se loguer a la liste des clefs qu’il doit accepter. Transposé dans la vraie vie, imaginez une serrure électrique qui peut accepter une liste de badges (et seulement eux) pour s’ouvrir : si vous vous pointez avec un badge non référencé ou simplement les mains dans les poches, la serrure ne s’ouvrira pas.
Il y a deux façon de procéder, suivant si votre ordi est sur une base UNIX (Linux et MacOS) ou si vous êtes windowsien. Il y a de nombreux tutoriels sur internet, en voici un parmi tant d’autres :
https://www.linode.com/docs/security/authentication/use-public-key-authentication-with-ssh/III-a) UNIX (Linux/MacOS)III-a-1) Création de la paire de clef.Une fois n’est pas coutume, cette étape ne se fait pas en root ni sur votre serveur : il faut la faire sur votre ordi local avec l’utilisateur que vous avez quand vous voulez joindre votre serveur via ssh. L’utilisateur en question n’a pas besoin d’être identique celui de votre serveur (je peux donc créer ma clef avec l’utilisateur « oncle » sur mon PC local alors que je me loguerai en tant que « tonton » sur le serveur).
Si vous possédez déjà une paire de clefs sur votre machine, vous pouvez sauter cette étape.
Ouvrez un terminal, et entrez
cd /home/user/.ssh
ssh-keygen -b 4096 –C "moncommentaire"
en remplaçant user par votre nom d’utilisateur (« oncle » dans notre exemple).
La clef générée est de type RSA et fait 4096 bits. Il vous sera peut-être demandé une passphrase pour la protéger (son utilisation demandera à chaque fois d’entrer la passphrase). Notez qu’une passphrase n’est rien d’autre qu’un mot de passe qui accepte des espaces, telle que « 1, 2, 3 nous irons aux bois ». Ainsi, si on vous dérobe votre ordinateur, le voleur ne pourra pas se loguer à votre serveur puisqu’il aura la clef, mais pas la passphrase pour l’utiliser. Attention, au moment de taper la passphrase puis sa confirmation, rien ne s’affiche à l’écran. C’est normal, c’est une mesure de protection sous linux.
Le commentaire servira à vous rappeler que cette clef vient de votre machine locale bidule et vous sert à vous connecter à votre serveur. Par exemple « GrosPC-Joe4 ».
Si on ne vous a pas demandé la passphrase à la création de la clef, vous pouvez la protéger ultérieurement en entrant
ssh-keygen –p
Cela peut aussi servir pour changer la passphrase de la clef.
Vous avez maintenant créé votre paire de clefs et l’avez protégée via une passphrase, bravo ! Reste à la balancer sur votre serveur.
III-a-2) Envoi de la clef au serveurPour cela, rien de plus simple :
ssh-copy-id –i maclef.pub tonton@192.168.1.20 –p 22
Remplacez tonton par votre user sur votre serveur, l’IP par celle du serveur et « 22 » par le numéro de port SSH du serveur (si vous ne l’avez pas changé, vous pouvez enlever l’argument « -p », ça tentera le port 22 par défaut). De même, si vous n’avez pas donnez de nom à votre clef lors de sa création, inutile d’utiliser l’argument « -i maclef.pub », ça va envoyer /home/user/.ssh/id_rsa.pub
Sous Mac apparemment faut l’installer manuellement :
brew install ssh-copy-id
Tentez maintenant de vous loguer en ssh sur votre serveur :
ssh tonton@192.168.1.20 –p 22
Passez
root sur votre serveur et éditez
/etc/ssh/sshd_config que nous avions au préalable déjà modifié.
Passez
PubkeyAuthentication à
yes, sauvegardez, relancez le service ssh (service ssh restart) puis quittez le serveur.
Et reloguez vous en ssh à votre serveur !
Si tout va bien, on va vous indiquer que vous vous loguez via une clef et qu’il lui faut sa passphrase.
Toujours sur votre serveur, protégez le fichier où est stocké la clef en lui donnant les droits appropriés :
chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys
Vous pouvez maintenant désactiver l’authentification par mot de passe et activer celle par clef : retournez en root sur /etc/ssh/sshd_config, et passez
PasswordAuthentication à
no.
Attention ! Cela désactive l’accès par mot de passe, il vous faudra donc impérativement une clef reconnue par le serveur pour vous y connecter en ssh !
Sur votre machine locale, prenez bien garde de faire des sauvegardes de votre clef sur d’autres supports.
III-b) WindowsC’est un peu plus chiant, et le plus simple est de passer via
PUTTY.
Vu que ça va nécessité plein de captures d’écrans et que j’en suis déjà à 5 pages de blabla, je vous laisse un lien qui détaille l’opération :
https://www.linode.com/docs/security/authentication/use-public-key-authentication-with-ssh/tl ;dr : C’est pareil que sous linouche, sauf que va falloir convertir la clef à un moment.