Protection des connexions frauduleuses

Dans le chapitre précédent, nous avons étudié les différents éléments composant le noyau qui pouvaient être secourus ou sécurisés, ainsi que des commandes permettant d’analyser l’écosystème lors d’une initialisation d’ordinateur. En dehors des programmes réseau, que nous verrons dans les chapitres suivants, permettant de filtrer les flux TCP/IP, nous allons chercher ici à détailler les outils rendant la sécurité d’un serveur plus efficiente. Nous allons commencer par les programmes effectuant les détections de tentatives d’accès en échec. En effet, cela peut représenter une menace lorsqu’il s’agit d’un pirate ou d’un hacker. Lorsqu’une personne s’authentifie auprès d’un serveur de type GNU/Linux, le mécanisme Pluggable Authentication Modules (aussi appelé PAM) permet de savoir s’il s’agit d’une tentative de fraude pour se glisser à l’insu de l’administrateur système, ou s’il s’agit d’une erreur de frappe. Il existe, parmi les nombreux outils de détection, un utilitaire particulier développé en Python permettant d’analyser des fichiers de logs et de déclencher des actions, en cas de détection de certains critères considérés alors comme suspects.

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 :

le nom du fichier de trace à analyser
le filtre à appliquer...

Protection contre les rootkits

Nous venons de voir comment se protéger d’attaques interactives de type déni de service ou force brute. Mais qu’en est-il des rootkits ? Par définition, un rootkit est un ensemble de techniques mises en œuvre par un ou plusieurs logiciels dissimulés, dont le but est d’obtenir et de pérenniser un accès de façon non autorisé, sur un ordinateur (ou un ensemble de machines), tout en restant dissimulé. On rencontre aussi l’expression outil de dissimulation d’activité ou maliciel furtif, ou encore simplement kit. De plus, le terme peut tout aussi bien désigner la technique de dissimulation ou l’ensemble particulier d’objets informatiques permettant ce genre d’exploit. La furtivité est généralement assurée par plusieurs systèmes de dissimulation tels que :

effacement de traces
masquage d’activité
dissimulation des communications

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.

La plupart des rootkits servent à installer des logiciels malveillants sur les machines dont l’accès a été obtenu. Mais certains fournisseurs de matériels informatiques s’en servent pour s’assurer du respect des conditions d’utilisation de l’équipement ou du produit, par leurs clients.

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

soit la mise à disposition de ressources système : temps CPU, connexions réseau, calculs…
soit l’espionnage des données stockées ou en transit sur l’équipement concerné.

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...

Protection des fichiers critiques

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 :

/boot : contenant le matériel de démarrage
/etc : contenant les fichiers de configuration
/bin : contenant les binaires courants
/sbin : contenant les binaires purement système
/var/log : contenant les journaux de traces
/etc/init.d : contenant les scripts d’arrêt et redémarrage du système
/lib : contenant les bibliothèques système
/usr : contenant les répertoires utilisateur

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...

Protection des ports de service

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 :

Les ports de 0 à 1 023 (aussi appelés well known ports) sont contrôlés et assignés par l’IANA (Internet Assigned Numbers Authority).
Les ports de 1 024 à 49 151 (appelés registered ports) représentent les ports enregistrés.
Les ports de 49 152 à 65 535 représentent les ports dynamiques ou privés.

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...

Protection des accès

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 :

Protection du BIOS de la machine.
Protection du système de démarrage (grub en général).
Sécurisation du noyau (mécanismes internes et recompilation des fonctionnalités minimales).
Chiffrement de la (ou des) partition(s) critique(s).
Utilisation du système LUKS ou encfs.
Mise en œuvre de gestion de confinement fail2ban.
Détection de rootkit grâce à rkhunter.
Activation de systèmes HIDS tels que aide ou tripwire.
Gestion d’une politique d’accès aux ports de services via portsentry.

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...

Protection des journaux

Sur nombre de systèmes GNU/Linux, les applications ou logiciels installés sont censés laisser des traces au sein des fichiers de journalisation. Le répertoire /var/log centralise la plupart du temps ces journaux de logs. En complément de la détection de failles, il est fortement conseillé d’installer un programme permettant de centraliser et d’exploiter l’ensemble de ces journaux de traces des différents serveurs au sein de l’infrastructure. Avant d’en arriver à une concentration complète de la totalité des journaux de logs en un seul point ou sur un seul serveur (comme le propose l’utilisation d’un SIEM que l’on verra ultérieurement), il faut commencer par se focaliser sur la constitution d’un rapport quotidien, regroupant les différentes traces applicatives où doivent figurer alors les tentatives de connexion, l’espace disponible utilisé, ainsi que les différentes erreurs remontées par le noyau. Cela revient à faire de la surveillance au niveau de ces fichiers.

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.

En fait, le daemon des journaux de traces syslogd a été remplacé par rsyslogd. Son fichier de configuration rsyslog.conf se trouve dans le répertoire /etc. Mais il implémente également syslog afin de conserver la compatibilité des outils antérieurs.

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 :