Cet article s'adresse aux personnes qui gèrent l'infrastructure et le système des serveurs : les sysadmin. Il concerne un système sous Linux (dans nos exemple, Debian stable). C'est un pense-bête plus qu'un vrai cours.

Installer fail2ban, Rkhunter, debsums (pour debian)

apt-get install fail2ban rkhunter debsums

Lorsque que Rkhunter détecte “quelque chose”, ça ne veut pas forcément dire que c'est grave, mais il faut enquêter.

Retrouver les warnings dans les logs :

cat /var/log/rkhunter.log | grep -i "warning"

Remonter les logs pour plus de détail dans /var/log/rkhunter.log

Vérifier la version de rkhunter :

rkhunter --versioncheck

Mettre à jour le programme :

rkhunter --update

Lister les différents tests effectués :

rkhunter --list

Effectuer une vérification :

rkhunter --checkall

• https://doc.ubuntu-fr.org/rkhunter

Fail2ban permet de surveiller les tentatives de connexion ratées. Il est un peu technique à configurer, mais bien documenté. Il permet de bloquer les attaques destinées à craquer un mot de passe en essayant toutes les combinaisons possibles (attaque par bruteforce).

Fail2ban peut aussi prendre pas mal de mémoire s'il est mal configuré. Surveillez uniquement les services utiles.

apt-get install fail2ban
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
nano /etc/fail2ban/jail.local

Prenez le temps de lire ce fichier et la doc, tranquillement. Quelques trucs à configurer quoi qu'il arrive :

• ignoreip = Mettez votre ip personnelle, si vous n'êtes pas en dynamique, ça vous évitera d'être bloqué parce que vous avez oublié le mot de passe… Savoir si on a une IP dynamique, et sinon, quel est notre adresse IP.
• bantime = 86400 Temps de ban en secondes. 86400 secondes correspond à une journée, ce qui est un temps assez long pour embêter les bots, et assez court pour ne pas bloquer un admin amnésique.
• findtime = 3600 Temps avant de recommencer. Ne pas mettre trop grand pour éviter que fail2ban analyse de longs fichiers de log, mais quand même assez long pour que les attaquants ne recommencent pas trop vite. 3600 correspond à une heure.
• maxretry = 6 Maximum de tentative autorisée par une adresse IP avant d'être bannie (pour le temps du bantime). 6 me semble un bon nombre : un humain a de quoi se tromper un peu, mais aucun mot de passe sérieux ne peut être craqué en 6 tentatives.

Ensuite, chaque service est configuré dans la section [JAIL].

[ssh]

enabled  = true  # Pour activer la surveillance de ce service
port     = ssh
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 6

Relancez la configuration avec

fail2ban-client reload

Vérifiez l'état des prisons :

fail2ban-client status

Pour la doc, voir

• http://doc.ubuntu-fr.org/fail2ban
• http://www.fail2ban.org/wiki/index.php/Main_Page

Debsums va comparer l'empreinte md5 avec les empreintes officielles.

Pour lister les erreurs :

debsums -s

Vérifier les paquets installés et leurs fichiers de configuration et lister les fichiers modifiés :

debsums -ca

Bien configurer le pare-feu.

Pour lister les ports ouverts sur son serveur :

netstat -a

Depuis un autre ordi :

nmap ip

Dans l'absolu, vos serveurs doivent être protégé par un pare-feu qui est si possible situé sur une machine différente. Les connexions en provenance d'internet passent par le pare-feu (qu'il s'agisse de requête web, ssh et autres) qui les redirigent ensuite vers les divers serveurs ; même trajet au retour, les serveurs passent par le pare-feu avant que l'information soit retransmise aux utilisateurs.

Cela veut dire que c'est sur le serveur du pare-feu que le certificat ssl sera configuré, entre autre.

SSH doit être bien configuré afin de limiter la portée des attaques. Voir l'article détaillé sur SSH.

Sauf cas très particulier, toutes les pages web devraient être accessibles uniquement via https. C'est absolument incontournable lorsque le serveur et le client échangent des informations, afin que les mots de passe ne soient pas transmis en clair sur le réseau.

Donc on configure bien son https. Voir l'article détaillé.

Apache n'est pas une obligation ; il existe d'autres très bons serveurs http, comme Nginx. Mais comme les tutoriels et les logiciels sont souvent paramétrés pour Apache, c'est plus facile pour les débutants d'utiliser ce dernier. Donc, quitte à l'utiliser, autant faire quelques manipulations de base.

Apache a un avantage dans le cas d'une architecture “pare-feu qui protège des serveurs”, il est assez facile d'avoir une communication mixte entre le pare-feu et les serveurs, avec et sans chiffrement. Certains logiciels ont besoin que toutes les communications soient protégés ; par exemple Teampass ne fonctionne pas sans https sur le serveur où il est installé (même si le pare-feu, lui, sert l'accès à l'internaute en https).

Pour Apache, il y a des modules à activer quoi qu'il arrive :

a2enmod headers ssl

Et dans le cas d'utilisation de proxy (typiquement si vous passez par un pare-feu) :

a2enmod proxy proxy_http

Pour connaître sa version d'apache et d'openssl :

apache -v
openssl version

À utiliser sur Mozilla SSL Configuration Generator pour générer les options de base à mettre dans sa configuration, ce sera probablement plus à jour que ce tutoriel au fil du temps.

Liens utiles :

• Rouler en classe A avec Apache
• Configurer son serveur web en HTTPS

En principe nos serveurs sont à jours, hein. Mais en cas d'oubli, ne facilitons pas la tâche des observateurs :

nano /etc/apache2/apache2.conf

# Cacher la version d'Apache2
ServerTokens Prod
ServerSignature Off

service apache2 restart

À refaire sur chacun de ses serveurs !

Activer les headers dans Apache si ce n'est pas déjà fait :

a2enmod headers

Puis modifiez le fichier /etc/apache2/mods-enabled/headers.conf :

# Ce qui suit vient de
# https://blog.adminrezo.fr/2016/12/securiser-serveur-apache-https-headers/
# controler l'acces des bots de facon plus fine qu'avec robots.txt :
Header set X-Robots-Tag "index,follow,noarchive"
# Evite que le contenu soit interprete differemment que definit dans le mime Type
Header set X-Content-Type-Options nosniff
# Protection contre le clickjacking
Header set X-Frame-Options "SAMEORIGIN"
# Protection contre les failles X-XSS
Header set X-XSS-Protection "1; mode=block"
# Faille specifique IE8
Header set X-Download-Options noopen;
# Interdire l'embarquement de tout ou partie de votre site dans un site ou logiciel tiers 
Header set X-Permitted-Cross-Domain-Policies none
# Enfin, les CSP permettent de vérifier l'origine des éléments du site
# CSP, pour eviter de charger des scripts d'ailleurs.
Header set Content-Security-Policy "default-src 'self' "

Les explications :

• Header set X-Robots-Tag : http://robots-txt.com/x-robots-tag/
• CSP : https://ole.michelsen.dk/blog/secure-your-website-with-content-security-policy.html .

Header set Content-Security-Policy "default-src 'self' *khaganat.net; script-src 'self' 'unsafe-inline' *khaganat.net; style-src 'self' 'unsafe-inline'; img-src * "

Activer le module ssl dans Apache si ce n'est pas déjà fait :

a2enmod ssl

Puis modifiez le fichier /etc/apache2/mods-available/ssl.conf suivant ces informations :

• Enlever le protocole SSL3 et SSLv2 qui ne sont plus considérés comme sûrs (notez le “-” devant SSLv3 et SSLv2)
• Interdire la compression d'échanges chiffrés (oui oui cela introduit une possibilité d'attaque)
• Lister la liste des algorithmes de chiffrement autorisés et interdits
• Imposer de négocier ces protocoles dans l'ordre, donc du plus sûr au moins sûr (notez le “!” devant certains nom d'algorithme pour les interdire, par exemple : !PSK, !RC4, etc… et le + devant ceux à favoriser)
• Le dernier morceau concerne OCSP qui accélère un peu les échanges en https, voir aussi Accélérer votre réponse SSL/TLS avec l’OCSP Stapling

SSLProtocol TLSv1.2
SSLCompression off
SSLCipherSuite HIGH:!aNULL:!eNULL:!LOW:!MEDIUM:!EXP:!RC4:!3DES:!MD5:!PSK:!kRSA:!SRP:-DH:+ECDH
SSLHonorCipherOrder On

# OCSP Stapling, only in httpd 2.3.3 and later
SSLUseStapling          on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache        shmcb:/var/run/ocsp(128000)

Pour la liste SSLCipherSuite, consulter les préconisations de Mozilla SSL Configuration Generator et lire tranquillement l'explication si dessous avant de modifier la proposition mise à jour le 29 novembre 2017.

À partir de la version 2.4.11 d'apache, vous pouvez ajouter dans le fichier /etc/apache2/mods-available/ssl.conf :

SSLSessionTickets Off

Une ciphersuite est un ensemble de 4 algorithmes différents, chacun servant à un rôle distinct :

• 1 pour faire un échange de clés
• 1 pour faire du chiffrement asymétrique
• 1 pour faire du chiffrement symétrique
• 1 pour le contrôle

Un exemple : DHE-RSA-AES256-SHA256

• DHE : diffie hellman, c'est l'échange de clés
• RSA pour l'asymétrique, en particulier pour la signature
• AES avec une clé de 256 bits pour le chiffrement symétrique
• et enfin sha256 pour calculer les empreintes des sommes de contrôle

On pourrait croire qu'il y a 5 algorithmes, par exemple avec ECDHE-RSA-AES128-GCM-SHA256. En fait, GCM est un des modes de fonctionnement d'AES, donc AES128-GCM désigne de l'AES en mode GCM avec une clé de 128 bits. Pour info, les EC devant ECDHE et parfois ECDSA c'est pour elliptic curve, donc l'utilisation de courbes elliptiques au lieu de nombres premiers.

SSL et TLS permettent d'utiliser non pas une seule combinaison, mais plusieurs, ce qui fait que ces protocoles intègrent une phase de négociation de la cipher suite. Chaque version de SSL ou TLS autorise ou non certaines cipher suites etc, bref c'est le bordel, sachant qu'il faut, avant ça, négocier la version de SSL ou TLS utilisée. Soit dit en passant, il existe une cipher suite NULL qui dit qu'il n'y a aucun chiffrement, du coup cette phase de négociation a été attaqué, un MITM¹⁾ permettant de forcer une cipher suite (genre NULL ou une faible).

Afin d'éviter les ennuis, on va dire au serveur de n'utiliser que certaines cipher suites et pas d'autres : c'est l'option SSLCipherSuite. Chaque cipher suite est séparée par : et s'il y a un ! devant son nom, c'est pour explicitement l'interdire.

Le site de Mozilla cite toutes les ciphersuites, c'est sans doute bien, mais ils ont juste oublié un truc : à tout citer explicitement, il faut faire évoluer la liste avec les avancées en matière de recherche. Personnellement j'utilise et recommande d'utiliser des familles. Ces familles sont définies par la librairie SSL/TLS utilisée :

• ALL ← on autorise tout
• !aNULL:!eNULL ← on interdit les familles de NULL
• !LOW:!MEDIUM ← on interdit les cipher suites disposant d'une clé de 128 bits (MEDIUM) ou moins (LOW)
• !EXP ← ce sont les variantes d'exportation, donc fortement affaiblies, de certains algos
• !RC4 ← RC4 est un algo de chiffrement symétrique qui a été démoli mais un truc bien grave alors qu'il était très populaire
• !3DES ← pareil, on interdit cette merde
• !MD5 ← celui qui utilise encore md5 pour du checksum crypto est un grand malade
• !PSK ← pareil, une merde de plus de virée
• +HIGH ← et enfin on autorise la famille des cipher suites reconnues comme fortes

Du coup on fait confiance dans les familles définies dans les lib crypto, mais en imposant des restrictions sur certains trucs trop limites pour y être inclus mais qui ont des chances de tout de même s'y retrouver.

Les librairies ont un outil pour lister les familles, qui liste soit toutes les cipher suites supportées, soit, si on précise, la liste de ce qui est autorisé :

openssl ciphers
openssl ciphers HIGH
openssl ciphers 'HIGH:!AES'

Voir aussi

man 1 ciphers

Une fois https configuré (let's encrypt lancé, les fichiers /etc/apache2/site-enabled/MONSITE-le-ssl.conf automatiquement configurés, vérifiez ces derniers. Là, deux possibilités : soit l'architecture “de base”, où on a un seul serveur, sur la même machine que le pare-feu, soit deux machines, l'un étant le pare-feu et l'autre hébergeant les services web.

Dans le cas d'un pare-feu sur un autre serveur que les serveurs de base, chaque vhost sur le serveur du pare-feu doit contenir ceci :

ServerName sousdomaine.monserveur.net

# Proxy : permet de renvoyer vers l'adresse ip du serveur. Ici l'exemple est 
# dans le cas de VM Xen, c'est donc une adresse locale.
ProxyPass / http://192.168.20.43/
ProxyPassReverse / http://192.168.20.43/

ProxyRequests off
ProxyPreserveHost on
                <Proxy *>
                Options FollowSymLinks MultiViews
                AllowOverride All
                Order allow,deny
                allow from all
                </Proxy>

# SSL
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/MONSITE.COM/certificate.pem
SSLCertificateChainFile /etc/letsencrypt/live/MONSITE.COM/chain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/MONSITE.COM/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf

# HSTS (mod_headers requis) (15768000 seconds = 6 months)(63072000 = 24 mois)
Header set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"

HSTS (module Header) permet de déclarer au client directement dans la réponse HTTP qu'il faut communiquer en HTTPS. Cet en-tête permet d'éviter le vol de cookies et le downgrade SSL.

# Le paramètre suivant est valide si vous avez amélioré la clé Diffie Hellman
SSLDHParametersFile /etc/letsencrypt/live/MONSITE.COM/dhparams.pem

Si vous avez une VM (A) qui sert de pare-feu avant de redistribuer le trafic aux autres VM (B) de votre serveur, il y a un petit souci : les VM B croient que tout le trafic vient de l'ip de la VM A. Ce qui pose un gros souci dans le cas où vous avez du spam et que votre CMS favori permet de bannir par IP… si vous bannissez la VM A, plus rien ne passera, même les utilisateurs légitimes.

Il faut donc activer le transfert des IP sur les VMs destinataires (pas toucher au pare-feu, ce n'est pas là que ça se joue.

Créer /etc/apache2/conf-available/remoteip.conf et lui donner ceci :

RemoteIPHeader X-Forwarded-For
RemoteIPInternalProxy 192.168.20.35

Remplacer 192.168.20.35 par l'IP interne de la VM pare-feu.

Activer le module remoteip qui fait ça :

a2enmod remoteip
a2enconf remoteip
service apache2 restart

Cela devrait marcher. À répeter sur chaque VM du réseau.