Pour sécuriser un serveur Linux de base, nous allons aborder un certain nombre de principes et de logiciels que l’on peut considérer comme indispensable sur un serveur en production. Il fait suite à l’installation d’un serveur Ubuntu et fait parti de la suite d’article Monter son site Web à 100 %.
Nous n’aborderons que les grandes lignes de la sécurisation d’un serveur. Il existe de nombreuses ressources sur Internet et de nombreux livres qui traitent du sujet.
Une partie des recommandations que je vais vous faire, s’appuie sur les recommandations de l’ANSI et encore je n’aborderai pas toutes les configurations considérées comme minimal. Ce guide est avant tout destiné aux professionnels.
Table des matières
Étape 1 : sécuriser les utilisateurs
sudo
La première chose à faire pour sécuriser un serveur Linux de base, c’est de définir les rôles et les droits de vos utilisateurs. Comme annoncé précédemment, l’utilisateur root n’est plus accessible directement.
Aujourd’hui, il y a deux types d’utilisateurs : les utilisateurs avec pouvoir et les utilisateurs sans pouvoir. Les utilisateurs avec pouvoir sont des utilisateurs qui peuvent utiliser des commandes qui avant étaient réservées au compte root, en les précédant de la commande sudo.
La commande sudo permet de gérer de manière très fine les autorisations à donner. Il est possible d’attribuer les droits soit un utilisateur, soit un groupe d’utilisateurs. Cependant, cette configuration peut rapidement devenir un véritable cauchemar pour l’administrateur. Elle est donc réservée à des personnes qui savent ce qu’elles font. Dans ce tutoriel pour sécuriser un serveur Linux de base, je n’aborderai pas cette configuration, mais uniquement son utilisation.
L’utilisateur qui a été créé lors de l’installation du système, a automatiquement été mis dans le groupe sudo. Vous n’avez donc rien à faire de particulier. Un autre article présentant plus en profondeur sudo abordera ce sujet.
Pour exécuter une commande en mode root :
gabriel@serveurweb:~$ sudo commande
Pour exécuter une commande avec les droits d’un utilisateur spécifique :
gabriel@serveurweb:~$ sudo -u compte commande
Note : cette dernière commande vous sera très souvent utile dans le cadre de l’administration des sites Web afin que les opérations soient effectuées directement par l’utilisateur du serveur HTTPD.
Les comptes de services.
Pour sécuriser un serveur Linux de base, il est nécessaire de réduire au strict minimum les logiciels utilisant les droits root. Ainsi en cas de compromission du service, celui-ci aura peu d’impact sur le reste du système.
Lors de l’installation de nombreux logiciels, ceux-ci peuvent créer un compte de service. Par défaut, ces comptes ont un UID inférieur à 1000. La majorité de ces comptes sont désactivés par défaut. Le seul moyen d’utiliser les droits d’un de ses comptes et de passer par la commande sudo une fois encore.
Si vous devez créer ce type de compte pour une application précise, il est recommandé de créer utilisateurs avec les options suivantes :
- -r : pour demander au système de choisir un UID inférieur à 1000.
- -M : pour que la commande ne crée pas un home directory. Uniquement si l’utilisateur est un utilisateur normal. Par défaut, pour les utilisateurs système, il n’y a pas de création du home directory.
- -d /chemin/vers_home : pour fournir le chemin du home directory si celui-ci est nécessaire. Je vous conseille de mettre le chemin en mode absolu et non pas en mode relatif.
- -s /usr/sbin/nologin : nous définissons le shell avec une option qui interdit de se connecter.
gabriel@serveurweb:~$ sudo useradd -rs /usr/sbin/nologin
N’hésitez pas à les vérifier dans le fichier /etc/passwd que le dernier champ de la ligne du compte en question est bien : /usr/sbin/nologin.
Note : nous l’avons appliqué lors de l’installation du serveur subversion.
Étape 2 : mettre en place un pare-feu
Théorie
Pour sécuriser un serveur Linux de base présence sur Internet, il faut installer obligatoirement un pare-feu logiciel. Sa mission est de surveiller le trafic qui arrive sur les ports IP du serveur.
Il existe deux types d’autorisation : autoriser ou refuser. Sans rentrer profondément dans la théorie du protocole IP, il faut savoir que chaque adresse IP est adressable sur un port particulier et qu’il y en a plusieurs dizaines de milliers. Un certain nombre de ses ports sont normalisées comme le port 22 est réservé à SSH et le port 443 est réservé à https. Sachez aussi que cette normalisation est informative et non pas obligatoire. Il faut juste que les différents interlocuteurs du logiciel utilisent le même port.
Sur un serveur qui n’est pas équipé d’un pare-feu logiciel, la totalité de ses ports sont autorisées. C’est-à-dire, n’importe quel logiciel qui écoute sur un de ses ports accepte sera la communication.
Au contraire si le serveur est équipé d’un pare-feu logiciel, la totalité de ses ports seront refusés. C’est-à-dire que le serveur ne sera plus en mesure de communiquer avec le reste du réseau. Certain pare-feu logiciel ouvre automatiquement certains ports lors de leur installation telle que le SSH.
Pourquoi fermer des ports ?
Sur Internet, il y a de nombreux logiciels qui vont tester si un port est ouvert ou pas. Cela va consommer de la puissance à votre serveur qui va répondre à des sollicitations qui ne sont pas voulues. Si le trafic n’est pas autorisé, le pare-feu n’initialise rase aucune communication. De plus, si un logiciel malveillant a réussi à s’installer sur le serveur. Sans pare-feu logiciel, il pourra communiquer directement avec les auteurs du logiciel. S’il y a un pare-feu, il sera obligé d’utiliser soit les ports déjà ouverts, soit modifier la configuration du pare-feu pour autoriser son trafic. Cela complexifie le travail des hackeurs.
Note : il existe des configurations plus avancées qui permettent différentes choses telles qu’autoriser tout le trafic sortant, n’autoriser que certaines adresses pour certains ports, choisir le protocole utilisé (TCP/UDP), etc. l’option n’autorisait que tout le trafic sortant, permet par exemple de s’assurer que les connections ne sont initialisées qu’à partir du serveur et non pas à partir de l’extérieur.
Pratique
Sous Linux, la gestion du réseau est effectuée directement par le noyau. La configuration se fait à partir de l’intermédiaire d’un outil qui se nomme IPtable. Si ce dernier est extrêmement puissant, il est aussi assez difficile à prendre en main. Un certain nombre d’interfaces ont alors été créé pour une utilisation plus simple. Pour sécuriser un serveur Linux de base, nous allons utiliser ufw qui est installé mais qui pas activé par défaut sur Ubuntu.
Si ce dernier n’est pas installé, vous pouvez le faire de la manière suivante :
gabriel@serveurweb:~$ sudo apt install ufw gabriel@serveurweb:~$ sudo ufw status Status : inactive Pour activer le pare-feu : gabriel@serveurweb:~$ sudo ufw enable Command may disrupt existing ssh connections. Proceed with operation (y|n) ? y Firewall is active and enabled on system startup Pour ajouter le service SSH : gabriel@serveurweb:~$ sudo ufw allow ssh Rule added Rule added (v6) pour voir le statut du pare-feu : gabriel@serveurweb:~$ sudo ufw status Status : active To Action From -- ------ ---- 22/tcp ALLOW Anywhere 22/tcp (v6) ALLOW Anywhere (v6)
Au fur et à mesure que nous monterons les différents services, nous allons rajouter de nouveaux services ou de nouveaux ports au pare-feu et ainsi continuer à sécuriser un serveur Linux de base.
Étape trois : mettre en place fail2ban
Ce merveilleux logiciel est un logiciel qui modifie les règles du pare-feu. Il se base sur les logs de tentative de connexion. Il bannit selon des règles prédéfinies, pendant un temps donné les adresses IP ayant eu un certain nombre de connexions échouées. Extrêmement puissant, il faut le configurer avec que soins si vous ne souhaitez pas vous faire bannir de votre propre serveur.
L’installation du logiciel se fait via le gestionnaire de paquets.
Note : à l’heure de l’écriture de cet article, le paquet présent dans les dépôts officiels ne fonctionne pas. Le correctif c’est par la communauté n’a pas encore été mis dans les dépôts stables. En revanche, il est disponible dans le dépôt noble-proposed. Ce dépôt n’est pas recommandé pour une utilisation sur des serveurs en production. Nous allons donc que l’activer uniquement pour pouvoir installer le logiciel, puis nous le désactiverons.
L’activation se fait en rajoutant noble-proposed dans le fichier des sources qui se trouve /etc/apt/sources.list.d/ubuntu.sources. À l’issue votre fichier devrait être le même que celui-ci :
gabriel@serveurweb:~$ sudo vim /etc/apt/sources.list.d/ubuntu.sources Types: deb URIs: http://fr.archive.ubuntu.com/ubuntu/ Suites: noble noble-updates noble-backports noble-proposed Components: main restricted universe multiverse Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg Types: deb URIs: http://security.ubuntu.com/ubuntu/ Suites: noble-security Components: main restricted universe multiverse Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg
Une fois la modification effectuée, nous devons mettre à jour le dépôt par la commande standard c’est-à-dire :
gabriel@serveurweb:~$ sudo apt update Atteint :1 http://fr.archive.ubuntu.com/ubuntu noble InRelease Atteint :2 http://fr.archive.ubuntu.com/ubuntu noble-updates InRelease Atteint :3 http://fr.archive.ubuntu.com/ubuntu noble-backports InRelease Réception de :4 http://fr.archive.ubuntu.com/ubuntu noble-proposed InRelease [265 kB] Atteint :5 http://security.ubuntu.com/ubuntu noble-security InRelease Réception de :6 http://fr.archive.ubuntu.com/ubuntu noble-proposed/main amd64 Packages [114 kB] Réception de :7 http://fr.archive.ubuntu.com/ubuntu noble-proposed/main Translation-en [29,2 kB] Réception de :8 http://fr.archive.ubuntu.com/ubuntu noble-proposed/main Translation-fr [491 kB] Réception de :9 http://fr.archive.ubuntu.com/ubuntu noble-proposed/main amd64 Components [44,1 kB] Réception de :10 http://fr.archive.ubuntu.com/ubuntu noble-proposed/main amd64 c-n-f Metadata [3 508 B] Réception de :11 http://fr.archive.ubuntu.com/ubuntu noble-proposed/restricted amd64 Packages [93,0 kB] Réception de :12 http://fr.archive.ubuntu.com/ubuntu noble-proposed/restricted Translation-en [17,3 kB] Réception de :13 http://fr.archive.ubuntu.com/ubuntu noble-proposed/restricted Translation-fr [3 292 B] Réception de :14 http://fr.archive.ubuntu.com/ubuntu noble-proposed/restricted amd64 Components [212 B] Réception de :15 http://fr.archive.ubuntu.com/ubuntu noble-proposed/restricted amd64 c-n-f Metadata [116 B] Réception de :16 http://fr.archive.ubuntu.com/ubuntu noble-proposed/universe amd64 Packages [72,4 kB] Réception de :17 http://fr.archive.ubuntu.com/ubuntu noble-proposed/universe Translation-fr [3 898 kB] Réception de :18 http://fr.archive.ubuntu.com/ubuntu noble-proposed/universe Translation-en [30,4 kB] Réception de :19 http://fr.archive.ubuntu.com/ubuntu noble-proposed/universe amd64 Components [42,4 kB] Réception de :20 http://fr.archive.ubuntu.com/ubuntu noble-proposed/universe amd64 c-n-f Metadata [9 396 B] Réception de :21 http://fr.archive.ubuntu.com/ubuntu noble-proposed/multiverse amd64 Packages [10,6 kB] Réception de :22 http://fr.archive.ubuntu.com/ubuntu noble-proposed/multiverse Translation-fr [89,0 kB] Réception de :23 http://fr.archive.ubuntu.com/ubuntu noble-proposed/multiverse Translation-en [2 808 B] Réception de :24 http://fr.archive.ubuntu.com/ubuntu noble-proposed/multiverse amd64 Components [940 B] Réception de :25 http://fr.archive.ubuntu.com/ubuntu noble-proposed/multiverse amd64 c-n-f Metadata [196 B] 5 217 ko réceptionnés en 1s (3 687 ko/s) Lecture des listes de paquets... Fait Construction de l'arbre des dépendances... Fait Lecture des informations d'état... Fait Tous les paquets sont à jour.
Nous allons ensuite faire l’installation du logiciel en spécifiant au gestionnaire de paquets que nous souhaitons prendre la version disponible dans le dépôt noble-proposed :
gabriel@serveurweb:~$ sudo apt install -t noble-proposed fail2ban
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
Lecture des informations d'état... Fait
Les paquets supplémentaires suivants seront installés :
python3-pyasyncore python3-pyinotify whois
Paquets suggérés :
mailx monit sqlite3 python-pyinotify-doc
Les NOUVEAUX paquets suivants seront installés :
fail2ban python3-pyasyncore python3-pyinotify whois
0 mis à jour, 4 nouvellement installés, 0 à enlever et 21 non mis à jour.
Il est nécessaire de prendre 496 ko dans les archives.
Après cette opération, 2 572 ko d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer ? [O/n] y
Réception de :1 http://fr.archive.ubuntu.com/ubuntu noble/main amd64 python3-pyasyncore all 1.0.2-2 [10,1 kB]
Réception de :2 http://fr.archive.ubuntu.com/ubuntu noble-proposed/universe amd64 fail2ban all 1.0.2-3ubuntu0.1 [409 kB]
Réception de :3 http://fr.archive.ubuntu.com/ubuntu noble/main amd64 python3-pyinotify all 0.9.6-2ubuntu1 [25,0 kB]
Réception de :4 http://fr.archive.ubuntu.com/ubuntu noble/main amd64 whois amd64 5.5.22 [51,7 kB]
496 ko réceptionnés en 0s (1 085 ko/s)
Sélection du paquet python3-pyasyncore précédemment désélectionné.
(Lecture de la base de données... 83376 fichiers et répertoires déjà installés.)
Préparation du dépaquetage de .../python3-pyasyncore_1.0.2-2_all.deb ...
Dépaquetage de python3-pyasyncore (1.0.2-2) ...
Sélection du paquet fail2ban précédemment désélectionné.
Préparation du dépaquetage de .../fail2ban_1.0.2-3ubuntu0.1_all.deb ...
Dépaquetage de fail2ban (1.0.2-3ubuntu0.1) ...
Sélection du paquet python3-pyinotify précédemment désélectionné.
Préparation du dépaquetage de .../python3-pyinotify_0.9.6-2ubuntu1_all.deb ...
Dépaquetage de python3-pyinotify (0.9.6-2ubuntu1) ...
Sélection du paquet whois précédemment désélectionné.
Préparation du dépaquetage de .../whois_5.5.22_amd64.deb ...
Dépaquetage de whois (5.5.22) ...
Paramétrage de whois (5.5.22) ...
Paramétrage de python3-pyasyncore (1.0.2-2) ...
Paramétrage de fail2ban (1.0.2-3ubuntu0.1) ...
/usr/lib/python3/dist-packages/fail2ban/tests/fail2banregextestcase.py:224: SyntaxWarning: invalid escape sequence '\s'
"1490349000 test failed.dns.ch", "^\s*test <F-ID>\S+</F-ID>"
/usr/lib/python3/dist-packages/fail2ban/tests/fail2banregextestcase.py:435: SyntaxWarning: invalid escape sequence '\S'
'^'+prefix+'<F-ID>User <F-USER>\S+</F-USER></F-ID> not allowed\n'
/usr/lib/python3/dist-packages/fail2ban/tests/fail2banregextestcase.py:443: SyntaxWarning: invalid escape sequence '\S'
'^'+prefix+'User <F-USER>\S+</F-USER> not allowed\n'
/usr/lib/python3/dist-packages/fail2ban/tests/fail2banregextestcase.py:444: SyntaxWarning: invalid escape sequence '\d'
'^'+prefix+'Received disconnect from <F-ID><ADDR> port \d+</F-ID>'
/usr/lib/python3/dist-packages/fail2ban/tests/fail2banregextestcase.py:451: SyntaxWarning: invalid escape sequence '\s'
_test_variants('common', prefix="\s*\S+ sshd\[<F-MLFID>\d+</F-MLFID>\]:\s+")
/usr/lib/python3/dist-packages/fail2ban/tests/fail2banregextestcase.py:537: SyntaxWarning: invalid escape sequence '\['
'common[prefregex="^svc\[<F-MLFID>\d+</F-MLFID>\] connect <F-CONTENT>.+</F-CONTENT>$"'
/usr/lib/python3/dist-packages/fail2ban/tests/servertestcase.py:1375: SyntaxWarning: invalid escape sequence '\s'
"`{ nft -a list chain inet f2b-table f2b-chain | grep -oP '@addr-set-j-w-nft-mp\s+.*\s+\Khandle\s+(\d+)$'; } | while read -r hdl; do`",
/usr/lib/python3/dist-packages/fail2ban/tests/servertestcase.py:1378: SyntaxWarning: invalid escape sequence '\s'
"`{ nft -a list chain inet f2b-table f2b-chain | grep -oP '@addr6-set-j-w-nft-mp\s+.*\s+\Khandle\s+(\d+)$'; } | while read -r hdl; do`",
/usr/lib/python3/dist-packages/fail2ban/tests/servertestcase.py:1421: SyntaxWarning: invalid escape sequence '\s'
"`{ nft -a list chain inet f2b-table f2b-chain | grep -oP '@addr-set-j-w-nft-ap\s+.*\s+\Khandle\s+(\d+)$'; } | while read -r hdl; do`",
/usr/lib/python3/dist-packages/fail2ban/tests/servertestcase.py:1424: SyntaxWarning: invalid escape sequence '\s'
"`{ nft -a list chain inet f2b-table f2b-chain | grep -oP '@addr6-set-j-w-nft-ap\s+.*\s+\Khandle\s+(\d+)$'; } | while read -r hdl; do`",
Created symlink /etc/systemd/system/multi-user.target.wants/fail2ban.service → /usr/lib/systemd/system/fail2ban.service.
Paramétrage de python3-pyinotify (0.9.6-2ubuntu1) ...
Traitement des actions différées (« triggers ») pour man-db (2.12.0-4build2) ...
Scanning processes...
Scanning linux images...
Running kernel seems to be up-to-date.
No services need to be restarted.
No containers need to be restarted.
No user sessions are running outdated binaries.
No VM guests are running outdated hypervisor (qemu) binaries on this host.La version devrait démarrer automatiquement sans aucun problème. Si l’on demande le statut logicielle faill2ban, vous devriez voir apparaître que le service SS HD est maintenant protégé par faillite oui.
gabriel@serveurweb:~$ systemctl status fail2ban
● fail2ban.service - Fail2Ban Service
Loaded: loaded (/usr/lib/systemd/system/fail2ban.service; enabled; preset: enabled)
Active: active (running) since Tue 2024-06-18 13:37:56 UTC; 25s ago
Docs: man:fail2ban(1)
Main PID: 4017 (fail2ban-server)
Tasks: 5 (limit: 1671)
Memory: 25.3M (peak: 25.6M)
CPU: 458ms
CGroup: /system.slice/fail2ban.service
└─4017 /usr/bin/python3 /usr/bin/fail2ban-server -xf start
juin 18 13:37:56 serveurweb systemd[1]: Started fail2ban.service - Fail2Ban Service.
juin 18 13:37:56 serveurweb fail2ban-server[4017]: 2024-06-18 13:37:56,452 fail2ban.configreader [4017]: WARNING 'allowipv6' not defined in 'Definition'. Using default one: 'auto'
juin 18 13:37:56 serveurweb fail2ban-server[4017]: Server readyNous allons vérifier quels sont les services qui sont protégé par Fail2ban avec la commande fail2ban-client. Cette dernière permet beaucoup plus de choses que nous n’aborderons pas ici.
gabriel@serveurweb:~$ sudo fail2ban-client status Status |- Number of jail: 1 `- Jail list: sshd
Il faut penser à supprimer le dépôt noble-proposed du fichier des sources est à mettre à jour la liste des paquets. Si vous ne le faites pas, vous risquez de vous retrouver avec une mise à jour qui ne fonctionne pas.
gabriel@serveurweb:~$ sudo vim /etc/apt/sources.list.d/ubuntu.sources Types: deb URIs: http://fr.archive.ubuntu.com/ubuntu/ Suites: noble noble-updates noble-backports Components: main restricted universe multiverse Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg Types: deb URIs: http://security.ubuntu.com/ubuntu/ Suites: noble-security Components: main restricted universe multiverse Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg gabriel@serveurweb:~$ sudo apt update Atteint :1 http://fr.archive.ubuntu.com/ubuntu noble InRelease Atteint :2 http://fr.archive.ubuntu.com/ubuntu noble-updates InRelease Atteint :3 http://fr.archive.ubuntu.com/ubuntu noble-backports InRelease Atteint :4 http://security.ubuntu.com/ubuntu noble-security InRelease Lecture des listes de paquets... Fait Construction de l'arbre des dépendances... Fait Lecture des informations d'état... Fait Tous les paquets sont à jour. gabriel@serveurweb:~$ sudo apt autoclean Lecture des listes de paquets... Fait Construction de l'arbre des dépendances... Fait Lecture des informations d'état... Fait gabriel@serveurweb:~$ sudo apt clean gabriel@serveurweb:~$
Étape quatre : sécuriser open SSH
Comme SSH est notre principal moyen d’accès au serveur, nous devons absolument le sécuriser pour sécuriser notre serveur Linux de base.
Le logiciel de connexion OpenSSH dispose de très nombreux paramètres dont certains sont en mesure de vous simplifier la vie et surtout de réduire la surface d’attaque. Pour certaines de ces options il faut avoir une clé SSH et je vous donnerai une procédure extrêmement rapide pour en obtenir et les envoyer vers votre serveur.
Je ne vous donne pas l’explication du fonctionnement de base des clés asymétriques sur lesquels s’appuie le logiciel OpenSSH.
Nous allons voir deux options très importantes qu’il convient de modifier. La première et la plus simple à mettre en place, il s’agit de positionner l’option PermitRootLogin à no. Cela aura pour conséquence de refuser systématiquement toutes les demandes de connexion avec comme identifiant root. N’ayez pas de crainte, cela ne vous empêche pas de passer des commandes avec sudo.
gabriel@serveurweb:~$ sudo vim /etc/ssh/sshd_config # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options override the # default value. Include /etc/ssh/sshd_config.d/*.conf #Port 22 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_ecdsa_key #HostKey /etc/ssh/ssh_host_ed25519_key # Ciphers and keying #RekeyLimit default none # Logging #SyslogFacility AUTH #LogLevel INFO # Authentication: #LoginGraceTime 2m PermitRootLogin no #StrictModes yes #MaxAuthTries 6 #MaxSessions 10
La seconde chose à faire est d’utiliser des clés SSH. Ces clés peuvent avoir ou pas un mot de passe. Les clés sans mot de passe sont utilisées entre autres pour les comptes d’application qui nécessite de se connecter sur un système pour par exemple transférer des fichiers avec SCP ou rsync.
Ces clés évitent d’avoir à transmettre le mot de passe sur le réseau, cela contribue fortement à sécuriser un serveur Linux de base.
Pour la plupart des clés SSH que nous allons générer, vous pouvez utiliser ou non un mot de passe. Si vous en mettez un, il vous sera demandé systématiquement à chaque fois que la clé devrait être utilisée. Si vous n’en mettez pas, la clé sera utilisée automatiquement. Sachez que certain gestionnaire de mots de passe, de manière native ou avec des plug-ins, sont capables de fournir directement le mot de passe de la clé en cas d’utilisation.
La procédure de génération de clés est relativement simple.
- Création de la clé SSH. Vous pouvez laisser les options par défaut.
- Exportation de la clé vers le serveur
- Test de la connexion
admin-libre@admin-libre:~$ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/home/admin-libre/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/admin-libre/.ssh/id_rsa Your public key has been saved in /home/admin-libre/.ssh/id_rsa.pub The key fingerprint is: SHA256:J+0Ku04+IIoEs7QXrZNFEkIuNxyEFUmo/vD9RNNWQ+4 admin-libre@admin-libre.fr The key's randomart image is: +---[RSA 3072]----+ |.O*+. . | |+.oo . o | |o.+ + + | |=o o o ..o . | |+o. = oSooE | |.=.=. . o+ | |o.=.o.o. . | |o o +oo . | | .*+. | +----[SHA256]-----+ admin-libre@admin-libre:~$ ssh-copy-id gabriel@192.168.1.148 /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/admin-libre/.ssh/id_rsa.pub" The authenticity of host '192.168.1.148 (192.168.1.148)' can't be established. ED25519 key fingerprint is SHA256:KQZ6iLiqQiFDVfnFPuAj3WqHDbz+CiGe05iAznrcMTk. This key is not known by any other names. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys gabriel@192.168.1.148's password: Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'gabriel@192.168.1.148'" and check to make sure that only the key(s) you wanted were added. admin-libre@admin-libre:~$ ssh gabriel@192.168.1.148 Welcome to Ubuntu 24.04 LTS (GNU/Linux 6.8.0-35-generic x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/pro System information as of mar. 18 juin 2024 14:25:37 UTC System load: 0.0 Usage of /: 14.9% of 14.66GB Memory usage: 16% Swap usage: 0% Processes: 161 Users logged in: 1 IPv4 address for enp2s0: 192.168.1.148 IPv6 address for enp2s0: 2001:861:d50:6d90::2791:b8a8 IPv6 address for enp2s0: 2001:861:d50:6d90:5054:ff:fe88:216b * Strictly confined Kubernetes makes edge and IoT secure. Learn how MicroK8s just raised the bar for easy, resilient and secure K8s cluster deployment. https://ubuntu.com/engage/secure-kubernetes-at-the-edge La maintenance de sécurité étendue pour Applications n'est pas activée. 0 mise à jour peut être appliquée immédiatement. Activez ESM Apps pour recevoir des futures mises à jour de sécurité supplémentaires. Visitez https://ubuntu.com/esm ou executez : sudo pro status Last login: Tue Jun 18 10:12:05 2024 from 192.168.1.100 gabriel@serveurweb:~$
Étape cinq : sauvegarder la configuration du système
Nous voici à la cinquième et dernière étape pour sécuriser un serveur Linux de base. Nous allons se garder à intervalles réguliers les fichiers de configuration du serveur. C’est-à-dire le contenu du dossier /etc.
Cela permettra de rétablir de manière plus simple un serveur en cas de problème. De revenir à une configuration qui fonctionne après une modification hasardeuse, de garder un historique des fichiers de configuration et de pouvoir grossièrement dater certaines modifications effectuées.
Vu que ces fichiers ne sont pas généralement pas modifiés de manière journalière, une sauvegarde hebdomadaire est envisageable. Maintenant, si vous modifiez ces fichiers tous les jours, il vaudrait mieux faire une sauvegarde journalière.
Je vous conseille aussi de renvoyer cette sauvegarde sur un autre serveur. Ainsi en cas de crash matériel, vous pourrez toujours y accéder. Je vous conseille aussi d’automatiser ce renvoi.
Nous allons utiliser uniquement la commande TAR et la commande SCP. Nous n’utiliserons pas de logiciel de sauvegarde dédiée. Le lancement de la sauvegarde sera effectué par grandes tables.
- Création de l’utilisateur
- Création du mot de passe
- Création du script
- mise en place de la crontab en mode root pour éviter les problèmes d’accès au fichiers.
gabriel@serveurweb:~$ sudo useradd -md /home/sauvegarde sauvegarde
gabriel@serveurweb:~$ sudo passwd sauvegarde
New password:
Retype new password:
passwd: password updated successfully
gabriel@serveurweb:~$ sudo -u sauvegarde vim /home/sauvegarde/sauvegarde.sh
#!/bin/bash
quand=`date +%F-%Hh%M`
echo "Date : ${quand}"
echo "Sauvegarde de la configuration serveur"
tar -acf /home/sauvegarde/svg/hebdomadaire/etc/etc_serveurweb-"${quand}".tar.gz /etc
chown sauvegarde:sauvegarde /home/sauvegarde/svg/hebdomadaire/etc/etc_serveurweb-"${quand}".tar.gz
echo "Envoie de la sauvegarde sur serveur_distant"
sudo -u sauvegarde scp -rp /home/sauvegarde/svg/ sauvegarde@serveur_distant:
gabriel@serveurweb:~$ sudo crontab -e
no crontab for root - using an empty one
Select an editor. To change later, run 'select-editor'.
1. /bin/nano <---- easiest
2. /usr/bin/vim.basic
3. /usr/bin/vim.tiny
4. /bin/ed
Choose 1-4 [1]: 3
crontab: installing new crontab
gabriel@serveurweb:~$ sudo crontab -l
# Edit this file to introduce tasks to be run by cron.
#
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
#
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').
#
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
#
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
#
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# For more information see the manual pages of crontab(5) and cron(8)
#
# m h dom mon dow command
# Mise à jour de locate
0 0 * * * sudo updatedb
########################################################################
# Sauvegarde fichier sites
########################################################################
0 2 * * 0 /home/sauvegarde/sauvegarde.sh >> /home/sauvegarde/svg/log_serverweb.log 2>&1Note : si vous avez besoin de prendre en main le logiciel Vim, j’ai fait un petit article que vous pouvez trouver ici : Bien démarrer avec Vim en 5 étapes.
C’est un système robuste, simple et largement suffisante donc que les volumes de données restent peu importants.
La surveillance du bon déroulement des sauvegardes est indispensable, tout comme savoir les réinjecter en cas de problème.
Il est conseillé de faire un test de restauration au moins une fois par an.
Conclusion de sécuriser un serveur Linux de base
Vous venez de sécuriser un serveur Linux de base. Cette sécurisation est un bon début mais elle n’est pas invulnérable. Au fur et à mesure que nous allons ajouter des briques à notre serveur Linux, de nouvelles sécurisations seront nécessaires.
Dans cette suite d’articles, nous garderons comme état d’esprit : « tout est interdit sauf ce qui est expressément autorisé. ». Ainsi, moins vous aurez de logiciels que vous n’utilisez pas, moins vous risquez d’être vulnérable à des CVE. De plus, cela réduira la charge de votre serveur.
La prochaine fois nous verrons comment mettre en place un site Web statique