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 UNIX¹, 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 :

Protection contre les maladresses des utilisateurs : c'est le cas le plus simple et cette fonction est le plus souvent déjà réalisée par le système d'exploitation. On trouve par exemple les copies de sauvegarde des éditeurs, les fichiers «en lecture seule» ou «protégés» par mot de passe, etc. Une bonne politique de sauvegarde résout de nombreux problèmes (cf. ci-dessous) ; cependant elle ne saurait suffire. Sur un système multi-utilisateurs comme Linux, il serait inconcevable qu'une erreur de manipulation permette d'effacer le fichier de quelqu'un d'autre ! Mais le système des droits des utilisateurs les protège de façon extrêmement satisfaisante, même sans aucune intervention ni de leur part ni de celle de l'administrateur.
Protection contre les pannes : la sécurité, dans ce cas, consiste à se protéger contre les pertes de données consécutives à une panne matérielle ou logicielle. Une sauvegarde régulière, efficace et testée (avec des mises en scène de sinistre) s'impose pour tout système, du plus simple au plus complexe.
Il est à noter ici que haute disponibilité n'est pas sauvegarde. On ne peut se contenter de la garantie apportée par un matériel redondant (ex : des disques RAID) pour la sécurité des données : en effet, le logiciel lui-même n'est pas «redondant». Lorsqu'un programme devient fou et efface tous les fichiers dont il a la charge, le matériel redondant reproduira l'opération sans broncher... Une véritable copie, si possible archivée sur un autre site, est alors indispensable.
Protection contre la malveillance externe : il s'agit ici de contrecarrer ceux qu'on appelle communément les pirates informatiques, qui tentent (pour diverses raisons) de prendre possession des ressources de votre ordinateur ou de l'empêcher de fonctionner normalement. Rentrent dans cette catégorie les attaques par réseau, les virus et chevaux de troie, etc. Linux est remarquablement bien protégé contre ce genre de problèmes (voir notamment le paragraphe 7) : tous ses services réseau non publics sont dûment protégés par mot de passe, et le cloisonnement des différents comptes système entre eux limite les dégâts en cas d'intrusion réussie sur l'un des services. De plus, il offre des fonctions sophistiquées de firewall ou de réseau privé virtuel (VPN) pour protéger également d'autres ordinateurs.
Protection contre la malveillance de la part d'utilisateurs accrédités : c'est là malheureusement le talon d'Achille du système UNIX. N'importe quel utilisateur ayant un accès shell sur une machine Linux dans sa configuration par défaut peut facilement mettre le système à genoux en consommant toutes ses ressources. De plus, une fonction très discutable d'UNIX pour la délégation des privilèges (les programmes setuidés) sont une source fréquente de trous de sécurité, de même qu'une certaine classe de faiblesses des programmes en C (les débordements de tampon).
Il reste toutefois que tout système UNIX est muni de fonctions complètes d'émission de traces d'audit (logs). Si elles sont correctement exploitées, ces traces permettent de repérer l'utilisateur fautif... Et de lui sucrer son compte sans autre forme de procès, après s'être assuré qu'il n'a pas tenté de confirmer des privilèges indûment acquis en installant une «porte de derrière».

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çons². 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.

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és³ .
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.
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.
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) :

nmap est un outil d'analyse réseau simple mais très puissant et rapide. Il liste les ports TCP et/ou UDP ouverts sur une ou plusieurs machines, ce qui permet de repérer les services accessibles ; il détecte également le type de système d'exploitation de l'hôte distant, en repérant la façon dont il réagit à certaines séquences de paquets inhabituelles.
Lorsqu'un port est ouvert, le client du protocole correspondant peut utilement être pointé vers lui pour savoir de quoi il retourne. On citera notamment smbclient pour l'analyse des partages exportés par des machines Windows, rpcinfo, showmount et ypcat pour explorer les protocoles NIS et NFS (tous deux notoirement non sûrs), et surtout netcat qui permet de réaliser des connexions à volonté en TCP ou en UDP, typiquement pour taper interactivement du texte vers les protocoles Internet usuels (POP, IMAP, SMTP, HTTP, FTP etc). telnet peut remplir le même rôle que netcat, mais uniquement pour TCP.
nessus est un logiciel complet de recherche de vulnérabilités en réseau. Il émet un rapport complet et facile à lire, dispose d'une interface graphique et de plus sa base de vulnérabilités est fréquemment mise à jour sur le site WWW qui l'héberge.

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 :

Pour supprimer un service, il suffit le plus souvent d'effacer son paquetage et de tuer le démon correspondant. Si le démon est lancé par le super-démon inetd, il faut commenter son entrée dans /etc/inetd.conf puis relancer inetd en lui envoyant un signal HUP.
Les TCP wrappers de Wietse Venema sont installés par défaut sur toutes les distributions Linux. Ils permettent d'interdire certaines adresses IP pour certains services, et également de signaler toutes les connexions effectuées à certains ports ; leurs fichiers de configuration sont hosts.allow et hosts.deny. Tous les programmes lancés par inetd bénéficient des TCP wrappers, et de nombreux autres (Samba, SSH, etc.) peuvent soit être configurés pour lire également ces fichiers, soient disposent de possibilités de filtrage et de rapport similaires (tels que sendmail ou bien le démon NFS).
La voie royale en matière de filtrage IP est bien entendu l'installation d'un firewall. À l'inverse des TCP wrappers, après installation d'un tel dispositif l'attaquant opérant depuis une adresse interdite ne pourra même pas savoir si le port correspondant est desservi ou pas ! Cependant, la configuration d'un firewall est une tâche ardue. On consultera avec profit l'IPCHAINS-HOWTO, traduit en français.

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) :

La liste de diffusion Bugtraq est l'élément incontournable d'information de l'administrateur système de sécurité. Non seulement c'est le canal d'alerte le plus rapide, mais de plus la lecture de cette liste de très haut niveau technique permet de se constituer une véritable culture de sécurité (même si les débuts sont parfois difficiles !).
Les sites WWW de sécurité : certains ont pour but d'avertir le consommateur (celui de RedHat et celui du CERT, notamment), d'autres... de faire peur aux vendeurs, en publiant des scripts d'exploitation de trous de sécurité qui sont restés inchangés pendant plusieurs mois ! Dans cette dernière catégorie, on citera notamment www.rootshell.com.

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 loi⁴ : le site ftp.zedz.net permet de se procurer les logiciels cryptographiques de Linux. On y trouve notamment :

ssh, un remplacement pour rsh et rcp avec les mêmes fonctionalités mais protégés par un système cryptographique fort. Ils permettent les mêmes fonctionalités que rsh ou telnet (prise de contrôle à distance) et rcp ou ftp (copie de fichiers par réseau), avec des avantages supplémentaires : transmission automatique des connexions X-Window, ou tunnels pour des protocoles TCP non sûrs (on peut par exemple s'en servir pour télécharger son courrier électronique via POP).
stunnel, une application SSL qui permet de transformer un service Linux non sûr en service sûr en trois coups de cuiller à pot. Comme il utilise le standard SSL, il est immédiatement compatible avec Netscape ce qui permet de sécuriser la réception de courrier électronique par POP ou IMAP.
pgp, sans doute le logiciel de cryptographie le mieux connu, permet de crypter son courrier électronique. Sa documentation constitue une bonne introduction aux concepts de la cryptographie à clef publique.
CIPE et FreeS/WAN sont deux logiciels de sécurité IP (cryptographie des paquets IP devant transiter sur un réseau non sûr). CIPE est beaucoup plus simple, mais ne propose pas (pour l'instant) de protocoles cryptographiques en clef publique et n'est pas compatible avec les autres implémentations de la sécurité IP du marché.

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.

Bugtraq⁵ est une liste de diffusion de courrier électronique qui parle de sécurité au jour le jour sur le mode de la divulgation complète. Elle est une source indispensable d'informations pour l'administrateur réseau consciencieux, bien que son niveau technique soit assez élevé. Il s'agit d'une liste modérée, avec un volume d'une vingtaine de messages par jour (ou un seul gros message si on choisit le format digest).
Phrack⁶ est un magazine en ligne qui sombre vers le côté obscur de la Force, mais qui contient des articles techniques très pointus dont notamment l'excellent smashing the stack for fun and profit⁷ , qui explique en détail les tenants et les aboutissants des problèmes de sécurité par débordement de tampon.
La page des errata de RedHat⁸ liste les mises à jour de sécurité disponibles pour cette distribution. Il est souhaitable de la consulter fréquemment.
Le CERT⁹ (Computer Emergency Response Team) est une institution mise en place au lendemain de la crise provoquée par l'Internet Worm de Morris en 1984. Sa tactique est de ne divulguer les trous de sécurité qu'après suffisamment de temps pour que les vendeurs de logiciel aient le temps de le corriger, ce qui fait qu'il n'est pas toujours suffisamment réactif (et est en butte aux critique des membres de la liste Bugtraq).
La Secure UNIX programming FAQ¹⁰ est un excellent document de référence pour programmer des composants sécurisés dans un système UNIX.
nmap¹¹ est un excellent outil de portscanning qui offre entre autres extensions la fonction de détection du système d'exploitation distant par analyse de l'empreinte TCP/IP.
Nessus¹² , SATAN¹³ et COPS¹⁴ sont des logiciels de détection de failles de sécurité en réseau qu'il convient de faire tourner périodiquement. Nessus est le mieux maintenu et le plus à jour des trois ; la documentation de SATAN contient des descriptions en détail de vieux trous de sécurité de SunOS qui sont une excellente introduction aux problèmes de sécurité du système UNIX.
Le site du CIAC¹⁵ contient encore de nombreux utilitaires de sécurité, en particulier Tripwire (un utilitaire qui permet de détecter les intrusions sur un système UNIX puis de chasser les intrus).
Le site ftp.zedz.net contient une archive complète des logiciels de cryptographie sous Linux.
StackGuard¹⁶ est une extension du compilateur C qui permet de rendre les programmes C beaucoup plus résistants à une classe d'attaques connue sous le nom de débordements de tampon. Le site propose en téléchargement une distribution de Linux entièrement recompilée de cette façon.
Crypto-Gram¹⁷ est une lettre d'information généraliste sur la sécurité informatique et la cryptographie, d'une excellente tenue et accessible quel que soit le niveau du lecteur.
Applied Cryptography, Bruce Schneier. John Wiley & Sons, 1986. Traduit en français sour le titre Cryptographie appliquée - Algorithmes, protocoles et codes sources (traduction de Marc Vauclair). International Thomson Publishing France, 1995. Ce livre date un peu (notamment certains algorithmes cryptographiques sont moins dignes d'éloges aujourd'hui que l'auteur le laisse entendre), mais c'est une excellente couverture du domaine de la cryptographie.

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 L^AT_EX par H^EV^EA.