Outils de base

1. Utilisation de fail2ban

L’outil fail2ban peut permettre l’envoi d’un message à destination de l’administrateur ou la mise en place de règles de sécurité, intégrées au pare-feu local : iptables. L’outil en lui-même est très modulaire et peut ainsi scruter différents types de protocoles réseau : ssh, ftp, http, smtp… Il se base sur un système de confinement (ou d’emprisonnement, aussi appelé jail en anglais) que l’on peut facilement définir, activer ou désactiver à l’aide d’un simple fichier de configuration placé, par défaut, dans le répertoire /etc/fail2ban/jail.conf. Une prison est donc composée des éléments suivants :

1. Définition d’un rootkit

Un rootkit peut s’installer depuis un autre programme, au travers d’une bibliothèque ou du noyau lui-même. Certains arrivent même à modifier un hyperviseur, fonctionnant au-dessus des systèmes, voire même le firmware (ou micrologiciel) intégré au matériel sous-jacent.

Du point de vue de l’attaquant, l’intérêt d’un rootkit est de permettre :

Il peut arriver que la machine cible ne soit qu’un rebond ou un intermédiaire afin que l’attaquant puisse atteindre sa véritable cible. Les rootkits sont classifiés parmi les logiciels les plus malveillants (même si ce n’est pas toujours le cas). Ils peuvent utiliser des techniques virales pour se transmettre...

1. Comment évaluer la criticité ?

Tous les fichiers d’un système d’exploitation, comme GNU/Linux, n’ont pas tous le même niveau de criticité. Certains peuvent empêcher l’ensemble du système de fonctionner, s’ils n’étaient pas présents. D’autres, au contraire, peuvent disparaître sans poser de problème. On peut donc se poser la question du comment déterminer la criticité des fichiers d’un système, et surtout, comment les protéger ? Un premier élément de réponse pourrait être de toujours garder un œil sur les répertoires purement système de la machine :

Toutefois, il faut ensuite traiter au cas par cas les différentes possibilités, au gré des circonstances rencontrées. En règle générale, pour un serveur GNU/Linux, les répertoires mentionnés ci-dessus suffisent amplement à la sécurisation du contenu du système. Une fois ce constat effectué, il faut se demander comment on peut procéder pour sécuriser l’ensemble de ces dossiers. L’approche la plus courante est de mettre en œuvre un outil de type HIDS, mentionné déjà dans les chapitres précédents. Nous allons ici utiliser l’outil AIDE (Advanced Intrusion Detection Environment).

2. L’utilitaire AIDE

Le package aide fait partie des dépôts officiels Debian et peut donc facilement s’installer :

# apt-egt install aide
 

L’outil présente l’avantage de supporter les algorithmes de hachage les plus variés : md5, sha1, rmd160, tiger, crc32, sha256, sha512 et whirlpool. On peut ainsi facilement surveiller également les attributs des fichiers sous-jacents aux répertoires...

1. Qu’est-ce qu’un port de service ?

Afin de permettre aux différents clients d’un serveur de se connecter, des numéros de ports logiciels ont été définis au sein d’un fichier de référence, appelé /etc/services (pour des systèmes GNU/Linux). Il existe ainsi des milliers de ports, codés sur 16 bits (c’est-à-dire exactement 65 536 possibilités), ayant chacun une affectation spécifique afin d’aider à la configuration des réseaux ainsi constitués. Par définition, la combinaison adresse IP et numéro de port est appelée socket. La RFC1700 décrit la désignation des numéros de port. Généralement, la répartition s’effectue de la façon suivante :

N’importe quel ordinateur que l’on contacte pour ses services tels que ftp, ssh, telnet, etc. possède des numéros de ports fixes, auxquels l’administrateur réseau associe des services. Les ports d’un serveur sont donc généralement compris entre 0 et 1 023. Côté client, le port est choisi aléatoirement, parmi ceux disponibles sur le système d’exploitation local. Les ports du client ne devraient jamais être compris entre 0 et 1 023, cet intervalle de valeurs étant réservé pour les ports des services du système.

Nous pouvons donc dire qu’un port de service est un point d’entrée à un service, sur un équipement (ordinateur, poste de travail, portable), connecté à un réseau et délivrant un service spécifique : service web, service d’annuaire, serveur de noms ou de messagerie. Ainsi, en se connectant à un serveur, on établit en réalité une connexion sur un point particulier, auquel est associé un service. Une même machine peut alors...

1. Comment définir un accès ?

Les accès à un serveur GNU/Linux s’effectuent par défaut via un mécanisme de session avec, le plus souvent, saisie de mot de passe. Lorsqu’un serveur fournit un ou plusieurs services, en accès libre, il est préférable de prendre quelques précautions quant à la qualité de ces accès, au niveau du système. Depuis la mise sous tension de la machine jusqu’à l’instant de la connexion effective du premier utilisateur, il existe toute une chaîne de points d’entrée où chaque maillon doit être sécurisé afin de ne pas compromettre la sécurité générale du serveur.

Les étapes, que nous avons déjà vues jusque-là, entre le moment de la mise sous tension et la connexion d’un utilisateur, se doivent d’être sécurisées au travers des différents mécanismes décrits précédemment :

La première des règles à suivre est celle consistant à respecter une politique de sécurité de l’entreprise et de positionner un mot de passe sécurisé et suffisamment fort, que ce soit pour n’importe quel utilisateur lambda ou même pour le super-utilisateur root. Les politiques courantes conseillent généralement un minimum de 10 caractères, sans triples répétitions, en utilisant des chiffres, des lettres, et des caractères spéciaux. Ces mots de passe doivent être régulièrement modifiés : généralement tous les 90 jours et ne doivent pas utiliser la même racine pour composer ledit...

1. Paramétrage des logs courants

Dans le cas où l’on ne dispose pas (encore) d’utilitaire de surveillance des journaux de traces, on peut cependant s’assurer de configurer correctement les logs standards. Il ne faut pas oublier que dans ces fichiers se trouvent un certain nombre d’informations cruciales qui seront la cible privilégiée des attaquants de tout poil. C’est le rôle du daemon rsyslogd de collecter les messages de services issus à la fois des applications du système et du noyau, et de les redistribuer vers les différents fichiers de traces situés dans /var/log.

Pour chaque message généré, le système lui associe un sous-système applicatif que l’on nomme « facility » parmi lesquelles on peut citer :