Sécuriser Apache2 : Les bonnes pratiques pour protéger votre serveur Web

Article publié le 17 Janvier 2026.

Installer un serveur Apache, c’est l’affaire de deux minutes en apt install. Le rendre prêt pour la production et résistant aux scans automatisés qui pullulent sur le web, c’est une autre histoire.

Aujourd’hui, on fait le tour des configurations indispensables pour durcir (hardener) votre service Apache2 sous Debian/Ubuntu.

1. On cache la version d’Apache et de l’OS

Par défaut, Apache est trop bavard. Il indique sa version et l’OS utilisé dans les signatures d’erreurs. C’est donner des indices précieux à un attaquant.

On modifie le fichier /etc/apache2/conf-enabled/security.conf (ou directement dans apache2.conf) :

 

2. Désactivation du listing des répertoires

Il n’y a rien de pire que de laisser un attaquant naviguer dans l’arborescence de vos fichiers si vous avez oublié un index.html.

Dans votre configuration de VirtualHost ou dans le répertoire racine :

Note : Le -Indexes désactive le listing, et -FollowSymLinks empêche de suivre des liens symboliques vers l’extérieur du répertoire.

3. Les Headers de sécurité (Le plat de résistance)

C’est ici que l’on gagne des points sur SecurityHeaders.com. Il faut activer le module headers : sudo a2enmod headers

Puis, ajoutez ces lignes dans votre config :

# Protection contre le Clickjacking
Header always set X-Frame-Options « SAMEORIGIN »
# Protection contre le XSS
Header set X-XSS-Protection « 1; mode=block »
# Désactivation du sniffing de type MIME
Header set X-Content-Type-Options « nosniff »
# Referrer Policy
Header set Referrer-Policy « no-referrer-when-downgrade »
# HSTS (A n’activer que si vous avez un certificat SSL valide !)
Header always set Strict-Transport-Security « max-age=31536000; includeSubDomains »

4. Désactiver les méthodes HTTP inutiles

La plupart du temps, vous n’avez besoin que de GET, POST et HEAD. Les méthodes TRACE ou TRACK peuvent être utilisées pour des attaques de type Cross-Site Tracing.

TraceEnable Off

<Location « / »>
AllowMethods GET POST HEAD
</Location>

5. Utiliser Fail2Ban pour bannir les bruteforcers

Apache génère des logs, autant s’en servir. Si vous ne l’avez pas encore, installez Fail2Ban pour bloquer les IPs qui cherchent des failles via des 404 à répétition.

Dans votre /etc/fail2ban/jail.local :

[apache-noscript]
enabled = true
port = http,https
filter = apache-noscript
logpath = /var/log/apache2/error.log
maxretry = 3

Si vous ne vous souvenez plus comment installer fail2ban n’hésitez pas à jeter un coup d’oeil à mon article 😉 https://journaldunadminlinux.fr/tutoriel-protegez-votre-serveur-avec-fail2ban/

Conclusion

Avec ces quelques modifications, vous réduisez drastiquement la surface d’attaque de votre serveur. N’oubliez pas de tester votre configuration avec un petit apache2ctl configtest avant de redémarrer le service !

Comme toujours, la sécurité est un processus continu. Gardez vos paquets à jour avec un apt update && apt upgrade régulier.



Tutoriel | Répartition de charge en fonction des ressources disponibles sur vos machines avec HAPROXY

Article publiée le 23 Septembre 2017

Il y a quelque temps, je suis tombé sur la problématique suivante: comment faire en sorte que mon LoadBalancer HAProxy répartisse les connexions sur les machines ayant le moins de charge CPU?

Un collègue m’a alors fait suivre une doc qui m’a apporté la solution.

Ci-dessous un petit tuto vous expliquant comment procéder en prenant comme exemple la répartition d’un flux SSH sur 2 machines. Rien ne vous empêche d’adapter ce tuto  pour rediriger d’autres type de connexion (HTTP, etc…)

1) Configuration de votre serveur HAPROXY

  • Installez HAPROXY:

Sous Debian/Ubuntu:

apt-get install haproxy

Sous RedHat/Centos

yum install haproxy

Éditez le fichier /etc/haproxy/haproxy.cfg (pensez à faire une sauvegarde avant) et écrasez le contenu avec la configuration ci-dessous:

global
log 127.0.0.1 local2
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
maxconn 4000
user haproxy
group haproxy
daemon

 

# turn on stats unix socket

stats socket /var/lib/haproxy/stats

 

defaults
mode tcp
log global
option dontlognull
option http-server-close
#option forwardfor except 127.0.0.0/8
option redispatch
retries 3
timeout http-request 10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 1m
timeout http-keep-alive 10s
timeout check 10s
maxconn 3000

 

 

listen haproxy_servers

#bind correspond au port d’écoute de votre HAPROXY

bind *:2222
mode tcp
option tcplog
timeout client 10800s
timeout server 10800s
#balance leastconn
default-server inter 10s downinter 5s rise 2 fall 2 slowstart 60s maxconn 200 maxqueue 250 weight 100 error-limit 10 on-error mark-down on-marked-down shutdown-sessions agent-port 9707 agent-inter 30s
server monserveur1.mondomaine.net monserveur1.mondomaine.net:22 check agent-check observe layer4
server monserveur2.mondomaine.net monserveur2.mondomaine.net:22 check agent-check observe layer4
server localhost 127.0.0.1:22 maxconn 500 backup weight 1

 

backend servers

mode tcp
option tcplog
#balance roundrobin
server monserveur1.mondomaine.net monserveur1.mondomaine.net:22
server monserveur2.mondomaine.net monserveur2.mondomaine.net:22

2) Installation de l’agent sur les machines hôtes

Déployez l’agent en suivant les instructions ci-dessous sur chacune des machines qui recevra la charge.

  • Créez le fichier /usr/local/bin/haproxy-agent-check et insérez le script ci-dessous

#!/bin/bash
LMAX=90

load=$(uptime | grep -E -o ‘load average[s:][: ].*’ | sed ‘s/,//g’ | cut -d’ ‘ -f3-5)
cpus=$(grep processor /proc/cpuinfo | wc -l)

while read -r l1 l5 l15; do {
l5util=$(echo « $l5/$cpus*100″ | bc -l | cut -d ». » -f1);
[[ $l5util -lt $LMAX ]] && echo « up 100% » && exit 0;
[[ $l5util -gt $LMAX ]] && [[ $l5util -lt 100 ]] && echo « up 50% » && exit 0;
echo « down#CPU overload »;
}; done < <(echo $load)

exit 0

  • Ajustez les droits pour que le script soit exécutable:

chmod +x /usr/local/bin/haproxy-agent-check

  • Installez xinetd (apt-get install xinetd ou yum install xinetd en fonction de votre distribution)
  • Éditez le fichier /etc/services et ajoutez y la ligne suivante:

haproxy-agent-check 9707/tcp                # haproxy-agent-check

  • Créez le fichier xinetd /etc/xinetd.d/haproxy-agent-check avec le contenu suivant:

# default: on
# description: haproxy-agent-check
service haproxy-agent-check
{
disable         = no
flags           = REUSE
socket_type     = stream
port            = 9707
wait            = no
user            = nobody
server          = /usr/local/bin/haproxy-agent-check
log_on_failure  += USERID
per_source      = UNLIMITED

}

  • Ajustez les droits:

chmod +x /etc/xinetd.d/haproxy-agent-check

  • Redémarrez le service xinetd

service xinetd restart

  • Une fois cette manipulation effectuée sur chacune de vos machine testez la connectivité entre votre serveur HAProxy et vos hôtes via le port 9707

telnet <DNS ou IP de votre machine> 9707

  • Redémarrez ensuite le service HaProxy sur la machine prévue à cet effet:

service haproxy restart

  • Enfin, depuis votre machine HAproxy, vérifiez que vos agents répondent correctement grâce à la commande suivante:

echo « show stat » | socat stdio unix-connect:/var/lib/haproxy/stats  | cut -d ‘,’ -f1,2,18,19 | grep haproxy

Vous devriez avoir un retour de ce type:

haproxy_servers,FRONTEND,OPEN,
haproxy_servers,<monserveur1>,UP,100
haproxy_servers,<monserveur2>,UP,100
haproxy_servers,localhost,no check,1
haproxy_servers,BACKEND,UP,200

Voila il ne vous reste plus qu’à vous connecter sur votre machines HAPROXY (via la port 2222 dans notre cas) et vous constaterez que votre LoadBalancer répartira la charge sur la machine ayant la charge CPU la plus faible!

Enjoy 😉