METTRE À JOUR LE SYSTÈME D’EXPLOITATION

Avant de commencer, on met l’OS à jour :

aptitude update && aptitude dist-upgrade

et on ajoute tout ce qu’il faut pour compiler :

aptitude install build-essential

Voilà, nous sommes prêts à démarrer.

SÉCURISATION DES SERVICES AVEC IPTABLES ET FAIL2BAN

Notre serveur est maintenant opérationnel et sert les pages du site. Il faut toutefois penser à le sécuriser un peu contre les attaques les plus communes.

Nous utilisons donc iptables – un firewall qui filtre activement nos ports utilisés et qui bloque les autres – et fail2ban qui scanne vos fichiers logs à la recherche de requêtes étranges pour bloquer les intrus à la porte lorsqu’ils deviennent trop insistants.
Installation et configuration d’iptables

Si ce n’est déjà fait, on installe iptables :

aptitude install iptables

Les règles peuvent porter sur 3 chaînes :

INPUT en entrée,
FORWARD dans le cas d’un routage réseau,
OUPUT en sortie.

et les actions à entreprendre sont ACCEPT (accepter le paquet), DROP (le jeter), QUEUE et RETURN. Les arguments utilisés sont :

i : interface d’entrée (input)
o : interface de sortie (output)
t : table (par défaut filter contenant les chaînes INPUT, FORWARD, OUTPUT)
j : règle à appliquer (Jump)
A : ajoute la règle à la fin de la chaîne (Append)
I : insère la règle au début de la chaîne (Insert)
R : remplace une règle dans la chaîne (Replace)
D : efface une règle (Delete)
F : efface toutes les règles (Flush)
X : efface la chaîne
P : règle par défaut (Policy)
lo : localhost (ou 127.0.0.1, machine locale)

Pour lister les règles en place, on entre la commande :

iptables --list

Créons un petit script pour accueillir nos règles de filtrage :

nano /etc/init.d/firewall

avec ces règles :

#!/bin/sh

# Vider les tables actuelles
iptables -t filter -F

# Vider les règles personnelles
iptables -t filter -X

# Interdire toute connexion entrante et sortante
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP

# Ne pas casser les connexions etablies
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# Autoriser le loopback
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT

# ICMP (ping)
iptables -t filter -A INPUT -p icmp -j ACCEPT
iptables -t filter -A OUTPUT -p icmp -j ACCEPT

# SSH
iptables -t filter -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 22 -j ACCEPT

# DNS (bind)
iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT

# APACHE : HTTP + HTTPS
iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 443 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 8443 -j ACCEPT

# Mail SMTP:25
iptables -t filter -A INPUT -p tcp --dport 25 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 25 -j ACCEPT

# Mail POP3:110
iptables -t filter -A INPUT -p tcp --dport 110 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 110 -j ACCEPT

# Mail IMAP:143
iptables -t filter -A INPUT -p tcp --dport 143 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 143 -j ACCEPT

# Mail POP3S:995
iptables -t filter -A INPUT -p tcp --dport 995 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 995 -j ACCEPT

# WEBMIN
iptables -t filter -A INPUT -p tcp --dport 10000 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 10000 -m state --state ESTABLISHED -j ACCEPT

et on rend notre fichier exécutable :

chmod +x /etc/init.d/firewall

On lance notre fichier :

sh /etc/init.d/firewall

Il vous faut maintenant tester vos services et vérifier que tout fonctionne : ouvrez une nouvelle session SSH, vérifiez que vous avez toujours accès à Webmin, qu’Apache est fonctionnel… c’est important. Si quelque chose ne tourne pas rond, rebootez le serveur et toutes les règles seront oubliées.

Si tout fonctionne comme prévu, on ajoute le script au démarrage :

update-rc.d firewall defaults

Pour le retirer, si besoin :

update-rc.d -f firewall remove

Pour activez le filtrage, il suffit de redémarrer le serveur ou d’exécuter le script directement :

sh /etc/init.d/firewall

Installation et configuration de fail2ban

On installe fail2ban :

aptitude install fail2ban

et on crée notre propre fichier de configuration :

cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

avant de l’éditer :

nano /etc/fail2ban/jail.local

Dans la section [DEFAULT], configurez ainsi :

# "ignoreip" can be an IP address, a CIDR mask or a DNS host. Fail2ban will not
# ban a host which matches an address in this list. Several addresses can be
# defined using space separator.
ignoreip = 127.0.0.1 VOTREIP

# "bantime" is the number of seconds that a host is banned.
bantime = 600

# A host is banned if it has generated "maxretry" during the last "findtime"
# seconds.
findtime = 600

# "maxretry" is the number of failures before a host get banned.
maxretry = 3

Pensez à mettre votre IP dans ignoreip pour éviter le filtrage. Ensuite, il suffit de parcourir le fichier et d’activer les filtres relatifs aux services activés sur le serveur en passant le paramètre enabled à “true” :

enabled = true

Une fois les modifications effectuées, sauvegardez le fichier et redémarrez fail2ban pour prendre en compte les modifications :

/etc/init.d/fail2ban restart

Voilà, c’est déjà un bon début mais ce n’est pas fini. Dans un tutoriel ultérieur, nous verrons comment sécuriser les services réseaux.

SECURISER la couche TCP/IP

Il est facile de sécuriser la couche TCP/IP du serveur juste en activant quelques directives.

Normalement, le réseau de l’hébergeur est suffisant stable pour que nous puissions désactiver certains fonctions de routage IPv4 et IPv6. Nous allons donc désactiver les redirections ICMP, nous protéger des attaques SYN FLOOD, du spoofing, du smurfing, désactiver le routage à l’intérieur des paquets et finalement désactiver l’autoconf IPV6.

Ce tutoriel prend à peine 10 minutes.
Configuration du fichier /etc/sysctl.conf

Il existe pas mal d’options dans le fichier sysctl.conf liées à la sécurité. Commençons par éditer le fichier :

nano /etc/sysctl.conf

Tout d’abord, on se protége du spoofing. Décommentez les 2 lignes :

net.ipv4.conf.default.rp_filter=1
net.ipv4.conf.all.rp_filter=1

On se protège ensuite des attaques de type SYN flood, décommentez la ligne :

net.ipv4.tcp_syncookies=1

et juste après, rajoutez :

net.ipv4.tcp_max_syn_backlog = 1024

On refuse les redirections ICMP pour éviter les attaques Man In The Middle (MITM) :

net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0

Nous ne sommes pas un routeur, nous n’envoyons donc pas de redirections ICMP :

net.ipv4.conf.all.send_redirects = 0
net.ipv6.conf.all.send_redirects = 0

et nous n’acceptons pas de router les paquets :

net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0

On peut également rajouter des directives supplémentaires. Par exemple, ignorer les codes réponses bogus des logs ICMP et éviter le smurfing :

net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1

ou encore désactiver l’autoconf IPv6 qui est responsable de l’erreur “kernel : IPv6 addrconf : prefix with wrong length 56?, très commune sur les serveurs OVH (dont notre kimsufi) :

net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.eth0.autoconf = 0

Il ne vous reste plus qu’à enregistrer le fichier et à appliquer les modifications :

sysctl -n -e -q -p /etc/sysctl.conf

Voilà, votre serveur devrait être un peu plus sécurisé qu’au départ.

SECURISER APACHE2 AVEC MODSECURITY

Aujourd’hui, on ajoute une couche de sécurité supplémentaire avec l’installation du module ModSecurity pour Apache.

ModSecurity est un firewall pour les applications web (WAF) pour Apache. Il permet de se prémunir contre pas mal d’attaques (connues/inconnues, injections SQL, failles XSS…) et permet de surveiller le traffic HTTP en temps réel. Très utile pour un serveur dédié sous Apache !

L’installation est très rapide, cela ne prend que quelques minutes et 3 étapes.
Etape 1 : installation de mod_security

On commence par éditer nos sources de dépôts :

nano /etc/apt/sources.list

et on ajoute les backports :

deb http://backports.debian.org/debian-backports squeeze-backports main

On met à jour et on installe mod_security :

aptitude update
aptitude install libapache-mod-security

On active le module :

a2enmod mod-security

Et on relance Apache pour prendre en compte nos changements :

/etc/init.d/apache2 restart

Etape 2 : configuration de mod_security

On crée quelques dossiers et fichiers nécessaires pour nos règles :

mkdir /var/asl
mkdir /var/asl/tmp
mkdir /var/asl/data
mkdir /var/asl/data/msa
mkdir /var/asl/data/audit
mkdir /var/asl/data/suspicious
mkdir /etc/apache2/modsecurity.d
mkdir /etc/asl/
touch /etc/asl/whitelist
touch /var/log/apache2/audit_log

On regarde sous quel utilisateur tourne Apache :

ps auxwww | grep apache

Chez moi, c’est www-data :

root 19268 2.3 9.4 567512 189456 ? Ss 14:45 0:01 /usr/sbin/apache2 -k start
www-data 19290 4.5 13.2 611288 265936 ? S 14:45 0:03 /usr/sbin/apache2 -k start
www-data 19291 0.5 10.8 581028 217700 ? S 14:45 0:00 /usr/sbin/apache2 -k start
www-data 19292 3.9 11.1 582540 224688 ? S 14:45 0:02 /usr/sbin/apache2 -k start
www-data 19293 1.2 11.1 583408 224768 ? S 14:45 0:00 /usr/sbin/apache2 -k start
www-data 19294 2.2 11.1 582024 223492 ? S 14:45 0:01 /usr/sbin/apache2 -k start
www-data 19295 1.0 10.9 581720 221420 ? S 14:45 0:00 /usr/sbin/apache2 -k start
www-data 19296 0.0 9.0 567512 183176 ? S 14:45 0:00 /usr/sbin/apache2 -k start

donc, on assigne à l’utilisateur www-data les droits sur les répertoires suivants :

chown www-data.www-data /var/asl/data/msa
chown www-data.www-data /var/asl/data/audit
chown www-data.www-data /var/asl/data/suspicious
chmod o-rx -R /var/asl/data/*
chmod ug+rwx -R /var/asl/data/*

On crée un fichier nécessaire pour mod_security :

nano /etc/apache2/conf.d/00_modsecurity.conf

et on y met :

Include /etc/apache2/modsecurity.d/*asl*.conf

Ensuite, on crée le fichier de configuration :

nano /etc/apache2/conf.d/modsecurity_crs_10_config.conf

et on y met :

SecRuleEngine On
SecRequestBodyAccess On
SecResponseBodyAccess On
SecResponseBodyMimeType (null) text/html text/plain text/xml
SecResponseBodyLimit 2621440
SecServerSignature Apache
SecComponentSignature 200911012341
SecUploadDir /var/asl/data/suspicious
SecUploadKeepFiles Off
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4(?!04))"
SecAuditLogType Concurrent
SecAuditLog /var/log/apache2/audit_log
SecAuditLogParts ABIFHZ
SecArgumentSeparator "&"
SecCookieFormat 0
SecRequestBodyInMemoryLimit 131072
SecDataDir /var/asl/data/msa
SecTmpDir /tmp
SecAuditLogStorageDir /var/asl/data/audit
SecResponseBodyLimitAction ProcessPartial
SecPcreMatchLimit 100000
SecPcreMatchLimitRecursion 100000

Admins, si vous voulez échapper au filtrage de mod_security, ajoutez votre IP dans :

/etc/asl/whitelist

Etape 3 : installation des dernières règles mod_security

On télécharge les dernières règles :

wget http://www.atomicorp.com/channels/rules/delayed/modsec-2.5-free-latest.tar.gz

On décompresse :

tar zxvf modsec-2.5-free-latest.tar.gz

et on les copie dedans :

cp modsec/* /etc/apache2/modsecurity.d/

Il ne nous reste plus qu’à relancer la configuration Apache :

/etc/init.d/apache2 reload

Test de mod_security

Et si on testait tout ça ?

wget http://localhost/index.php?foo=http://fakeattacker.com

Nous retourne une belle ERROR 403 : Forbidden :

http://localhost/index.php?foo=http://fakeattacker.com
Resolving localhost... 127.0.0.1
Connecting to localhost|127.0.0.1|:80... connected.
HTTP request sent, awaiting response... 403 Forbidden

Parfait ! Un petit tour dans les logs Apache nous le prouve également :

[error] [client xx.xx.xx.xx] ModSecurity: Access denied with code 403 (phase 2). Match of "beginsWith http://%{SERVER_NAME}/" against "MATCHED_VAR" required. [file "/etc/apache2/modsecurity.d/10_asl_rules.conf"] [line "455"] [id "340162"] [rev "193"] [msg "Atomicorp.com - FREE UNSUPPORTED DELAYED FEED - WAF Rules: Remote File Injection attempt in ARGS (AE)"] [data ""] [severity "CRITICAL"] [hostname "www.skyminds.net"] [uri "/index.php"] [unique_id "TYYG64eklt5yZMAAEwBmIoAAAAJ"]

A noter que lorsque ModSecurity est désactivé, cette requête nocive provoque une erreur 404 (not found), ce qui veut dire que le serveur essaie la requête. ModSecurity tue la requête directement (erreur 403, forbidden) avant que celle-ci n’atteigne le serveur.
Conclusion

Voilà, votre serveur est un peu plus sécurisé qu’avant. L’étape 3 sera à renouveler de temps en temps, histoire de mettre à jour les règles.

Je sous invite à visiter le site d'origine de ce tuto.