Prise en main du serveur
Chaque étudiant s'est vu assigner un serveur qui lui servira tout au long de cette semaine. L'objectif est de vous donner les bases de la mise en place d'un serveur.
Ces serveurs ont comme adresses vpsX.lpmiaw-lr.fr, X allant de 1 à 10.
Première connexion
Chaque serveur possède un compte lpmiaw vous permettant de vous connecter. Ce compte possède des droits root à travers la commande sudo.
Pour commencer, connectez-vous en SSH pour valider ces identifiants :
ssh lpmiaw@<votre-serveur>
SSH devrait vous demander votre mot de passe, puis ouvrir un terminal distant sur votre serveur.
Sécurisation du compte
Une fois connecté, changez votre mot de passe à l'aide de la commande passwd. C'est très important, il faut toujours modifier le mot de passe d'origine quand on vous en communique un.
Mise à jour du serveur
Il est important de garder un serveur à jour notamment pour corriger les failles de sécurité. On peut faire en sorte que le serveur se mette à jour tout seul. Debian possède des mises à jour sans danger appelées unattended upgrades qui remplissent ce rôle.
Cependant, si on veut mettre à jour à la main, voici les commandes à réaliser :
sudo apt update
sudo apt upgrade
Authentification par clé SSH
L'authentification par mot de passe, en plus de ne pas être très pratique, représente aussi un risque en termes de sécurité. Généralement, une des premières étapes lors de la prise en main d'un serveur consiste à désactiver cette possibilité, et de ne permettre la connexion qu'en utilisant une clé SSH.
Vous disposez normalement chacun d'une clé SSH dont vous vous servez pour envoyer votre code sur Gitlab. Nous allons utiliser cette dernière pour se connecter au serveur.
Comme vous le savez, le protocole SSH utilise un mécanisme de chiffrement asymétrique : vous disposez d'une clé privée, qui sert à déchiffrer les messages reçus, et d'une clé publique, qui sert à chiffrer des messages qui vous sont destinés.
Installer sa clé SSH
Pour être capable de vérifier votre identité, le serveur doit disposer de votre clé publique, qui doit être enregistrée comme clé autorisée pour votre utilisateur. Avec SSH, ces clés sont enregistrées dans le fichier /home/lpmiaw/.ssh/authorized_keys.
De même lors de la connexion au serveur, celui-ci vous communique sa clé publique qui est stockée sur votre machine dans le fichier ~/.ssh/known_hosts.
Vous pourriez ajouter manuellement votre clé SSH dans le fichier authorized_keys, mais il existe une alternative beaucoup plus pratique : la commande ssh-copy-id.
Cette commande se connecte au serveur distant, et ajoute automatiquement votre clé publique dans le bon fichier.
Voici un exemple d'utilisation :
ssh-copy-id lpmiaw@<votre-serveur>
Vous devez installer votre clé publique sur le serveur à l'aide de la commande ssh-copy-id.
Si la commande ne fonctionne pas, c'est probablement parce que votre clé n'est pas chargée dans l'agent SSH, ou tout simplement que vous n'avez pas d'agent SSH. Pour vérifier, vous pouvez essayer de lister les clés chargées dans votre agent SSH avec la commande suivante :
ssh-add -l
Si la commande vous renvoie une liste vide :
Vous avez un agent SSH, mais votre clé n'est pas chargée. Vous pouvez la charger avec la commande suivante :
ssh-add
Si votre clé n'est pas à un emplacement standard, vous pouvez spécifier son chemin à l'aide de la commande suivante :
ssh-add -i <chemin vers votre clé privée>
Si la commande vous informe que vous n'avez pas d'agent SSH :
Vous n'êtes pas obligé d'avoir un agent SSH pour copier votre clé publique sur le serveur. Vous pouvez spécifier à ssh-copy-id le chemin vers votre clé de la façon suivante :
ssh-copy-id -i <chemin vers votre clé> lpmiaw@<votre serveur>
Pour vérifier le bon fonctionnement de votre clé, essayez de vous connecter à votre serveur. Cette fois-ci, vous ne devriez pas avoir besoin de rentrer votre mot de passe.
Si vous n'avez pas d'agent SSH :
Vous pouvez spécifier à la commande SSH la clé privée à utiliser de la vôtre :
ssh -i <chemin vers votre clé privée> lpmiaw@<votre serveur>
Désactiver l'authentification par mot de passe
Maintenant que vos clés SSH sont configurées, vous n'avez plus besoin d'avoir la possibilité de vous connecter avec un mot de passe, vous pouvez donc désactiver cette fonctionnalité, améliorant ainsi grandement la sécurité de votre installation.
Le serveur SSH est configuré à l'aide d'un fichier situé à cet emplacement : /etc/ssh/sshd_config.
Il contient notamment une ligne permettant d'activer ou de désactiver l'authentification par mot de passe, qui ressemble à ceci :
PasswordAuthentication yes
Vous pouvez afficher son contenu à l'aide de la commande less :
less /etc/ssh/sshd_config.d/50-cloud-init.conf
Pour éditer ce fichier, vous ne disposez pas d'éditeur de texte classique, puisque vous êtes dans un terminal. Il existe cependant de nombreux éditeurs de fichiers textes qui fonctionnent dans un terminal.
Pour aujourd'hui, je vous propose d'utiliser un des plus intuitifs : nano mais rien ne vous empêche d'utiliser la commande vim si vous le souhaitez.
Ouvrez le fichier dans l'éditeur avec la commande suivante :
sudo nano /etc/ssh/sshd_config.d/50-cloud-init.conf
Naviguez jusqu'à la ligne citée précédemment, et mettez sa valeur à no.
Une fois ceci fait, vous pouvez sortir de l'éditeur avec le raccourci Ctrl + X. Nano devrait vous proposer de sauvegarder vos changements, en validant avec les touches Y ou N (pour yes ou no).
Maintenant que le fichier est modifié, vous pouvez redémarrer le serveur SSH pour qu'il prenne en compte vos changements avec la commande suivante :
sudo service ssh restart
Déconnectez-vous du serveur, puis essayez de vous y reconnecter sans clé SSH. Comme vous pouvez le constater, le serveur ne vous demande plus le mot de passe, et se contente de vous refuser la connexion.
Pour ceux qui disposent d'un agent SSH :
Vous pouvez retirer toutes les clés chargées dans votre agent avec la commande suivante :
ssh-add -d
On pourrait également modifier le numéro de port par défaut de notre serveur ssh pour éviter les attaques par force brute. Cependant, la DSI n'autorise que le port 22 pour les connexions SSH vers l'extérieur.
Pare-feu
Maintenant que vous avez installé vos clés SSH, l'étape suivante est d'installer un pare-feu (firewall) pour assurer la sécurité de votre serveur.
Cet outil permet de limiter l'accès à votre serveur depuis l'extérieur : il s'installe assez bas dans les couches réseau de votre serveur, et vérifie pour chaque paquet qu'il correspond bien aux règles que vous avez autorisées. Si le paquet ne correspond pas, il est immédiatement rejeté, et n'atteint jamais sa destination.
Installation
Sur votre serveur, la commande iptables permet de configurer votre pare-feu. Cependant, cette commande est complexe à utiliser, et rend la configuration particulièrement difficile pour un novice.
Il existe cependant des outils qui simplifient grandement la configuration d'un pare-feu. Je vous propose d'en utiliser un nommé UFW (pour Uncomplicated FireWall).
Tout d'abord, il nous faut installer ce programme, qui n'est pas livré par défaut sur notre serveur Debian. Pour ce faire, nous allons utiliser le gestionnaire de paquet de Debian, Aptitude.
Dans un premier temps, il faut demander au gestionnaire de paquet de mettre à jour ses sources, c'est-à-dire sa liste de paquets et leur provenance. Cette opération s'effectue avec la commande suivante :
sudo apt update
Maintenant que la liste des paquets disponibles est à jour, nous pouvons installer UFW avec la commande suivante :
sudo apt install ufw
Vous verrez probablement sur d'autres sites internet l'utilisation de la commande apt-get. Pour votre culture, sachez que cette dernière est plus adaptée à l'utilisation dans les scripts, mais que la commande interactive recommandée pour le terminal est aujourd'hui apt.
Configuration
Maintenant que UFW est installé, il nous faut configurer les règles de filtrage des paquets.
Au lieu de travailler avec des fichiers de configuration, UFW expose une ligne de commande assez simple à utiliser.
Vous pouvez d'ores et déjà utiliser la commande suivante pour lister les règles existantes :
sudo ufw status
Comme vous pouvez le constater, il n'y a encore aucune règle dans notre pare-feu.
Dans notre cas, nous auront besoin d'autoriser les accès suivants :
- L'accès SSH qui nous permet de nous connecter au serveur
- Les accès HTTP et HTTPS qui nous permettront d'accéder à notre application
Comme vous le savez sûrement, les ports d'entrée correspondant à ces protocoles sont les suivants :
- Port 22 pour SSH
- Port 80 pour HTTP
- Port 443 pour HTTPS
Par ailleurs, ces trois protocoles utilisent le protocole TCP.
Pour autoriser ces trois connections, nous pouvons utiliser la commande suivante :
sudo ufw allow proto tcp to any port 80
Nous demandons ainsi à ufw d'autoriser en entrée l'accès au port 80 sur le protocole TCP.
Faîtes de même pour SSH et HTTPS. Une fois que vos modifications vous semblent convenables, vous pouvez activer le pare-feu avec la commande suivante :
sudo ufw enable
Attention ! Si vous avez fait une erreur, vous risquez de vous retrouver coinçés à l'extérieur de votre serveur !
Vous pouvez vérifier que vous pouvez toujours vous connecter en SSH depuis un autre terminal.