Linux et la sécurité

La sécurité informatique est un problème extrêmement complexe, et de surcroît mal compris par une grande partie des intervenants. Des problèmes très différents sont recouverts par ce terme : protection contre les dommages et les sinistres informatiques (qu'ils soient accidentels ou malintentionnés), non-divulgation de données confidentielles, authentification d'un correspondant, isolation des différents utilisateurs d'un même système informatique etc.

Un cours d'une semaine serait nécessaire pour maîtriser tous les aspects de ce problème, même en se limitant à une seule plateforme. C'est pourquoi le présent support de cours consistera principalement en pointeurs pour obtenir plus d'informations.

1   Diffusion du présent document

Ce document appartient à IDEALX. Il est librement diffusable dans les termes de la Licence de Documentation Libre GNU (traduit de la GNU Free Documentation License).

2   Comment aborder le problème de la sécurité ?

2.1   « La sécurité est un processus, pas un produit » (Bruce Schneier)

Il n'est pas rare d'observer dans la presse informatique des publicités pour telle ou telle «solution» qui se vante de pouvoir «sécuriser» votre courrier électronique, ou vos accès à l'Internet, etc. Ces produits ne proposent qu'exceptionnellement un suivi gratuit (excepté pour les antivirus), et ne sont pour ainsi dire jamais accompagnés de documentation expliquant les risques qu'ils sont sensés couvrir. Leur interface utilisateur est simple, alors que la sécurité informatique est un domaine complexe. Leurs cryptosystèmes sont parfois couverts par le secret de la propriété industrielle, alors que d'excellents cryptosystèmes sont disponibles librement et ont fait l'objet d'une revue scientifique internationale.

De tels produits ne peuvent qu'inciter l'acheteur à la méfiance. Car dans l'état actuel de l'informatique, aucun logiciel ou matériel, quel que soit le soin avec lequel il est conçu, ne peut prétendre être exempt de bogues : cet état de fait durera tant que ce sont des humains qui programmeront les ordinateurs. Et plus le logiciel est complexe, plus il a des chances de contenir des bogues. Certaines de ces bogues, c'est fatal, concernent la sécurité ; c'est-à-dire qu'un attaquant rusé pourra se servir de ces bogues non pas simplement pour «planter» un logiciel, mais pour le détourner suffisamment de son rôle pour invalider la sécurité de telle partie d'un système informatique.

2.2   « Divulgation complète » contre « sécurité par obscurité »

Face à cette fatalité de la présence de bogues, deux attitudes sont possibles. La plus couramment adoptée par les marchands de sécurité est de protéger le plus possible les détails de leurs systèmes, afin que les bogues restent secret et que le pirate potentiel, à court d'information, ne puisse mener à bien son forfait.

L'histoire a montré les déboires de cette méthode, depuis le ver Internet de Morris en 1984 jusqu'aux allégations mensongères de sécurité de certaine société monopolistique de cette fin de siècle. L'information finit toujours par filtrer, que ce soit à la suite de divulgations accidentelles ou parce qu'un reverse engineering est pratiqué sur un exemplaire du logiciel. Ainsi, des trous de sécurité ont été trouvés sur la puce Skipjack, une proposition de standard pour l'encryptage des communications aux États-Unis dans les années 1980 bien que seule une implantation matérielle du protocole fut publiquement disponible ; ainsi, les codes de protection du DVD ont été cassés, etc. etc. Et lorsque l'information est disponible, plus rien ne peut l'endiguer : des milieux de la recherche scientifique, elle passe rapidement sur l'Internet où n'importe qui peut l'obtenir. Les outils de pénétration sont simplifiés et rendus utilisables par n'importe qui, tel par exemple le fameux BackOrifice pour Windows. Le secret, une fois que cela est arrivé (et cela arrive toujours) est alors pire que l'absence de protection puisqu'il empêche les utilisateurs légitimes de mettre à jour leur sécurité.

Sous Linux, l'ensemble des codes sources de tous les logiciels sensibles du point de vue de la sécurité sont publics. N'importe qui peut les lire et rechercher les bogues (et donc les failles de sécurité) à l'intérieur. Pourtant, la sécurité des logiciels libres est la meilleure de tous les systèmes d'exploitation publiquement disponibles. Cela découle en partie d'une meilleure conception initiale du système UNIX1, mais aussi, et surtout, du suivi quotidien dont bénéficie le logiciel.

Lorsqu'une bogue est découverte dans un logiciel Linux, elle est immédiatement publiée sur divers sites et des courriers électroniques sont envoyés à l'auteur du logiciel et aux mainteneurs des distributions. Lesdites personnes font alors de leur mieux pour réparer le problème et publier une mise à jour ; si bien qu'une solution est disponible pour l'administrateur réseau la plupart du temps en moins de cinq jours. Même pour une personne qui n'installe que les nouvelles versions de sa distribution tous les deux mois, les mises à jour de sécurité sont incorporées en temps et en heure. Le résultat est que même si il n'est malheureusement pas impossible d'attaquer un système Linux, c'est extrêmement difficile et cela l'est d'autant plus que l'administrateur de cette machine est consciencieux du point de vue de sa veille technologique de sécurité.

2.3   Différents types de sécurité pour différents types de risques

Évidemment, les équipements et les procédures de sécurité à mettre en oeuvre dépendent du contexte dans lequel est utilisé l'ordinateur. Inutile de passer des détecteurs d'intrusion pour un ordinateur portable qui ne se connecte jamais à aucun réseau... On peut grosso modo classifier les problèmes de sécurité sous Linux en quatre catégories, en fonction de la provenance et de la difficulté à parer le danger :

Les deux dernières classes de risque sont ce qu'un expert UNIX entend généralement par «sécurité». Ces deux classes se subdivisent à leur tour en de nombreux sous-problèmes, certains d'entre eux faisant appel à une branche très spéciale des mathématiques : la cryptographie. L'objet de ce cours est d'élucider les outils et les méthodes applicables pour réduire ces risques.

3   Les concepts de la sécurité sous Linux

3.1   L'appel système bind

L'appel système bind (à ne surtout pas confondre avec le Berkeley Internet Name Daemon, le serveur DNS de Linux) est celui que doit exécuter tout programme serveur afin de recevoir des données en provenance du réseau. Il prend deux paramètres liés à la sécurité : une adresse IP et un numéro de port.

L'adresse IP est optionnelle : il doit nécessairement s'agir de l'adresse d'une des interfaces réseau de l'ordinateur. Si elle est spécifiée, seules les requêtes réseau qui arrivent sur l'interface réseau seront honorées ; sinon la requête peut provenir de n'importe où. Cette fonctionalité peut servir à protéger un service interne (typiquement, le DNS) contre les accès depuis l'extérieur d'un réseau quand le programme serveur est installé sur une machine disposant de plusieurs interfaces réseau : si le fichier de configuration du démon le permet, il convient alors de ne le faire binder que sur l'interface interne.

Le numéro de port est bien entendu celui sur lequel doit s'installer le service. Les ports dont le numéro est compris entre 0 et 1023 sont dits privilégiés : seul root peut binder sur ces ports. Cette restriction était à l'origine conçue comme un adjuvant de la sécurité (un utilisateur lambda ne peut pas profiter du fait qu'un démon soit planté pour lui voler son port et démarrer un serveur bidon), mais elle présente un défaut majeur : certains démons réseau ont besoin des privilèges de root uniquement pour cette opération.

3.2   Le démon inetd

Le démon inetd est également appelé super-démon réseau, parce qu'il est chargé de lancer les autres services réseau. Au lieu de lancer autant de petits démons qu'il y a de services réseau à fournir sur une station Linux, un seul démon est lancé et il effectue l'appel bind sur tous les ports. Lorsqu'une connexion est reçue, le démon correspondant est lancé et il traite l'appel.

Le démon inetd résout de nombreux problèmes de sécurité, en particulier celui des ports privilégiés (il peut abaisser ses privilèges après avoir bindé, mais avant de lancer le sous-démon) et celui de la centralisation des procédures de sécurité (tous les services figurent dans le même fichier de configuration et de plus inetd peut généraliser facilement l'emploi des TCP wrappers). Cependant, certains services ont besoin que leur démon soit lancé en permanence et ne peuvent donc être lancés par inetd : c'est le cas notamment de SSH et Apache.

3.3   Les programmes setuidés

Sous UNIX, les programmes setuidés et setgidés sont des programmes disposant de privilèges étendus, attribués à l'aide de la commande chmod. Un programme setuidé gagne les droits du propriétaire du fichier binaire du programme, en plus de ceux de l'utilisateur appelant ; un programme setgidé gagne les droits du groupe à qui appartient le fichier binaire, en plus de ceux du groupe de l'utilisateur appelant. Ces processus sont protégés contre certaines classes d'interactions : en particulier, on ne peut pas utiliser un débogueur sur eux.

L'utilité d'un programme setuidé est d'établir une voie d'accès entre un utilisateur et le système : ainsi le programme passwd permet de modifier son mot de passe. Il est donc setuidé par root, ce qui lui permet d'ouvrir le fichier /etc/passwd en écriture. Cependant, il est bien évidemment impensable d'ouvrir le fichier /etc/passwd en écriture à tous ! Seul le programme passwd en a le droit, en exerçant les vérifications qui s'imposent.

Malheureusement, les programmes setuidés sont une source fréquente de trous de sécurité car c'est l'utilisateur lui-même qui les exécute. Il contrôle donc beaucoup trop de paramètres vitaux sur ce processus, ce qui permet à un pirate de le pousser à la faute d'un grand nombre de façons2. Il est beaucoup plus sûr d'instaurer une communication entre un démon privilégié et le processus de l'utilisateur via une socket de domaine UNIX, qui permet de lire l'identité de son correspondant dans la version 2.2 du noyau Linux.

En attendant, de (trop) nombreux programmes setuidés subsistent dans Linux. Leur code a reçu une revue exhaustive, mais il n'est pas exclu que de nouvelles façons d'exploiter indûment leurs privilèges soient découverts.

3.4   Les principes de l'échec bloquant et du moindre privilège

Le principe de l'échec bloquant est un critère de conception de systèmes sûrs. Une serrure à gâche électrique qui fonctionne en maintenant le pène engagé dans le chambranle à l'aide d'un électro-aimant alimenté électriquement est à échec non bloquant : si le courant est coupé, le pène rentre dans la porte,... qui s'ouvre. La bonne façon de concevoir cette serrure serait au contraire d'installer un ressort qui maintient le pène dans le chambranle, et l'électro-aimant ne s'activerait que pour ouvrir la porte : l'échec du système de sécurité (panne de courant) serait ainsi bloquant (porte fermée).

Les systèmes de sécurité doivent être conçus avec cette directive à l'esprit. En généralisant au maximum ce principe, on arrive à la maxime suivante : le cas par défaut d'un système d'accession à un privilège quelconque doit être le refus. Cette maxime est vraie pour les portes, pour les firewalls et (en tirant un peu les concepts par les cheveux) elle se traduit en administration UNIX par le principe du moindre privilège : un processus ne doit pas bénéficier de plus de privilège que sa tâche l'exige. C'est ainsi que le programme ps s'est vu sous Linux dépouiller de son privilège d'aller piocher dans la mémoire du noyau (le privilège kmem), car le système de fichiers /proc élimine ce besoin. Le moindre privilège veut donc que comme ps peut faire autrement (et bien que l'ancien mode d'accès persiste), il soit reprogrammé pour utiliser la nouvelle interface non privilégiée.

3.5   La notion d'attaque discrète

Un ordinateur se distingue de toute autre sorte de machine par la disproportion entre la quantité d'informations qu'on peut observer à tout instant sur ses périphériques, et la quantité d'état qu'elle contient à l'intérieur d'elle-même. En ce qui nous concerne, rien ne permet de différencier un vrai shell d'un programme en C qui affiche un dièse (du moins tant qu'on ne touche pas au clavier) ; rien ne permet non plus de différencier un système de mots de passe planté d'un programme pirate qui répond systématiquement «login incorrect» (tout en stockant les mots de passe tapés pour en référer à son autorité de tutelle). Et, encore plus grave, rien ne permet de distinguer un ordinateur piraté dans lequel le pirate a pris soin d'effacer les fichiers d'audit d'un ordinateur normal.

Il résulte de tout cela que la confiance accordée aux éléments logiciels d'un ordinateur qui ne sont pas inscrits en ROM doit disparaître totalement dès qu'on a de bonnes raisons de supposer qu'il a été piraté. Il existe, sur les sites pirates, des modules du noyau Linux qui ont le même effet que les virus dits stealth : ils permettent à un fichier binaire de ne pas avoir le même contenu suivant qu'il est lu ou exécuté. Ce qui fait que tripwire, voyant l'apparence normale du binaire, ne détecte pas qu'il s'agit d'une porte de derrière. Bien évidemment, un tel module prend également soin de se radier lui-même de la liste des modules chargés par le noyau...

Un pirate qui réalise cette attaque peut s'attribuer un contrôle total et invisible de la machine : cela s'appelle une attaque discrète. La méthode à suivre pour réparer est la même que celle qui sert à éradiquer un virus de bootsector sous DOS : il faut amorcer à partir d'une disquette sûre (celle créée par tripwire, par exemple). Et comme l'hypothèse d'une attaque discrète ne peut jamais être exclue a priori, cette manoeuvre doit s'exécuter à chaque fois qu'une intrusion est soupçonnée !

4   L es outils de la sécurité

4.1   Sauvegardes

Il est très facile de faire des sauvegardes sous UNIX, nous ne nous étendrons pas sur ce point. Qu'il suffise de rappeler quelques utilitaires : find permet de rechercher sur tout le disque dur des fichiers possédant certaines caractéristiques (par exemple, par nom, ou par date de modification) ; et cpio permet d'en faire une archive. Ces deux programmes peuvent facilement être pipelinés, comme dans la commande suivante qui sauvegarde tout le contenu du répertoire /etc au format standard .tar.gz (également appelé .tgz) :

find /etc -print0 | cpio --create -0 -H ustar | gzip -c > fichiers-de-config.tar.gz

4.2   Sécurisation des accès réseau

Il s'agit de l'étape la plus importante de l'activité de l'expert en sécurité : on distingue quatre phases.

  1. auditer son réseau pour rechercher les problèmes de sécurité :

    1. les services privatifs qui ne doivent pas être accessibles de l'extérieur (exemple type : une imprimante en réseau). TCP/IP étant un protocole qui permet de faire abstraction de la différence entre le réseau local et le reste du monde, cette étape est importante et le vendeur du système d'exploitation ne peut pas la faire à la place de l'administrateur.
    2. Les protocoles intrinsèquement non sûrs. certains protocoles réseau véhiculent des mots de passe en clair (exemples typiques : telnet et ftp), d'autres utilisent l'adresse IP de l'appelant comme moyen d'authentification, ce qui est notoirement faible (rlogin, rsh, NIS et NFS). En fonction des besoins de sécurité du site, ces protocoles devront être réservés à certaines machines ou bien carrément supprimés3 .
    3. Les vulnérabilités des logiciels réseau, c'est-à-dire les bogues qui sont exploitables par un attaquant malintentionné. Il convient de différencier celles qui sont accessibles depuis l'extérieur du réseau de celles qui ne le sont pas. Dans de nombreux cas, en effet, le scénario de sécurité est du type «nous contre eux» et un certain niveau de confiance peut être accordé aux ordinateurs du réseau interne.
  2. Remédier aux défauts constatés en installant des correctifs pour les vulnérabilités (soit des mises à jour de logiciel, soit des modifications de configuration par défaut) et des procédures de filtrage adéquates pour les services privés.
  3. Mettre en place un système de surveillance qui allie récupération des alertes, détection précoce des intrusions et surveillance des machines et des réseaux ainsi sécurisées.

4.2.1   Repérage des services et des vulnérabilités

Il n'est pas toujours facile (ni même possible) de lire toutes les documentations de tous les ordinateurs du réseau pour savoir quels services ils hébergent. Un outil automatique de détection (appelé un scanner dans le jargon de sécurité) est indispensable au-delà de quelques postes. On trouve dans cette catégorie les logiciels suivants, librement téléchargeables (cf. les pointeurs) :

4.2.2   Suppression ou filtrage de services

Pour supprimer un service IP ou le restreindre à certaines classes d'adresses, plusieurs méthodes sont disponibles :

4.2.3   Outils d'audit et d'alerte

Sauvegarder les fichiers d'audit
La première priorité de l'administrateur système est d'empêcher l'attaquant de réussir une attaque discrète : pour cela, les traces d'audit produites par les machines à observer doivent être mises en lieu sûr. Il faut savoir qu'il existe des root-kits qui permettent à l'attaquant de confirmer ses privilèges en... huit secondes ! La méthode qui consiste à récupérer les traces d'audit par un transfert périodique est donc inefficace.

Le démon syslogd de Linux peut être configuré pour envoyer par UDP une copie de tous les messages qu'il reçoit à un hôte distant. Cette fonctionalité doit être mise à profit au moins pour le firewall, qui peut typiquement envoyer tous ses messages sur la machine de l'administrateur système. Et il ne faut surtout pas s'arrêter là : si toutes les traces d'audit sont rassemblées dans le même flux, le repérage d'attaques concernant tout le réseau (comme les scans) est grandement facilité. Cela constitue un bon début de système d'alerte précoce... À condition que les fichiers en question soit lus ! C'est pourquoi il est conseillé à l'administrateur de rechercher les messages correspondant à des situations qui ne doivent pas normalement arriver (typiquement, la mort d'un démon) et de conserver la trace d'audit complète pour une investigation plus poussée en cas de besoin.

Se protéger contre les chevaux de Troie et les portes de derrière
Le logiciel tripwire doit être installé sur les serveurs à protéger. Il fonctionne en stockant en lieu sûr une somme de contrôle cryptographique pour chaque binaire du système. L'administrateur peut ainsi détecter si des programmes ont été modifiés. Il nécessite l'arrêt du serveur et son redémarrage depuis une disquette d'amorçage sûre, pour contrer le risque que tripwire ne soit trompé par une attaque discrète réussie (cf. paragraphe 3.5).

5   Les habitudes de la sécurité

5.1   Garder une longueur d'avance

Comme on l'a vu au paragraphe 2.2, la sécurité informatique moderne est essentiellement une affaire de course à l'information : il faut en savoir suffisamment pour boucher les trous avant que les outils d'exploitation de ce trou ne soient conçus, testés et distribués (ce qui, heureusement, prend plus de temps que de couper un service). Et même lorsqu'on gagne cette course, pas question de s'endormir sur ses lauriers ! Heureusement, des supporters efficaces sont à la disposition de l'administrateur système consciencieux (cf. les pointeurs à la fin de ce cours) :

5.2   Savoir détecter et réparer les intrusions

Si une attaque réussie est détectée ou suspectée sur un des serveurs, toute confiance doit immédiatement lui être retirée. Cette machine ne doit plus fournir de services critiques pour la sécurité du réseau, et elle doit être éteinte le plus tôt possible (éventuellement à l'aide du gros bouton rouge). Son disque doit être monté dans une autre machine afin de récupérer ce qui doit l'être (il ne faut surtout pas la faire redémarrer avec son propre disque !); elle ne devra pas être redémarrée tant que l'administrateur ne s'est pas assuré (à l'aide de tripwire) qu'elle ne contient pas de portes de derrière ou de chevaux de Troie. Au besoin, une copie de sauvegarde sera utile pour remplacer les programmes «troyanisés» par leurs originaux.

6   Les outils cryptographiques

Étant donné la facilité avec laquelle on peut falsifier son adresse IP, ou bien espionner des mots de passe, les informations qu'on trouve dans un paquet IP standard qui ont trait à la sécurité ne sont pas dignes de confiance dans le cas général. Une seule solution existe : la cryptographie, qui permet de signer (pour authentifier la provenance des données) et de chiffrer (pour les soustraire aux oreilles indiscrètes).

Malheureusement, la cryptographie est considérée comme arme de guerre par certains pays, dont le nôtre (nonobstant les assouplissements en cours dans la législation). En la matière, toutefois, nécessité fait loi4 : le site ftp.zedz.net permet de se procurer les logiciels cryptographiques de Linux. On y trouve notamment :

7   Et les virus ?

Cela peut paraître incroyable, mais il n'y a pas de virus sous Linux ! Cela tient bien sûr à sa philosophie de conception : la sécurité fait partie du noyau du système et aussi de la mentalité des programmeurs. Pas question, sous Linux, de programmer un logiciel de traitement du courrier électronique qui interpréterait des macrocommandes dans les pièces jointes... Et pour ce qui est des virus plus classiques, qui s'attaquent au système d'exploitation et aux binaires des programmes, il n'est pas tout à fait inenvisageable d'en fabriquer ; cependant l'avis de l'auteur est que la compétence nécessaire pour réaliser cela est hors de portée d'un programme automatique (et de surcroît minuscule) comme un virus. L'infodiversité dans le monde Linux est suffisamment importante pour qu'un virus ne puisse pas trouver de niche écologique suffisamment uniforme entre différentes distributions, différentes versions d'un même programme, etc. Et c'est la vraie raison pour laquelle il n'y a pour l'instant qu'un seul virus Linux, qui exploite une vulnérabilité de confiance de rsh à présent presque totalement éradiquée !

8   Pointeurs utiles

La sécurité informatique n'est pas, trois fois hélas ! une préoccupation hexagonale (du moins pour les entreprises civiles). Il s'ensuit que tous les liens qui sont présentés ici pointent vers des sites anglophones... Heureusement, quelques livres traduits sont disponibles sur le sujet ; cependant, en raison des délais de publication et de traduction, les informations qu'ils contiennent sont souvent un peu vieillies. Ils doivent donc être considérés plutôt comme des manuels d'initiation que comme du matériel d'expert.


1
Encore que... UNIX possède bien une protection des processus les uns contre les autres, mais son système de droits est simpliste (il a été rajouté la première version) et de nombreux protocoles font passer des informations vitales en clair sur le réseau (survivance d'un temps où l'administrateur d'un site avait root sur toutes les machines de son réseau, lequel n'avait donc pas besoin d'être sécurisé tant le prix d'un ordinateur pirate était élevé).
2
Voir à ce sujet la secure UNIX programming FAQ, citée en annexe.
3
Pour chacun d'eux, des protocoles sécurisés par la cryptographie existent, cf. le paragraphe 6.
4
La véritable loi prévoit que l'utilisation de cryptographie n'est pas en soi passible de peine : il s'agit uniquement d'un facteur aggravant en cas d'activités délictueuses avérées. Pour citer un membre de la DST qui tient à conserver l'anonymat, «si tu installes SSH sur ton ordinateur la DST s'en fout !»
5
http://www.securityfocus.comforumsbugtraqfaq.html
6
http://phrack.infonexus.com/archive.html
7
http://phrack.infonexus.com/search.phtml?view&article=p49-14
8
http://www.redhat.com/support/errata/rh62-errata-security.html
9
http://www.cert.org
10
http://www.whitefang.comsupsecure-faq.html
11
http://www.insecure.org/nmap/
12
http://www.nessus.org
13
http://www.porcupine.org/satan
14
ftp://ftp.cert.org/pub/tools/cops/
15
http://ciac.llnl.gov/ciac/ToolsUnixSysMon.html
16
http://www.cse.ogi.eduDISCprojectsimmunixStackGuard/
17
http://www.counterpane.com/crypto-gram.html

Ce document a été traduit de LATEX par HEVEA.