Différences

Ci-dessous, les différences entre deux révisions de la page.

--- pratique:informatique:serveur_mail [11/10/2023 10:48] – [Postscreen, pour filtrer plus de bandits] Zatalyz
+++ pratique:informatique:serveur_mail [23/05/2024 10:37] (Version actuelle) – Zatalyz
@@ Ligne 32: / Ligne 32: @@
 ===== Installation de l'OS =====
+CF [[pratique:informatique:start_serveur]]. Détails propre au serveur mail :
    * Partir d'une installation fraîche, ne pas tenter de saut de version entre Debian (cf [[https://workaround.org/ispmail/bullseye/migrating-from-buster/|Migration, par ISPmailtutorial]] ).
-   * La machine hébergeant le mail ne doit servir qu'au mail : pas de site web etc. Même le webmail sera ailleurs. Cela améliore la réputation du serveur.
+   * Dans l'absolu, la machine hébergeant le mail ne doit servir qu'au mail : pas de site web etc. Même le webmail sera ailleurs. Cela améliore la réputation du serveur. Mais dans les faits, hein...
    * Utiliser LVM, cela permettra les snapshots (entre autres avantages).
-Partitionner de cette façon :
+Pour le pare-feu : dans la majorité des cas, le serveur est déjà derrière un pare-feu (proxy, box), les ports autorisés le sont explicitement. Chez moi, derrière la box. Un coup de ''nmap ip'' permet de vérifier les ports ouverts. Sur Numenaute, de la même façon, le proxy protège les containers et vm derrière ; mais là c'est sur lui qu'il faut vérifier que tout est propre.
-  * sda1 en partition primaire pour /boot. 510MB minimum (option par défaut de Debian, en ext2) ; mais trop ça peut aussi poser souci.
-  * sda2 en LVM. Le VG sera divisé de cette façon côté LV (à adapter suivant la taille, je préfère prendre mes aises) :
-    * ''/'' pour la base du système, ext4, minimum 20 GB, prévoir direct 50 pour ne plus se poser de question
-    * ''/tmp'', 5 GB, ext4
-    * ''/var/vmail'' (beaucoup, je commence avec 100 GB), ext4
-    * ''/var/log'' : ça c'est si on se plante avec logrotate et autres données, ça évitera de casser le système. 10 GB.
-    * swap : autant que de RAM ; ou si vraiment beaucoup de ram, au moins 2GB.
-  * Il faudra sans doute paramétrer fstab afin d'utiliser les labels et non les UUIDs et éviter les conflits lors de l'utilisation des snapshots
-  * Il est possible sans problème de faire un snapshot de root, puis de revenir en arrière. Je ne sais pas si le merge en arrière peut être pris en compte autrement qu'avec un reboot, par contre.
-Une fois le système installé :
+Il faut tout de même s'assurer que certains ports seront accessibles (on redétaille plus loin ? il n'y a pas "tout") :
-  * Paramétrer Grub pour qu'il ne mette pas 4 secondes à se lancer...
-    * ''nano /etc/default/grub ''
-    * grub-mkconfig -o /boot/grub/grub.cfg
-  * Installer sudo et y ajouter l'user de base :
-    * ''apt install sudo''
-    * usermod -a -G sudo zatalyz
-  * Paramétrer ssh.
-    * Remplacer ''/etc/ssh/sshd_config'' par celui personnalisé ([[https://alinea.ninm.net/dokuwiki/pratique:informatique:start_serveur#parametrer_ssh_sur_le_serveur|ici]])
-    *  Ajouter la clé ssh pour pouvoir se co :
-<code>mkdir /home/zatalyz/.ssh
-nano /home/zatalyz/.ssh/authorized_keys
-# Mettre la clé publique dans ce fichier
-chown -R zatalyz: /home/zatalyz/.ssh
-chmod 0700 /home/zatalyz/.ssh/
-chmod 0600 /home/zatalyz/.ssh/authorized_keys</code>
-    * Redémarrer SSH : ''service ssh restart ''
-Se connecter en SSH (on n'est plus root !) et finaliser la préparation préliminaire :)
-<code>sudo apt update
-sudo apt upgrade
-sudo apt install apt-listbugs debsums apt-listchanges
-</code>
-On peut aussi installer quelques outils utiles :
-  sudo apt install git binutils net-tools curl htop dnsutils
-Pour la suite et afin de ne pas se surcharger en paquets non voulu, on va désactiver "recommandés" et "suggérés" d'APT (on avisera suivant les recommandations). Créer un fichier dans ''/etc/apt/apt.conf.d/'' :
-  sudo nano /etc/apt/apt.conf.d/00recommandperso
-Mettre le contenu suivant :
-<code>
-APT::Install-Recommends "0";
-APT::Install-Suggests "0";
-</code>
-Et ''sudo apt update'' (je ne sais pas si c'est utile mais dans le doute...).
-Et on fait un snapshot de root à ce moment, pour revenir "à zéro" si on se plante trop dans nos essais d'installation.
-  sudo lvcreate -L 20g -s -n snap_root_$(date --iso) /dev/VgPoste/root
-S'il y a un souci, on revient en arrière :
-  sudo lvconvert --merge /dev/VgPoste/snap_root_XXX
-Et s'il y a un souci pour recréer un snapshot après ça, c'est
-  sudo lvchange --refresh VgPoste
-===== Sécurisation du serveur =====
-Il y aura plusieurs itérations sur le sujet au fil des logiciels installés, mais il me semble important de partir sur une base déjà aussi saine et avec quelques outils que je trouve utile.
-La configuration de SSH était la première partie (et changer le port SSH permet déjà de bloquer une partie des noceurs, les plus idiots, ok).
-On va installer fail2ban, rkhunter, et vérifier que la configuration du pare-feu est bonne. Notez que sans les "recommands", en cas d'erreur on n'aura pas de mail système sur le sujet, mais comme on va installer un vrai serveur mail derrière... on va éviter de mélanger divers paquets de MTA.
-Par ailleurs, il y a débat sur l'intérêt de ce genre de logiciels. Je trouve que ça apporte un peu de surveillance voir de mitigation sur certaines menaces, sans nuire au système, donc... je les utilise. Je suis toujours intéressée par une discussion sur le sujet et à améliorer mes pratiques.
-==== Rkhunter ====
-<WRAP center round info 100%>
-rkhunter (pour Rootkit Hunter) est un programme qui essaye de détecter les rootkits, portes dérobées et exploits. Pour cela, il compare le hash SHA256, SHA512, SH1 et MD5 des fichiers importants avec les hash connus, qui sont accessibles à partir d'une base de données en ligne. Il alerte également l'utilisateur lorsqu'il trouve des permissions qu'il juge anormales, des fichiers cachés, des chaînes suspectes dans le kernel etc.
-De par l'exhaustivité des tests qu'il effectue, et à cause du nombre de systèmes sur lesquels il tourne, rkhunter renvoie généralement de nombreux avertissements. L'analyse de ces avertissements (warnings) nécessite une bonne connaissance des systèmes Unix. Dans une écrasante majorité des cas, ces avertissements sont bénins et peuvent être ignorés.
-Source : [[https://doc.ubuntu-fr.org/rkhunter|Ubuntu-fr]]
-</WRAP>
-J'ai souvenir qu'il est effectivement bavard. Et aussi que ce n'est pas une sécurité en soi, juste un outil permettant de détecter certains problèmes.
-sudo apt
-On le configure un chouia
-  sudo nano /etc/rkhunter.conf
-Modifier les options suivantes pour qu'elles aient ces valeurs :
-<code>
-UPDATE_MIRRORS=1
-MIRRORS_MODE=0
-#WEB_CMD="/bin/false"
-ALLOWHIDDENDIR=/etc/.git
-ALLOWHIDDENDIR=/dev/.lxc
-ALLOWHIDDENDIR="/dev/.udev"
-ALLOWHIDDENDIR="/dev/.static"
-ALLOWDEVFILE="/dev/.udev/rules.d/root.rules"
-PKGMGR=DPKG
-ALLOW_SSH_PROT_V1=0
-</code>
-Après ces modifications, exécuter ceci :
-  rkhunter -C
-  rkhunter --propupd
-Modifier aussi ''/etc/default/rkhunter''.
-CRON_DAILY_RUN="true"
-CRON_DB_UPDATE="true"
-APT_AUTOGEN="yes"
-Quand à envoyer un mail quotidien... ça fait du bruit, qu'il se passe un truc ou non. On verra par la suite, d'autant qu'il faut un service d'envoi de mail.
-Et on se fait un petit test en mettant à jour l'ensemble puis en affichant juste ce qui est avec des warnings :
-<code>rkhunter --update
-rkhunter --list
-rkhunter -c --rwo</code>
-==== Fail2ban ====
-Tout est noté dans un article à part, parce que ça commençait à être long : [[pratique:informatique:fail2ban]]
-==== Pare-feu (iptables, nftable, ipset, etc) ====
-Bon, là, ça devient compliqué. Dans la majorité des cas, le serveur est déjà derrière un pare-feu (proxy, box), les ports autorisés le sont explicitement. Chez moi, derrière la box. Un coup de ''nmap ip'' permet de vérifier les ports ouverts. Sur Numenaute, de la même façon, le proxy protège les containers et vm derrière ; mais là c'est sur lui qu'il faut vérifier que tout est propre.
-Là, je ne vais pas trop m'y attarder, parce que ma box fait son taf...
-Il faut tout de même s'assurer que certains ports seront accessibles :
   * 25 : port smtp de base
   * 143 : imap avec STARTTLS
@@ Ligne 169: / Ligne 50: @@
 ===== Systemd, ton univers impitoyable =====
-<WRAP center round help 60%>
+Parait que la commande suivante permet d'avoir les logs "mails" de postfix (plus tard dans le tuto) :
-Cette partie se discute. Personnellement, je ne supporte pas journactl. La manip suivant ne le désactive pas, elle permet juste d'avoir en plus des logs lisibles et faciles à consulter. Il me semble que c'est le meilleur des deux mondes : les fonctionnalités de journactl sont là au besoin, mais pour un check rapide de ce qui se passe, on a des logs faciles à lire.
-</WRAP>
-On va se modifier le système de log histoire de suivre ce qui peut se passer.
-  sudo apt install rsyslog
-  sudo nano /etc/systemd/journald.conf
-Décommenter et vérifier les 3 lignes suivantes :
-<code>SystemMaxUse=512M
-SystemMaxFiles=100
-ForwardToSyslog=yes</code>
-Sinon, parait que la commande suivante permet d'avoir les logs "mails" de postfix (plus tard dans le tuto) :
   journalctl -ru postfix@-.service
@@ Ligne 190: / Ligne 56: @@
 En gros postfix.service ça doit être les logs du démon postfix, et postfix@-.service ceux de son pool de mails.
-Relancer systemd :
-  systemctl restart systemd-journald.service
 ===== Logiciels à installer =====
@@ Ligne 851: / Ligne 713: @@
 ==== Postscreen, pour filtrer plus de bandits ====
 Doc de référence : [[https://www.postfix.org/postconf.5.html]].
+<WRAP center round important 60%>
+Attention, c'est pas au point parce que je n'ai pas encore mis en place "subcleanin" comme proposé dans https://blog.debugo.fr/serveur-messagerie-optimisation-postfix/ et donc ben... c'est le bordel !
+</WRAP>
 Postscreen va appliquer des vérifications sur les domaines (entre autre) et faciliter le tri. On pourra ainsi déclarer certains domaines comme bloqués, et d'autres comme de confiance, et en mettre certains en liste grise. Pour chaque contrôle, on peut au choix :
@@ Ligne 906: / Ligne 773: @@
 postscreen_greet_banner = Cool, we have time...
 postscreen_greet_action = drop</code>
+=== Listes de blocage ===
 Ensuite, on va ajouter des listes à interroger pour savoir si l'ip ne serait pas bloquée. Si oui, alors... on vire
@@ Ligne 915: / Ligne 784: @@
 postscreen_dnsbl_action = drop
 </code>
-Ici, quelques subtilités :
+Ici, quelques subtilités (si j'ai compris, ce qui n'est pas certain !) :
   * Si on rejette le mail, l'expéditeur aura l'information du nom de domaine ayant servi à la blocklist. Cela peut se cacher (via postscreen_dnsbl_sites) , mais personnellement je juge plutôt correct de dire "je ne te veux pas car tu est bloqué ici" ; si l'expéditeur est légitime et que c'est une erreur, il peut se faire débloquer.
-  * Interroger les listes demande du temps, pas la peine d'en ajouter trop.
+  * Interroger les listes demande du temps, pas la peine d'en ajouter trop, mais, on va le voir ensuite, pas la peine d'en mettre trop peu non plus.
   * Forcément, on fait appel à un prestataire externe, avec ce que ça peut questionner sur la confiance. Les listes en question peuvent parfaitement faire une liste des ip qui contactent notre serveur. Personnellement je me dis que l'intérêt de l'information reste limité, surtout si peu à peu j'ai plus d'utilisateurs.
-  * ''postscreen_dnsbl_threshold'' indique la limite inférieure inclusive du score du domaine testé qu'on peut accepter. Par défaut, postfix met à 1. Donc "3" c'est un peu moins restrictif ?
+  * ''postscreen_dnsbl_threshold'' indique la limite inférieure inclusive du score du domaine testé qu'on peut accepter. Et là ça demande un peu de détails.
+Si une ip est trouvée dans une des listes, ça va compter pour "1". Sauf si on ajoute un chiffre après le nom du domaine et l'astérisque ; dans ce cas ça sera pondéré d'autant. Dans l'exemple ici, si une ip est trouvée sur zen.spamhaus.org, ça va compter pour "2". Là, avec nos trois listes dont 2 pondérées à "2", si l'ip est listée partout, elle obtiendra un score de 5. C'est plus haut que 3 => c'est probablement une adresse louche.
+Interroger plusieurs listes augmente donc les chances que l'ip bloquée le soit pour des raisons légitimes.
+<WRAP center round todo 60%>
+Et c'est une partie que je dois améliorer dans ma config
+</WRAP>
+Mais, attention. Ces listes ne sont pas toutes gratuites, elles ont des conditions d'utilisation, bref pour ne pas se faire ban soi-même... il faut aller voir tout ça.
+=== Greylisting ===
 Enfin, quelques manip qui passent les ip en "greylisting" en attente d'en savoir plus. Attention, cela peut éjecter des serveurs légitimes mais configurés de façon un peu légère (d'ailleurs, moi-même, je donnerais quoi ?). Enfin, bon, comme cela risque surtout de concerner des copains et qu'ils savent comment me contacter autrement... perso ça ne me stresse pas. <WRAP center round important 60%>