Config Debian – Commune

Je prends ici quelques notes sur comment je configure mes serveurs Debian. Ça me permettra de les réinstaller / me souvenir de ce que je fais. Ce sera peut-être utile à d’autres, ou alors j’aurai peut-être des commentaires intéressants.

Quelques applis pas forcément installées

Sur les VPS de Contabo, je me suis aperçu que certaines applis que je pensais installées ne l’étaient pas. Je les installe parce que j’en ai besoin par ailleurs :

sudo apt install cron logrotate
sudo systemctl enable cron

Gestion utilisateur

À chaque installation de Debian, l’installateur me crée un accès root et un accès utilisateur username. Je donne les droits administrateurs à mon accès utilisateur. Si besoin, j’installe sudo quand l’installateur ne l’a pas déjà ajouté. À noter que sur Debian, certaines commandes sont par défaut inaccessibles si non exécutées avec sudo, même si sudo n’est pas installé.

# Besoin du mot de passe root pour avoir les droits administrateurs
su root
apt-install sudo # Si pas installé
# Par défaut, les commandes sur les utilisateurs sont bloquées derrière sudo
sudo usermod -aG sudo username

Réseau

Dans les notes de mise à jour vers Trixe, il est indiqué que isc_dhcp, un client et serveur DHCP, est déprécié. Il est aussi mis que ifupdown, le paquet historique pour la gestion des interfaces est vieillissant, et qu’il vaut mieux utiliser des gestionnaires de réseau plus récent. Pour le serveur de sauvegarde, j’utilise systemd, pour les VPS, il faut que je regarde si j’utilise netplan.

Configuration SSH

Je désactive le login root et je change le port SSH. Pour mon serveur de sauvegarde, qui est chez moi, je suis de toute façon obligé pour pouvoir ouvrir un port sur la box.

sudo nano /etc/ssh/sshd_config.d/01_custom.conf
--------------------------------------
# Numéro du port
Port XXXXX
# Interdit le login root
PermitRootLogin no
# À terme, désactiver l’authentification par mot de passe pour ne laisser que l’authentification par clé
#PasswordAuthentication no

Pour créer une clé SSH, j’ai une page dédiée aux clés SSH avec Yubikey.

Pour les clés SSH classiques, je précise juste que je pense qu’il faut augmenter le nombre de passes de chiffrement (option -a, au minimum 500, voire plus).

Une fois que mes 2 clés SSH sont sur le serveur, je peux désactiver l’authentification par mot de passe :

sudo nano /etc/ssh/sshd_config.d/01_custom.conf
--------------------------------------
# Numéro du port
Port XXXXX
# Interdit le login root
PermitRootLogin no
# Désactiver l’authentification par mot de passe pour ne laisser que l’authentification par clé
PasswordAuthentication no

Pare-feu UFW

Je configure UFW pour refuser tout le trafic entrant qui ne soit pas sur les ports que j’ai décidés. J’autorise le trafic sortant, pour le moment, parce que ce serait un peu compliqué de configurer tous les ports pour que le serveur fonctionne correctement, je pense (envoyer des mails, télécharger les mises à jour…)

sudo apt install ufw
# Autoriser le trafic sortant
sudo ufw default allow outgoing comment 'allow all outgoing traffic'
# Interdire le trafic entrant
sudo ufw default deny incoming comment 'deny all incoming traffic'
# Autoriser les connexions SSH
sudo ufw allow proto tcp from all to any port XXXXX comment 'SSH'
# Pour autoriser les connexions SSH depuis des adresses IP spécifiques
sudo ufw allow proto tcp from 192.168.1.XX to any port XXXXX comment 'Nom associé à l’IP'

C’est la seule règle UFW un peu commune à mes serveurs. Pour certains, j’ajoute des règles en fonction des applications qui tournent dessus (ou je laisse Yunohost faire le boulot).

Monitoring serveur

Il y a une partie commune au monitoring serveur, qui concerne notamment la surveillance des mises à jour et l’envoi de mails d’alertes. À noter que Yunohost s’en occupe déjà (notamment via l’app unattended-upgrades).

Envoi de mails

Je ne souhaite pas de mail local, uniquement envoyer les mails via SMTP. Après vérification (merci dealingtrap), utiliser un petit utilitaire comme msmtp est suffisant. Prendre la version mta permet de créer automatiquement des liens symboliques pour que les mails systèmes utilisent msmtp (ça tombe bien, c’est principalement ce que je veux).

# Je rajoute bsd-mailx qui permet d’utiliser la fonction mail. Pratique pour faire des tests, je ne sais pas si les applis en ont besoin.
sudo apt install msmtp-mta bsd-mailx

La configuration se fait grâce à un fichier de configuration générale. Il est aussi possible d’avoir des configurations par utilisateur, mais ce n’est pas ce qui m’intéresse.

sudo nano /etc/msmtprc
----------------------
# Valeurs par défaut pour le protocole et quelques réglages
defaults
port                587
tls                 on
tls_starttls        on
auth                on
protocol            smtp
domain              %H
logfile             "/var/log/msmtp"
aliases             "/etc/aliases"

# Compte par défaut
account             nomdecompte
host                petitmote.fr
user                user
password            "mot de passe"
from                user-alias@petitmote.fr
allow_from_override off
set_from_header     on

# On indique le compte par défaut
account default : nomdecompte

Sur Yunohost, j’ai créé un compte spécial pour l’envoi de notifications. Je lui crée un alias par serveur pour savoir d’où viennent les messages. Je voulais utiliser la syntaxe nom <user@petitmote.fr>, mais il semble que le serveur mail de Yunohost n’aime pas ça.

Note : les logs ne peuvent pas être mis n’importe où à cause de la configuration de AppArmor. Si on les veut dans /var/log, c’est le seul nom qu’on peut leur donner.

J’ajoute des alias par défaut :

sudo nano /etc/aliases
----------------------
# […] à mettre après les alias déjà définis
root:mail@example.com
default:mail@example.com

Après ça, il ne reste qu’à tester

mail -s "Test" mail@example.com <<END
Un test de mail de notification
END

Gestion des logs

D’autres comptes peuvent avoir besoin d’accéder au fichier de logs. Pour ça, on va les ajouter au groupe msmtp qui aura les droits d’accès en écriture au fichier de logs :

sudo usermod -aG msmtp user

Il faut ensuite modifier les droits sur le fichier de logs :

sudo chown root:msmtp /var/log/msmtp
sudo chmod 660 /var/log/msmtp

J’active la rotation des fichiers de logs (normalement, ils ne devraient pas peser lourd, mais sait-on jamais que je les oublie…)

sudo nano /etc/logrotate.d/msmtp
--------------------------------
/var/log/msmtp
{
  rotate 6
  size 10M
  nomissingok
  notifempty
  create 660 root msmtp
}

Cela donne : surveiller le fichier de logs msmtp, ne garder que 6 fichiers d’historique, qui feront une taille maximale de 10 Mo. Ce n’est pas normal si le fichier n’est pas présent (logrotate s’effectue une fois par jour et j’ai normalement au moins un mail de unattended-upgrades, le fichier doit donc être présent à chaque lancement de logrotate). Si le fichier est vide, ne pas le faire tourner. Recréer le fichier de logs après en lui redonnant les droits que l’on a spécifié plus tôt.

Mises à jour automatiques

J’utilise unattended-upgrades pour les mises à jour automatiques.

sudo apt install unattended-upgrades

La configuration par défaut se trouve dans /etc/apt/apt.conf.d/50unattended-upgrades. Je crée un 2e fichier pour surcharger certains paramètres :

sudo nano /etc/apt/apt.conf.d/52unattended-upgrades-local
----------------------------------------------------
Unattended-Upgrade::Mail "root";
Unattended-Upgrade::MailReport "always";
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

Dans l’ordre :

Le mail à qui envoyer un rapport. L’envoyer à l’utilisateur root permet d’avoir juste à définir l’alias une fois (si jamais on change d’adresse mail destinataire)
Envoyer toujours un mail même s’il n’y a pas de paquet à installer, ce qui me permet d’être sûr que unattended-upgrades fonctionne toujours
Redémarrage automatique quand il y a besoin
Heure du redémarrage automatique. Varie selon le serveur : mes serveurs applicatifs le feront la nuit, mais le serveur de sauvegarde va plutôt le faire en journée ou tout début de journée (comme les sauvegardes des serveurs se feront la nuit).

Ensuite, un test pour vérifier que ça fonctionne, y compris l’alerte par mail :

sudo unattended-upgrade

Si tout fonctionne, on va configurer le service via APT Periodic (et non pas uniquement la configuration de unattended-upgrades). Voir le wiki de Debian.

sudo nano /etc/apt/apt.conf.d/02periodic
----------------------------------------
// Control parameters for cron jobs by /etc/cron.daily/apt-compat //


// Enable the update/upgrade script (0=disable)
APT::Periodic::Enable "1";


// Do "apt-get update" automatically every n-days (0=disable)
APT::Periodic::Update-Package-Lists "1";


// Do "apt-get upgrade --download-only" every n-days (0=disable)
APT::Periodic::Download-Upgradeable-Packages "1";


// Run the "unattended-upgrade" security upgrade script
// every n-days (0=disabled)
// Requires the package "unattended-upgrades" and will write
// a log in /var/log/unattended-upgrades
APT::Periodic::Unattended-Upgrade "1";


// Do "apt-get autoclean" every n-days (0=disable)
APT::Periodic::AutocleanInterval "21";


// Send report mail to root
//     0:  no report             (or null string)
//     1:  progress report       (actually any string)
//     2:  + command outputs     (remove -qq, remove 2>/dev/null, add -d)
//     3:  + trace on
APT::Periodic::Verbose "1";

Penser à supprimer le fichier /etc/apt/apt.conf.d/20auto-upgrades si auto-upgrades était configuré tout seul avant. Note : à voir si ça permet vraiment d’être mis au courant des autres paquets à mettre à jour, ou s’il faut plus de configuration ou passer par apticron.

Je ne modifie pas les paramètres par défaut, ce qui veut dire que ce sont surtout les mise à jour de sécurité qui seront installée. Pour les mises à jour classiques du système et des applications, il faudra toujours se connecter manuellement.

Surveillance des logs

Pour surveiller les logs, je vais utiliser logcheck, créé par Debian pour analyser régulièrement les logs (nécessite cron).

sudo apt install logcheck

Pour recevoir les mail, on crée un alias de logcheck vers root (l’installation l’avait créé automatiquement pour moi) :

sudo nano /etc/aliases
----------------------
[…]
logcheck: root

Ensuite, comme Debian n’utilise plus syslog, on peut faire :

sudo nano /etc/logcheck/logcheck.logfiles.d/syslog.logfiles

Et commenter les deux lignes.

Attention : Yunohost installe rsyslog pour utilisation avec Fail2Ban. Dans ce cas, il faut vérifier si les logs sont dupliqués dans les fichiers du syslog (/var/log/auth.log et /var/log/syslog) ou s’ils sont seulement présents dans le syslog. Dans le 2e cas, il faut garder les lignes dans ce fichier.

Pour tester qu’il fonctionne :

sudo -u logcheck logcheck -t -m root

Et on devrait recevoir un mail sur l’adresse de l’utilisateur root.

Il faudrait maintenant voir pour rajouter des règles sur les autres fichiers de logs, ou même si juste les rajouter à liste des fichiers à surveiller est intéressant.