Sécuriser son serveur Linux (Partie 2)

Sécuriser son serveur Linux (Partie 2)

21/10/2015 1 Par Vincent

On va pousser la sécurité d’un cran au dessus. Normalement, si vous avez suivi le premier tutorial, vous avez un accès SSH plus sur qui empêche dans un premier temps n’importe qui d’accéder au root. De plus l’accès ssh est restreint également donc plus de sécurité.

Maintenant (je l’avais promis), on passe aux choses sérieuses :

  • Création de règles iptables (configuration du firewall)
  • Protection d’intrusions (Portsentry, Fail2ban, Snort, Rkhunter)
  • Surveillance des logs (logwatch)
  • Testons maintenant notre serveur (scan de ports et vulnérabilités)

Configuration d’iptables (firewall)

Iptables ? C’est LE firewall de Linux. C’est pas mieux, ni moins bien qu’un autre (si si, celui de Windows est très bien s’il est bien configuré) ; tout dépend de sa configuration. En fait, je vous propose ici une méthode mais il existe d’autres choses. Vous devez bien sur avoir iptables d’installé, mais c’est normalement le cas (sinon aller voir le internet comment on fait).

Ma stratégie est la suivante : on bloque tout (toutes les entrées, toutes les sorties et même tous le traffic traversant). Pour les entrées et les sorties, pas besoin de dessin je pense par contre pour le traffic traversant l’idée est d’empêcher une connexion établie sur un port d’être routé à travers notre machine (utile si on ne veut pas être la superbe passerelle entre un pirate lambda et la cible).

Je vous mets le début du fichier, la suite est fonction de votre réseau, serveur… Chez moi, c’est iptables.sh

[pastacode lang= »bash » message= » » highlight= » » provider= »manual » manual= »%23!%2Fbin%2Fbash%0A%0A%23%23%23%20Autoriser%20toutes%20les%20connexions%0Aiptables%20-P%20INPUT%20ACCEPT%0Aiptables%20-P%20FORWARD%20ACCEPT%0Aiptables%20-P%20OUTPUT%20ACCEPT%0A%0A%23%23%23%20Vider%20les%20tables%20actuelles%0Aiptables%20-t%20filter%20-F%0A%0A%23%23%23%20Vider%20les%20r%C3%A8gles%20personnelles%0Aiptables%20-t%20filter%20-X%0A%0A%23%23%23%20–%3E%20Les%20lignes%20ci-dessous%20doivent%20%C3%AAtre%20r%C3%A9alis%C3%A9es%20permier%20%23%23%23%0A%23%23%23%20Connexions%20d%C3%A9j%C3%A0%20%C3%A9tablies%0Aiptables%20-A%20INPUT%20-m%20conntrack%20–ctstate%20ESTABLISHED%20-j%20ACCEPT%0Aiptables%20-A%20INPUT%20-m%20state%20–state%20ESTABLISHED%2CRELATED%20-j%20ACCEPT%0Aiptables%20-A%20OUTPUT%20-m%20state%20–state%20RELATED%2CESTABLISHED%20-j%20ACCEPT%0A%23%23%23%20Accepte%20le%20SSH%2022%20TCP%0Aiptables%20-A%20INPUT%20-p%20tcp%20–dport%2022%20-j%20ACCEPT%0Aiptables%20-A%20OUTPUT%20-p%20tcp%20–dport%2022%20-j%20ACCEPT%0A%23%23%23%20Accepte%20la%20boucle%20Localhost%0Aiptables%20-t%20filter%20-A%20INPUT%20-i%20lo%20-j%20ACCEPT%0Aiptables%20-t%20filter%20-A%20OUTPUT%20-o%20lo%20-j%20ACCEPT%0A%23%23%23%20Accepte%20le%20ping%20de%20la%20machine%0Aiptables%20-t%20filter%20-A%20INPUT%20-p%20icmp%20-j%20ACCEPT%0Aiptables%20-t%20filter%20-A%20OUTPUT%20-p%20icmp%20-j%20ACCEPT%0A%23%23%23%20–%3E%20Les%20lignes%20ci-dessus%20doivent%20%C3%AAtre%20r%C3%A9alis%C3%A9es%20en%20premier%20%23%23%0A%0A%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%0A%23%23%23%20ATTENTION%20LES%20LIGNES%20JUSTE%20DESSOUS%20SONT%20DANGEREUSES%20%23%23%0A%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%0A%23%23%23%20Interdire%20toute%20connexion%20entrante%20et%20sortante%0Aiptables%20-P%20INPUT%20DROP%0Aiptables%20-P%20FORWARD%20DROP%0Aiptables%20-P%20OUTPUT%20DROP%0A%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%0A%23%23%23%20ATTENTION%20LES%20LIGNES%20JUSTE%20DESSUS%20SONT%20DANGEREUSES%20%23%23%23%0A%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%23%0A%0A%23%23%23%20Serveur%20DNS%20(si%20install%C3%A9)%0Aiptables%20-t%20filter%20-A%20OUTPUT%20-p%20tcp%20–dport%2053%20-j%20ACCEPT%0Aiptables%20-t%20filter%20-A%20OUTPUT%20-p%20udp%20–dport%2053%20-j%20ACCEPT%0Aiptables%20-t%20filter%20-A%20INPUT%20-p%20tcp%20–dport%2053%20-j%20ACCEPT%0Aiptables%20-t%20filter%20-A%20INPUT%20-p%20udp%20–dport%2053%20-j%20ACCEPT%0A%0A%23%23%23%20NTP%20(Serveur%20de%20temps%2C%20MAJ%20de%20l’heure%20via%20internet)%0Aiptables%20-t%20filter%20-A%20OUTPUT%20-p%20udp%20–dport%20123%20-j%20ACCEPT%0A%0A%23%23%23%20HTTP%2FHTTPS%20(Serveur%20web%20en%20sortie)%0Aiptables%20-t%20filter%20-A%20OUTPUT%20-p%20tcp%20–dport%2080%20-j%20ACCEPT%0Aiptables%20-t%20filter%20-A%20OUTPUT%20-p%20tcp%20–dport%20443%20-j%20ACCEPT%0A%0A%23%23%23%20HTTP%2FHTTPS%20(Serveur%20web%20en%20entr%C3%A9e)%0Aiptables%20-t%20filter%20-A%20INPUT%20-p%20tcp%20–dport%2080%20-j%20ACCEPT%0Aiptables%20-t%20filter%20-A%20INPUT%20-p%20tcp%20–dport%20443%20-j%20ACCEPT »/]

Pour l’appliquer, j’utilise à chaque démarrage ce script que je lance via /etc/rc.local. Comme ça je suis tranquille.

Je n’ai volontairement pas créé de règle pour MySQL par exemple (port par défaut : 3306) parceque je n’utilise ma base de donnée que pour mon site local. Bien sur, si d’autres machines doivent se connecter à la base de données, vous devez ouvrir le port, au moins en entrée (les connections établies pourront ressortir selon les premières règles). Ainsi de suite avec tous vos services.

On pourrait être plus restrictif en n’autorisant que certaines IP à accéder au serveur, mais ça pose un problème de taille : les BOX ADSL change d’IP souvent, donc vous seriez dans l’incapacité de contacter votre machine.

Protection initiale Flood/Scanning de ports

On peut à partir d’iptables commencer une protection contre le flood (attaque par dépassement des capacités du serveur en lui soumettant beaucoup de requêtes à la fois) et contre le scanning de ports (très sommairement). Enfin, vous pouvez ajouter ici des IPs que vous souhaitez bannir définitivement de votre machine (si vous repérez par exemple toujours la même machine qui veut se connecter sans raison à votre serveur).

[pastacode lang= »bash » message= » » highlight= » » provider= »manual » manual= »%23!%2Fbin%2Fbash%0A%0A%23%23%23%20Configuration%20avanc%C3%A9e%20du%20firewall%20(ajout%20d’un%20premier%20niveau%20de%20protection%20Flood%2FScan)%0A%0A%23%23%23%20Protection%20basique%20contre%20le%20flood%20(Denis%20de%20Service)%20DDOS%0Aiptables%20-A%20FORWARD%20-p%20tcp%20–syn%20-m%20limit%20–limit%201%2Fsecond%20-j%20ACCEPT%0Aiptables%20-A%20FORWARD%20-p%20udp%20-m%20limit%20–limit%201%2Fsecond%20-j%20ACCEPT%0Aiptables%20-A%20FORWARD%20-p%20icmp%20–icmp-type%20echo-request%20-m%20limit%20–limit%201%2Fsecond%20-j%20ACCEPT%0A%0A%23%23%23%20Scan%20de%20ports%20basique%0Aiptables%20-A%20FORWARD%20-p%20tcp%20–tcp-flags%20SYN%2CACK%2CFIN%2CRST%20RST%20-m%20limit%20–limit%201%2Fs%20-j%20ACCEPT%0A%0A%23%23%23%20Bannir%20une%20IP%20d%C3%A9rangeante%0A%23%23%23%20Template%20iptables%20-A%20INPUT%20-s%20adresse_ip%20-j%20DROP%0A%23iptables%20-A%20INPUT%20-s%20x.x.x.x%20-j%20DROP »/]

Protection d’intrusions

Actuellement, le firewall va bloquer toutes tentatives de connexions sur les ports fermés. Mais qu’en est-il des ports ouverts ? Afin de contrôler plus précisément ce qui se passe dessus, le firewall n’est pas suffisant et nous allons devoir utiliser d’autres outils, appelés IDS (Intrusion Detection System) et IPS (Intrusion Prevention System). Ces deux catégories de logiciels vont – comme leur nom l’indique – surveiller toute tentative d’intrusion sur le serveur.

Portsentry

Portsentry permet de bloquer en temps réel les scans de ports en bloquant la majorité des ports connus et inconnus contre ce type d’attaque. Dans un premier temps, installez-le.

Pour le configurer :

[pastacode lang= »bash » message= » » highlight= » » provider= »manual » manual= »nano%20%2Fusr%2Flocal%2Fpsionic%2Fportsentry%2Fportsentry.conf%0A%23%20ou%0Anano%20%2Fetc%2Fportsentry%2Fportsentry.conf »/]

Commentez les lignes:

[pastacode lang= »bash » message= » » highlight= » » provider= »manual » manual= »KILL_HOSTS_DENY »/]

 

Décommettez les lignes :

[pastacode lang= »bash » message= » » highlight= » » provider= »manual » manual= »%23%20Kill_route%20d%C3%A9fini%20l’action%20%C3%A0%20r%C3%A9aliser%20envers%20l’IP%20qui%20scan%20votre%20machine%0AKILL_ROUTE%3D%22%2Fsbin%2Fiptables%20-I%20INPUT%20-s%20%24TARGET%24%20-j%20DROP%22%0A%0A%23%20Mise%20en%20route%20des%20bans%0ABLOCK_UDP%3D%221%22%0ABLOCK_TCP%3D%221%22″/]

Vous devez ensuite passer en mode « advanced » (avancé) pour que le programme soit le plus efficace /etc/default/portsentry :

[pastacode lang= »bash » message= » » highlight= » » provider= »manual » manual= »%23%20On%20remplace%20ceci%20%3A%0ATCP_MODE%3D%22tcp%22%0AUDP_MODE%3D%22udp%22%0A%23%20Par%20ceci%20%3A%0ATCP_MODE%3D%22atcp%22%0AUDP_MODE%3D%22audp%22%0A »/]

Pour finir la partie configuration, assurez-vous de mettre votre IP dans le fichier /etc/portsentry/portsentry.ignore de façon à ce que vous ne soyez pas soumis au bannissement pendant vos tests !!!

Pour lancer le processus, il faut prévoir un cron pour les deux lignes là (on le lance en deux fois une pour udp, l’autre pour tcp). Si vous avez un firewall dont les règles correspondent à celles du dessus (-A XXXX DROP), par défaut tout est bloqué donc ce programme n’est pas ultra nécessaire. On peut aussi utiliser un launch_script /etc/init.d/portsentry start/stop/restart depuis la dernière version.

[pastacode lang= »bash » message= » » highlight= » » provider= »manual » manual= »portsentry%20%E2%80%93audp%0Aportsentry%20%E2%80%93atcp »/]

Fail2ban

Fail2ban, c’est très simple : c’est un petit programme qui permet de bannir (temporairement ou infiniment) l’ip d’une personne qui essayerait de brute-forcer un accès (ssh ou autre d’ailleurs). Si par exemple, une machine connait l’existence de l’utilisateur admin, il peut lancer une attaque par dictionnaire ou autre pour trouver le mot de passe. Par défaut, il n’y a pas de limite d’erreur. Tant que ça ne fonctionne pas, le serveur redemande de saisir le mot de passe. Fail2ban permet donc de définir le nombre de tentative avant l’exclusion permanent ou d’un temps donné du serveur.

Vous devez donc installer Fail2ban.

Puis dans la configuration :

[pastacode lang= »bash » message= » » highlight= » » provider= »manual » manual= »nano%20%2Fetc%2Ffail2ban%2Fjail.conf »/]

Je vous encourage à remplir le champ ci-dessous :

[pastacode lang= »bash » message= » » highlight= » » provider= »manual » manual= »%5BDEFAULT%5D%0A%23%20Les%20IP%20non%20concern%C3%A9%20par%20le%20ban%20en%20cas%20d’%C3%A9chec%20(localhost)%20et%208.8.8.8%20votre%20IP%20(si%20elle%20ne%20change%20pas).%0Aignoreip%20%3D%20127.0.0.1%208.8.8.8%0A%23%20Recherche%20de%20tentative%20dans%20les%20logs%20(en%20secondes).%0Afindtime%20%3D%203600%0A%23%20Temps%20de%20bannissement%20en%20secondes%0Abantime%20%3D%2086400″/]

Il y a aussi : destemail -> indiquez une adresse mail si vous voulez recevoir des mails d’alerte de la part de fail2ban.

Attention : fintime défini le temps de recherche dans les logs d’échecs de connexion. Mettre une valeur raisonnable, pas plus d’une heure ou deux. En effet, si vous mettez 1 an par exemple, si vous avez dans la dernière année le nombre maxi d’échecs autorisés, vous serez alors directement banni. Le nombre de tentative n’est pas forcement consécutif, mais plutôt dans un laps de temps. Si vous mettez 1 minutes (60 secs), vous bloqué la bruteforce mais vous vous laisser la possibilité de vous tromper de mot de passe de temps en temps…

Pour chaque service supporter ensuite, il faut :

[pastacode lang= »bash » message= » » highlight= » » provider= »manual » manual= »%5Bssh%5D%0A%0A%23%20Mets%20en%20fonction%20Fail2ban%20pour%20ssh%0Aenabled%20%3D%20true%0A%0A%23%20Sp%C3%A9cifie%20le%20port%20contr%C3%B4%C3%A9%0Aport%20%20%20%20%3D%20ssh%2Csftp%0Afilter%20%20%3D%20sshd%0A%23%20Sp%C3%A9cifie%20le%20log%20qu’il%20surveille%0Alogpath%20%20%3D%20%2Fvar%2Flog%2Fauth.log%0A%23%20Sp%C3%A9cifie%20le%20nombre%20d’essai%20avant%20le%20ban%0Amaxretry%20%3D%206″/]

Enfin pour appliquer la modification, comme d’habitude, on relance le service : /etc/init.d/fail2ban restart

Si vous avez besoin de débannir quelqu’un de la liste (ça peut arriver d’échouer des connexions SSH plusieurs fois de suite), regarder par ici :

[pastacode lang= »apacheconf » message= » » highlight= » » provider= »manual » manual= »fail2ban-client%20status%20ssh »/]

Plus d’aide sur fail2ban-client : http://www.fail2ban.org/wiki/index.php/Commands

Rkhunter

Pour finir, ce petit outil est intéressant pour détecter des RootKits et backdoors qui peuvent laisser des pirates qui arriveraient quand même à accéder à votre machine. Ce n’est pas une solution ultime. En fait, c’est même relativement difficile à utiliser. Il va générer des rapports énormes à chaque intervention. Mais ça peut quand même dépanner en cas de problème.

Après installation, vous devez regarder le fichier de configuration /etc/default/rkhunter :

[pastacode lang= »bash » message= » » highlight= » » provider= »manual » manual= »%23%20indiquez%20un%20mail%20pour%20recevoir%20des%20alertes%20de%20Rkhunter%20(c’est%20tr%C3%A8s%20souvent)%0AREPORT_EMAIL%0A%23%20mettez%20%C2%AB%20yes%20%C2%BB%20pour%20une%20v%C3%A9rification%20quotidienne%20de%20votre%20machine%20via%20un%20cron%0ACRON_DAILY_RUN%20%3A%20″/]

Si vous souhaitez un niveau de protection encore supérieur dans le domaine de la détection de rootkit, je vous laisse regarder du coté de GRsec mais ça requiert énormément de connaissance au niveau du kernel (noyau) de Linux. Bref, c’est super mais inutilisable sur un serveur dédié (ou alors pour les pros…).

Surveillance de logs

C’est quelque chose qu’il est intéressant de mettre en place pour surveiller son serveur sans avoir à se connecter régulièrement et surtout avoir besoin d’ouvrir 15 fichiers de logs pour chaque services installés. Ici nous utiliserons logwatch qui permet de regrouper toutes les données dans un rapport et de les envoyer soit par mail local soit par email à une adresse donnée.

Logwatch

Renseignez-vous de l’installation sur votre serveur (debian/gentoo/centos).

Ensuite, nous copions le fichier standard de configuration dans le dossier /etc et nous le personnalisons :

[pastacode lang= »bash » message= » » highlight= » » provider= »manual » manual= »cp%20%2Fusr%2Fshare%2Flogwatch%2Fdefault.conf%2Flogwatch.conf%20%2Fetc%2Flogwatch%2Fconf%2Flogwatch.conf »/]

Ensuite on édite les éléments suivants en fonctionne du résultat attendu :

[pastacode lang= »bash » message= » » highlight= » » provider= »manual » manual= »%23%20Votre%20dossier%20contenant%20vos%20autres%20logs%0ALogDir%20%3D%20%2Fvar%2Flog%0A%0A%23%20La%20sortie%20sera%20du%20type%20mail%20(email)%0A%23%20ou%20file%20(fichier%20sur%20le%20serveur)%0AOutput%20%3D%20mail%0A%0A%23%20Le%20format%20du%20rapport%20text%20(pour%20mail%20local)%0A%23%20ou%20html%20(pour%20mail%20sur%20une%20adresse%20email)%0AFormat%20%3D%20text%0A%0A%23%20Encodage%20none%20ou%20base64%0AEncode%20%3D%20none%0A%0A%23%20Ici%20la%20personne%20qui%20va%20recevoir%20le%20mail%0A%23%20Il%20peut%20s’agir%20d’un%20utilisateur%20local%20(root%2C%20admin)%0A%23%20ou%20d’une%20adresse%20e-mail%20(admin%40gmail.com)%20ou%20m%C3%AAme%0A%23%20de%20plusieurs%20si%20tout%20est%20s%C3%A9par%C3%A9%20par%20une%20virgule%0AMailTo%20%3D%20root%0A%0A%23%20Vous%20indiquez%20ici%20le%20nom%20de%20l’emetteur%20de%20l’email%0AMailFrom%20%3D%20Logwatch-WEB-LSD%0A%0A%23%20Le%20niveau%20de%20detail%20du%20rapport%0A%23%20Faible%20%3D%200%0A%23%20Intermediaire%20%3D%205%0A%23%20Eleve%20%3D%2010%0ADetail%20%3D%2010″/]

Maintenant, vous n’avez plus qu’à utiliser cron pour lancer logwatch quand vous voulez (personnellement, tous les jours dans la nuit).

PS : pour l’utilisation de cron, deux techniques en fonction des systèmes :

[pastacode lang= »bash » message= » » highlight= » » provider= »manual » manual= »crontab%20-l%0Acrontab%20-e »/]

ou via la mise en place de scripts dans :

[pastacode lang= »bash » message= » » highlight= » » provider= »manual » manual= »%2Fetc%2Fcron.daily%0A%23%20ou%0A%2Fetc%2Fcron.hourly%0A%23%20etc. »/]

Petite ligne de code (la question va venir sinon) sur comment vider la messagerie d’une session linux facilement :

[pastacode lang= »bash » message= » » highlight= » » provider= »manual » manual= »%3E%2Fvar%2Fspool%2Fmail%2Fadmin%0A%23%20Si%20l’utilisation%20s’appelle%20admin%20bien%20sur »/]

On teste tout ça maintenant ?

Bon, c’était sympa tout ça. En réalité, on n’est toujours pas à l’abri d’un problème mais bon. On peut tester rapidement via deux outils :

  • nmap pour scanner les ports
  • nessus pour scanner les vulnérabilités

Pour les deux logiciels, vous devez les utiliser sur vos propres serveurs. Pas chez les autres…

Pour namp, faites des essais avec plusieurs paramètres pour voir si la sécurité est améliorée ou non. Vous commencez par ces tests avant les modifications, puis après et vous comparerez. Vous aurez alors un bon visuel sur ce qu’il reste à faire…

[pastacode lang= »bash » message= » » highlight= » » provider= »manual » manual= »nmap%20-v%20ip_de_votre_serveur%0A%23%20pour%20tester%20un%20port%20en%20particulier%0Anmap%20-p%2080%20ip_de_votre_serveur%0A%23%20Essayez%20%C3%A7a%20aussi%0Anmap%20-sN%20ip_de_votre_serveur%0Anmap%20-sS%20ip_de_votre_serveur%0Anmap%20-sI%20ip_de_votre_serveur »/]

Pour nessus, je vous laisse regarder par ici : http://doc.ubuntu-fr.org/nessus

J’en veux encore

Pour aller plus loin, je vous conseille un excellent document pdf issu des recommandations en terme de sécurité informatique de la NSA (vous savez l’organisation qui espionne tout le monde…).

Mais avant le lien quelques commentaires au sujet du documents :

  • Grosse paranoïa dans le pdf (ce sont des cas extrême de sécurité)
  • Tout n’est pas réalisable pour vous (restriction de votre hébergeur de serveur ; matériel incompatible (RAM avec correction d’erreur…, KVM..))
  • Le document est de 2011, certaines technologies ont évolué même si dans l’ensemble, c’est très solide
  • Est-il nécessaire d’aller si loin ? Pour une plateforme qui accueille des centaines d’utilisateurs peut-être mais pour un serveur dédié au web…

Le lien : https://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf

Second lien : http://olivieraj.free.fr/fr/linux/information/firewall/fw-03-04.html