Auteur Sujet: Base: Installation et sécurisation d'un serveur Ubuntu  (Lu 4028 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 43 567
    • Twitter LaFibre.info
Base: Installation et sécurisation d'un serveur Ubuntu
« le: 14 octobre 2021 à 08:47:43 »
Tutoriel testé avec Ubuntu version 20.04 et 22.04
(les différences entre les deux versions sont mentionnées quand elles existent)

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

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 :
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

  • « mtr-tiny » : traceroute amélioré très pratique, installé par défaut dans Ubuntu server, mais pas dans des dérivés d'Ubuntu (comme Raspberry Pi OS).
  • « htop » permet de suivre l’utilisation du CPU et mémoire des différents process dans une interface texte.« whois » : outil pour interroger le whois, qui permet d'obtenir des informations sur une adresse IP ou un nom de domaine.
  • « iotop » : Un équivalent de top dédié aux accès disques.
  • « iftop » : permet de voir quelles IP consomment le plus de réseau.
  • « nload » : permet de voir le trafic sur une interface réseau.
  • « nmon » : permet d’afficher le processeur, la mémoire, le réseau, les disques, les systèmes de fichiers, les principaux processus, les ressources.
  • « neofetch », permet d'afficher un écran d’information sur le système.
  • « manpages-fr manpages-fr-dev manpages-fr-extra » : avoir la version française des pages de manuel des programmes.
apt autoremove : Supprime les éventuelles dépendances devenues inutiles
apt clean permet de supprimer les paquets .deb téléchargés

vivien

  • Administrateur
  • *
  • Messages: 43 567
    • Twitter LaFibre.info
Base: Installation et sécurisation d'un serveur Ubuntu
« Réponse #1 le: 14 octobre 2021 à 08:48:26 »
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.

vivien

  • Administrateur
  • *
  • Messages: 43 567
    • Twitter LaFibre.info
Base: Installation et sécurisation d'un serveur Ubuntu
« Réponse #2 le: 14 octobre 2021 à 08:48:54 »
4/ Sécurisation du serveur SSH :

Changement de port de SSH, pour limiter d'être la cibles des attaques sur le port 22 et permettre de maintenir la connexion SSH, y compris derrière un CG-Nat :
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 CG-NAT
ClientAliveInterval 4
ClientAliveCountMax 22
La connexion au reboot se fera avec ssh [login]@[nom de domaine] -p 2222
Optionnel : ne faire écouter SSH que sur les IPv6 : rajouter

AddressFamily inet6Optionnel : ne faire écouter SSH que sur une IPv6 dédiée (qu'il faudra configurer dans netplan), rajouter :
AddressFamily inet6
ListenAddress [2103:b860:de01:1100:2200:abcd:ef01:1100]

vivien

  • Administrateur
  • *
  • Messages: 43 567
    • Twitter LaFibre.info
Base: Installation et sécurisation d'un serveur Ubuntu
« Réponse #3 le: 14 octobre 2021 à 08:49:14 »
5/ Limitation du nombre de connexion TCP simultanées par IP :

On va limiter à 100 connexions par IPv4 et par plage IPv6 /64, afin de bloquer certains type d’attaque par déni de service.
Pour un site web important, il peut être nécessaire de monter à 200 connexions simultanés.
On va loger les loger les connexions, mais pour éviter d'être submergé par les connexion à loguer, on va limiter drastiquement 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)

vivien

  • Administrateur
  • *
  • Messages: 43 567
    • Twitter LaFibre.info
Base: Installation et sécurisation d'un serveur Ubuntu
« Réponse #4 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

vivien

  • Administrateur
  • *
  • Messages: 43 567
    • Twitter LaFibre.info
Base: Installation et sécurisation d'un serveur Ubuntu
« Réponse #5 le: 14 octobre 2021 à 08:52:45 »
8/ 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.




9/ 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

vivien

  • Administrateur
  • *
  • Messages: 43 567
    • Twitter LaFibre.info
Base: Installation et sécurisation d'un serveur Ubuntu
« Réponse #6 le: 14 octobre 2021 à 08:53:48 »
10/ 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 :

  • SystemKeepFree : L’espace qui doit rester libre sur la partition où sont trouvés les journaux. Par défaut 15%, ce qui veut dire qu’à 85% d’espace utilisé, journald supprimera des logs pour éviter de remplir la partition. S'il y avait suffisamment d'espace libre avant et que les fichiers journaux ont été créés, et par la suite quelque chose d'autre provoque le remplissage du système de fichiers, journald cessera d'utiliser plus d'espace, mais il ne supprimera pas non plus les fichiers existants pour réduire à nouveau l'empreinte. Notez également que seuls les fichiers archivés sont supprimés pour réduire l'espace occupé par les fichiers journaux.
  • SystemMaxFileSize : Journald écrit ses fichiers au format binaire et fait une rotation sur ces fichiers. Le fichier en cours d’écriture sera rempli jusqu’à la taille spécifiée, avant qu’un nouveau fichier soit créé. Par défaut 1/8 de la taille totale définie avec SystemMaxUse. Par exemple, si vous définissez un SystemMaxUse de 600M, chaque fichier de journal sur disque fera au maximum 75M avant rotation.
  • SystemMaxFiles : contrôle le nombre de fichiers journaux individuels à conserver au maximum. Notez que seuls les fichiers archivés sont supprimés pour réduire le nombre de fichiers jusqu'à ce que cette limite soit atteinte ; les fichiers actifs resteront. Cela signifie qu'en fait, il peut y avoir encore plus de fichiers journaux au total que cette limite une fois l'opération de nettoyage terminée. Ce paramètre est défini par défaut sur 100.

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 :

  • persistent : Les logs sont écrits sur le disque, dans le dossier /var/log/journal, à la condition que /var soit monté.
  • volatile : Les logs sont gardés dans la mémoire, plus précisément stockés dans le dossier /run/log/journal
  • auto (par défaut) : Le système choisit où sont écrits les logs. Si le dossier /var/log/journal existe et est accessible, alors les logs y seront écrits. Sinon, ça se fera en mémoire.
  • none : Les logs ne sont pas stockés et donc directement droppés à la réception

Attention :
  • Les options SystemMaxUse=, SystemKeepFree=, SystemMaxFileSize=, SystemMaxFiles= concernent le stockage persistant (sur disque donc).
  • Les options RuntimeMaxUse=, RuntimeKeepFree=, RuntimeMaxFileSize=, RuntimeMaxFiles= sont leur équivalent pour le stockage volatile (en RAM donc).

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

vivien

  • Administrateur
  • *
  • Messages: 43 567
    • Twitter LaFibre.info
Base: Installation et sécurisation d'un serveur Ubuntu
« Réponse #7 le: 14 octobre 2021 à 08:54:14 »
11/ Horloge système

Optionnel sur un serveur physique : mettre le système à l'heure toutes les 4h pour limiter le décalage horaire
nano /etc/cron.d/maj-heure

# Mise à jour de l'heure a 0h59 ; 4h59 ; 8h59 ; 12h59 ; 16h59 ; 20h59
59 */4 * * * root sleep 8s ; /usr/sbin/ntpdate ntp.lafibre.info >>/tmp/ntpdate.log 2>&1

Optionnel, si installation en dual boot avec Windows à coté, pour mettre l'heure du PC sur l'heure locale :
timedatectl set-local-rtc 1 (vérification : timedatectl)




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

vivien

  • Administrateur
  • *
  • Messages: 43 567
    • Twitter LaFibre.info
Base: Installation et sécurisation d'un serveur Ubuntu
« Réponse #8 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

vivien

  • Administrateur
  • *
  • Messages: 43 567
    • Twitter LaFibre.info
Base: Installation et sécurisation d'un serveur Ubuntu
« Réponse #9 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

vivien

  • Administrateur
  • *
  • Messages: 43 567
    • Twitter LaFibre.info
Base: Installation et sécurisation d'un serveur Ubuntu
« Réponse #10 le: 14 octobre 2021 à 08:56:35 »
15/ Vérification les règles IPtables :

IPv4 :
sudo iptables -L

# 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

# 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

vivien

  • Administrateur
  • *
  • Messages: 43 567
    • Twitter LaFibre.info
Base: Installation et sécurisation d'un serveur Ubuntu
« Réponse #11 le: 14 octobre 2021 à 08:57:04 »
16/ Vérifications que le watchdog fontionne (si installé)
Installation réalisée à l'étape 12/ Optionnel : Installation du Watchdog.

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 :
  • Watchdog Timer Is : Permet de savoir si le watchdog fonctionne : Il faut que ce soit « Started/Running ».
  • Watchdog Timer Actions : L'action effectuée en cas d’expiration du délai « Initial Countdown » Il faut que ce soit « Hard Reset » pour provoquer un reboot.
  • Initial Countdown : Délai du watchdog initial (celui configuré dans /etc/systemd/system.conf)
  • Present Countdown : Délai actuel avant reboot (« Present Countdown » est remis régulièrement à « Initial Countdown » a la moitié du temps écoulé).


Si le wathdog ne fonctionne pas :

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



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 :