Sécurisation et monitoring d’un serveur Linux Debian
Sommaire
Firewall
La carte ethernet du serveur est directement connecté a internet. C’est donc le serveur lui même qui fait office de par feu. Pour ce chapitre je vous propose de récupérer un script simple que l’on va installer. Celui-ci fonctionne de la façon suivante:
- On bloque tout le trafic entrant
- On laisse le trafic sortant libre. Le serveur va ou il veut.
- On autorise le ping
- Empêcher le syn flood
- Empêcher le scan de port
- Enfin ouverture de deux services de base: SSH et HTTP
Vous allez devoir modifier ce script au fur et à mesure de l’implémentation de nouveau service sur vôtre machine. Pour cela vous devez connaitre le port en écoute et le protocole (TCP et/ou UDP).
Par exemple si vous installé un serveur de chat vocale comme mumble, ce dernier écoute sur le port 64738 en TCP et en UDP. Il faut alors ajouter les lignes suivantes au script
|
1
2
3
|
# Serveur mumble
iptables –t filter –A INPUT –p tcp —dport 64738 –j ACCEPT
iptables –t filter –A INPUT –p udp —dport 64738 –j ACCEPT
|
Bref je ne donne pas plus d’explication. Vous trouverez ce qu’il faut sur Google en cas de besoin.
Allé on installe le script. Déja pour commencer si vous n’avez pas GIT d’installé il faut taper ça
|
1
|
apt–get install git
|
On récupère le code
|
1
|
git clone https://github.com/Sispheor/Linux_Scripts.git
|
On se place dans le dossier
|
1
|
cd Linux_Scripts/
|
On copie le script dans la init.d
|
1
|
cp Firewall.sh /etc/init.d/myfirewall
|
On le rend exécutable
|
1
|
chmod +x /etc/init.d/myfirewall
|
On le place au démarrage
|
1
|
update–rc.d myfirewall defaults
|
Et enfin, on le lance
|
1
|
/etc/init.d/myfirewall
|
Protection anti-intrusion
Les machines exposées au réseau Internet, sont continuellement la cible de tentatives d’attaques de type brute force et DOS. Pour s’en protéger nous allons mettre en place un petit programme du nom de Fail2Ban.
Pour rappel, Fail2Ban est un programme écrit en python et disponible dans la plupart des dépôts Linux qui à pour but de prévenir des attaques de type brute-force. Fail2ban lit les logs de divers serveurs (SSH, Apache, FTP…) à la recherche d’erreurs d’authentification répétées et ajoute une règle iptables pour bannir l’adresse IP de la source.
Installation
|
1
|
apt–get install fail2ban
|
Il y a plusieurs modifications à effectuer pour utiliser correctement Fail2Ban:
- Fail2ban doit démarrer APRES le script firewall dans l’initd. Comment faire ça ? il faut modifier le script /etc/init.d/fail2ban et rajouter dans les tags LSB dans les Required-Start le nom du script firewall. Du coup, si le script firewall est nommé “myfirewall” dans ses tags LSB, les tags LSB du fail2ban doivent ressembler à ça :
|
1
2
3
4
5
6
7
8
9
10
11
12
|
### BEGIN INIT INFO
# Provides: fail2ban
# Required-Start: $local_fs $remote_fs $myfirewall
# Required-Stop: $local_fs $remote_fs
# Should-Start: $time $network $syslog iptables firehol shorewall ipmasq arno-iptables-firewall
# Should-Stop: $network $syslog iptables firehol shorewall ipmasq arno-iptables-firewall
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start/stop fail2ban
# Description: Start/stop fail2ban, a daemon scanning the log files and
# banning potential attackers.
### END INIT INFO
|
-
Par défaut, les prisons (jails) de fail2ban sont un peu trop permissives, il faut les changer pour que le nombre d’essais soit plus petit et le temps de ban soit plus long. Ça se passe dans /etc/fail2ban/jail.conf, voici un exemple de conf :
|
1
2
3
|
ignoreip = 127.0.0.1/8
bantime = –1 # ban infini
maxretry = 3
|
- Dans ce même fichier de configuration on va changer l’adresse email de contact
|
1
|
destemail = moua@gmail.com
|
- Et enfin, toujours dans ce fichier de configuration, on change l’action par défaut pour que Fail2Ban envoi un mail avec un rapport complet sur l’adresse bannie.
|
1
|
action = %(action_mwl)s
|
- Un problème problème avec fail2ban, c’est qu’il ne persiste pas les ips bannies… Quand on redémarre, les méchants sont unbans et c’est open-bar pour eux de nouveau. Pour persister les ips bannies, il faut modifier le fichier /etc/fail2ban/action.d/iptables-multiport.conf qui définit (entre autres) les actions en cas de ban et en cas de démarrage de fail2ban. En cas de ban, on ajoute l’ip à un fichier texte. Au start de fail2ban, on lit ce fichier texte et on bannit toutes les ips qu’il contient.
|
1
2
3
4
|
actionstart = iptables –N fail2ban–<name>
iptables –A fail2ban–<name> –j RETURN
iptables –I <chain> –p <protocol> –m multiport —dports <port> –j fail2ban–<name>
cat /etc/fail2ban/ip.blacklist | while read IP; do iptables –I fail2ban–<name> 1 –s $IP –j DROP; done
|
|
1
2
|
actionban = iptables –I fail2ban–<name> 1 –s <ip> –j DROP
echo ‘<ip>’ >> /etc/fail2ban/ip.blacklist
|
- Un truc pas mal aussi, si vous avez plusieurs serveurs, c’est de savoir qui envoi le mail. Pour cela on édite le fichier /etc/fail2ban/action.d/sendmail-whois-lines.conf. En ce qui me concerne j’ai modifié pour les 3 actions (actionstart, actionstop et actionban) la valeur entre croché ou il est écrit “[Fail3Ban]” par le nom de mon serveur.
|
1
2
3
4
5
6
7
8
|
actionstop = printf %%b « Subject: [Serveur_test] : stopped
Date: `date –u +« %%a, %%d %%h %%Y %%T +0000 »`
From: Fail2Ban <>
To: n
Hi,n
The jail has been stopped.n
Regards,n
Fail2Ban » | /usr/sbin/sendmail –f
|
Par défaut seul la prison SSH est active. Vous trouverez à la fin du fichier de configuration /etc/fail2ban/jail.conf une liste de prison pré-configurée. Pour les activer il suffit de changer l’état de la variable “enabled”. Par exemple si l’on installe un serveur web par la suite on activera la prison correspondante comme cela
|
1
2
3
4
5
6
|
[apache]
enabled = true
port = http,https
filter = apache–auth
logpath = /var/log/apache*/*error.log
maxretry = 6
|
Il ne reste qu’a relancer le programme pour prendre en compte les changements
|
1
|
/etc/init.d/fail2ban restart
|
Protection contre le scan de ports
C’est l’une des premières étapes pour effectuer le piratage d’une machine sur internet: le scan de ports.
Cette technique consiste à effectuer un balayage des ports ouverts sur la machine cible. Chacun de ses ports correspondant à des services accessibles. Le pirate peut ensuite chercher une faille à exploiter dans l’un des services en question pour s’introduire sur vôtre système. On va mettre en place un outil pour empêcher ce scan.
Installation de portsentry
|
1
|
apt–get install portsentry
|
La configuration s’effectue dans le fichier /etc/portsentry/portsentry.conf. Je vous affiche ici uniquement les lignes à modifier
|
1
2
3
4
5
6
7
8
9
|
# blocage en cas de detection d’attaque
BLOCK_UDP=« 1 »
BLOCK_TCP=« 1 »
# ajout d’une route pour bloquer l’attaque
KILL_ROUTE=« /sbin/route add -host $TARGET$ reject »
# ajout d’une regle iptables en plus pour bloquer également
KILL_ROUTE=« /sbin/iptables -I INPUT -s $TARGET$ -j DROP »
# envoi d’un mail pour prévenir l’admin
KILL_RUN_CMD=« echo ‘Blocage scan de port $TARGET$’ | mail -s ‘scan port ban $TARGET$’ moua@gmail.com »
|
On redemarre le service pour prendre en compte
|
1
|
/etc/init.d/portsentry restart
|
Test depuis un client Linux. Attention cette ligne de commande va provoquer le bannissement de l’IP à l’origine de l’attaque.
|
1
|
nmap –v –PN –p 0–2000,60000 192.168.0.101
|
Pour enlever le ban on supprime la route.
|
1
|
route del <ip> rejected
|
Puis on édite le fichier /etc/hosts.deny et on supprime la ligne de l’ip correspondante qui ressemble a ceci
|
1
|
ALL: 192.168.0.47 : DENY
|
Le serveur est suffisamment protégé pour le moment. D’autres sécurités seront mis en place au fur et à mesure de la mise en place de service.
On va passer à la dernière étape de la configuration du serveur: le monitoring.
A ce stade le serveur fonctionne bien et possède une sécurisation minimale. Mais qu’arrive-t-il si pour une raison ou une autre un des services tombe ? Dans ce dernier chapitre on va se concentrer sur la partie monitoring du serveur.
Monitoring et surveillance du disque dur
Le disque dur est un organe central d’un serveur dédié. Avec le temps, de petites détériorations peuvent apparaître et entraîner une perte de données ou une instabilité du système.
Si comme moi vous avez un serveur Kimsufi chez OVH, il faut savoir que la surveillance du disque dur de la machine est à vôtre charge. En cas de panne de ce dernier il vous faudra prévenir l’hébergeur afin qu’il procède au remplacement de la pièce.
L’idée est donc de contrôler l’état du disque du serveur afin de diagnostiquer un éventuel problème qui pourrait conduire au changement préventif du disque. Pour cela nous allons utiliser le protocole SMART. SMART est une technologie implémentée dans les disques durs permettant permet ainsi de collecter en permanence des informations sur la santé du matériel.
Comme d’habitude l’installation s’effectue via le gestionnaire de paquets
|
1
|
apt–get install smartmontools
|
On va identifier le disque avec la commande fdik -l.
|
1
|
fdisk –l
|
Le disque est donc sda. Normalement c’est sda si vous n’avez qu’un seul disque dans le serveur.
Petit test rapide en manuel
|
1
|
smartctl –H /dev/sda
|
La commande doit retourner
|
1
2
|
=== START OF READ SMART DATA SECTION ===
SMART overall–health self–assessment test result: PASSED
|
Si la commande ne retourne pas “PASSED” c’est que le disque est en train de passer l’arme à gauche.
On va vérifier à présent se qui est faisable avec le SMART de vôtre disque.
|
1
|
smartctl –c /dev/sda
|
Ce qui donne pour le disque de mon serveur perso
La ligne intéressante est “Self-test supported”. Le disque peut s’auto diagnostiquer.
Cette ligne vous donne aussi une idée des durées de test estimés. Pour un test court (short) c’est une minute dans mon cas. 43 minutes pour un long (Extended).
On va justement lancer un test rapide
|
1
|
smartctl –t short /dev/sda
|
Le résultat nous demande d’attendre une minute.
|
1
2
3
4
5
6
|
=== START OF OFFLINE IMMEDIATE AND SELF–TEST SECTION ===
Sending command: « Execute SMART Short self-test routine immediately in off-line mode ».
Drive command « Execute SMART Short self-test routine immediately in off-line mode » successful.
Testing has begun.
Please wait 1 minutes for test to complete.
Test will complete after Sat Aug 31 19:39:48 2013
|
A la fin de cette minute on peut regarder le résultat avec la commande:
|
1
|
smartctl –l selftest /dev/sda
|
Qui nous donne
=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed without error 00% 8867 –
# 2 Short offline Completed without error 00% 8863 –
Completed without error donc c’est tout bon! Bref ça c’était la partie manuel pour se rassurer que tout va bien. On va maintenant automatiser un peu. Pour cela rien de plus simple. Smartmontools est livré avec son propre deamon qu’il faut juste régler.
Pour que le démon se lance au démarage du serveur on décommante la ligne suivante dans le fichier /etc/default/smartmontools
|
1
|
start_smartd=yes
|
On édite ensuite le fichier /etc/smartd.conf.
On commande la ligne par défaut.
|
1
|
# DEVICESCAN -d removable -n standby -m root -M exec /usr/share/smartmontools/smartd-runner
|
On ajoute notre disque.
|
1
|
/dev/sda –a –d sat –o on –S on –s (S/../.././02|L/../../7/03) –m moua@gmail.com –M test
|
Explication des paramètres
-a : Monitor la santé du disque
-d : Précise le type de disque
-o : Offline test
-S : Autosave
-m : adresse ou envoyer le mail d’alerte
-M : en mode test pour vérifier de suite que l’envoi de mail est ok
On démarre le programme pour prendre en compte les changements.
|
1
|
/etc/init.d/smartmontools start
|
On reçoit le mail de test
|
1
|
|
C’est tout bon, on édite à nouveau le fichier de configuration pour remplacer le paramètre -M comme ceci
|
1
|
/dev/sda –a –d sat –o on –S on –s (S/../.././02|L/../../7/03) –m moua@gmail.com –M exec /usr/share/smartmontools/smartd–runner
|
On redémarre pour prendre en compte et c’est fini. Le prochain mail reçu de sa part sera à prendre avec considération car cela voudra dire qu’il y a un problème avec le disque.
|
1
|
/etc/init.d/smartmontools restart
|
Petite supervision
Je dis “petite” parce que en terme de supervision il existe de l’artillerie lourde sur Linux (nagios, centreon, skinken,etc…). Ici on va juste mettre en place un petit outil sous forme de script qui se place dans le cron et qui se nomme MotdStat.
Ce petit programme permet deux choses:
- Un petit monitoring du serveur avec des alertes par mail
- Afficher certaines constantes à la connexion ssh
Voila une petite idée de se que l’outil propose comme affichage à la connexion SSH
Le programme n’est pas disponible dans les dépôts officiels. Il faut récupérer l’archive sur le site ici. Pour l’installer il faut compiler les sources.
|
1
|
tar xzf MOTDstat–0.0.3.tar.gz
|
|
1
|
cd MOTDstat–0.0.3
|
|
1
|
make install
|
Pour tester
|
1
|
motdstat —generate
|
Le message est alors généré dans le fichier /etc/motd et doit apparaître après le login de connexion SSH.
On ajoute cette même ligne de commande au crontab de façon à automatiser la génération par exemple toutes les 5 minutes.
Editer la crontab
|
1
|
crontab –e
|
On ajoute la ligne suivante et on ferme le fichier
|
1
|
*/5 * * * * /usr/bin/motdstat —generate
|
Toutes les 5 minutes, le fichier /etc/motd (motd = message of the day ), sera mis à jour avec les dernières constantes relevées du système.
Toute la configuration se passe au même endroit , soit dans /etc/motdstat , ou vous pouvez lister les fichiers suivants :
-
fstab_limits : ici on ajoute les partitions à surveiller avec la limite à atteindre avant une alerte mail
-
motdstat.conf : Configuration principale du programme. C’est ici que l’on va saisir le mail de destination des alertes par exemple
-
netservice : Surveillance des ports qui doivent être en écoute sur la machine
-
process : Les processus qui doivent tourner sur la machine
Les fichiers de configuration plutôt simple je ne détaillerai donc pas plus.
En cas de problème comme l’arrêt d’un service ou le dépassement du seuil d’espace disque, un mail vous sera envoyé. Dans l’exemple, le cron lance le script toute les 5 minutes. A vous de choisir quel délais de détection via la ligne du crontab. Sachez toutefois qu’un mail part à chaque lancement du script en cas d’alerte tant que vous n’avez pas réglé le problème.
