Installer et utiliser OpenVAS sous CentOS

Logo OpenVASOpenVAS (Vulnerability Assessment Scanner) est un outil qui permet d’effectuer un audit de sécurité d’une machine ou d’un réseau entier. Dans le monde de l’open source, OpenVAS est sans doute le logiciel phare dans la catégorie des scanners de vulnérabilité. C’est un fork libre de Nessus, publié sous licence GPL jusqu’à la version 2.2, et qui est devenu propriétaire lors de son passage à la version 3.0. L’application est officiellement supportée par le BSI (Bundesamt für Sicherheit in der Informationstechnik, l’agence fédérale allemande chargée de la sécurité des technologies de l’information et de la communication).

OpenVAS n’est pas très bien documenté, hormis une série de tutos en ligne qui relaient des informations parfois un peu fantaisistes. Je me suis donc familiarisé avec les documents disponibles, j’ai expérimenté pas mal, j’ai pris des notes, et j’ai décidé de rédiger ma propre documentation.

L’outil OpenVAS est un framework (comprendre « usine à gaz »), et son installation n’est pas tout à fait triviale. Sur une configuration récente, il faut compter près de trois quarts d’heure pour disposer d’une installation fonctionnelle. En revanche, une fois qu’OpenVAS est en place, sa prise en main est extrêmement simple.

OpenVAS

Quel dépôt tiers choisir ?

Pour Red Hat Enterprise Linux et CentOS, OpenVAS est fourni par deux dépôts de paquets tiers concurrents.

La plupart des tutos en ligne font référence au dépôt tiers Atomicorp, fournissant un seul paquet openvas qui contient tout ce qu’il faut. Curieusement,  la documentation officielle sur le site de l’éditeur renvoie même vers un de ces tutos.

Pour ma part, je préfère m’en tenir au dépôt EPEL, qui fournit des paquets de qualité pour Red Hat Enterprise Linux et CentOS, et que j’utilise sur mes serveurs aussi bien que sur mes postes de travail. Les paquets EPEL fournissent une série de paquets pour OpenVAS, étant donné qu’il s’agit là d’un véritable framework avec une série de composants.

  • openvas-scanner
  • openvas-libraries
  • openvas-manager
  • openvas-cli
  • openvas-gsa

OpenVAS Scanner

La pièce centrale d’OpenVAS, c’est OpenVAS Scanner. Je vais donc l’installer en premier.

# yum install openvas-scanner

D’après la documentation officielle, ce paquet contient un script shell openvas-check-setup qui permet de vérifier l’état de l’installation d’OpenVAS. À partir de là, je vais adopter une démarche quelque peu originale pour installer et configurer OpenVAS. Je vais me servir des messages d’erreur et autres avertissements du script openvas-check-setup pour compléter la mosaïque pas à pas.

Création du certificat SSL

Une première invocation du script me renvoie ceci.

# openvas-check-setup 
...
Checking OpenVAS Scanner ... 
OK: OpenVAS Scanner is present in version 5.0.6.
ERROR: No CA certificate file of OpenVAS Scanner found.
FIX: Run 'openvas-mkcert'.

Je génère le certificat SSL comme le script me le suggère. J’opte pour une validité de dix ans pour être tranquille.

# openvas-mkcert
...
CA certificate life time in days [1460]: 3650
Server certificate life time in days [365]: 3650
Your country (two letter code) [DE]: FR
Your state or province name [none]: Gard
Your location (e.g. town) [Berlin]: Montpezat
Your organization [OpenVAS Users United]: Microlinux

Le serveur Redis

Redis (Remote Dictionary Server) est un système de gestion de bases de données clé/valeur. Il fait partie de la famille des bases NoSQL et vise la performance. Et notre système OpenVAS a visiblement besoin d’un serveur Redis pour fonctionner correctement.

# openvas-check-setup
...
ERROR: No redis-server installation found.
FIX: You should install redis-server for improved scalability and 
     ability to trace/debug the KB

On va donc installer Redis.

# yum install redis

Éditer /etc/redis.conf et spécifier un emplacement approprié pour le fichier socket, aux alentours de la ligne 100.

# Unix socket.
#
# Specify the path for the Unix socket that will be used to listen 
# for incoming connections. There is no default, so Redis will not 
# listen on a unix socket when not specified.
#
unixsocket /run/redis/redis.sock

Ensuite, éditer /etc/openvas/openvassd.conf et ajouter une ligne pour spécifier l’emplacement de la Knowledge Base.

# KB test replay :
kb_dont_replay_scanners = no
kb_dont_replay_info_gathering = no
kb_dont_replay_attacks = no
kb_dont_replay_denials = no
kb_max_age = 864000
kb_location = /run/redis/redis.sock
#--- end of the KB section

Activer et démarrer Redis.

# systemctl enable redis
# systemctl start redis
# systemctl status redis

Récupérer les tests de vulnérabilité

OpenVAS se sert d’une base de près de 50.000 tests de vulnérabilité, nommée NVT (Network Vulnerability Tests). Pour l’instant nous ne disposons pas de cette base.

# openvas-check-setup
...
ERROR: The NVT collection is very small.
FIX: Run a synchronization script like openvas-nvt-sync 
     or greenbone-nvt-sync.

Nous allons utiliser la commande openvas-nvt-sync pour récupérer les NVT.

# openvas-nvt-sync
...
zabbix_web_detect.nasl.asc
znc_detect.nasl
znc_detect.nasl.asc
zone_alarm_local_dos.nasl
zone_alarm_local_dos.nasl.asc
[i] Download complete
[i] Checking dir: ok
[i] Checking MD5 checksum: ok

OpenVAS Manager

Le prochain élément du framework, c’est OpenVAS Manager, le service qui contrôle OpenVAS Scanner via le protocole OTP (OpenVAS Transfer Protocol). Cette pièce nous manque pour l’instant.

# openvas-check-setup
...
ERROR: No OpenVAS Manager (openvasmd) found.
FIX: Please install OpenVAS Manager.

Il faut donc installer le paquet correspondant.

# yum install openvas-manager

Générer le certificat SSL client

OpenVAS Manager a besoin d’un certificat SSL client pour se connecter.

# openvas-check-setup
...
ERROR: No client certificate file of OpenVAS Manager found.
FIX: Run 'openvas-mkcert-client -n -i'

Ici, nous allons dévier quelque peu de la procédure suggérée. L’option -n exécute le script en mode non-interactif en acceptant les valeurs par défaut. Nous allons nous contenter de l’option -i qui se charge d’installer le certificat, et là aussi, nous allons générer un certificat SSL valable pour dix ans.

# openvas-mkcert-client -i
Client certificates life time in days [365]: 3650
Your country (two letter code) [DE]: FR
Your state or province name [none]: Gard
Your location (e.g. town) [Berlin]: Montpezat
Your organization [none]: Microlinux
Your organizational unit [none]:
e-Mail []: info@microlinux.fr

Construire la base de données

Pour l’instant, OpenVAS Manager ne dispose pas de base de données.

# openvas-check-setup
...
ERROR: No OpenVAS Manager database found. 
       (Tried: /var/lib/openvas/mgr/tasks.db)
FIX: Run 'openvasmd --rebuild' while OpenVAS Scanner is running.

Dans un premier temps, on va activer et démarrer OpenVAS Scanner.

# systemctl enable openvas-scanner
# systemctl start openvas-scanner
# systemctl status openvas-scanner

Ensuite, on va construire la base de données. L’option --progress ne nous dit pas grand-chose sur l’avancement des opérations, mais au moins, la petite animation qui s’excite progressivement suggère que ça mouline sous le capot. Étant donné qu’il y a plus de 50.000 entrées à traiter, l’opération peut durer un petit moment. Même sur une machine rapide, on a largement le temps d’aller boire un café.

# openvasmd --rebuild --progress
Rebuilding NVT cache... \

Créer un utilisateur

La prochaine étape consiste à créer un utilisateur qui puisse se connecter à OpenVAS Manager.

# openvas-check-setup
...
ERROR: No users found. You need to create at least one user 
       to log in.
It is recommended to have at least one user with role Admin.
FIX: create a user by running 'openvasmd --create-user=<name>
     --role=Admin && 
     openvasmd --user=<user> --new-password=<password>'

Attention au mot de passe qui s’affiche en clair dans le terminal.

# openvasmd --create-user=microlinux --role=Admin
User created with password 'd6edadcd-ce9e-45cf-bb3c-4382b6d6e071'.
# openvasmd --user=microlinux --new-password=*********

Récupérer la base SCAP

La prochaine étape consiste à récupérer la base SCAP (Security Content Automation Protocol).

# openvas-check-setup
...
ERROR: No OpenVAS SCAP database found. 
(Tried: /var/lib/openvas/scap-data/scap.db)
FIX: Run a SCAP synchronization script like openvas-scapdata-sync 
     or greenbone-scapdata-sync.

La commande openvas-scapdata-sync nous permet de récupérer la base. Cette opération peut durer une bonne vingtaine de minutes.

# openvas-scapdata-sync
[i] This script synchronizes a SCAP data directory with the 
    OpenVAS one.
...
[i] Updating CVSS scores and CVE counts for CPEs
[i] Updating CVSS scores for OVAL definitions
[i] Updating placeholder CPEs

Récupérer la base CERT

La troisième et dernière base de données nécessaire pour le bon fonctionnement d’OpenVAS, c’est la base CERT.

# openvas-check-setup 
...
ERROR: No OpenVAS CERT database found. 
       (Tried: /var/lib/openvas/cert-data/cert.db)
FIX: Run a CERT synchronization script like openvas-certdata-sync 
     or greenbone-certdata-sync.

De manière similaire, c’est la commande openvas-certdata-sync qui nous permet de récupérer cette base.

# openvas-certdata-sync
[i] This script synchronizes a CERT advisory directory with the 
    OpenVAS one.
...
[i] Updating Max CVSS for CERT-Bund
[i] Updating Max CVSS for DFN-CERT

Greenbone Security Assistant

Le troisième composant du framework, c’est le Greenbone Security Assistant.

# openvas-check-setup
...
ERROR: No Greenbone Security Assistant (gsad) found.
FIX: Please install Greenbone Security Assistant.

Installer le paquet correspondant.

# yum install openvas-gsa

OpenVAS CLI

Enfin, le quatrième et dernier composant du framework, c’est OpenVAS CLI.

# openvas-check-setup
...
ERROR: No OpenVAS CLI (omp) found.
FIX: Please install OpenVAS CLI.

Là aussi, il suffit d’installer le paquet correspondant.

# yum install openvas-cli

Activer et démarrer les services

Le service openvas-scanner est déjà activé et lancé, mais il nous manque encore les deux autres.

# openvas-check-setup
...
ERROR: OpenVAS Manager is NOT running!
FIX: Start OpenVAS Manager (openvasmd).
ERROR: Greenbone Security Assistant is NOT running!
FIX: Start Greenbone Security Assistant (gsad).

Activer et démarrer OpenVAS Manager.

# systemctl enable openvas-manager
# systemctl start openvas-manager
# systemctl status openvas-manager

Procéder de même avec le Greenbone Security Assistant.

# systemctl enable openvas-gsa
# systemctl start openvas-gsa
# systemctl status openvas-gsa

Installer les outils tiers

OpenVAS utilise une série d’outils tiers, qui ne sont pas fournis par une installation par défaut.

# openvas-check-setup
...
WARNING: Could not find pdflatex binary, the PDF report format will 
         not work.
SUGGEST: Install pdflatex.
...
WARNING: Could not find alien binary, LSC credential package 
         generation for DEB based targets will not work.
SUGGEST: Install alien.
WARNING: Could not find makensis binary, LSC credential package 
         generation for Microsoft Windows targets will not work.
SUGGEST: Install nsis.

Installer les paquets manquants comme ceci.

# yum install texlive-* alien mingw32-nsis

Note : l’installation de TeX Live est assez volumineuse, près de 560 paquets qui font plusieurs centaines de Mo, mais la génération de PDF échoue avec une installation partielle, et dans le doute, il vaut mieux disposer d’une installation TeX cohérente.

Premier essai avec l’assistant

La dernière invocation du script openvas-check-setup nous a certes encore affiché quelques avertissements, mais aucune erreur et rien de prohibitif. Le moment est venu de faire un premier test.

# openvas-check-setup
...
It seems like your OpenVAS-8 installation is OK.

Dans la configuration par défaut, le Greenbone Security Assistant écoute sur le port 9443. Étant donné que j’ai installé le serveur et le client sur la même machine, je dois me connecter à https://localhost:9443. L’avertissement sur la connexion non sécurisée est tout à fait normal, vu que j’utilise un certificat SSL auto-signé. Je clique sur Avancé.

OpenVAS

Je clique sur Ajouter une exception.

OpenVAS

Et enfin, je confirme l’exception de sécurité de façon permanente.

OpenVAS

La fenêtre de connexion du Greenbone Security Assistant s’affiche. Je fournis l’identifiant et le mot de passe définis lors de l’installation.

OpenVAS

La prise en main du Greenbone Security Assistant est extrêmement simple. Le champ Quick Start permet de saisir l’adresse IP ou le nom d’hôte d’une machine à scanner. Il peut s’agir d’une machine publique ou d’un poste dans le réseau local. Il est tout à fait possible de scanner plusieurs machines en même temps. Un simple clic sur le lien correspondant à une machine nous amène au rapport de vulnérabilité.

OpenVAS

Voici comment se présente le rapport de sécurité d’une machine. Les vulnérabilités sont classées par ordre de sévérité, et un clic sur chaque lien fournit les détails de la faille en question ainsi que la solution pour y remédier.

OpenVAS

 

Publié dans CentOS, Documentation Microlinux | Marqué avec , , , | Laisser un commentaire

Hébergement WordPress sous CentOS

Logo WordPressCet article décrit l’installation du moteur de blog WordPress sur un serveur dédié tournant sous CentOS 7. WordPress est le CMS (Content Management System) ou SGC (Système de Gestion de Contenu) le plus utilisé au monde. Actuellement, près de 28 % des sites web dans le monde utilisent WordPress d’après les statistiques de W3Techs.com.

Prérequis

Installation

Basculer SELinux en mode permissif.

# setenforce 0

Le module mod_security semble poser problème avec WordPress. Pour l’instant on va donc le désactiver pour notre nouvel hôte virtuel.

# /etc/httpd/conf.d/40-blog.slackbox.fr.conf
...
# https://blog.slackbox.fr
<VirtualHost _default_:443>
  Header always set Strict-Transport-Security \
    "max-age=63072000; includeSubDomains"
  ServerAdmin info@microlinux.fr
  DocumentRoot "/var/www/html/slackbox-blog/html"
  <Directory "/var/www/html/slackbox-blog/html">
    Options +FollowSymlinks
    AllowOverride All
    <IfModule mod_security2.c>
      SecRuleEngine Off
    </IfModule>
  </Directory>

Créer la base de données.

# mysql -u root -p
Enter password: ********
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 5
Server version: 5.5.52-MariaDB MariaDB Server

MariaDB [(none)]> create database `slackbox-wordpress`;
Query OK, 1 row affected (0.02 sec)

MariaDB [(none)]> grant all on `slackbox-wordpress`.* 
    -> to slackboxuser@localhost 
    -> identified by '********';
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> flush privileges;
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> quit;
Bye

Créer un répertoire de téléchargement en un endroit approprié et récupérer WordPress sur le site de l’éditeur.

# mkdir -pv webapps/wordpress
mkdir: création du répertoire « webapps »
mkdir: création du répertoire « webapps/wordpress »
# cd webapps/wordpress/
# links fr.wordpress.org

Suivre les liens Téléchargement > Télécharger au format .tar.gz. Télécharger l’application et quitter Links.

L’hôte virtuel se situera dans /var/www/html/slackbox-blog/html. Créer le répertoire parent, décompresser l’archive téléchargée à l’intérieur de ce répertoire et renommer le répertoire wordpress résultant en html.

# cd /var/www/html/
# mkdir slackbox-blog
# cd slackbox-blog/
# tar xzf /root/webapps/wordpress/wordpress-4.8-fr_FR.tar.gz 
# ls
wordpress
# mv wordpress/ html

Définir des droits d’accès sains par défaut. Pour les permissions, nous suivons les recommandations officielles adaptées à notre installation.

# cd /var/www/html/
# chown -R microlinux:microlinux slackbox-blog/
# find slackbox-blog/ -type d -exec chmod 0755 \{} \;
# find slackbox-blog/ -type f -exec chmod 0644 \{} \;

Permettre à WordPress de gérer wp-content.

# cd slackbox-blog/html/
# chown -R microlinux:apache wp-content/
# find wp-content/ -type d -exec chmod 0775 \{} \;
# find wp-content/ -type f -exec chmod 0664 \{} \;
# ls -ld wp-content/
drwxrwxr-x. 5 microlinux apache 4096  7 juil. 17:00 wp-content/
# ls -l wp-content/
total 16
-rw-rw-r--. 1 microlinux apache   28  8 janv.  2012 index.php
drwxrwxr-x. 4 microlinux apache 4096  7 juil. 17:00 languages
drwxrwxr-x. 3 microlinux apache 4096  7 juil. 17:00 plugins
drwxrwxr-x. 5 microlinux apache 4096  7 juil. 17:00 themes

À partir de là, on peut ouvrir l’URL du blog avec un navigateur.

Installation WordPress

Renseigner le nom de la base MySQL (slackbox-wordpress) et l’utilisateur associé (slackboxuser). Attention, le mot de passe MySQL s’affiche en clair dans l’interface.

Installation WordPress

Étant donné que nous avons défini des droits d’accès assez restrictifs, WordPress ne peut pas créer le fichier wp-config.php. Nous devons donc le faire à sa place, en définissant les permissions qui vont bien, et en effectuant un copier/coller du contenu affiché dans l’interface d’installation.

# cd /var/www/html/slackbox-blog/html/
# vim wp-config.php (copier/coller le contenu affiché)
# chown microlinux:apache wp-config.php 
# chmod 0660 wp-config.php 
# ls -l wp-config.php 
-rw-rw----. 1 microlinux apache 0 16 juil. 09:45 wp-config.php

Installation WordPress

La prochaine étape nous permet de renseigner le titre du site et de définir un administrateur pour le blog avant de finaliser l’installation.

Installation WordPress

À présent, on peut se connecter au Tableau de bord.

Installation WordPress

Le Tableau de bord dans sa configuration par défaut.

Installation WordPress

Et voici notre blog flambant neuf avec le thème par défaut.

Installation WordPress

WordPress et SELinux

Maintenant que notre installation est en place, voyons ce qu’en pense SELinux.

# sealert -a /var/log/audit/audit.log
100% done
found 9 alerts in /var/log/audit/audit.log
------------------------------------------
SELinux is preventing /usr/sbin/sendmail.postfix 
from read access on the file /etc/postfix/main.cf.

Lors d’une nouvelle installation de WordPress, un mail de bienvenue est envoyé à l’administrateur.

Installation WordPress

Apparemment, l’envoi de ce mail pose un problème à SELinux, qui nous suggère la solution suivante.

# setsebool -P httpd_can_sendmail=1

Configurer les permaliens personnalisés

Dans sa configuration par défaut, WordPress utilise un format de liens du style https://blog.slackbox.fr/?p=123. On va préférer un format du genre https://blog.slackbox.fr/exemple-article/. Dans le Tableau de bord, aller dans Réglages > Permaliens et sélectionner Nom de l’article.

Permaliens WordPress

Le problème, c’est qu’à partir de là, les pages ne s’affichent plus.

Not Found

Après avoir jeté un oeil sur l’utilisation des permaliens dans la documentation officielle, nous allons effectuer quelques modifications à la configuration d’Apache.

Nous avons désactivé l’option FollowSymlinks dans les directives globales. Nous devons donc la réactiver explicitement pour notre hôte virtuel. Quant à l’option AllowOverride, elle détermine ce que l’on peut mettre dans le fichier .htaccess.

# https://blog.slackbox.fr
<VirtualHost _default_:443>
  Header always set Strict-Transport-Security \
    "max-age=63072000; includeSubDomains"
  ServerAdmin info@microlinux.fr
  DocumentRoot "/var/www/html/slackbox-blog/html"
  <Directory "/var/www/html/slackbox-blog/html">
    Options +FollowSymlinks
    AllowOverride All
  </Directory>
  ServerName blog.slackbox.fr:443
  ServerAlias slackbox.fr
  SSLEngine on
  ...

Prendre en compte les modifications.

# systemctl reload httpd

À partir de là, l’interface de configuration des permaliens nous affiche un avertissement quant à la création du fichier .htaccess.

Wordpress .htaccess

La solution consiste ici à créer un fichier vide .htaccess à la racine de notre installation et d’autoriser le serveur à écrire dedans.

# cd /var/www/html/slackbox-blog/html/
# touch .htaccess
# chown microlinux:apache .htaccess 
# chmod 0660 .htaccess 
# ls -la .htaccess 
-rw-rw----. 1 microlinux apache 0 17 juil. 10:52 .htaccess

Si nous revenons maintenant dans l’interface de configuration des permaliens, nous nous apercevons que WordPress a effectivement écrit dans le fichier.

# cat .htaccess

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Dorénavant, les pages s’affichent correctement avec les permaliens personnalisés.

Gérer les extensions et les mises à jour

WordPress permet la gestion des extensions et des mises à jour dans le tableau de bord, sans pour autant installer un serveur FTP/SFTP local. Pour cela, il suffit d’éditer wp-config.php et d’ajouter la directive FS_METHOD à la fin du fichier.

/** Réglage des variables de WordPress et de ses fichiers inclus. */
require_once(ABSPATH . 'wp-settings.php');

/** Gérer les plugins et les mises à jour */
define('FS_METHOD','direct');

À partir de là, il suffit d’un simple clic pour mettre à jour WordPress ou pour installer une extension.

Touches finales

Une fois que tout est installé, on peut repasser SELinux en mode renforcé.

# setenforce 1

De même, on peut réactiver mod_security. Éditer /etc/httpd/conf.d/40-blog.slackbox.fr.conf et repasser SecRuleEngine à On.

 
<IfModule mod_security2.c>
  SecRuleEngine On
</IfModule>

L’installation ou la désinstallation de certaines extensions peut déclencher mod_security. Dans ce cas, la solution la plus simple consiste à le désactiver temporairement.

Publié dans Documentation Microlinux, Hébergement | Marqué avec , , , , | Laisser un commentaire

Serveur mail sous CentOS (3) SSL

SSL Postfix DovecotDans notre série d’articles sur la mise en place d’un serveur mail sous CentOS avec Postfix et Dovecot, ce troisième volet sera consacré à la sécurisation du serveur, et plus précisément au chiffrement des connexions. En effet, lors de l’authentification des clients mail sur le serveur, les identifiants de connexion et les mots de passe des utilisateurs se baladent en clair sur le réseau. Pour éviter cela, nous allons ajouter le chiffrement SSL à Postfix et Dovecot.

Prérequis

Notre serveur héberge les mails pour plusieurs domaines (en l’occurrence slackbox.fr et unixbox.fr), mais Postfix et Dovecot ne peuvent gérer les certificats que pour un seul domaine. Nous avons donc besoin d’un certificat SAN multi-domaines valable pour tous les domaines que nous gérons.

Les connexions sécurisées se font via le port 465 en TCP pour le SMTPS et le port 993 en TCP pour l’IMAPS. Il faut donc songer à ouvrir ces deux ports dans le pare-feu.

Configurer le chiffrement SSL pour Postfix

Pour activer le chiffrement SSL dans Postfix, il faut éditer /etc/postfix/main.cf et ajouter quatre lignes à la stance qui gère l’authentification SMTP, en précisant le chemin vers le certificat SSL et la clé privée.

# Authentification SMTP
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = $myhostname
smtpd_recipient_restrictions = permit_mynetworks,
                               permit_auth_destination,
                               permit_sasl_authenticated,
                               reject
smtpd_use_tls = yes
smtpd_tls_cert_file = /etc/letsencrypt/live/slackbox.fr/cert.pem
smtpd_tls_key_file = /etc/letsencrypt/live/slackbox.fr/privkey.pem
smtpd_tls_session_cache_database = btree:/etc/postfix/smtpd_scache

Ensuite, il faut éditer /etc/postfix/master.cf et décommenter les lignes 26 à 28 du fichier, comme ceci.

smtps  inet  n   -   n   -   -   smtpd
  -o syslog_name=postfix/smtps
  -o smtpd_tls_wrappermode=yes

Configurer le chiffrement SSL pour Dovecot

Les options relatives au chiffrement SSL pour Dovecot sont rassemblées dans le fichier /etc/dovecot/conf.d/10-ssl.conf. Éditer les premières lignes de ce fichier pour activer le chiffrement SSL et indiquer le chemin vers notre certificat.

ssl = yes
...
ssl_cert = </etc/letsencrypt/live/slackbox.fr/cert.pem
ssl_key = </etc/letsencrypt/live/slackbox.fr/privkey.pem

Redémarrer Postfix et Dovecot pour prendre en compte la nouvelle configuration.

# systemctl restart postfix dovecot

Configuration de Thunderbird

Voici à quoi ressemble la configuration du client mail Thunderbird avec le chiffrement SSL. Le serveur entrant se connecte sur le port 993, le serveur sortant sur le port 465. SSL/TLS est utilisé pour les connexions entrantes et sortantes.

Configuration Thunderbird SSL

Notre connexion est désormais sécurisée, et Thunderbird ne nous affiche plus d’avertissement pour notre configuration.

Publié dans CentOS, Documentation Microlinux | Marqué avec , , , , , | Laisser un commentaire

Serveur mail sous CentOS (2) Dovecot

Logo DovecotL’installation de Postfix nous permet d’envoyer et de recevoir des e-mails directement sur le serveur, en utilisant le client mutt. En revanche, l’utilisation d’un client mail externe comme Mozilla Thunderbird nécessite un accès distant aux boîtes mail du serveur. C’est là où Dovecot entre en jeu.

Dovecot est un serveur IMAP et POP3 pour les systèmes d’exploitation Unix et dérivés. Nous n’utiliserons que le seul protocole IMAP, où les e-mails restent sur le serveur, tout en étant gérés à distance.

La première configuration proposée ici n’a qu’une visée pédagogique. Elle n’est pas sécurisée. Pour utiliser Dovecot dans un environnement de production, nous devons impérativement ajouter le chiffrement SSL par la suite.

Prérequis

Dans le pare-feu, il faudra ouvrir le port 143 en TCP pour le protocole IMAP.

Pour mes tests, j’utilise l’adresse jean.mortreux@slackbox.fr que j’ai mise en place dans Postfix.

Installation

Dovecot est fourni par le dépôt [base] de CentOS.

# yum install dovecot

Configuration initiale

Les fichiers de configuration de Dovecot se trouvent dans le répertoire /etc/dovecot. En dehors du fichier /etc/dovecot/dovecot.conf, le répertoire /etc/dovecot/conf.d contient une véritable forêt de fichiers de configuration, totalisant près de 1.500 lignes de texte.

Pas la peine de s’inquiéter pourtant. D’une part, la plupart de ces 1.500 lignes sont des commentaires, souvent très détaillés. Les directives à proprement parler occupent relativement peu de place.

D’autre part, Dovecot est immédiatement utilisable dans sa configuration par défaut, ou presque. Il suffit d’éditer une poignée de directives pour disposer d’un serveur IMAP fonctionnel, et c’est ce que nous allons faire.

Le premier fichier à éditer, c’est /etc/dovecot/dovecot.conf. À la ligne 24, l’option protocols permet de spécifier le protocole du serveur.

# Protocols we want to be serving.
protocols = imap

Un peu plus loin, à la ligne 30, la directive listen permet de définir Dovecot pour l’IPv4 et/ou l’IPv6. Nous n’utiliserons que l’IPv4.

# A comma separated list of IPs or hosts where to listen in for 
# connections. "*" listens in all IPv4 interfaces, "::" listens in 
# all IPv6 interfaces. If you want to specify non-default ports or 
# anything more complex, edit conf.d/master.conf.
listen = *

Ensuite, nous allons autoriser l’authentification en texte clair en éditant /etc/dovecot/conf.d/10-auth.conf à la ligne 10. Décommenter et désactiver l’option disable_plaintext_auth comme ceci.

disable_plaintext_auth = no

Toujours dans le fichier 10-auth.conf, ajouter l’argument login à la directive auth_mechanisms. Cet argument permet à des clients comme Outlook Express ou Windows Mail de se connecter au serveur.

auth_mechanisms = plain login

Postfix utilise le format Maildir/ pour stocker les mails, et c’est ce que nous allons spécifier à Dovecot dans le fichier /etc/dovecot/conf.d/10-mail.conf, en décommentant et en éditant l’option mail_location à la ligne 30.

mail_location = maildir:~/Maildir

Désactiver le chiffrement SSL dans /etc/dovecot/conf.d/10-ssl.conf, à la ligne 8.

ssl = no

Configurer l’authentification SMTP pour Postfix

Le MTA Postfix n’est pas capable d’effectuer l’authentification SMTP. C’est Dovecot qui va s’en charger.

Dans un premier temps, éditer /etc/dovecot/conf.d/10-master.conf, décommenter la stance suivante aux alentours de la ligne 96 en l’éditant comme ceci.

# Postfix smtp-auth
unix_listener /var/spool/postfix/private/auth {
  mode = 0666
  user = postfix
  group = postfix
}

Ensuite, ajouter une série de directives à la fin du fichier /etc/postfix/main.cf.

# Authentification SMTP
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = $myhostname
smtpd_recipient_restrictions = permit_mynetworks,
                               permit_auth_destination,
                               permit_sasl_authenticated,
                               reject

Premier lancement

Activer et démarrer Dovecot.

# systemctl enable dovecot
# systemctl start dovecot

Vérifier si Dovecot tourne correctement.

# systemctl status dovecot
● dovecot.service - Dovecot IMAP/POP3 email server
   Loaded: loaded (/usr/lib/systemd/system/dovecot.service; 
   enabled; vendor preset: disabled)
   Active: active (running) since mer. 2017-07-12 15:44:22 CEST; 
   4s ago
# cat /var/log/maillog
... Dovecot v2.2.10 starting up for imap (core dumps disabled)

Configuration de Thunderbird

Sur un poste client, lancer Thunderbird, interrompre la configuration automatique en cliquant sur Configuration manuelle et renseigner les champs comme ceci.

Configuration Thunderbird

Étant donné que nous n’utilisons aucun chiffrement, Thunderbird nous gratifie d’un avertissement haut en couleurs, ce qui est tout à fait normal. N’oublions pas que dans la configuration actuelle, nos données d’utilisateur se baladent en texte clair dans le réseau.

Configuration Thunderbird

À partir de là, nous sommes prêts à envoyer et recevoir des mails à des fins de test.

Configuration Thunderbird

La sécurisation des connexions fera l’objet de notre prochain article.

Publié dans CentOS, Documentation Microlinux | Marqué avec , , , | Laisser un commentaire

Serveur mail sous CentOS (1) Postfix

Postfix LogoPostfix est un serveur mail, et plus exactement un MTA (Mail Transfer Agent). Il gère l’envoi et la réception de mails par Internet en utilisant le protocole SMTP. Le monde de l’Open Source offre toute une panoplie de MTA, parmi lesquels on trouve Postfix, Exim, Qmail et Sendmail.

Prérequis

Dans le pare-feu, il faudra ouvrir le port 25 en TCP.

Vérifier si le serveur n’est pas blacklisté quelque part.

Il faut impérativement disposer d’un ou de plusieurs noms de domaines enregistrés et valides.

  • slackbox.fr
  • unixbox.fr
  • etc.

Sur une machine externe, vérifier la configuration DNS des domaines pour lesquels on souhaite gérer le courrier, comme ceci.

$ host -t mx slackbox.fr
slackbox.fr mail is handled by 10 mail.slackbox.fr.
$ host mail.slackbox.fr
mail.slackbox.fr has address 163.172.220.174
$ host slackbox.fr
slackbox.fr has address 163.172.220.174
slackbox.fr mail is handled by 10 mail.slackbox.fr.
$ host 163.172.220.174
174.220.172.163.in-addr.arpa domain name pointer 
sd-100246.dedibox.fr.

Installation

Postfix est inclus dans une installation minimale de CentOS. S’il n’est pas présent sur le système, on peut l’installer comme ceci.

# yum install postfix

On installera également la commande mail (paquet mailx) et le client mutt pour pouvoir tester et gérer les mails en ligne de commande directement sur le serveur.

# yum install mailx mutt

Configuration initiale

Les fichiers de configuration utilisés par Postfix se situent dans /etc/postfix.

  • Le fichier master.cf gère la configuration du démon master de Postfix. Dans la plupart des configurations de base, on n’aura pas à intervenir sur ce fichier.
  • Le fichier main.cf contient les paramètres de contrôle des démons de Postfix. C’est celui que l’on modifiera le plus souvent.

Le fichier main.cf fourni par défaut fait près de 680 lignes, la plupart étant des commentaires. On peut commencer par aérer ce fichier pour ne garder que les directives.

# cd /etc/postfix
# mv main.cf main.cf.orig
# grep -h -v '^[[:space:]]*\#' main.cf.orig | \
  grep -v '^[[:space:]]*$' > main.cf

On obtient un fichier beaucoup plus lisible.

# /etc/postfix/main.cf
queue_directory = /var/spool/postfix
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
mail_owner = postfix
inet_interfaces = localhost
inet_protocols = all
mydestination = $myhostname, localhost.$mydomain, localhost
unknown_local_recipient_reject_code = 550
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
debug_peer_level = 2
debugger_command =
  PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
  ddd $daemon_directory/$process_name $process_id & sleep 5
sendmail_path = /usr/sbin/sendmail.postfix
newaliases_path = /usr/bin/newaliases.postfix
mailq_path = /usr/bin/mailq.postfix
setgid_group = postdrop
html_directory = no
manpage_directory = /usr/share/man
sample_directory = /usr/share/doc/postfix-2.10.1/samples
readme_directory = /usr/share/doc/postfix-2.10.1/README_FILES

Si un paramètre n’est pas présent dans main.cf, Postfix utilisera sa valeur par défaut. Pour la plupart, ces valeurs sont définies « en dur » dans le code source de Postfix, tandis que certaines sont initialisées à la compilation et quelques-unes au moment du lancement du programme.

Le programme postconf est très utile pour examiner les valeurs courantes et par défaut du fichier main.cf. Pour afficher la valeurs de certains paramètres de configuration, il suffit de les fournir en argument.

# postconf inet_interfaces
inet_interfaces = localhost

L’option -d affichera la valeur par défaut des paramètres demandés.

# postconf -d inet_interfaces
inet_interfaces = all

Nous allons supprimer la plupart des paramètres redondants ou autrement inutiles, pour commencer avec quelques directives de base.

# /etc/postfix/main.cf

# Désactiver l'IPv6
inet_protocols = ipv4

# Identification
smtpd_banner = $myhostname ESMTP $mail_name (CentOS)

# Nom d'hôte pleinement qualifié du serveur
myhostname = sd-100246.dedibox.fr

# Domaine du serveur
mydomain = dedibox.fr

# Domaine pour qualifier les adresses sans partie domaine
myorigin = $myhostname

# Domaines locaux
mydestination = $myhostname, localhost.$mydomain, localhost

# Envoi de mails sans authentification
mynetworks = 127.0.0.0/8

# Relais
relayhost =

# Format de stockage
home_mailbox = Maildir/

# Tables de correspondance
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases

# Commande de débogage
debugger_command =
  PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
  ddd $daemon_directory/$process_name $process_id & sleep 5

# Chemins des commandes
sendmail_path = /usr/sbin/sendmail.postfix
newaliases_path = /usr/bin/newaliases.postfix
mailq_path = /usr/bin/mailq.postfix

# Documentation
manpage_directory = /usr/share/man
sample_directory = /usr/share/doc/postfix-2.10.1/samples
readme_directory = /usr/share/doc/postfix-2.10.1/README_FILES

Quelques remarques :

  • Si l’IPv6 est désactivé au niveau du système, il faudra également le faire ici grâce à la directive inet_protocols.
  • smtpd_banner définit la chaîne de caractères avec laquelle Postfix s’identifie auprès d’un autre MTA.
  • myhostname est censé contenir le nom d’hôte pleinement qualifié du serveur, c’est-à-dire le résultat de la commande hostname --fqdn.
  • myorigin définit le domaine auquel sont associés des mails envoyés localement. Par défaut, myorigin a la même valeur que myhostname.
  • mydestination fournit la liste des domaines pour lesquels les messages reçus doivent être stockés dans une boîte mail locale. Même si Postfix gère plusieurs domaines, mydestination ne doit spécifier que le domaine principal. Les domaines virtuels seront gérés par la directive virtual_alias_domains, que nous verrons plus loin.
  • mynetworks définit les adresses depuis lesquelles Postfix accepte les mails sans authentification via SMTP. Les plages d’adresses fournies ici désignent donc toutes les machines auxquelles Postfix fait confiance, si l’on peut dire. Sur un serveur dédié public, il est impératif de définir uniquement l’hôte local pour mynetworks, sous peine de se retrouver avec une « pompe à merde », le terme communément utilisé pour les serveurs mails mal configurés qui sont utilisés par des tiers malintentionnés pour l’envoi massif de spams sans authentification. Les spammeurs du monde entier adorent ce genre de machines.
  • relayhost définit le MTA auquel on est censé transférer les mails qui ne doivent pas être acheminés localement. Dans notre configuration, cette directive doit rester vide. On l’utilisera sur un serveur de réseau local pour transférer les mails à un MTA public sur Internet.
  • Le format de stockage par défaut de Postfix, c’est mbox. On préférera le format Maildir/, bien plus adapté pour une configuration IMAP.
  • alias_maps définit l’emplacement de la table de correspondance, et alias_database la base de données correspondante. Certaines informations ne peuvent pas être facilement représentées dans main.cf. Les tables de correspondance permettent de les stocker dans des fichiers externes. Postfix n’utilise pas directement les fichiers texte, ce serait trop lent. Au lieu de cela, les tables de correspondance de type hash (ou « tables de hachage) servent pour construire des fichiers indexés, grâce à la bibliothèque Berkeley DB. Le programme postmap est utilisé pour construire les fichiers indexés. Pour mettre à jour les alias, on utilisera la commande newaliases.

Éditer la table de correspondance.

# /etc/aliases
# Basic system aliases -- these MUST be present.
mailer-daemon:  postmaster
postmaster:     root
# General redirections for pseudo accounts.
bin:            root
daemon:         root
adm:            root
...
# trap decode to catch security attacks
decode:         root
# Person who should get root's mail
root:           microlinux

Construire le fichier indexé.

# newaliases

Premier test

Activer et démarrer Postfix.

# systemctl enable postfix
# systemctl start postfix

Vérifier si Postfix tourne correctement.

# systemctl status postfix
● postfix.service - Postfix Mail Transport Agent
   Loaded: loaded (/usr/lib/systemd/system/postfix.service; 
           enabled; vendor preset: disabled)
   Active: active (running) since sam. 2017-06-10 12:51:19 CEST; 
           47s ago
   ...
# cat /var/log/maillog
... starting the Postfix mail system
... daemon started -- version 2.10.1, configuration /etc/postfix

Basculer vers un compte utilisateur normal (microlinux dans l’exemple) et envoyer un mail vers un compte mail externe auquel on a accès. Un point . sur une ligne à part marque la fin du message.

# su - microlinux
Dernière connexion : samedi 10 juin 2017 à 10:18:37 CEST sur pts/0
$ mail info@microlinux.fr
Subject: Test Postfix
Ceci est un test.
.
EOT

Se connecter au compte mail externe et vérifier si le message a bien été envoyé, puis répondre à ce message. Si tout se passe bien, le répertoire utilisateur contient un nouveau répertoire ~/Maildir, qui ressemble à ceci.

$ tree Maildir/
Maildir/
├── cur
├── new
│   └── 1497093622.V802I148M893901.sd-100246.dedibox.fr
└── tmp

3 directories, 1 file

Le nouveau mail est un simple fichier texte, que l’on peut afficher avec less par exemple.

$ less Maildir/new/1497093622.V802I148M893901.sd-100246.dedibox.fr
Return-Path: <info@microlinux.fr> 
X-Original-To: microlinux@sd-100246.dedibox.fr
Delivered-To: microlinux@sd-100246.dedibox.fr
...

Le 10/06/2017 à 13:19, microlinux a écrit :
> Ceci est un test.
> 

Et voici la réponse.

-- 
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Web  : http://www.microlinux.fr
Mail : info@microlinux.fr
Tél. : 04 66 63 10 32

Gérer les mails en ligne de commande avec Mutt

Mutt est un MUA (Mail User Agent) en ligne de commande. On peut l’utiliser sur des machines dépourvues d’interface graphique.

Avant de lancer Mutt, éditer le fichier de configuration ~/.muttrc.

# ~/.muttrc 
set mbox_type=Maildir
set folder="~/Maildir"
set spoolfile="~/Maildir"
set mbox="+Mailbox"
my_hdr From: microlinux@sd-100246.dedibox.fr (Microlinux)
my_hdr Reply-To: microlinux@sd-100246.dedibox.fr (Microlinux)

Lancer Mutt :

$ mutt

La fenêtre principale de Mutt affiche la boite de réception. Les nouveaux mails sont marqués par un N. Une barre d’état en haut de l’écran affiche les principaux raccourcis. En règle générale, Mutt fonctionne avec les mêmes raccourcis que Vim. Pour lire un message, il suffit de le sélectionner et d’appuyer sur Entrée.

Mutt

Créer les comptes Linux pour la messagerie

Bien sûr, c’est plus élégant de créer des comptes virtuels gérés par une base de données et tout le bling bling. Le Web regorge d’ailleurs de tutos de ce genre, rivalisant de complexité. Pour commencer, nous allons rester fidèles au principe KISS et passer par des comptes Linux traditionnels.

Dans l’exemple qui suit, nous gérons le courrier des deux domaines slackbox.fr et unixbox.fr, avec les adresses mail suivantes.

  • jean.mortreux@slackbox.fr
  • agnes.debuf@slackbox.fr
  • fanny.banester@slackbox.fr
  • jean.mortreux@unixbox.fr
  • franck.teyssier@unixbox.fr

Dans un premier temps, nous allons créer des comptes Linux traditionnels, un par compte mail, en respectant les conventions de nommage classiques.

# useradd -c "Jean Mortreux" -s /sbin/nologin jmortreux
# useradd -c "Jean Mortreux" -s /sbin/nologin jmortreux2
# useradd -c "Agnès Debuf" -s /sbin/nologin adebuf
# useradd -c "Fanny Banester" -s /sbin/nologin fbanester
# useradd -c "Franck Teyssier" -s /sbin/nologin fteyssier

Deux remarques.

  • Les utilisateurs n’ont pas de shell de connexion, c’est-à-dire qu’ils ne pourront pas se connecter directement au serveur.
  • L’utilisateur Jean Mortreux dispose de deux comptes distincts jmortreux et jmortreux2, un pour chaque adresse mail.

Pour ne pas avoir à inventer des mots de passe raisonnablement compliqués pour chaque utilisateur, on peut utiliser l’outil pwgen, disponible dans le dépôt EPEL. Voici un exemple pour créer un mot de passe aléatoire long de huit caractères, composé de chiffres et de lettres majuscules et minuscules.

# pwgen -n -N 1

On va créer notre propre « base de données » sous forme de simple fichier texte mails.txt.

Nom              Mail                         Login       Pass
=================================================================
Agnès Debuf      agnes.debuf@slackbox.fr      adebuf      iesch6Ah
Fanny Banester   fanny.banester@slackbox.fr   fbanester   nai7abYi
Franck Teyssier  franck.teyssier@unixbox.fr   fteyssier   axr2aeNu
Jean Mortreux    jean.mortreux@slackbox.fr    jmortreux   aeFphk3t
                 jean.mortreux@unixbox.fr     jmortreux2  Psaelie3

Étant donné qu’il contient des informations sensibles, on va le stocker dans un
endroit approprié, à l’abri des regards curieux.

# ls -l /root/mails.txt
-rw-------. 1 root root 466 11 juil. 10:07 /root/mails.txt

Les alias

Un alias est un nom supplémentaire pour recevoir du courrier électronique. En réalité, les mails sont acheminés vers un compte qui existe déjà. Les alias sont définis dans le fichier /etc/aliases.

...
# Person who should get root's mail
root: microlinux

# Utilisateurs
agnes.debuf: adebuf
fanny.banester: fbanester
franck.teyssier: fteyssier
jean.mortreux: jmortreux, jmortreux2

À chaque modification de ce fichier, il faut reconstruire /etc/aliases.db, la base
de données des alias.

# newaliases

Définir les destinataires autorisés

Dans la configuration par défaut, tous les comptes Linux peuvent recevoir du courrier, y compris les comptes système comme root, named ou nobody si l’on utilise le fichier /etc/aliases fourni par défaut. Dans notre configuration, c’est l’utilisateur microlinux qui recevra les mails pour les comptes système.

Pour tester ce comportement, on peut créer un utilisateur bidon avec useradd et lui envoyer un mail à l’adresse bidon@sd-100246.dedibox.fr. On constate alors que ça passe comme une lettre à la poste.

# tree /home/bidon/Maildir/
/home/bidon/Maildir/
├── cur
├── new
│   └── 1489396170.V803I1c00037M362342.sd-100246.dedibox.fr
└── tmp

On va donc instaurer quelques restrictions pour éviter de spammer tout ce petit monde. Pour ce faire, on va créer un fichier /etc/postfix/local-recips avec la liste de tous les destinataires autorisés, en suivant la syntaxe suivante.

# /etc/postfix/local-recips
adebuf      x
fbanester   x
fteyssier   x
jmortreux   x
jmortreux2  x
microlinux  x

À partir de ce fichier, on va générer une base de données dans un format lisible pour Postfix.

# cd /etc/postfix
# postmap local-recips

Nous pouvons vérifier si le fichier a été généré correctement.

# postmap -s hash:local-recips
blabevue  x
jdupont   x
fantasio  x
glagaffe  x
glagaffe2 x

À chaque modification de local-recips, il faudra réinvoquer postmap local-recips pour reconstruire le fichier de base de données local-recips.db.

Pour prendre en compte les nouvelles restrictions, éditer /etc/postfix/main.cf et ajouter le paramètre suivant.

# Tables de correspondance
alias_maps = hash:/etc/postfix/aliases
alias_database = hash:/etc/postfix/aliases
local_recipient_maps = hash:/etc/postfix/local-recips $alias_maps

Prendre en compte les modifications.

# systemctl reload postfix

À partir de là, seuls les utilisateurs explicitement définis dans local-recips pourront recevoir du courrier.

Comptes Linux et adresses de messagerie

La prochaine étape consiste à faire correspondre les comptes Linux et les adresses de messagerie. Pour ce faire, on va créer un fichier /etc/postfix/canonical.

# /etc/postfix/canonical
adebuf      agnes.debuf@slackbox.fr
fbanester   fanny.banester@slackbox.fr
fteyssier   franck.teyssier@unixbox.fr
jmortreux   jean.mortreux@slackbox.fr
jmortreux2  jean.mortreux@unixbox.fr

Convertir le tableau en un format lisible pour Postfix.

# cd /etc/postfix
# postmap canonical

Définir le paramètre correspondant dans /etc/postfix/main.cf.

# Tables de correspondance
alias_maps = hash:/etc/postfix/aliases
alias_database = hash:/etc/postfix/aliases
local_recipient_maps = hash:/etc/postfix/local-recips $alias_maps
canonical_maps = hash:/etc/postfix/canonical

Domaines virtuels avec des utilisateurs distincts

Les domaines virtuels (Hosted Domains) sont tous les domaines qui ne correspondent pas au nom d’hôte du serveur, c’est-à-dire au résultat de la commande hostname -d.

Créer un fichier /etc/postfix/virtual avec un tableau qui fait correspondre chaque adresse mail d’un domaine virtuel à un compte Linux.

# /etc/postfix/virtual
agnes.debuf@slackbox.fr      adebuf
fanny.banester@slackbox.fr   fbanester
franck.teyssier@unxibox.fr   fteyssier
jean.mortreux@slackbox.fr    jmortreux
jean.mortreux@unixbox.fr     jmortreux2

Là aussi, rendre ce fichier lisible pour Postfix.

# postmap virtual

Adapter /etc/postfix/main.cf pour prendre en compte les domaines virtuels.

# Domaines locaux
mydestination = $myhostname, localhost.$mydomain, localhost

# Domaines virtuels
virtual_alias_domains = slackbox.fr,
                        unixbox.fr

...

# Tables de correspondance
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
local_recipient_maps = hash:/etc/postfix/local-recips $alias_maps
canonical_maps = hash:/etc/postfix/canonical
virtual_alias_maps = hash:/etc/postfix/virtual

Il ne reste qu’à recharger Postfix pour prendre en compte la nouvelle configuration.

# systemctl reload postfix

Le prochain article traitera de la configuration du serveur IMAP Dovecot.

Publié dans CentOS, Documentation Microlinux | Marqué avec , , | Laisser un commentaire

Sécuriser le serveur web Apache sous CentOS

Audit ApacheL’installation par défaut du serveur web Apache comporte une série de vulnérabilités connues. La correction de ces failles constitue l’objet de cet article. Notre démarche consistera à installer un scanner de sécurité sur une machine distante, qui nous permettra d’auditer le serveur. Ensuite, nous allons peaufiner la configuration d’Apache en fonction des résultats de notre audit. Pour nos tests, nous partons d’une installation par défaut d’Apache avec PHP.

Le scanner de sécurité Nikto

Nikto est un scanner de sécurité pour les serveurs Web. Il permet d’auditer Apache à la recherche de failles diverses et variées, en puisant dans une base de données de vulnérabilités connues à ce jour.

# yum install nikto

L’utilisation de Nikto est triviale. Il suffit de fournir l’adresse IP ou le nom d’hôte du serveur en argument.

$ nikto -h sd-100246.dedibox.fr

Au premier lancement, Nikto nous affiche l’avertissement suivant.

*** RFIURL is not defined in nikto.conf--no RFI tests will run ***

Pour effectuer les tests RFI (Remote File Inclusion), nous allons éditer /etc/nikto/config et fournir l’URL du fichier distant index.php avec la fonction phpinfo().

# RFI URL. This remote file should return a phpinfo call, 
# for example: <?php phpinfo(); ?>
RFIURL=http://sd-100246.dedibox.fr/index.php

Au deuxième lancement, Nikto va mouliner quelques minutes, pour nous afficher une  liste de vulnérabilités potentielles du serveur. À partir de là, il suffit d’être un peu méthodique.

Masquer les infos sur le système

Dans la configuration par défaut, Apache fournit des infos sur la version du serveur, le système d’exploitation et la version de PHP. Autant d’infos précieuses pour un attaquant potentiel.

-----------------------------------------------------------------
+ Target IP:          163.172.220.174
+ Target Hostname:    sd-100246.dedibox.fr
+ Target Port:        80
+ Start Time:         2017-07-10 10:59:49 (GMT2)
-----------------------------------------------------------------
+ Server: Apache/2.4.6 (CentOS) PHP/5.4.16

Pour masquer ces infos, créer un fichier /etc/httpd/conf.d/hardening.conf comme ceci.

# /etc/httpd/conf.d/hardening.conf

# Masquer les infos d'Apache
ServerSignature Off
ServerTokens Prod

Recharger la configuration d’Apache.

# systemctl reload httpd

À présent, Apache est bien moins bavard.

$ nikto -h sd-100246.dedibox.fr
- Nikto v2.1.5
-----------------------------------------------------------------
+ Target IP:          163.172.220.174
+ Target Hostname:    sd-100246.dedibox.fr
+ Target Port:        80
+ Start Time:         2017-07-10 11:21:40 (GMT2)
-----------------------------------------------------------------
+ Server: Apache

Masquer la signature de PHP

Le deuxième avertissement concerne la signature de PHP sur le serveur.

+ Retrieved x-powered-by header: PHP/5.4.16

Pour corriger ce comportement, il suffit d’éditer /etc/php.ini sur le serveur. Repérer la variable expose_php et modifier sa valeur en conséquence.

expose_php = Off

Recharger Apache.

# systemctl reload httpd

Empêcher les détournements de clics

Le clickjacking ou détournement de clic est une technique malveillante visant à pousser un internaute à fournir des informations confidentielles ou à prendre le contrôle de son ordinateur en le poussant à cliquer sur des pages apparemment sûres.

+ The anti-clickjacking X-Frame-Options header is not present.

Pour empêcher ce genre d’attaque, éditer /etc/httpd/conf.d/hardening.conf et ajouter la directive suivante.

# Clickjacking
<IfModule mod_headers.c>
  Header always append X-Frame-Options SAMEORIGIN
</IfModule> 

Prendre en compte les modifications.

# systemctl httpd reload

L’avertissement relatif au clickjacking ne s’affiche plus. Notons au passage que Nikto nous affiche un nouvel avertissement, que nous pouvons ignorer sereinement, vu qu’il s’agit d’un bug dans le scanner.

+ Uncommon header 'x-frame-options' found, with contents: SAMEORIGIN

Désactiver les ETags

Les ETags (ou entity tags) sont normalement utilisés pour pouvoir différencier deux versions d’un même document. C’est un identifiant de la forme 1321-553ba6ed5c167, unique pour une URL, qui est transmis entre le navigateur et le serveur dans les requêtes HTTP. Et c’est également une faille de sécurité potentielle d’Apache, qui peut permettre à un attaquant d’obtenir des infos sensibles sur les fichiers du serveur, comme les inodes. Dans la configuration par défaut d’Apache, les ETags sont activés.

+ Server leaks inodes via ETags, header found with file /, 
fields: 0x1321 0x5058a1e728280

Pour désactiver les ETags, on va ajouter une ligne à notre fichier /etc/httpd/conf.d/hardening.conf.

# ETags
FileETag none

Recharger la configuration.

# systemctl reload httpd

Désactiver l’affichage du contenu des répertoires

En l’absence d’un fichier index.html ou index.php, Apache affiche le contenu d’un répertoire.

+ OSVDB-3268: /icons/: Directory indexing found.

Voici à quoi cela ressemble concrètement.

Apache Directory Listing

Cette fonctionnalité peut être désactivée grâce à la directive Options. Ouvrir /etc/httpd/conf/httpd.conf et repérer la stance suivante.

<Directory "/var/www/html">
  Options Indexes FollowSymlinks
  AllowOverride None
  Require all granted
</Directory>

Éditer les options comme ceci.

<Directory "/var/www/html">
  Options -Indexes 
  Options FollowSymlinks
  AllowOverride None
  Require all granted
</Directory>

Prendre en charge les modifications.

# systemctl reload httpd

Apprécier le résultat.

Apache Directory Listing Forbidden

Empêcher Apache de suivre les liens symboliques

Dans la configuration par défaut, Apache suit les liens symboliques, ce qui n’est pas recommandé en termes de sécurité. Pour empêcher ceci, nous allons reprendre la stance précédente dans /etc/httpd/conf/httpd.conf en l’éditant comme ceci.

<Directory "/var/www/html">
 Options -Indexes -FollowSymlinks 
 AllowOverride None
 Require all granted
</Directory>

Recharger la configuration, et le tour est joué.

# systemctl reload httpd

Installer le module mod_security

Nikto nous affiche toute une série d’avertissement relatifs au XST (cross-site tracing) et au XSS (cross-site scripting), qui ressemblent à ceci.

+ OSVDB-877: HTTP TRACE method is active, suggesting the host is 
  vulnerable to XST

Le meilleur moyen de lutter contre ce genre d’attaque tout comme les injections SQL, c’est d’installer le pare-feu applicatif mod_security, qui se présente sous la forme d’un module pour Apache.

Outre le module mod_security à proprement parler, CentOS fournit le paquet mod_security_crs qui contient une collection de règles de base (Core Rule Set) pour le bon fonctionnement du module.

# yum install mod_security mod_security_crs

Après l’installation, le répertoire /etc/httpd/conf.d contient un nouveau fichier mod_security.conf. Le module mod_security est activé dans la configuration par défaut.

SecRuleEngine On
  • On – Les règles sont activées
  • Off – Les règles sont désactivées
  • DetectionOnly – Les transactions sont interceptées et journalisées

Recharger la configuration.

# systemctl restart httpd

L’activation de mod_security se manifeste dans /var/log/httpd/error.log.

ModSecurity for Apache/2.7.3 (http://www.modsecurity.org/) 
configured.

L’installation de ce module semble avoir résolu un grand nombre de failles de sécurité d’Apache, au vu du nombre réduit d’avertissements de Nikto.

Désactiver les SSI et l’exécution des CGI

Les SSI (Server Side Includes ou « Inclusions Côté Serveur ») sont un langage de programmation fait pour être interprété par un serveur HTTP lorsqu’il sert un document HTML. Une attaque SSI exploite une application web en exécutant du code arbitraire à distance, ce qui permet à l’attaquant d’accéder à des infos sensibles comme les fichiers de mots de passe, ou encore d’exécuter des commandes de shell. Il vaut donc mieux désactiver cette fonctionnalité si l’on n’en a pas besoin.

Là encore, reprendre la stance précédente dans /etc/httpd/conf/httpd.conf en ajoutant les deux options correspondantes.

<Directory "/var/www/html">
 Options -Indexes -FollowSymlinks -ExecCGI -Includes 
 AllowOverride None
 Require all granted
</Directory>

Recharger la configuration d’Apache.

# systemctl reload httpd

Désactiver les modules superflus

Dans la configuration par défaut, Apache charge une quantité de modules. Nous allons désactiver les modules que nous n’utilisons pas. Le répertoire /etc/httpd/conf.modules.d contient une série de fichiers qui s’occupent du chargement des modules Apache. Ouvrir 00-base.conf et commenter les modules superflus.

#LoadModule autoindex_module modules/mod_autoindex.so
#LoadModule info_module modules/mod_info.so
#LoadModule userdir_module modules/mod_userdir.so

Le module mod_autoindex est appelé par /etc/httpd/conf.d/autoindex.conf. Étant donné que nous avons désactivé l’affichage du contenu des répertoires, nous pouvons le désactiver comme ceci.

# cd /etc/httpd/conf.d
# mv autoindex.conf autoindex.conf.deactivated

Recharger la configuration d’Apache.

# systemctl reload httpd

Protéger Apache des attaques XSS

XSS est une faille de sécurité qui permet d’injecter du code dans des pages web, par le biais de variables mal protégées. Pour contrer ce genre d’attaque, on peut activer la protection XSS en ajoutant la stance suivante au fichier /etc/httpd/conf.d/hardening.conf.

# XSS
<IfModule mod_headers.c>
   Header set X-XSS-Protection "1; mode=block"
</IfModule>

Une fois qu’on a rechargé la configuration d’Apache, voici comment cela se présente côté client.

$ curl --head http://sd-100246.dedibox.fr
HTTP/1.1 200 OK
Date: Mon, 10 Jul 2017 13:59:38 GMT
Server: Apache
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Content-Type: text/html
Publié dans CentOS, Documentation Microlinux | Marqué avec , , , , | Laisser un commentaire

Goodbye Slackware, hello CentOS

Logo CentOSMicrolinux is currently moving its desktop and server systems from Slackware to CentOS, for a variety of reasons. While I won’t engage in futile arguments over the respective merits of these two Linux distributions, let me offer a few words of explanation at least. Slackware and CentOS are two very different beasts, and I have a soft spot for both of them. It’s just that in the current state of things, the latter is much more adapted to my company’s needs. And yes, I still have to update the information on that website.

I’m regularly offering training courses for Linux admins, which up to this point have been based on Slackware Linux. The first part of these courses has been published in book form, and students generally enjoyed the course. But in the long run, I’ve decided to base my future Linux training on RHEL/CentOS, since this is what the majority of companies are using on their servers, in France at least. And I don’t want to paint myself into a corner.

Last but not least, while Slackware is a fine and reliable system, there’s too much stuff missing, at least for my needs. On the latest count, the MLED/MLES repositories contained more than 1.500 (!) extra packages for 32-bit and 64-bit servers and desktops based on Slackware 14.0, 14.1 and 14.2. These last months, I spent a significant amount of my time compiling and updating stuff. And since my company is a one-man-company, I can’t afford to do that in the long run.

If you want a rock-solid, reliable and functional Linux desktop with bells and whistles that JustWorks(tm), you can give my CentOS-based custom KDE desktop a spin.This is what I currently use on my workstation and on my laptop, and this is also what I install on my client’s desktop PCs. On older hardware, you can use the previous GNOME-based version.

Die-hard Slackware users can still use packages present on the slackware.uk mirror, though be advised that these are unmaintained. Of course, I’d be glad if someone forked my work and continued to maintain it. Everything’s still in place in the Github repository.

Cheers from the sunny South of France,

Niki Kovacs (a.k.a. Kiki Novak)

Publié dans Divers | Marqué avec | Un commentaire

Organiser les hôtes virtuels Apache sous CentOS

Apache Virtual HostsComme la plupart des distributions Linux, Red Hat et CentOS fournissent un répertoire comprenant une série de fichiers de configuration modulaires pour Apache, en l’occurrence /etc/httpd/conf.d. Ces fichiers sont pris en compte grâce à la directive Include qui figure dans le fichier de configuration principal /etc/httpd/conf/httpd.conf.

# Load config files in the "/etc/httpd/conf.d" directory, if any.
IncludeOptional conf.d/*.conf

Le répertoire /etc/httpd/conf.d contient un fichier README qui nous renseigne un peu plus sur le fonctionnement particulier de cette configuration modulaire.

This directory holds configuration files for the Apache HTTP Server;
any files in this directory which have the ".conf" extension will be
processed as httpd configuration files.  The directory is used in
addition to the directory /etc/httpd/conf.modules.d/, which contains
configuration files necessary to load modules.

Files are processed in alphabetical order.

L’info à retenir ici, c’est que les bouts de fichiers de configuration pour Apache sont traités par ordre alphabétique. Partant de là, on peut répartir la configuration des hôtes virtuels sur plusieurs fichiers pour plus de lisibilité, avec un VirtualHost par fichier, et en nommant chaque fichier en correspondance avec le nom d’hôte. Voici la solution que j’ai adoptée sur mes serveurs.

Dans un premier temps, les fichiers contenant la configuration globale d’Apache sont préfixés 00-* comme ceci.

# cd /etc/httpd/conf.d
# ls
autoindex.conf  php.conf  README  ssl.conf  userdir.conf  
welcome.conf
# for FILE in $(ls *.conf); do
> mv $FILE 00-$FILE
> done
# ls
00-autoindex.conf  00-php.conf  00-ssl.conf  00-userdir.conf  
00-welcome.conf README

Ensuite, j’ai deux hôtes virtuels qui pointent vers la page par défaut et vers les infos PHP. Les deux sont préfixés 10-* comme ceci.

  • 10-sd-100246.dedibox.fr.conf
  • 10-phpinfo.slackbox.fr.conf

Enfin, les hébergements à proprement parler sont tous préfixés 20-* et nommés en fonction du nom d’hôte.

# ls -1
00-autoindex.conf
00-php.conf
00-ssl.conf
00-userdir.conf
00-welcome.conf
10-phpinfo.slackbox.fr.conf
10-sd-100246.dedibox.fr.conf
20-mail.slackbox.fr.conf
20-mail.unixbox.fr.conf
20-www.slackbox.fr.conf
20-www.unixbox.fr.conf
README

 

 

Publié dans CentOS, Documentation Microlinux | Marqué avec , , , | Laisser un commentaire

Hébergement sécurisé avec Apache et SSL sous CentOS

HTTPSCet article décrit la mise en place d’un hébergement sécurisé sur un serveur Apache tournant sous CentOS 7. Le protocole HTTP (Hypertext Transfer Protocol) transmet les données entre le serveur et le navigateur « en clair ». Les données personnelles, mots de passe et autres numéros de Carte Bleue sont donc interceptables. Pour résoudre ce problème, on utilisera le protocole HTTPS, qui ajoute une couche de cryptage SSL (Secure Sockets Layer) au protocole HTTP.

Le transfert crypté des données ne constitue qu’un aspect dans l’établissement d’une connexion sécurisé. L’autre aspect tout aussi important, c’est que l’utilisateur doit être sûr de communiquer avec la bonne personne. Autrement dit, votre numéro de Carte Bleue a beau être transmis de façon sécurisée, encore faut-il que la plateforme de paiement ne soit pas située sur un serveur géré par la mafia albanaise.

Pour savoir si l’on a bien affaire au bon interlocuteur, on utilisera un certificat. Cette véritable carte d’identité électronique contient non seulement la clé publique du serveur pour crypter les transmissions, mais également des renseignements sur le site ainsi que la signature de l’autorité de certification.

La génération d’un certificat électronique fait l’objet d’un article à part. Pour nos essais, nous utiliserons un certificat SSL/TLS fourni par le client Certbot. Si l’on décide de partir sur un certificat auto-signé, la configuration devra être adaptée en conséquence.

Dans l’exemple ci-dessous, nous allons configurer un hébergement public https://www.slackbox.fr.

Prérequis

Le protocole HTTPS utilise le port 443. Il faut donc songer avant toute chose à ouvrir ce port dans le pare-feu.

Installation

Le chiffrement SSL/TLS pour Apache est fourni par le paquet mod_ssl.

# yum install mod_ssl

On notera l’apparition d’un fichier de configuration ssl.conf dans /etc/httpd/conf.d.

Configurer Apache et SSL

Avant de continuer, effectuer une copie de sauvegarde du fichier de configuration par défaut.

# cd /etc/httpd/conf.d
# cp ssl.conf ssl.conf.orig

Partant d’un répertoire /var/www/html vide, on peut récupérer un peu de contenu statique pour avoir quelque chose à nous mettre sous la dent.

# cd /var/www/html/
# cp -R /usr/share/httpd/noindex/* .

Régler les permissions de l’arborescence de fichiers téléchargés.

# chown -R microlinux:microlinux *
# find . -type d -exec chmod 0755 \{} \;
# find . -type f -exec chmod 0644 \{} \;

Ensuite, éditer /etc/httpd/conf.d/ssl.conf en renseignant les directives DocumentRoot et ServerName ainsi que l’emplacement du certificat SSL et de la clé privée.

##
## SSL Virtual Host Context
##
<VirtualHost _default_:443>
DocumentRoot "/var/www/html"
ServerName www.slackbox.fr:443
...
SSLCertificateFile /chemin/vers/cert.pem
SSLCertificateKeyFile /chemin/vers/privkey.pem
SSLCertificateChainFile /chemin/vers/fullchain.pem
...
</VirtualHost>

Redémarrer Apache.

# systemctl restart httpd

Ouvrir le site avec Firefox. On notera la présence du petit cadenas vert en haut à gauche dans la barre d’adresses pour indiquer l’établissement d’une connexion sécurisée.

Apache SSL

Améliorer la sécurité de notre hébergement

Rendons-nous sur la page SSL Server Test du portail Qualys SSL Labs pour effectuer un audit de la sécurité de notre hébergement.

Qualys Labs Test SSL

Pour l’heure, la résultat est plutôt médiocre et comporte une série de vulnérabilités, que nous allons éliminer l’une après l’autre en suivant les suggestions affichées.

La vulnérabilité à l’attaque POODLE se résoud en désactivant SSLv3 dans ssl.conf. L’option SSLProtocol se situe dans la configuration de l’hôte virtuel. Il faut la déplacer au début du fichier dans les options globales, en ajoutant -SSLv3, comme ceci.

#
# When we also provide SSL we have to listen to the 
# the HTTPS port in addition.
#
Listen 443 https

##
##  SSL Global Context
##
##  All SSL configuration in this context applies both to
##  the main server and all SSL-enabled virtual hosts.
##

#   SSL Protocol support:
# List the enable protocol levels with which clients will be able 
# to connect.  Disable SSLv2 access by default:
SSLProtocol all -SSLv2 -SSLv3

Prendre en compte les modifications et relancer un test sur le site de Qualys Labs en cliquant sur Clear cache.

Qualys Labs Test SSL

C’est déjà un peu mieux. La prochaine suggestion concerne la désactivation du chiffrement RC4. Cette fois-ci, il faut récupérer l’option SSLCipherSuite dans la configuration de l’hôte virtuel et la placer en tête du fichier dans les options globales, en ajoutant !RC4.

#   SSL Protocol support:
# List the enable protocol levels with which clients will be able to
# connect.  Disable SSLv2 access by default:
SSLProtocol all -SSLv2 -SSLv3

#   SSL Cipher Suite:
#   List the ciphers that the client is permitted to negotiate.
#   See the mod_ssl documentation for a complete list.
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SEED:!IDEA:!RC4

Recharger la configuration d’Apache et relancer un test.

Qualys Labs Test SSL

On avance petit à petit. Pour nous débarrasser de la vulnérabilité restante, repérer l’option commentée SSLHonorCipherOrder et l’insérer juste après SSLCipherSuite en la décommentant.

#   SSL Cipher Suite:
#   List the ciphers that the client is permitted to negotiate.
#   See the mod_ssl documentation for a complete list.
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SEED:!IDEA:!RC4
SSLHonorCipherOrder on

Cette fois-ci, nous avons bel et bien éliminé l’ensemble des failles de sécurité connues concernant le chiffrement.

Qualys Labs Test SSL

La politique HSTS

HSTS (HTTP Strict Transport Security) est un mécanisme de politique de sécurité proposé pour HTTP, permettant à un serveur web de déclarer à un agent utilisateur (navigateur web) compatible qu’il doit interagir avec lui en utilisant une connexion sécurisée (comme HTTPS). La politique est donc communiquée à l’agent utilisateur par le serveur via la réponse HTTP, dans le champ d’en-tête nommé Strict-Transport-Security. La politique spécifie une période de temps durant laquelle l’agent utilisateur doit accéder au serveur uniquement de façon sécurisée.

Pour activer cette politique dans la configuration d’Apache, il suffit d’ajouter la ligne suivante dans la définition de l’hôte virtuel.

<VirtualHost _default_:443>
# HSTS
Header always set Strict-Transport-Security \
  "max-age=63072000; includeSubDomains"
...
</VirtualHost>

L’audit de sécurité nous montre qu’on est assez proche de la perfection.

Qualys Labs Test SSL

Héberger plusieurs sites sécurisés

Si l’on souhaite héberger plusieurs sites sécurisés sous forme d’hôtes virtuels Apache, la solution la plus propre consiste à éditer /etc/httpd/conf.d/ssl.conf pour ne garder que les options globales, comme ceci par exemple.

# /etc/httpd/conf.d/ssl.conf
Listen 443 https
SSLPassPhraseDialog exec:/usr/libexec/httpd-ssl-pass-dialog
SSLSessionCache         shmcb:/run/httpd/sslcache(512000)
SSLSessionCacheTimeout  300
SSLRandomSeed startup file:/dev/urandom  256
SSLRandomSeed connect builtin
SSLCryptoDevice builtin
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SEED:!IDEA:!RC4
SSLHonorCipherOrder on

Ensuite, chaque hôte virtuel disposera de son propre fichier de configuration dans /etc/httpd/conf.d. Voici un exemple.

# /etc/httpd/conf.d/www.slackbox.fr.conf

# http://www.slackbox.fr -> https://www.slackbox.fr
<VirtualHost *:80>
  ServerName www.slackbox.fr
  ServerAlias slackbox.fr
  Redirect / https://www.slackbox.fr
</VirtualHost>

# https://www.slackbox.fr
<VirtualHost _default_:443>
  Header always set Strict-Transport-Security \
    "max-age=63072000; includeSubDomains"
  ServerAdmin info@microlinux.fr
  DocumentRoot "/var/www/html/slackbox-site/html"
  ServerName www.slackbox.fr:443
  ServerAlias slackbox.fr
  SSLEngine on
  SSLCertificateFile /etc/letsencrypt/.../cert.pem
  SSLCertificateKeyFile /etc/letsencrypt/.../privkey.pem
  SSLCertificateChainFile /etc/letsencrypt/.../fullchain.pem
  BrowserMatch "MSIE [2-5]" \
    nokeepalive ssl-unclean-shutdown \
    downgrade-1.0 force-response-1.0
  ErrorLog logs/www.slackbox.fr-error_log
  CustomLog logs/www.slackbox.fr-access_log common
</VirtualHost>
Publié dans CentOS, Documentation Microlinux | Marqué avec , , , , , | Laisser un commentaire

Certificats SSL/TLS avec Certbot sous CentOS

CertificatCet article décrit la gestion des certificats SSL/TLS gratuits sur un serveur dédié tournant sous CentOS 7. Un certificat électronique peut être vu comme une carte d’identité numérique. Il est utilisé principalement pour identifier et authentifier une personne physique ou morale, ou pour chiffrer des échanges. Il est signé par un tiers de confiance qui atteste du lien entre l’identité physique et l’entité numérique. Le standard le plus utilisé pour la création des certificats numériques est le X.509.

Les prix des certificats électroniques sont extrêmement variables, et certaines entreprises comme par exemple Verisign les font payer très cher. En revanche, il est tout à fait possible de les avoir gratuitement…

Let’s Encrypt est une autorité de certification lancée le 3 décembre 2015 en version bêta publique. Elle fournit des certificats SSL/TLS gratuits grâce au client Certbot installé sur le serveur qui automatise la plupart des tâches. On n’est donc plus obligé de payer une fortune et/ou de sauter à travers des cerceaux en feu pour créer et renouveler les certificats.

Les certificats générés avec Certbot sont reconnus par l’ensemble des navigateurs Web modernes. Cette technologie repose sur le protocole ACME (Automated Certificate Management Environment).

Installation

Certbot est fourni par le dépôt EPEL.

# yum install certbot

On notera au passage que le paquet dépend d’une quantité importante de modules Python.

Plug-ins

Le client Certbot supporte une série de plug-ins pour Apache et Nginx. L’option plugins permet d’afficher les plug-ins installés.

# certbot plugins
Saving debug log to /var/log/letsencrypt/letsencrypt.log
* standalone
Description: Spin up a temporary webserver
Interfaces: IAuthenticator, IPlugin
Entry point: standalone = certbot.plugins.standalone:Authenticator

* webroot
Description: Place files in webroot directory
Interfaces: IAuthenticator, IPlugin
Entry point: webroot = certbot.plugins.webroot:Authenticator

Notre installation dispose des plug-ins standalone et webroot.

Tester Certbot et générer un certificat

Pour commencer, nous allons générer un certificat pour le domaine slackbox.fr. Étant donné que la requête utilise le port 443, il faut d’abord arrêter le serveur Web. En passant, il faudra éventuellement vérifier si le port 443 est bien ouvert dans le pare-feu.

# systemctl stop httpd

Pour nos tests, nous allons partir d’une installation par défaut d’Apache.

  • Vider le répertoire /var/www/html
  • Supprimer les hôtes virtuels dans /etc/httpd/conf.d

Dans un premier temps, nous allons tester la génération du certificat comme ceci.

# certbot certonly --non-interactive --email info@microlinux.fr \
  --preferred-challenges tls-sni-01 --standalone --agree-tos \
  --renew-by-default --webroot-path /var/www/html \
  -d slackbox.fr -d www.slackbox.fr --test-cert

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Starting new HTTPS connection (1): acme-staging.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for slackbox.fr
tls-sni-01 challenge for www.slackbox.fr
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
 /etc/letsencrypt/live/slackbox.fr/fullchain.pem. Your cert will
 expire on 2017-10-03. To obtain a new or tweaked version of this
 certificate in the future, simply run certbot again. To
 non-interactively renew *all* of your certificates, run "certbot
 renew"

Pour en savoir un peu plus sur les options utilisées, on peut afficher l’aide de certbot comme ceci.

# certbot --help all | less

Si tout s’est passé comme prévu, on peut réitérer la commande ci-dessus en omettant l’option --test-cert pour générer le certificat pour de vrai.

Les fichiers générés se trouvent tous dans le répertoire /etc/letsencrypt/live/<domaine>. On va donc jeter un oeil.

# ls -1 /etc/letsencrypt/live/slackbox.fr/
cert.pem  
chain.pem  
fullchain.pem  
privkey.pem

À quoi correspondent ces fichiers ?

  • privkey.pem : c’est la clé privée pour le certificat. Ce fichier ne doit surtout pas être divulgué. Le serveur doit pouvoir y accéder pour que SSL/TLS fonctionne. C’est ce qu’Apache utilisera comme fichier SSLCertificateKeyFile.
  • cert.pem : le certificat du serveur. C’est ce qui correspond au SSLCertificateFile d’Apache.
  • chain.pem : les certificats requis par le navigateur hormis le certificat du serveur. Requis par Apache < 2.4.8 pour le SSLCertificateChainFile.
  • fullchain.pem : tous les certificats, y compris celui du serveur. Il s’agit là de la concaténation de chain.pem et de cert.pem. C’est requis par Apache >= 2.4.8 pour le SSLCertificateFile.

On pourrait théoriquement tenter de créer un certificat propre au FQDN de la Dedibox.

# certbot certonly --non-interactive --email info@microlinux.fr \
  --preferred-challenges tls-sni-01 --standalone \
  --renew-by-default --agree-tos \
  --webroot-path /var/www/html -d sd-100246.dedibox.fr 

Avec un peu de chance, ça passe. Dans le cas contraire, on est gratifié d’un message d’erreur de dépassement de quota en raison d’un nombre de sous-domaines trop élevé pour le domaine dedibox.fr. Cela dépend des jours.

Utiliser et tester le certificat

Pour commencer, on peut mettre en place un hébergement sécurisé avec le serveur Web Apache. La procédure détaillée fait l’objet d’un article à part. Voici la stance correspondante dans la configuration d’Apache.

...
SSLCertificateFile "/chemin/vers/cert.pem"
SSLCertificateKeyFile "/chemin/vers/privkey.pem"
SSLCertificateChainFile "/chemin/vers/fullchain.pem"
...

Renouveler un certificat

La durée de vie d’un certificat est de 90 jours, ce qui n’est pas beaucoup. Pour prolonger la validité d’un certificat, il suffit de le renouveler en réinvoquant exactement la même commande utilisée pour le générer initialement.

Révoquer un certificat

Dans certains cas de figure – par exemple lorsqu’on déménage un hébergement vers une autre machine avec une adresse IP différente – il peut être nécessaire de révoquer un certificat avant de le générer ailleurs. On peut le faire comme ceci.

# cd /etc/letsencrypt/live
# certbot --text revoke --cert-path chemin/vers/cert.pem

Certificats et permissions

Si l’on souhaite utiliser plusieurs applications sécurisées pour un même domaine (Web, courrier, messagerie XMPP), on se retrouve confronté à un problème de permissions. Concrètement, si le serveur Web ainsi que le serveur de messagerie Prosody doivent accéder en lecture au certificat et à la clé privée, on peut utiliser la solution qui suit.

On crée un groupe système certs, on ajoute les utilisateurs système respectifs à ce groupe et on règle les permissions des fichiers en fonction, c’est-à-dire root:certs. Concrètement :

# groupadd -g 240 certs
# chgrp -R certs /etc/letsencrypt
# chmod -R g=rx /etc/letsencrypt

Si l’on souhaite qu’une application accède au certificat et à la clé privée, il suffit qu’on ajoute l’utilisateur correspondant au groupe système certs. Exemple pour la messagerie XMPP Prosody :

# usermod -a -G certs prosody

Notez que ce n’est pas la peine d’ajouter l’utilisateur apache au groupe certs. Au démarrage, le serveur Apache s’exécute avec les droits root, puis lance une série de processus enfants avec des droits restreints :

# ps aux | grep httpd | grep -v grep
root   3168 0.0 0.2 ... /usr/sbin/httpd -DFOREGROUND
apache 3169 0.0 0.2 ... /usr/sbin/httpd -DFOREGROUND
apache 3170 0.0 0.3 ... /usr/sbin/httpd -DFOREGROUND
apache 3171 0.0 0.3 ... /usr/sbin/httpd -DFOREGROUND
apache 3254 0.0 0.3 ... /usr/sbin/httpd -DFOREGROUND

Automatiser la procédure

La procédure de génération et de renouvellement peut être automatisée à l’aide d’un petit script. Voici un exemple.

#!/bin/bash
#
# mkcert.sh
#
# Create/renew SSL/TLS certificate

# Create certs group with GID 240
if ! grep -q "^certs:" /etc/group ; then
  groupadd -g 240 certs
  echo ":: Added certs group."
  sleep 3
fi

# Stop Apache
if ps ax | grep -v grep | grep httpd > /dev/null ; then
  echo ":: Stopping Apache."
  systemctl stop httpd 1 > /dev/null 2>&1
  sleep 5
fi

# Generate SSL/TLS certificate
certbot certonly \
  --non-interactive \
  --email info@microlinux.fr \
  --preferred-challenges tls-sni-01 \
  --standalone \
  --agree-tos \
  --renew-by-default \
  --webroot-path /var/www/html \
  -d slackbox.fr -d www.slackbox.fr

# Fix permissions
echo ":: Setting permissions."
chgrp -R certs /etc/letsencrypt
chmod -R g=rx /etc/letsencrypt

# Start Apache
echo ":: Starting Apache."
systemctl start httpd

À partir de là, on peut définir une tâche automatique (cronjob) pour renouveler le certificat tous les débuts de mois, comme ceci par exemple.

# crontab -l
# Renouveler le certificat SSL le 1er du mois à 4h30
30 4 1 * * /usr/local/sbin/mkcert.sh 1> /dev/null

Certificat SAN multi-domaines

Dans certains cas de figure, notamment lorsqu’on met en place le serveur de messagerie Postfix, on peut avoir besoin de regrouper les certificats pour plusieurs domaines dans un seul certificat SAN (Subject Alternative Names). Pour générer un certificat SAN multi-domaine, on pourra adapter le script ci-dessus.

Voici un exemple pour un certificat SAN pour les domaines slackbox.fr et unixbox.fr et les sous-domaines mail.slackbox.fr et mail.unixbox.fr.

# Generate SSL/TLS certificate
certbot certonly \
  --non-interactive \
  --email info@microlinux.fr \
  --preferred-challenges tls-sni-01 \
  --standalone \
  --agree-tos \
  --renew-by-default \
  --webroot-path /var/www/html/slackbox-site/html \
  -d slackbox.fr -d www.slackbox.fr \
  --webroot-path /var/www/html/slackbox-mail/html \
  -d mail.slackbox.fr \
  --webroot-path /var/www/html/unixbox-site/html \
  -d www.unixbox.fr -d unixbox.fr \
  --webroot-path /var/www/html/unixbox-mail \
  -d mail.unixbox.fr

Le cas de figure domaine-0001

Il peut arriver qu’on soit confronté à la création d’un répertoire domaine-0001 dans /etc/letsencrypt/live, par exemple suite à la suppression d’un sous-domaine pour un certificat SAN. Du coup les chemins vers les certificats ne sont plus valides, et c’est une belle pagaille.

La manière la plus simple de rectifier le tir pour récupérer une configuration consiste à faire le ménage « à la louche ».

  1. Révoquer tous les certificats.
  2. Supprimer le contenu de l’arborescence.
  3. Relancer le script pour générer les certificats.

Téléchargement

Un modèle de script mkcert.sh est disponible au téléchargement dans mon dépôt Github centos, dans le répertoire el7/certbot.

$ git clone https://github.com/kikinovak/centos
Publié dans CentOS, Documentation Microlinux | Marqué avec , , , , , | Laisser un commentaire