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

vivien · « **Réponse #12 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 :

Code: [Sélectionner]

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.

vivien · « **Réponse #13 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.

vivien · « **Réponse #14 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

Code: [Sélectionner]

#  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

vivien · « **Réponse #15 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 et 14/ Vérification les règles IPtables

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

Code: [Sélectionner]

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

Code: [Sélectionner]

# 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

Code: [Sélectionner]

# 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

vivien · « **Réponse #16 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.

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

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

vivien · « **Réponse #17 le:** 06 novembre 2021 à 11:25:23 »

N'hésitez pas à faire vos commentaires ou suggestions ci-dessous !

laurent34 · « **Réponse #18 le:** 08 novembre 2021 à 10:06:09 »

Citation de: vivien le 14 octobre 2021 à 08:49:55

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

vivien · « **Réponse #19 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.

laurent34 · « **Réponse #20 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 !)

Free_me · « **Réponse #21 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....

vivien · « **Réponse #22 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.

Free_me · « **Réponse #23 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)