La Fibre

Télécom => Logiciels et systèmes d'exploitation => Ubuntu Tutoriels pour Ubuntu server => Discussion démarrée par: vivien le 14 octobre 2021 à 08:47:43

Titre: Base: Installation et sécurisation d'un serveur Ubuntu
Posté par: vivien le 14 octobre 2021 à 08:47:43
Tutoriel testé avec Ubuntu version 20.04 LTS, Ubuntu 22.04 LTS et Ubuntu 23.10.
(les différences entre les versions sont mentionnées quand elles existent)

Pré-requis :
- Avoir Ubuntu server d'installé

Si vous mettez /boot dans une partition distincte, j'en profite pour vous recommander une partition /boot d'une taille de 2 Go minimum. Les noyaux grandissent et se limiter à 700 Mo comme on voit souvent va poser un problème dans le futur.

(https://lafibre.info/testdebit/ubuntu/202303_ubuntu_manque_place_boot.webp)

sudo -s : On passe avec les droits root, pour ne pas taper sudo à toutes les commandes qui vont suivre.



Optionnel : modifier le serveur DNS utilisé sous Ubuntu 22.04 (systemd-resolved)
C'est dans le fichier : nano /etc/systemd/resolved.conf

Remplacer la ligne

#DNS=par les DNS à utiliser, séparés par un espace : (exemple avec les DNS Bouygues Telecom IPv6)
DNS=2001:860:b0ff:1::1 2001:860:b0ff:1::2


1/ Passer les dépôts en https avec fr.archive.ubuntu.com :

https permet de chiffrer le contenu avec les dépôts.
sed -i -e "s/http:\/\/fr.archive.ubuntu.com/https:\/\/fr.archive.ubuntu.com/g" /etc/apt/sources.list
sed -i -e "s/http:\/\/security.ubuntu.com/https:\/\/fr.archive.ubuntu.com/g" /etc/apt/sources.list


Mise à jour du système :
apt update : permet de mettre à jour le catalogue de logiciels
apt full-upgrade : permet de mettre tous les logiciels à jour.




2/ Installation de paquets importants :

Paquets à installer sur un serveur physique (inutile sur une machine virtuelle) :
apt install ntpdate lm-sensors
Pour un serveur physique avec un module IPMI (https://fr.wikipedia.org/wiki/Intelligent_Platform_Management_Interface) :
apt install openipmi ipmitool
Outils pour aider la gestion du serveur (à installer dans tous les cas) :
apt install curl whois htop iotop iftop nload nmon neofetch language-pack-fr language-pack-fr-base manpages-fr manpages-fr-dev manpages-fr-extra

apt autoremove : Supprime les éventuelles dépendances devenues inutiles
apt clean permet de supprimer les paquets .deb téléchargés
Titre: Base: Installation et sécurisation d'un serveur Ubuntu
Posté par: vivien le 14 octobre 2021 à 08:48:26
Note : Mise à jour mai 2023 avec la configuration Arcep QoS mobile 2023 : le maximum de la fenêtre TCP passe de 16 à 32 Mo.

3/ Optimisations réseau et swappiness :

nano /etc/sysctl.d/90-server-optimization.conf
Copier / coller la configuration BBR ou la configuration Cubic en fonction de votre choix.

Serveur BBR :
Copier / coller le texte ci-dessous dans le fichier :
# Algorithme d’évitement de congestion TCP et qdisc
net.ipv4.tcp_congestion_control=bbr
net.core.default_qdisc=fq

# décorrélation des tests successifs
net.ipv4.tcp_no_metrics_save=1

# Paramétrage de la fenêtre TCP à 32 Mio
net.ipv4.tcp_rmem=4096 131072 33554432
net.ipv4.tcp_wmem=4096 87380 33554432
net.core.rmem_max=33554432
net.core.wmem_max=33554432

# Limiter l’utilisation du swap
vm.swappiness = 1

# Augmentation de la file d'attente dans le noyau Linux où le trafic est stocké après réception par la carte réseau
net.core.netdev_max_backlog=4000

# Réduire le seuil où un DDOS impacte le serveur
net.ipv4.tcp_max_syn_backlog = 4096

# Augmenter le nombre de connexions entrantes
net.core.somaxconn = 4096

Serveur Cubic : Copier / coller le texte ci-dessous dans le fichier :
# Algorithme d’évitement de congestion TCP et qdisc
net.ipv4.tcp_congestion_control=cubic
net.core.default_qdisc=fq_codel

# décorrélation des tests successifs
net.ipv4.tcp_no_metrics_save=1

# Paramétrage de la fenêtre TCP à 32 Mio
net.ipv4.tcp_rmem=4096 131072 33554432
net.ipv4.tcp_wmem=4096 87380 33554432
net.core.rmem_max=33554432
net.core.wmem_max=33554432

# Limiter l’utilisation du swap
vm.swappiness = 1

# Augmentation de la file d'attente dans le noyau Linux où le trafic est stocké après réception par la carte réseau
net.core.netdev_max_backlog=4000

# Réduire le seuil où un DDOS impacte le serveur
net.ipv4.tcp_max_syn_backlog = 4096

# Augmenter le nombre de connexions entrantes
net.core.somaxconn = 4096



Explications de la configuration proposée :

Configuration BBR vs Cubic :

Cubic et BBR sont les deux algorithmes les plus utilisés côté serveur pour décider de la vitesse d’envoi des paquets.
Aujourd’hui, la majorité de l’internet utilise Cubic, créé en 2006, qui s’appuie sur la perte de paquets comme signal pour réduire le débit. Cubic est l'implémentation par défaut sous Linux, Android et MacOS.
Google a développé en 2016 BBR (pour « Bottleneck Bandwidth and Round-trip propagation time ») qui utilise un modèle différent se basant sur la bande passante maximale et le temps d’aller-retour (RTT ou « round trip time »). Cette approche permet à BBR de proposer un débit nettement plus élevé que Cubic sur un réseau qui perd des paquets sans lien avec une congestion. BBR est de plus en plus utilisé par certains grands acteurs de l’Internet.

« net.ipv4.tcp_congestion_control=bbr » va utiliser l’algorithme de congestion BBR, conçu par Google, à la place de Cubic, afin d’avoir de meilleures performances réseau.
Important : Le paramétrage "qdisc", le protocole de queuing discipline doit être adapté au protocole de congestion :
- Pour Cubic, on recommande fq_codel
- Pour BBR, on recommande fq

Optionnel, pour la configuration Cubic, proposer BBR en protocole de congestion optionnel : Si vous souhaitez qu'il soit disponible pour un outil tel que iperf3 qui permet de sélectionner le protocole de congestion, il faut créer un fichier pour charger le module :
nano /etc/modules-load.d/tcp_allowed_congestion_control.conf

Copier / coller le texte ci-dessous dans le fichier :
# TCP congestion control protocol
# cat /proc/sys/net/ipv4/tcp_allowed_congestion_control
tcp_bbr



Décorrélation des tests successifs : tcp_no_metrics_save=1

Par défaut, TCP enregistre diverses métriques de connexion dans le cache de routage lorsque la connexion se ferme, de sorte que les connexions établies dans un proche avenir peuvent les utiliser pour définir les conditions initiales. Habituellement, cela augmente les performances globales, mais peut parfois entraîner une dépendance du test N au test N-1.
Dans le cadre des tests de débit, et afin d’assurer une décorrélation des tests successifs, la mémorisation des tests précédents a été désactivée sur le serveur via « tcp_no_metrics_save=1 » afin d’éviter que le serveur bride tous les tests, à la suite d’une performance limitée.




Paramétrage de la fenêtre TCP : maximum de 32 Mio

TCP utilise un mécanisme de fenêtrage glissante pour empêcher qu'un émetteur rapide ne surcharge un récepteur plus lent. Le récepteur annonce la quantité de données que l'émetteur doit envoyer avant d'attendre l'actualisation de la fenêtre par le récepteur. Le délai le plus rapide d'actualisation d'une fenêtre correspond à un aller-retour, ce qui conduit à la formule suivante pour calculer l'une des limites de performance du transfert de données groupées sur une connexion TCP : Débit <= taille de la fenêtre / latence du délai aller-retour (DAR).

Une fenêtre TCP trop petite peut limiter artificiellement le débit pour les connexions à très haut débit ou forte latence. La configuration par défaut des serveurs peut limiter artificiellement les débits, notament pour les  utilisateurs ultramarines (quand le serveur est en métropole).

La taille de la fenêtre TCP est affectée par les 4 paramètres suivants :
• net.ipv4.tcp_rmem
• net.ipv4.tcp_wmem
• net.core.rmem_max
• net.core.wmem_max
Note : le paramétrage net.ipv4.xxx s’applique également au protocole IPv6.

Les deux premiers paramètres configurables affectent la taille de fenêtre TCP pour les applications qui laissent la fonction de réglage automatique de Linux se charger de cette tâche.
Les deux derniers paramètres configurables affectent la taille maximale de fenêtre TCP pour les applications qui tentent de contrôler directement la taille de la fenêtre TCP, en limitant la requête des applications à ces valeurs seulement.

Paramètres de la mémoire tampon de réception TCP (net.ipv4.tcp_rmem=4096 131072 33554432).  Les 3 valeurs sont :
• Taille minimale du tampon de réception pouvant être allouée à un socket TCP.
• Taille par défaut du tampon de réception.
• Taille maximale de la mémoire tampon de réception pouvant être allouée à un socket TCP.

Paramètres de la mémoire tampon d’envoi TCP (net.ipv4.tcp_wmem=4096 87380 33554432).  Les 3 valeurs sont :
• Espace minimal du tampon d'envoi TCP disponible pour un socket TCP.
• Espace par défaut du tampon autorisé pour un socket TCP.
• Espace maximal du tampon d'envoi TCP.

Taille maximale de la mémoire tampon de réception du système d'exploitation pour tous les types de connexions :
net.core.rmem_max= 33554432

Taille maximale de la mémoire tampon d'envoi du système d'exploitation pour tous les types de connexions :
net.core.wmem_max= 33554432




Limiter l’utilisation du swap :vm.swappiness = 1

Le paramètre « vm.swappiness = 1 » ne concerne pas TCP/IP, mais demande au système de limiter l’utilisation de l’espace d’échange situé sur disque (swap). Cet espace est utilisé par le système d'exploitation pour déplacer des données peu utilisées des programmes en cours d'exécution, afin d'utiliser l'espace libéré comme cache du système de fichiers.
Ce comportement risque de dégrader les performances réseau au moment où des données peu utilisées en mémoire vive sont mises dans le SWAP. Afin de fiabiliser le flux de données généré par le serveur, on met « vm.swappiness = 1 », ce qui permet de limiter l’utilisation du swap aux cas où c’est nécessaire.
Titre: Base: Installation et sécurisation d'un serveur Ubuntu
Posté par: vivien le 14 octobre 2021 à 08:48:54
4/ Sécurisation du serveur SSH :

Changement de port de SSH, pour limiter d'être la cible des attaques sur le port 22 et permettre de maintenir la connexion SSH, y compris derrière un CG-Nat :

Ubuntu 23.10 / Ubuntu 24.04 LTS Le port d'écoute de SSH se configure dans systemd :
sudo systemctl edit ssh.socket
Ajouter les 3 lignes suivantes :
[Socket]
ListenStream=
ListenStream=2222
(En remplaçant 2222 par le port de votre choix, prendre de préférence un port au-dessus de 10 000)
(https://lafibre.info/testdebit/ubuntu/202401_tuto_ubuntu_changer_port_ssh.webp)
Éviter les déconnexions par un Carrier-grade NAT :
nano /etc/ssh/sshd_config.d/client_alive.conf

Copier-coller le texte ci-dessous dans le fichier :
# Forcer un échange toutes les 4 secondes, pour éviter la déconnexion derrière un Carrier-grade NAT
ClientAliveInterval 4
ClientAliveCountMax 22



Ubuntu 18.04 LTS / 20.04 LTS / 22.04 LTS Le port d'écoute de SSH se configure dans sshd_config ou un fichier de configuration dans le dossier sshd_config.d

nano /etc/ssh/sshd_config.d/client_alive.conf
Copier-coller le texte ci-dessous dans le fichier :
# Spécifie le port sur lequel le serveur écoute les connexions entrantes à la place du port par défaut 22
Port 2222
# Forcer un échange toutes les 4 secondes, pour éviter la déconnexion derrière un Carrier-grade NAT
ClientAliveInterval 4
ClientAliveCountMax 22



Application des paramètres :

Pour Ubuntu 22.10 et suivants, il est possible de faire sudo systemctl daemon-reload et sudo systemctl restart ssh, mais personnellement, je préfère attendre le redémarrage du serveur.

La connexion au reboot se fera avec ssh [login]@[nom de domaine] -p 2222




Optionnel : ne faire écouter SSH que sur les IPv6 : rajouter dans /etc/ssh/sshd_config.d/client_alive.conf :
AddressFamily inet6
Optionnel : ne faire écouter SSH que sur une IPv6 dédiée (qu'il faudra configurer dans netplan), rajouter dans /etc/ssh/sshd_config.d/client_alive.conf :
AddressFamily inet6
ListenAddress [2103:b860:de01:1100:2200:abcd:ef01:1100]
Titre: Base: Installation et sécurisation d'un serveur Ubuntu
Posté par: vivien le 14 octobre 2021 à 08:49:14
5/ Limitation du nombre de connexions TCP simultanées par IP :

On va limiter à 100 connexions par IPv4 et par plage IPv6 /64, afin de bloquer certains types d’attaque par déni de service.
Pour un site web important, il peut être nécessaire de monter à 200 connexions simultanées (sur lafibre.info 100 connexions peuvent être insuffisante pour un usage légitime avec HTTP/2 d'activé).
On va loger les connexions, mais pour éviter d'être submergé par les connexions à loguer, on va limiter radicalement les logs : 1 log toutes les 2 minutes sans possibilité de burst.
nano /root/iptables-rules.sh

Copier / coller le texte ci-dessous dans le fichier :
#!/bin/dash
# Limiter le nombre de sessions tcp par client (un client = une IPv4 ou un /64 en IPv6)
/usr/sbin/iptables  -A INPUT -p tcp --syn -m connlimit --connlimit-above 100 -m limit --limit 30/hour --limit-burst 1 -j LOG --log-prefix="drop-c-"
/usr/sbin/iptables  -A INPUT -p tcp --syn -m connlimit --connlimit-above 100 -j REJECT
/usr/sbin/ip6tables -A INPUT -p tcp --syn -m connlimit --connlimit-above 100 --connlimit-mask 64 -m limit --limit 30/hour --limit-burst 1 -j LOG --log-prefix="drop-c-"
/usr/sbin/ip6tables -A INPUT -p tcp --syn -m connlimit --connlimit-above 100 --connlimit-mask 64 -j REJECT

chmod +x /root/iptables-rules.sh : On rend le script exécutable
echo "# Application des règles iptables au reboot" > /etc/cron.d/iptables-rules
echo "@reboot root /root/iptables-rules.sh" >> /etc/cron.d/iptables-rules
: Lancmenbet du script au démarrage du serveur




6/ Nom de domaine FQDN (fully qualified domain name) :

Vérifier que le nom de domaine apparaît bien avec la commande :
hostname -f
Si ce n'est pas le cas, il faut rajouter les informations FQDN dans /etc/hosts : nano /etc/hosts
On met en premier l’IP, suivit d’un espace et du nom de domaine pleinement qualifié (avec le .com ou .fr) suivit d’un espace et du nom simple du serveur.
Si vous souhaitez changer le nom du serveur, il faut également modifier nano /etc/hostname
On met seulement le nom simple du serveur (pas besoin du nom complet avec le .com ou .fr)
Titre: Base: Installation et sécurisation d'un serveur Ubuntu
Posté par: vivien le 14 octobre 2021 à 08:49:55
7/ Automatiser l'installation des mises à jour de sécurité de nuit

(On utilise le paquet unattended-upgrades, installé de base avec Ubuntu, mais pas certains dérivés d'Ubuntu. Il suffit alors de faire un apt install unattended-upgrades)
dpkg-reconfigure --priority=low unattended-upgrades (demande au système d'installer les mises à jour)
=> Va créer le fichier /etc/apt/apt.conf.d/20auto-upgrades qui va demander de faire une mise à jour quotidienne, en fonction de ce qui est demandé dans le fichier « /etc/apt/apt.conf.d/50unattended-upgrades ».
sed -i -e "s/\/\/\t\"\${distro_id}:\${distro_codename}-updates\"/\t\"\${distro_id}:\${distro_codename}-updates\"/g" /etc/apt/apt.conf.d/50unattended-upgrades : Installer les mises à jour disponibles
sed -i -e "s/\/\/Unattended-Upgrade::Remove-Unused-Dependencies \"false\"/Unattended-Upgrade::Remove-Unused-Dependencies \"true\"/g" /etc/apt/apt.conf.d/50unattended-upgrades : apt-get autoremove pour supprimer les dépendances inutiles, comme les anciennes version du noyeau Linux
sed -i -e "s/\/\/Unattended-Upgrade::Automatic-Reboot \"false\"/Unattended-Upgrade::Automatic-Reboot \"true\"/g" /etc/apt/apt.conf.d/50unattended-upgrades : redémarrer automatiquement la nuit, si une mise à jour nécessite un redémarrage (c’est les cas des mises à jour du noyau Linux)
Vérification : nano /etc/apt/apt.conf.d/50unattended-upgrades
Les log seront dans /var/log/unattended-upgrades/unattended-upgrades.log
Si besoin de lancer un redémarrage lors des prochaines mises à jour : sudo touch /var/run/reboot-required

Optionnel : Décaler les taches crontab de 6h25 a 5h54, pour que le reboot se réalise en pleine nuit et pas au petit matin :
sed -i -e "s/25 6\t\* \* \*\troot/54 5\t\* \* \*\troot/g" /etc/crontab
Vérifications : nano /etc/crontab
sed -i -e "s/OnCalendar=\*-\*-\* 6,18:00/OnCalendar=\*-\*-\* 5:50/g" /lib/systemd/system/apt-daily.timer
sed -i -e "s/RandomizedDelaySec=12h/RandomizedDelaySec=1m/g" /lib/systemd/system/apt-daily.timer

Vérifications : nano /lib/systemd/system/apt-daily.timer
sed -i -e "s/OnCalendar=\*-\*-\* 6:00/OnCalendar=\*-\*-\* 5:55/g" /lib/systemd/system/apt-daily-upgrade.timer
sed -i -e "s/RandomizedDelaySec=60m/RandomizedDelaySec=1m/g" /lib/systemd/system/apt-daily-upgrade.timer

Vérifications : nano /lib/systemd/system/apt-daily-upgrade.timer
systemctl daemon-reload pour appliquer la configuration systemd modifiée




Info : pour voir quand se sont fait les derniers lancement de mise à jour :
cat /var/log/unattended-upgrades/unattended-upgrades.log
Titre: Base: Installation et sécurisation d'un serveur Ubuntu
Posté par: vivien le 14 octobre 2021 à 08:52:45
8/ timedatectl : Faire en sorte que le serveur reste à l'heure

Depuis Ubuntu 16.04, la synchronisation de l'horloge système se fait à l'aide du service timesyncd de systemd (cela remplace ntpdate). Par défaut, timesyncd synchronise l'heure une fois au démarrage (une fois que les connexions réseau actives) puis à intervalles réguliers, timesyncd assure le maintien de la synchronisation de l'horloge.

Vérifier que la synchronisation de l'horloge fonctionne :
1/ timedatectl
2/ timedatectl timesync-status
(https://lafibre.info/testdebit/ubuntu/202304_ubuntu_timedatectl.webp)

Si j'en parle ici, c'est qu'il y a des serveurs où la synchronisation ne fonctionne pas. C'est donc un point à vérifier à l'installation.

Si vous avez "System clock synchronized: no" ou "NTP service: n/a" ce n'est pas bon.

$ timedatectl
               Local time: lun. 2023-04-17 10:06:39 CEST
           Universal time: lun. 2023-04-17 08:06:39 UTC
                 RTC time: lun. 2023-04-17 08:06:43
                Time zone: Europe/Paris (CEST, +0200)
System clock synchronized: no
              NTP service: n/a

          RTC in local TZ: no


Les premières étapes à faire si vous vous retrouvez dans ce cas-là :
1/ Installer systemd-timesyncd : sudo apt install systemd-timesyncd
2/ Activer timesyncd : sudo timedatectl set-ntp true
3/ Si un serveur a été indiqué dans la configuration, vérifier qu'il répond.
La configuration de timesyncd est sur nano /etc/systemd/timesyncd.conf

Optionnel, si vous désirez modifier le fuseau horaire :
1/ Répertorier les fuseaux horaires disponibles : timedatectl list-timezones
2/ Définissez maintenant le fuseau horaire : sudo timedatectl set-timezone Europe/Paris

Optionnel, si installation en dual boot avec Windows à coté, mettre l'heure du PC sur l'heure locale (et non l'heure UTC) :
timedatectl set-local-rtc 1 (vérification : timedatectl)
Titre: Base: Installation et sécurisation d'un serveur Ubuntu
Posté par: vivien le 14 octobre 2021 à 08:53:48
9/ Optionnel : création d'un ramdisque pour /tmp (Cela vise à réduire l'usure du SSD avec des écritures inutiles).

nano /etc/fstab rajouter ces 2 lignes dans le fichier /etc/fstab :
# Placer /tmp sur un RamDisque
tmpfs /tmp tmpfs defaults,size=40% 0 0
ou# Placer /tmp sur un RamDisque
tmpfs /tmp tmpfs defaults,size=4g 0 0
Vérification : mount -a permet de monter tous les systèmes de fichiers déclarés dans le fichier /etc/fstab.
=> Vérifier l'absence d'erreur.




10/ Optionnel : Désactiver la compression de tous les fichiers de logs

(Cela vise à réduire l'usure du SSD avec des écritures inutiles)
1/ Supprimer les .gz existants dans les dossiers des log : rm /var/log/*.gz ; rm /var/log/*/*.gz
2/ Aller dans le dossier de la conf logrotate : cd /etc/logrotate.d/
3/ Chercher les fichiers de conf avec compress : grep compress *
4/ Supprimer delaycompress : sed -i '/delaycompress/d' /etc/logrotate.d/*
5/ Remplacer compress par nocompress : sed -i -e "s/compress/nocompress/g" /etc/logrotate.d/*
6/ Chercher les fichiers avec nonocompress : grep nonocompress *
7/ Remplacer nonocompress par nocompress : sed -i -e "s/nonocompress/nocompress/g" /etc/logrotate.d/*
8/ Vérification : la ligne suivante ne doit rien retourner : grep nonocompress *

Version manuelle : Pour chaque fichier dans le dossier /etc/logrotate.d/ :
A/ Supprimer la ligne delaycompress si présente
B/ Modifier la ligne compress par nocompress
Titre: Base: Installation et sécurisation d'un serveur Ubuntu
Posté par: vivien le 14 octobre 2021 à 08:54:14
11/ Optionnel : Limiter la taille des logs systemd /var/log/journal/

Si certains fichiers de log sont gérés par logrotate, les différents éléments du système sont lancés par systemd qui tient à jour son propre système de journalisation nommé The Journal, enregistré dans le répertoire /var/log/journal/. Si une machine a peu d'espace disque, on peut imiter la taille maximum du journal (par défaut à 10% de la taille du système de fichier, avec un maximum de 4 Go).

nano /etc/systemd/journald.conf

Pour la fixer à 500 Mo par exemple, on modifie la ligne #SystemMaxUse= par SystemMaxUse=600M

D'autres modifications peuvent être envisagée sur /etc/systemd/journald.conf :


On peut aussi faire en sorte que les journaux ne soient pas conservés sur le disque au redémarrage afin de limiter l'usure des SSD sur un serveur avec de la ram ou les logs ne sont pas importants (on perdra les log au reboot du serveur) : Modifier la ligne #Storage=auto par Storage=volatile

Voici les options possibles :


Attention :

Si vous partez sur Storage=volatile, il faudra donc définir un RuntimeMaxUse=300M pour limiter à 300 Mo l’utilisation de ram pour les logs.

Une fois les modifications effectuées, il faut redémarrer le service systemd-journald pour ce soit pris en compte :
systemctl restart systemd-journald




12/ Optionnel : détecter les sondes et rajouter les modules nécessaires

Exécuter sudo sensors-detect
Répondez positivement à toutes les questions ;
À un certain moment sensors-detect vous demande s'il doit ajouter lui même la configuration des capteurs au lancement d'Ubuntu en affichant ceci :

To load everything that is needed, add this to /etc/modules:
#----cut here----
# Chip drivers
coretemp
#----cut here----
If you have some drivers built into your kernel, the list above will
contain too many modules. Skip the appropriate ones!

Do you want to add these lines automatically to /etc/modules? (yes/NO)
Tapez yes, puis faites Entrée.

Vérification du contenu du fichier /etc/modules modifié : cat /etc/modules
Titre: Base: Installation et sécurisation d'un serveur Ubuntu
Posté par: vivien le 14 octobre 2021 à 08:54:53
13/ Optionnel : Installation du Watchdog

Un watchdog (chien de garde en Français s'assure que le serveur ne reste pas bloqué. C'est une protection destinée généralement à redémarrer le système, si une action définie n'est pas exécutée dans un délai imparti (nous allons configurer 120 secondes sans réponse quand le système est démarré ou redémarrage du serveur qui dépasse 10 minutes). Le chien de garde est un registre qui est mis à jour via une interruption régulièrement à 120 secondes et qui est ensuite décrémenté. Si le compteur arrive a descendre jusqu'à 0, le serveur est redémarré, car cela signifie de façon certains qu'il est planté.
L'étape précédente, "Optionnel : détecter les sondes et rajouter les modules nécessaires" permet de détecter et installer un watchdog non IPMI. L'utilitaire d'information lshw peut aider à vérifier si le serveur à un Watchdog. Dans tous les cas, il n'y a pas de risque à suivre le tutoriel si vous n'avez pas de watchdog. Au redémarrage on va simplement voir qu'il ne fonctionne pas.

A/ Installation des paquets nécessaires
apt install openipmi ipmitool watchdog

B/ Configuration du fichier /etc/systemd/system.conf
On configure le temps de non réponse avant reboot :
- 120 secondes quand le serveur est redémarré
- 10 minutes dans une phase de reboot (la ligne existe déjà, on ne fait que enlever le # qui la désactive)

Ubuntu 20.04 :
sed -i -e "s/#RuntimeWatchdogSec=0/RuntimeWatchdogSec=120/g" /etc/systemd/system.conf
sed -i -e "s/#ShutdownWatchdogSec=10min/ShutdownWatchdogSec=10min/g" /etc/systemd/system.conf


Ubuntu 22.04 :
sed -i -e "s/#RuntimeWatchdogSec=0/RuntimeWatchdogSec=120/g" /etc/systemd/system.conf
sed -i -e "s/#RebootWatchdogSec=10min/RebootWatchdogSec=10min/g" /etc/systemd/system.conf


Vérification : sed -e '/^#\|^$/d' /etc/systemd/system.conf

Ces lignes doivent s'afficher :
[Manager]
RuntimeWatchdogSec=120
RebootWatchdogSec=10min

C/ Configuration du fichier /etc/watchdog.conf :
sed -i -e "s/#watchdog-device/watchdog-device/g" /etc/watchdog.conf
Vérification : sed -e '/^#\|^$/d' /etc/watchdog.conf

Ces lignes doivent s'afficher :
watchdog-device = /dev/watchdog
realtime = yes
priority = 1

D/ Configuration du fichier /etc/modules :
Le module impi_watchdog n'est pas automatiquement chargé par le noyau Linux, on va donc le charger :
echo "# Rajouté pour installation WatchDog" >> /etc/modules
echo ipmi_watchdog >> /etc/modules

Vérification du contenu du fichier /etc/modules : cat /etc/modules
Titre: Base: Installation et sécurisation d'un serveur Ubuntu
Posté par: vivien le 14 octobre 2021 à 08:55:25
14/ Appliquer les modifications et vérifier que tout est conforme :

reboot

Vérifier la prise en compte des modifications après redémarrage du serveur : taper la commande en bleu et vérifiez que le résultat affiché est celui en dessous.
Il n'est pas nécessaire de passer en super-utilisateur pour ces commandes.

# Protocole de congestion TCP par défaut
cat /proc/sys/net/ipv4/tcp_congestion_control
Doit retourner : bbr (défaut : cubic)

# Protocole de congestion TCP disponible sur le système
cat /proc/sys/net/ipv4/tcp_allowed_congestion_control
Doit retourner : reno cubic bbr (défaut : reno cubic)

# Protocole de Queuing Discipline
cat /proc/sys/net/core/default_qdisc
Configration BBR : doit retourner fq
Configuration Cubic : doit retourner fq_codel
Valeur par défaut : fq_codel depuis au moins 2018. Ubuntu 22.10 a par défaut pfifo_fast, mais c'est une erreur, il est moins performant que fq_codel

# Réduire l'utilisation de la swap
cat /proc/sys/vm/swappiness
Doit retourner : 1 (défaut : 60)

# Désactiver la mémorisation des tests précédents sur le serveur afin d’assurer une décorrélation des tests successifs et éviter que le serveur bride les tests suite à une performances limitée
cat /proc/sys/net/ipv4/tcp_no_metrics_save
Doit retourner : 1 (défaut :  0)

# Augmenter les buffer TCP pour que cela ne soit pas l'élément limitant du débit
cat /proc/sys/net/ipv4/tcp_rmem
Doit retourner : 4096 131072 33554432 (défaut : 4096   131072   6291456)

# Increase the write-buffer-space allocatable
cat /proc/sys/net/ipv4/tcp_wmem
Doit retourner : 4096 87380 33554432 (défaut : 4096   16384   4194304)

# Increase the read-buffer space allocatable
cat /proc/sys/net/core/rmem_max
Doit retourner : 33554432 (défaut : 212992)

cat /proc/sys/net/core/wmem_max
Doit retourner : 33554432 (défaut : 212992)

# Augmenter la file d'attente au sein du noyau Linux où le trafic est stocké, après réception de la carte réseau :
cat /proc/sys/net/core/netdev_max_backlog
Doit retourner : 4000 (défaut : 1000)

# Réduire le seuil où un DDOS impacte le serveur :
cat /proc/sys/net/ipv4/tcp_max_syn_backlog
Doit retourner : 4096 (défaut : 1024 - 32 Go de RAM 4096 pour 256 Go de RAM)

# Augmenter le nombre de connexions entrantes :
cat /proc/sys/net/core/somaxconn
Doit retourner : 4096 (défaut : 4096 pour les noyaux récents avec 8 Go de RAM, mais beaucoup moins avec des noyaux anciens)

# Vérification que le ramdisque est présent
df -h
Vérifier /tmp est sur un système de fichier "tmpfs"

# Vérifier la température :
sensors
Titre: Base: Installation et sécurisation d'un serveur Ubuntu
Posté par: vivien le 14 octobre 2021 à 08:56:35
15/ Vérification les règles IPtables :

IPv4 :
sudo iptables -L -n -v

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
LOG        tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN #conn src/32 > 50 limit: avg 30/hour burst 1 LOG level warning prefix "drop-c-"
REJECT     tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN #conn src/32 > 50 reject-with icmp-port-unreachable
DROP       udp  --  anywhere             anywhere             udp dpts:5200:5209

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

IPv6 :
sudo ip6tables -L -n -v

# ip6tables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
LOG        tcp      anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN #conn src/64 > 50 limit: avg 30/hour burst 1 LOG level warning prefix "drop-c-"
REJECT     tcp      anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN #conn src/64 > 50 reject-with icmp6-port-unreachable
DROP       udp      anywhere             anywhere             udp dpts:5200:5209

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
Titre: Base: Installation et sécurisation d'un serveur Ubuntu
Posté par: vivien le 14 octobre 2021 à 08:57:04
16/ Vérifications que le watchdog fontionne (si installé)
Installation réalisée à l'étape 13/ Optionnel : Installation du Watchdog (https://lafibre.info/ubuntu/securisation-serveur/msg898845/#msg898845).

La commande pour interroger le watchdog est la suivante :
sudo ipmitool mc watchdog get

ok : il fonctionne parfaitement

# ipmitool mc watchdog get
Watchdog Timer Use:     SMS/OS (0x44)
Watchdog Timer Is:      Started/Running
Watchdog Timer Actions: Hard Reset (0x01)
Pre-timeout interval:   0 seconds
Timer Expiration Flags: 0x10
Initial Countdown:      120 sec
Present Countdown:      77 sec

Non ok : En cas de plantage, le serveur ne redémarrera pas.
# ipmitool mc watchdog get
Watchdog Timer Use:     SMS/OS (0x04)
Watchdog Timer Is:      Stopped
Watchdog Timer Actions: No action (0x00)
Pre-timeout interval:   0 seconds
Timer Expiration Flags: 0x10
Initial Countdown:      10 sec
Present Countdown:      10 sec

Détail des différentes lignes affichées :


Si le wathdog ne fonctionne pas :

Le Watchdog peut être désactivé dans l'UEFI, il faut dans ce cas là l'activer :

(https://lafibre.info/images/materiel/201605_watchdog_dell_poweredge_r320.jpg)

Dépendance manquante dans /etc/modules : Les modules « ipmi_si » et « ipmi_devintf » sont nécessaire au Watchdog IPMI :
lsmod | grep ipmi

ipmi_ssif              24576  0
ipmi_devintf           20480  0
ipmi_si                57344  0
ipmi_msghandler        49152  3 ipmi_ssif,ipmi_devintf,ipmi_si


Si la ligne « ipmi_devintf » est absente : echo ipmi_devintf >> /etc/modules
Si la ligne « ipmi_si absent » est absente : echo ipmi_si >> /etc/modules


Vérification du contenu du fichier /etc/modules : cat /etc/modules


L'état du watatchdog peut aussi se vérifier dans l'iDrac pour un serveur Dell :


(https://lafibre.info/testdebit/ubuntu/202111_watchdog_dell_poweredge_r330_1.png)
Titre: Base: Installation et sécurisation d'un serveur Ubuntu
Posté par: vivien le 14 octobre 2021 à 08:57:28
Annexes :


Renommer le serveur :

nano /etc/hosts
On met en premier l’IP, suivit d’un espace et du nom de domaine pleinement qualifié (avec le .com ou .fr) suivit d’un espace et du nom simple du serveur.
nano /etc/hostname
On met seulement le nom simple du serveur (pas besoin du nom complet avec le .com ou .fr)
reboot




Si le système est en anglais, pour le passer en Français :

sudo locale-gen fr_FR.UTF-8
sudo dpkg-reconfigure locales

vérifier que nano /etc/default/locale contienne :

LANG=fr_FR.UTF-8


Modifier le fuseau horaire

Pour changer le fuseau horaire, pour avoir l'heure locale et pas l'heure UTC (Universal Time Zone)

sudo dpkg-reconfigure tzdata

Sélectionner ensuite le continent et la ville.
Titre: Base: Installation et sécurisation d'un serveur Ubuntu
Posté par: vivien le 14 octobre 2021 à 08:57:56
Annexes : Créer un nouvel utilisateur et lui donner les droits root via sudo :

adduser VOTRE_LOGIN : création de l'utilisateur
usermod -a -G sudo VOTRE_LOGIN : on lui donne les droits de faire sudo pour avoir les droits root




Verrouiller l'utilisateur root : (ne concerne que les installations où il y a un utilisateur root)

C'est une commande à faire depuis un autre utilisateur qui a les droits root via sudo.
sudo usermod -L root
Retirer l'autorisation de connexion SSH avec l'utilisateur root : sudo nano /etc/ssh/sshd_config
Chercher la ligne « PermitRootLogin yes » qui est à la ligne 32 sur mon fichier et remplacer le yes par no.
Titre: Base: Installation et sécurisation d'un serveur Ubuntu
Posté par: vivien le 14 octobre 2021 à 08:58:47
Annexes : Désactiver l’historisation des commandes tapées (.bash_history)

set +o history
echo 'set +o history' >> ~/.bashrc
rm ~/.bash_history




Empêcher un PC portable, utilisé en serveur de se mettre en veille quand l'écran est refermé :

Il suffit de mettre la ligne #HandleLidSwitch=suspend à HandleLidSwitch=ignore dans le fichier /etc/systemd/logind.conf
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# See logind.conf(5) for details

[Login]
#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
Controllers=blkio cpu cpuacct cpuset devices freezer hugetlb memory perf_event net_cls net_prio
ResetControllers=
#InhibitDelayMaxSec=5
#HandlePowerKey=poweroff
#HandleSuspendKey=suspend
#HandleHibernateKey=hibernate
HandleLidSwitch=ignore
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=yes
#IdleAction=ignore
#IdleActionSec=30min
systemctl daemon-reload pour appliquer la configuration systemd modifiée
Titre: Base: Installation et sécurisation d'un serveur Ubuntu
Posté par: vivien le 14 octobre 2021 à 14:06:23
Annexes : Consulter les log IPtables de paquets rejetés car allant au-delà de 200 connexions par IP4 ou /64 IPv6 :

Cela fait suite à la commande mise en place à l'étape 5/ Limitation du nombre de connexion TCP simultanées par IP (https://lafibre.info/ubuntu/securisation-serveur/msg898840/#msg898840) et 14/ Vérification les règles IPtables (https://lafibre.info/ubuntu/securisation-serveur/msg898846/#msg898846)

Pour consulter les logs : journalctl -k | grep drop-c-

Voici ce que cela donne (j'ai juste remplacé le dernier octet de l'adresse IP par x) :

avril 07 17:28:51 ubuntu kernel: drop-c-IN=enp2s0f0 OUT= MAC=3c:fd:fe:1a:1d:e0:84:26:2b:c6:6f:18:08:00 SRC=81.50.121.xx DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=55 ID=15945 DF PROTO=TCP SPT=33263 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
avril 07 17:28:51 ubuntu kernel: drop-c-IN=enp2s0f0 OUT= MAC=3c:fd:fe:1a:1d:e0:84:26:2b:c6:6f:18:08:00 SRC=81.50.121.xx DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=55 ID=12818 DF PROTO=TCP SPT=33274 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
avril 07 17:39:57 ubuntu kernel: drop-c-IN=enp2s0f0 OUT= MAC=3c:fd:fe:1a:1d:e0:84:26:2b:c6:6f:18:08:00 SRC=193.49.116.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=30786 DF PROTO=TCP SPT=57506 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
avril 07 17:48:27 ubuntu kernel: drop-c-IN=enp2s0f0 OUT= MAC=3c:fd:fe:1a:1d:e0:84:26:2b:c6:6f:18:08:00 SRC=37.71.114.xx DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=57578 DF PROTO=TCP SPT=42584 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
avril 07 17:51:06 ubuntu kernel: drop-c-IN=enp2s0f0 OUT= MAC=3c:fd:fe:1a:1d:e0:84:26:2b:c6:6f:18:08:00 SRC=92.134.126.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=55 ID=24377 DF PROTO=TCP SPT=36510 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
avril 07 18:00:35 ubuntu kernel: drop-c-IN=enp2s0f0 OUT= MAC=3c:fd:fe:1a:1d:e0:84:26:2b:c6:6f:18:08:00 SRC=154.245.36.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=47 ID=55231 DF PROTO=TCP SPT=55514 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
avril 07 18:00:36 ubuntu kernel: drop-c-IN=enp2s0f0 OUT= MAC=3c:fd:fe:1a:1d:e0:84:26:2b:c6:6f:18:08:00 SRC=154.245.36.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=47 ID=55232 DF PROTO=TCP SPT=55514 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
avril 07 18:00:38 ubuntu kernel: drop-c-IN=enp2s0f0 OUT= MAC=3c:fd:fe:1a:1d:e0:84:26:2b:c6:6f:18:08:00 SRC=154.245.36.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=47 ID=55233 DF PROTO=TCP SPT=55514 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
avril 07 18:00:42 ubuntu kernel: drop-c-IN=enp2s0f0 OUT= MAC=3c:fd:fe:1a:1d:e0:84:26:2b:c6:6f:18:08:00 SRC=154.245.36.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=47 ID=55234 DF PROTO=TCP SPT=55514 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
avril 07 18:00:50 ubuntu kernel: drop-c-IN=enp2s0f0 OUT= MAC=3c:fd:fe:1a:1d:e0:84:26:2b:c6:6f:18:08:00 SRC=154.245.36.x DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=47 ID=55235 DF PROTO=TCP SPT=55514 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0
avril 07 18:01:49 ubuntu kernel: drop-c-IN=enp2s0f0 OUT= MAC=3c:fd:fe:1a:1d:e0:84:26:2b:c6:6f:18:08:00 SRC=91.219.68.xx DST=194.158.119.186 LEN=60 TOS=0x00 PREC=0x00 TTL=46 ID=27223 DF PROTO=TCP SPT=4591 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0



Consultation des statistiques IPtables (nombre de paquets) :

Consulter les stats IPv4 : iptables -n -v -L INPUT
# iptables -n -v -L INPUT
Chain INPUT (policy ACCEPT 1685M packets, 3081G bytes)
 pkts bytes target     prot opt in     out     source               destination         
  105  5672 LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:0x17/0x02 #conn src/32 > 50 limit: avg 30/hour burst 1 LOG flags 0 level 4 prefix "drop-c-"
68052 3825K REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:0x17/0x02 #conn src/32 > 50 reject-with icmp-port-unreachable
   16   512 DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpts:5200:5209

Consulter les stats IPv6 : ip6tables -n -v -L INPUT
# ip6tables -n -v -L INPUT
Chain INPUT (policy ACCEPT 162M packets, 2140G bytes)
 pkts bytes target     prot opt in     out     source               destination         
    1    80 LOG        tcp      *      *       ::/0                 ::/0                 tcp flags:0x17/0x02 #conn src/64 > 50 limit: avg 30/hour burst 1 LOG flags 0 level 4 prefix "drop-c-"
    7   560 REJECT     tcp      *      *       ::/0                 ::/0                 tcp flags:0x17/0x02 #conn src/64 > 50 reject-with icmp6-port-unreachable
    0     0 DROP       udp      *      *       ::/0                 ::/0                 udp dpts:5200:5209
Titre: Base: Installation et sécurisation d'un serveur Ubuntu
Posté par: vivien le 06 novembre 2021 à 11:25:00
Annexes : Le watchdog en action

Le watchdog que nous avons configuré va redémarrer le serveur en cas de non réponse pendant 120 secondes quand le système à démarré ou 10 minutes quand le système redémarre.

Voici ci-dessous un exemple d'un reboot qui n'a pas fonctionné. La cause est probablement matérielle, la carte réseau étant dans un état second (https://lafibre.info/serveurs/intel-x710-da2/msg902349/#msg902349).

Le KVM-IP est resté 10 minutes sur cet écran puis a redémarré le serveur :

(https://lafibre.info/testdebit/ubuntu/202111_watchdog_dell_poweredge_r330_2.png)

Dans les log de l'iDrac, on voit l'action du watchdog :


(https://lafibre.info/testdebit/ubuntu/202111_watchdog_dell_poweredge_r330_3.png)
Titre: Base: Installation et sécurisation d'un serveur Ubuntu
Posté par: vivien le 06 novembre 2021 à 11:25:23
N'hésitez pas à faire vos commentaires ou suggestions ci-dessous !
Titre: Base: Installation et sécurisation d'un serveur Ubuntu
Posté par: laurent34 le 08 novembre 2021 à 10:06:09
7/ Automatiser l'installation des mises à jour de sécurité de nuit
[...]
sed -i -e "s/\/\/Unattended-Upgrade::Automatic-Reboot \"false\"/Unattended-Upgrade::Automatic-Reboot \"true\"/g" /etc/apt/apt.conf.d/50unattended-upgrades : redémarrer automatiquement la nuit, si une mise à jour nécessite un redémarrage (c’est les cas des mises à jour du noyau Linux)
[...]
Hello,
en alternative au reboot pour le patch du noyau, il existe le livepatch qui est gratuit jusqu'à trois serveurs (en utilisation perso c'est cool). Il faut créer un compte ubuntu one, récupérer un token, installer le service, et ça roule.
Du coup, on paramètre les maj comme tu le dits, mais on ne programme pas de reboot. Les majs kernels se feront effectivement le jour où on rebootera.
En attendant, le kernel est patché à chaud sans reboot, une commande permet de voir les CVE corrigées.
https://ubuntu.com/advantage#livepatch
https://github.com/canonical-web-and-design/tutorials.ubuntu.com/blob/master/tutorials/server/enable-the-livepatch-service/enable-the-livepatch-service.md

EDIT: la doc a un peu évolué depuis mon installation: https://manpages.ubuntu.com/manpages/focal/man1/ua.1.html  et  https://ubuntu.com/tutorials/enable-the-livepatch-service#3-enabling-livepatch

Voilà ce que ça donne chez moi:
$ canonical-livepatch status --verbose
last check: 17 minutes ago
kernel: 5.4.0-77.86-generic
server check-in: succeeded
patch state: ✓ all applicable livepatch modules inserted
patch version: 81.1
tier: updates (Free usage; This machine beta tests new patches.)
machine id:  blablabla
client version: 9.8.0
architecture: x86_64
cpu model: AMD GX-415GA SOC with Radeon(tm) HD Graphics
boot time: 3 months ago
fixes:
  * cve-2013-1798
    The ioapic_read_indirect [...]
etc... etc... etc ...


Titre: Base: Installation et sécurisation d'un serveur Ubuntu
Posté par: vivien le 11 novembre 2021 à 10:16:56
Attention tous les noyaux ne sont pas pris en charge par le Livepath.

Voici les noyaux Linux supportés par le Livepath : https://ubuntu.com/security/livepatch/docs/kernels

Pour Ubuntu 20.04 LTS, le noyau HWE n'est pas encore supporté. Il sera supporté quand le noyau HWE d'Ubuntu 20.04 sera celui d'Ubuntu 22.04.
Titre: Base: Installation et sécurisation d'un serveur Ubuntu
Posté par: laurent34 le 11 novembre 2021 à 11:35:05
Hello, merci pour cette précision, je ne n'avais pas vu cette subtilité.

Et en complément, je me rends compte à l'instant du message "This machine beta tests new patches" sur ma machine.
https://ubuntuforums.org/showthread.php?t=2463244

Il semblerait que l'offre gratuite de Livepatch implique de recevoir les versions beta des patchs de sécu !

Bon, pour mon petit serveur perso dans le garage, ça me convient quand même.

(PS: merci pour ton guide qui est très bien !)
Titre: Base: Installation et sécurisation d'un serveur Ubuntu
Posté par: Free_me le 11 novembre 2021 à 19:47:35
je ne vois pas quelle est cette folie de vouloir que l'ordi reboot tout seul....
Franchement j'ai mis ubuntu a la place de windows uniquement parce que le merdier ne s'amuse pas a reboot tout seul et si je veux je reboot moi meme apres  6 mois si ca me chante....
Titre: Base: Installation et sécurisation d'un serveur Ubuntu
Posté par: vivien le 11 novembre 2021 à 20:56:52
Il y a des mises à jour de sécurité, principalement celles qui concernent le noyau qui demandent soit de redémarrer soit de patcher à la volée, le service livepatch dont on parle.

Quand tu te logue en SSH sur un serveur qui a besoin d'être redémarré, il afficher *** System restart required ***

Bien sur c'est facultatif, mais avoir un serveur (car là on parle plus de serveur) pas à jour, cela entraîne un risque.
Titre: Base: Installation et sécurisation d'un serveur Ubuntu
Posté par: Free_me le 11 novembre 2021 à 21:01:50
heu justement sur un serveur c'est encore pire....
deja sur un pc perso c'est chiant tu te pointes un matin et tu te rend compte que tout tes softs ouverts ont degagé, youpi....
mais sur un serveur, c'est encore pire, c'est le business de tes clients...
(serveur perso pour des conneries a la limite ouais pourquoi pas)
Titre: Base: Installation et sécurisation d'un serveur Ubuntu
Posté par: vivien le 11 novembre 2021 à 21:06:10
Deux à trois minutes d'indisponibilité en pleine nuit ce n'est pas problématique.

Si tu fais bien les scripts, tout est opérationnel au redémarrage, même pour un serveur complexe.
Titre: Base: Installation et sécurisation d'un serveur Ubuntu
Posté par: testing5555 le 12 novembre 2021 à 08:35:17
C'est ce que j'allais dire, si ton serveur de prod ne relance pas tout seul les applis après redémarrage c'est que tu n'as pas fait ton boulot comme il faut.
Et laisser un serveur que tu vends à tes clients sans mise à jour pendant 6 mois c'est pas top niveau cyber-sécu donc c'est que tu ne fais pas bien ton boulot non plus.
Même en usage perso sur mes SBC je m'assure que les applis sensées tourner 24:7 sont bien relancées après un reboot (et ce n'est pas un gros travail car souvent tu trouves ce qu'il faut pour faire tourner les applis en tant que services)

Après pour la mise à jour en mode auto eu milieu de la nuit en prod faut être un peu joueur car tu as toujours un risque que ça coince et que tout ne redémarre pas (j'ai déjà eu le cas où un mysql n'arrivait pas à se mettre à jour et donc ne démarrait plus). Si tu fais la MAJ à la main tu détectes bien plus vite un éventuel problème (mais tu crées une indispo pendant les heures de bureau ce qui peut être gênant)

Pour livepatch en mode gratuit oui c'est clairement un deal où tu as la fonction gratuitement pour qu'en échange ils puissent tester les patchs sur un grand nombre de machines avant de les envoyer sur les machines de ceux qui payent afin de pouvoir détecter un éventuel problème sur une conf spécifique qui serait passé inaperçu lors de leurs tests. Sur une install standard je pense que le risque reste assez limité.
Titre: Base: Installation et sécurisation d'un serveur Ubuntu
Posté par: Free_me le 12 novembre 2021 à 08:56:43
le vrai soucis n'est pas que quelque se passe mal au redemarrage des services (meme si oui evidement c'est aussi un enjeu : t'as pas envie de recevoir un appel a 8h du mat "heu.... je comprend pas y a plus rien qui marche là !!" juste pour une connerie de redemarrage auto), le reel soucis c'est que le serveur n'est plus disponible et que c'est du business qui tourne dessus.
Tout n'est pas clusteurisé dans du k8s. La plupart des clients ont des plateformes basiques (nginx,apache,mysql,postgre,elasticsearch,redis, etc..) et dont les services ne sont pas interruptibles de maniere transparente et du coup pas possible de redemarrer un mysql quand ca me fait plaisir (ou pire, quand le serveur en a envie...).
Et encore pire, j'ai certains services qui sont lancés par le client lui meme (des conneries en nodejs). Enfin on va dire que ca ca compte pas.

Par contre serveur perso : ouais je suis d'accord.

PS :
D'ailleurs tiens, j'ai un windows 11 qui s'est permis de rebooter cette nuit : j'ai regardé l'ampleur des degats et je suis assez surpris. On dirait que ca y est ils sont enfin capables de restaurer les bloc-notes ouverts ? Ca s'ameliore pas mal donc ! Bon il resterai quand meme : les phpstorm, les vm virtualbox, notepad++, les explorateurs de fichier, les mobaxterm (et ne pas juste la fenetre vide hein : bien reouvrir mes onglets ssh).... et tout ca a remettre chacun dans le bon bureau.


Titre: Base: Installation et sécurisation d'un serveur Ubuntu
Posté par: Free_me le 12 novembre 2021 à 09:06:13
C'est ce que j'allais dire, si ton serveur de prod ne relance pas tout seul les applis après redémarrage c'est que tu n'as pas fait ton boulot comme il faut.
Et laisser un serveur que tu vends à tes clients sans mise à jour pendant 6 mois c'est pas top niveau cyber-sécu donc c'est que tu ne fais pas bien ton boulot non plus.

ah mais on en fait. Sauf que c'est programmé, selon les serveurs soit entre midi et 14h, soit plutot à 23h. Et c'est selon la cadence du client, donc en moyenne tous les 2 mois quoi.

Après pour la mise à jour en mode auto eu milieu de la nuit en prod faut être un peu joueur car tu as toujours un risque que ça coince et que tout ne redémarre pas (j'ai déjà eu le cas où un mysql n'arrivait pas à se mettre à jour et donc ne démarrait plus). Si tu fais la MAJ à la main tu détectes bien plus vite un éventuel problème (mais tu crées une indispo pendant les heures de bureau ce qui peut être gênant)

j'ai deja eu le cas. Et pas envie de revivre ca.
Et en gros ca m'arrive quasi une fois par an que le reboot du soir 22h, ben tu galeres 1h car un service veut plus redemarrer pour une raison X ou Y.
Dernier en date : maxscale qui passe de v2.5 à v6 a cause de 2 variables plus reconnues... => imagine tu fais ca la nuit en auto, peinard pendant que tu dors.... franchement pour certains client ce serait la catastrophe.

Titre: Base: Installation et sécurisation d'un serveur Ubuntu
Posté par: vivien le 13 décembre 2021 à 20:41:05
Il y a des mises à jour de sécurité, principalement celles qui concernent le noyau qui demandent soit de redémarrer soit de patcher à la volée, le service livepatch dont on parle.

Quand tu te logue en SSH sur un serveur qui a besoin d'être redémarré, il afficher *** System restart required ***

Bien sur c'est facultatif, mais avoir un serveur (car là on parle plus de serveur) pas à jour, cela entraîne un risque.

Si vous souhaitez savoir quel outil nécessite un redémarrage quand *** System restart required *** s'affihche quand vous vous sconnectez en SSH sur le serveur, il faut installer un petit outil : checkrestart

sudo apt install debian-goodies

Pour voir les service a redémarrer, il suffit de faire :

sudo checkrestart

Exemple :

(https://lafibre.info/testdebit/ubuntu/202112_ubuntu_checkrestart.png)
Titre: Base: Installation et sécurisation d'un serveur Ubuntu
Posté par: Fric-Box le 17 mars 2022 à 07:42:21
Merci pour ce guide très précieux pour un débutant comme moi, ça permet de piocher plein de bonnes idées et de tester !
Titre: Base: Installation et sécurisation d'un serveur Ubuntu
Posté par: vivien le 08 mai 2023 à 17:28:10
Mise à jour en rajoutant une section sur la mise à l'heure : timedatectl : Faire en sorte que le serveur reste à l'heure (https://lafibre.info/ubuntu/securisation-serveur/msg898842/#msg898842).

Je suis en effet tombé sur un serveur qui avait plusieurs minutes de décalage avec la véritable heure.

Cela semble actif par défaut, mais certains hébergeurs qui préinstallent Ubuntu server semblent le désactiver sans proposer de solution alternative.