Ce document est soumis aux droits de copyright (c) 1998 - 2000 Kevin Fenzi et Dave Wreski

Les modifications depuis la version v2.0, 11 Juin 2002, sont (C)opyright 2000-2004 Mandriva.

Ce document est distribué selon les termes suivants :

Ce chapitre traite certains des principaux problèmes affectant la sécurité de GNU/Linux. La philosophie générale ainsi que les ressources réseau sont aussi abordées.

Un certain nombre d'autres HOWTOs débordent sur les questions de sécurité et ces documents ont été référencés chaque fois qu'ils s'y prêtaient.

Ce chapitre n'est pas destiné à recenser tous les trous de sécurité. Un grand nombre de nouvelles techniques sont sans arrêt utilisées. Ce chapitre vous apprendra où rechercher ce type d'information mise à jour, et donnera des méthodes générales pour empêcher de telles exactions d'avoir lieu.

Dans le monde en ébullition des communications mondiales de données, des connexions Internet abordables, et du développement de programmes accéléré, la sécurité devient une question de plus en plus importante. La sécurité est maintenant une nécessité de base, parce que l'informatique mondiale est intrinsèquement exposée au danger. Alors que vos données circulent d'un point A vers un point B sur Internet, par exemple, elles peuvent transiter par plusieurs autres points sur le trajet, donnant à d'autres la possibilité de les intercepter ou même de les modifier. Même d'autres utilisateurs sur votre système peuvent intentionnellement modifier vos données à votre insu. Les accès non autorisés à votre système peuvent êtres obtenus par des intrus, aussi appelés crackers, qui utilisent alors des techniques avancées pour se faire passer pour vous, vous voler de l'information, ou même vous empêcher d'accéder à vos propres ressources. Si vous vous demandez quelle est la différence entre un « hacker » et un « cracker », lisez le document How to Become a Hacker de Eric Raymond.

Il convient de garder à l'esprit qu'aucun système ne peut jamais être absolument sûr. Tout ce que vous pouvez faire, est de rendre la tâche de plus en plus difficile à quiconque tenterait de compromettre votre système. Pour l'utilisateur moyen de GNU/Linux, il suffit de peu pour garder le cracker à l'écart. Néanmoins, pour les utilisateurs GNU/Linux de renom (banques, compagnies de télécommunications, etc), beaucoup plus de travail est nécessaire.

Un autre facteur à prendre en compte est que plus votre système est sécurisé, plus votre sécurité devient intrusive. Vous devez décider un juste milieu, compromis entre la sécurité et la facilité d'utilisation. En fait, vous pourriez exiger que toute personne se connectant à votre système utilise un modem à retour d'appel (call-back) pour les rappeler à leur propre numéro de téléphone. Cela est plus sûr, mais si quelqu'un n'est pas chez lui, cela devient difficile pour lui de se connecter. Vous pouvez aussi configurer votre système GNU/Linux sans réseau ou connexion Internet, mais cela réduit son utilité.

Si vous êtes en charge d'un site de taille moyenne à grande, vous devriez établir une politique de sécurité faisant état du degré de sécurité requis pour votre site, et de quel outil d'audit est en place pour le contrôler. Vous pouvez trouver un exemple bien connu de politique de sécurité sur le site faqs.org. Il propose un modèle exhaustif pour établir un plan de sécurité pour votre société.

Avant d'essayer de sécuriser votre système, vous devriez déterminer de quel niveau de menace vous avez à vous protéger, quels risques vous pouvez ou ne pouvez pas prendre, et comme résultat, quel sera le degré de vulnérabilité de votre système. Vous devriez analyser votre système pour savoir ce que vous protégez, pourquoi vous le protégez, quelle est sa valeur, et qui est responsable pour vos données et autres biens.

Créez une politique simple, générique, que vos utilisateurs pourront aisément comprendre et suivre. Cela devrait protéger les données et l'intimité des utilisateurs. Certains aspects que vous pouvez aborder sont : Qui a accès au système (ma fiancée peut-elle utiliser mon compte ?) Qui est autorisé à installer des programmes sur le système, qui possède quelle donnée, récupération des catastrophes, et utilisation appropriée du système.

Une politique de sécurité généralement acceptée commence par la phrase

«  Ce qui n'est pas permis est interdit  »

Ceci signifie que, à moins que vous n'autorisiez l'accès à un service pour un utilisateur, cet utilisateur ne devrait pas utiliser ce service jusqu'à ce que vous l'y autorisiez. Assurez vous que les règles fonctionnent pour votre compte d'utilisateur normal. Vous dire « Ah, je n'arrive pas à résoudre ce problème de permissions, je vais le faire comme root » peut conduire à des trous de sécurité évidents et d'autres n'ayant pas encore été exploités.

RFC 1244 est un document décrivant comment créer votre propre politique de sécurité réseau.

RFC 1281 est un document qui décrit un exemple de politique de sécurité avec des descriptions détaillées de chaque étape.

Enfin, vous pourrez jeter un coup d'oeil à la bibliothèque COAST pour voir de quoi ont l'air de véritables politiques de sécurité.

Cette section va aborder plusieurs moyens grâce auxquels vous pourrez sécuriser les entités pour lesquelles vous avez travaillé dur : votre propre machine, vos données, vos utilisateurs, votre réseau, et même votre réputation. Qu'arriverait il à votre réputation si un intrus effaçait des données de vos utilisateurs ? Ou défigure votre site Web ? Ou publie le projet trimestriel de votre compagnie ? Si vous envisagez une installation réseau, il y a beaucoup de facteurs dont vous devez tenir compte avant d'ajouter une simple machine à votre réseau.

Même si vous avez un simple compte PPP, ou juste un petit site, cela ne signifie pas que les intrus se désintéresseront de votre système. Les grands sites célèbres ne sont pas les uniques cibles, beaucoup d'intrus veulent simplement pénétrer le plus de sites possibles, sans égard à leur taille. De plus, ils peuvent utiliser un trou de sécurité de votre site pour obtenir l'accès à d'autres sites auxquels vous êtes connectés.

Les intrus ont beaucoup de temps devant eux, et peuvent s'économiser de deviner comment vous avez bouché les trous, simplement en essayant toutes les possibilités. Il y a aussi plusieurs raisons pour lesquelles un intrus peut être intéressé par votre système, ce que nous traiterons plus tard.

Ce chapitre a été divisé en un certain nombre de sections. Elles couvrent plusieurs larges problèmes de sécurité. La première Section 4.3, « Sécurité physique », explique comment vous devez protéger votre machine physique de violations. La seconde, Section 4.4, « Sécurité locale », décrit comment protéger votre système de violations par des utilisateurs locaux. La troisième, Section 4.5, « Sécurité des fichiers et des systèmes de fichiers », vous enseigne comment configurer votre système de fichiers et les permissions sur les fichiers. La suivante, Section 4.6, « Sécurité des mots de passe et cryptage », traite des moyens de cryptage pour mieux sécuriser machines et réseaux. Section 4.7, « Sécurité du noyau » propose des options du noyau (kernel) que vous pouvez utiliser pour un système plus sûr. Section 4.8, « Sécurité réseau », décrit comment mieux sécuriser votre système GNU/Linux d'attaques réseau. Section 4.9, « Préparation de sécurité (avant de vous connecter) », vous informe de la préparation des machines avant leur connexion. Ensuite, Section 4.10, « Que faire, avant et pendant une effraction », conseille l'attitude à avoir lors d une intrusion en cours et comment détecter une intrusion récente. Dans Section 4.11, « Documents de base », quelques documents de base sur la sécurité sont recensés. La section Questions et Réponses Section 4.12, « Foire aux questions », répond à quelques questions fréquentes, et enfin une section Section 4.14, « Conclusion ».

Les deux points principaux à réaliser lors de la lecture de ce chapitre sont :

De nombreux boîtiers d'ordinateur proposent une option de « verrouillage ». Cela se présente généralement sous la forme d'une serrure sur l'avant du boîtier vous permettent de passer d'un état déverrouillé à verrouillé à l'aide d'une clé. Ce type de verrouillage peut empêcher quelqu'un de voler votre ordinateur, ou ouvrir le boîtier pour directement manipuler ou voler votre matériel. Il peut aussi parfois empêcher le redémarrage de la machine par une disquette ou autre.

Ces verrouillages de boîtier font différentes choses selon le support par la carte mère et la conception du boîtier. Sur beaucoup d'ordinateurs ils font en sorte que vous devez casser le boîtier pour pouvoir l'ouvrir. Sur d'autres, ils empêchent la connexion de nouveaux claviers ou souris. Consultez les caractéristiques de votre carte mère ou du boîtier pour plus de renseignements. Ils peuvent être parfois une caractéristique très utile, même si la serrure est parfois de très mauvaise qualité, et facile à forcer avec un passe-partout.

Certains boîtiers (particulièrement des SPARCs et macs) possèdent un anneau à l'arrière, de sorte que si vous y passez un câble l'attaquant devra couper le câble ou casser le boîtier pour pouvoir l'ouvrir. Y mettre un cadenas ou une chaîne peut avoir un bon effet dissuasif sur quelqu'un essayant de voler votre machine.

Le BIOS est le niveau logiciel le plus bas qui configure ou manipule votre matériel x86. LILO ou d'autres méthodes de boot GNU/Linux accèdent au BIOS pour déterminer comment démarrer votre machine GNU/Linux. Les autres architectures sur lesquelles GNU/Linux tourne ont des programmes similaires (OpenFirmware sur Mac et nouveaux Sun, Sun boot PROM, etc.). Vous pouvez utiliser votre BIOS pour empêcher les attaquants de redémarrer votre machine et y manipuler votre système GNU/Linux.

La plupart des BIOS de PC permettent la configuration d'un mot de passe. Cela ne garantit pas beaucoup de sécurité (le BIOS peut être réinitialisé, ou enlevé si quelqu'un a accès au boîtier), mais peut être une bonne dissuasion (c'est à dire que cela prendra du temps et laissera des traces d'effraction). De même, sur S/Linux (GNU/Linux pour SPARC(^tm)), votre EEPROM peut être configurée pour exiger un mot de passe de démarrage.Cela ralentira les attaquants potentiels.

Le mot de passe par défaut s'avère un autre risque lorsque vous faites confiance au mot de passe du BIOS pour sécuriser votre système. La plupart des fabricants de BIOS ne s'attendent pas à ce que les utilisateurs ouvrent leur ordinateur et déconnectent les batteries s'ils oublient leur mot de passe et ont muni leurs BIOS de mots de passe par défaut qui fonctionnent, nonobstant le mot de passe que vous avez choisi. Voici certains des mots de passe les plus communs :

j262
     AWARD_SW
     AWARD_PW
     lkwpeter
     Biostar
     AMI
     Award
     bios
     BIOS
     setup
     cmos
     AMI!SW1
     AMI?SW1
     password
     hewittrand
     shift + s y x z

J'ai testé un BIOS Award et AWARD_PW ont fonctionné. Ces mots de passe sont assez faciles à obtenir sur les sites Web des fabricants ou sur astalavista et en tant que tel, un mot de passe de BIOS ne peut pas être considéré comme une protection adéquate contre les attaquants informés.

Beaucoup de BIOS x86 vous permettent aussi de spécifier plusieurs autres bons paramètres de sécurité. Consultez le manuel de votre BIOS ou explorez le la prochaine fois que vous redémarrez. Par exemple, certains BIOS désactivent le démarrage depuis une disquette et d'autres demandent un mot de passe pour pouvoir accéder aux caractéristiques du BIOS.

	Note
	Si votre machine est un serveur, et vous configurez un mot de passe de démarrage, votre machine ne pourra pas redémarrer toute seule. Gardez à l'esprit que vous aurez besoin de vous déplacer et fournir le mot de passe en cas de coupure de courant.

Le PROM est le niveau logiciel le plus bas qui configure ou manipule votre matériel SPARC x86. LILO ou d'autres méthodes de boot GNU/Linux accèdent au PROM pour déterminer comment démarrer votre machine GNU/Linux. Les autres architectures sur lesquelles GNU/Linux tourne ont des programmes similaires (OpenFirmware sur Macs et nouveaux Suns,BIOS x86, etc...). Vous pouvez utiliser votre PROM pour empêcher les attaquants de redémarrer votre machine et y manipuler GNU/Linux.

OpenBoot est plus évolué qu'un BIOS de PC lorsqu'il s'agit de sécurité (consultez le « Installation Guide » sur la façon d'utiliser OpenBoot).

	Note
	Si votre machine est un serveur, et vous configurez un mot de passe de démarrage, votre machine ne pourra pas redémarrer toute seule. Gardez à l'esprit que vous aurez besoin de vous déplacer et fournir le mot de passe en cas de coupure de courant.

Gardez à l'esprit lorsque vous mettez en place tous ces mots de passe, que vous devez vous en souvenir ! Rappelez-vous aussi que ces mots de passe vont seulement ralentir un intrus déterminé. Ils ne vont pas empêcher quelqu'un de démarrer à partir d'une disquette et monter votre partition racine.

Si vous utilisez la sécurité en conjonction avec votre chargeur de démarrage, vous devriez aussi désactiver le démarrage depuis une disquette, ainsi que protéger l'accès au BIOS.

Si vous utilisez la sécurité en conjonction avec votre chargeur de démarrage, vous devriez aussi protéger l'accès au PROM.

	Note
	Une fois encore, si votre machine est un serveur, et vous configurez un mot de passe de démarrage, votre machine ne pourra pas redémarrer toute seule. Gardez à l'esprit que vous aurez besoin de vous déplacer et fournir le mot de passe en cas de coupure de courant.

password très_secret
      /boot/grub/menu2.lst

Si vous vous éloignez de votre machine de temps à autre, il est bon de « verrouiller » votre console afin que personne ne puisse manipuler ou regarder votre travail. Pour ce faire, vous pouvez utiliser les programmes xlock ou vlock.

xlock est un verrouilleur d'écran X;. Vous pouvez lancer xlock depuis n'importe quel terminal X, il verrouillera alors l'affichage et exigera un mot de passe pour pouvoir y retourner. La plupart des environnements graphiques proposent aussi cette option dans leurs menus respectifs.

vlock est un simple petit programme qui vous permet de verrouiller quelques unes ou toutes les consoles de votre machine GNU/Linux. vous pouvez bloquer juste celle que vous utilisez ou bien toutes. Si vous n'en bloquez qu'une, d'autres peuvent venir et utiliser la console ; ils ne seront simplement pas autorisés à utiliser votre console jusqu'à ce que vous la déverrouilliez.

Bien sûr, verrouiller votre console empêchera quelqu'un de falsifier votre travail, mais ne les empêchera pas de redémarrer la machine, et ainsi interrompre votre travail. Ça ne les empêche pas non plus d'accéder à votre machine depuis une autre et y faire des dégâts.

Plus important, cela n'empêche personne de quitter complètement X Window System et d'aller sur un prompt de console virtuelle normale, ou à la console (VC) depuis laquelle X (X11) a été démarré et la suspendre, obtenant ainsi vos privilèges. Pour cette raison, vous ne devriez utiliser cela que sous le contrôle de KDM (ou autre).

Si une webcam ou un microphone est relié à votre système, vous devriez analyser s'il est possible qu'un attaquant gagne l'accès à votre système par leur entremise. Lorsqu'ils ne sont pas utilisés, débrancher ou carrément enlever ces périphériques s'avère une option intelligente. Sinon, vous devriez lire la documentation et examiner tout logiciel qui pourrait donner accès à ces périphériques.

La première chose à toujours noter, est quand la machine est redémarrée. Du fait que GNU/Linux est un système d'exploitation stable et robuste, les seules fois où votre machine devrait redémarrer, est lorsque vous l'arrêtez pour des mises à jour majeure, changement de matériel, ou des actions de cet ordre. Si votre machine a redémarré sans votre intervention, cela pourrait être un signe qu'un intrus l'a violée. Beaucoup des manières de violer votre machines impliquent en effet le redémarrage ou l'arrêt de celle-ci.

Vérifier qu'il n'y a aucune trace d'effraction sur le boîtier et dans la zone de la machine. Bien que la plupart des intrus nettoient les traces de leur passage des logs, c'est une bonne idée de les vérifier et noter toute irrégularité.

C'est aussi une bonne idée de garder les données de logs en un endroit sûr, comme un serveur de logs dédié, à l'intérieur de votre réseau bien protégé. Lorsque une machine a été violée, les données de logs deviennent de peu d'utilité, car il est fort probable qu'ils aient aussi étés modifiés par l'intrus.

Le démon syslog peut être configuré pour envoyer automatiquement les données de logs vers un serveur syslog central, mais les données sont généralement envoyées en clair, permettant à un intrus de consulter les logs lors du transfert. Cela pourrait révéler des informations sur votre réseau qui ne devraient pas être dévoilées. Il y a des démons syslog disponibles qui cryptent les données lorsqu'elles sont envoyées.

Soyez aussi conscient que falsifier les messages de syslog est facile - avec un programme de craquage ayant été publié. syslog accepte même les entrées de logs réseau qui prétendent venir de l'hôte local sans même indiquer leur origine réelle.

Quelques points à vérifier dans vos logs :

Nous parlerons des données logs système dans le chapitre Section 4.9.5, « Gardez trace des données de journalisation du système ».

Vous devriez vous assurer de fournir aux comptes utilisateurs le strict minimum requis pour leur tâche. Si vous donnez un compte à votre fils (10 ans), vous voudrez peut-être qu'il puisse accéder à un traitement de textes et un programme de dessin, mais qu'il ne puisse pas effacer des données qui ne sont pas les siennes.

Plusieurs bonnes règles à suivre lorsque vous autorisez des gens à accéder à votre machine GNU/Linux :

Beaucoup de comptes d'utilisateurs locaux qui sont utilisés dans des effractions de sécurité n'ont pas été utilisés pendant des mois ou des années. Comme personne ne les utilise, ils sont des vecteurs d'attaque idéaux.

Le compte le plus sollicité sur votre machine est le compte root (super-utilisateur). Ce compte a l'autorité sur toute la machine, ce qui peut aussi inclure l'autorité sur d'autres machines du réseau. Rappelez vous que vous ne devriez utiliser le compte root que pour de très courtes tâches particulières, et être le plus souvent sous votre compte normal. Même de petites erreurs commises lorsque vous êtes connecté en tant que root peuvent causer des problèmes. Moins vous êtes connecté avec les privilèges de root, plus sûr ce sera.

Plusieurs astuces pour éviter de bousiller votre propre machine en tant que root :

Si vous avez absolument besoin d'autoriser quelqu'un (de préférence de toute confiance) à avoir un accès root sur votre machine, il y a un certain nombre d'outils qui peuvent vous y aider. sudo autorise les utilisateurs à accéder à un certain nombre de commandes comme root avec leur propre mot de passe. Cela devrait vous permettre ainsi de laisser un utilisateur éjecter et monter un support amovible, sans aucun autre privilège root. sudo garde aussi une trace de toutes les tentatives réussies ou non d'utilisation, vous permettant de savoir qui a utilisé quelle commande pour faire quoi. Pour cette raison sudo marche bien même à des endroits où certaines personnes ont des accès root, car il vous aide à suivre les changements apportés.

Bien que sudo puisse être utilisé pour donner à certains utilisateurs des privilèges pour effectuer certaines tâches, il présente quelques inconvénients. Il devrait être utilisé uniquement pour un ensemble de tâches limitées, comme redémarrer un serveur ou ajouter de nouveaux utilisateurs. Tout programme offrant une fuite vers un shell donnera l'accès root à un utilisateur l'invoquant depuis sudo. Cela inclut la plupart des éditeurs, par exemple. De même, un programme aussi inoffensif que /bin/cat peut être utilisé pour écraser des fichiers, ce qui pourrait être utilisé pour exploiter root. Envisagez sudo comme un moyen de responsabilisation, mais n'espérez pas qu'il remplace l'utilisateur root tout en étant sûr.

La commande umask peut être utilisée pour connaître le mode de création des fichiers par défaut sur votre système. C'est le complément octal du mode du fichier en question. Si les fichiers sont créés sans égard à leurs permissions, l'utilisateur pourrait donner des permissions en lecture ou en écriture par inadvertance à quelqu'un qui ne devrait pas avoir ces permissions. Généralement, les paramètres umask sont 022, 027, ou 077 (qui est le plus restrictif). Normalement, le umask est fixé dans /etc/profile, de sorte qu'il s'applique à tous les utilisateurs du système. Le masque de création de fichiers peut être calculé en soustrayant la valeur souhaitée de 777. En d'autres termes, un umask de 777 implique que les fichiers nouvellement créés contiennent des permissions sans lecture, ni écriture, ni exécution pour tout le monde. Un masque de 666 implique que les fichiers nouvellement créés ont un masque de 111. Par exemple, vous pourriez avoir une ligne comme celle-ci :

# Fixer le umask utilisateur
      par défaut umask 033

Assurez-vous d'utiliser un umask pour root's de 077, qui interdira lecture, écriture, et exécution pour les autres utilisateurs a moins que vous ne changiez cela explicitement avec la commande chmod. Dans ce cas, les répertoires nouvellement créés devraient avoir des permissions de 744, obtenues en soustrayant 033 de 777. Les fichiers nouvellement créés avec un umask de 033 devraient avoir des permissions de 644.

	Note
	Pour Mandriva Linux, il est juste nécessaire d'utiliser un umask de 002. Cela est dû au fait que la configuration de base utilise un groupe par utilisateur.

Il est important de vous assurer que vos fichiers système ne sont pas ouverts à des modifications accidentelles des utilisateurs et des groupes qui ne devraient pas faire de maintenance système.

UNIX différencie le contrôle d'accès aux fichiers et répertoire selon trois critères : propriétaire, groupe, et autres. Il y a toujours un seul propriétaire, un nombre quelconque de membres du groupe et tous les autres.

Une explication rapide des permissions sous UNIX :

Propriété – Quels utilisateurs et groupes ont le contrôle des paramètres de permission du noeud et du parent du noeud

Permissions – Bits susceptibles d'être mis ou enlevés pour permettre un certain type d'accès. Les permissions pour les répertoires peuvent avoir une signification différente des mêmes paramètres de permissions sur un fichier.

Lecture :

Écriture:

Exécution:

Vous – Le propriétaire du fichier

Groupe – Le groupe auquel vous appartenez

Tous – Quiconque sur le système qui n'est ni propriétaire, ni membre du groupe

Exemple de fichier :

        -rw-r--r--  1 kevin  users         114 Aug 28  1997 .zlogin
1st bit - répertoire?                 (non)
2nd bit - lecture propriétaire?       (oui, par kevin)
3rd bit - écriture par propriétaire?  (oui, par kevin)
4th bit - exécution propriétaire?     (non)
5th bit - lecture groupe?             (oui, par users)
6th bit - écriture groupe?            (non)
7th bit - exécution groupe?           (non)
8th bit - lecture tous?               (oui, par tous)
9th bit - lecture tous?               (non)
10th bit - exécution tous?            (non)

Les lignes suivantes sont des exemples d'ensembles de permissions qui sont nécessaires pour avoir l'accès décrit. Vous voudrez sans doute donner plus de permissions que celles données ici, mais on ne décrit ici que l'effet de ces permissions minimales :

-r--------  Autoriser l'accès en lecture au fichier par le propriétaire
     --w-------  Autoriser le propriétaire à modifier ou effacer le fichier
	(Notez que quiconque ayant les droits d'écriture sur le répertoire
	dans lequel se trouve le fichier peut l'écraser/effacer)
---x------  Le propriétaire peut exécuter ce programme, mais pas de
	script shell, qui de plus nécessite un droit en lecture
---s------  Sera exécuté avec l'UID du propriétaire
------s---  Sera exécuté avec le GID du groupe
-rw------T  Pas de mise à jour du "last modified time"
	(Heure de dernièremodification).
	Généralement utilisé pour le fichiers d'échange (swap)
---------t  Aucun effet. (anciennement bit de conservation)

Exemple de répertoires :

drwxr-xr-x  3 kevin  users         512 Sep 19 13:47 .public_html/
1e bit - répertoire?             (oui, il contient de nombreux fichiers)
2e bit - lecture propriétaire?   (oui, par kevin)
3e bit - écriture propriétaire?  (oui, par kevin)
4e bit - exécution propriétaire? (oui, par kevin)
5e bit - lecture groupe?         (oui, par users)
6e bit - écriture groupe?        (non)
7e bit - exécution groupe?       (oui, par users)
8e bit - lecture par tous?       (oui, par tous)
9e bit - écriture par tous?      (non)
10e bit - exécution par tous?    (oui, par tous)

Les lignes qui suivent sont des exemples des ensembles de permissions minimum requis pour autoriser l'accès décrit. Vous voudrez sans doute donner plus de permissions que celles données ici, mais on ne décrit ici que l'effet de ces permissions minimales :

dr--------  Le contenu peut être listé, mais l'attribut des fichiers ne peut être lu
d--x------  Le répertoire est accessible, et utilisé comme chemin en exécution complète
dr-x------  Les attributs de fichiers peuvent être lus par le propriétaire
d-wx------  Les fichiers peuvent être créés/effacés, même si le répertoire  n'est pas le répertoire courant
d-----x--t  Empêche l'effacement de fichiers par "tous" ceux ayant un droit d'écriture. Utilisé pour /tmp
d--s--s---  Aucun effet

Les fichiers de configuration système (généralement dans /etc) ont souvent un mode de 640 (-rw-r-----), et sont possédés par root. Selon les besoins en sécurité de votre site, vous pouvez les ajuster. Ne laissez jamais un fichier système en écriture pour un groupe ou pour tous. Certains fichiers de configuration, dont /etc/shadow, devraient n'être en lecture que par root, et les répertoires de /etc ne devraient pas être accessibles par tous, au moins.

Une autre très bonne manière de détecter des attaques locales (et réseau) sur votre système est de lancer un contrôleur d'intégrité comme Tripwire, Aide ou Osiris. Ces contrôleurs d'intégrité génèrent un certain nombre de sommes de contrôle sur tous vos binaires et fichiers systèmes importants et les comparent à une base de données précédemment générée de valeurs références bien connues. Ainsi, tout changement dans un fichier sera détecté.

C'est un bon réflexe d'installer ce genre de programmes sur une disquette, puis d'empêcher physiquement l'écriture sur celle-ci. De cette façon. les intrus ne pourront pas altérer le contrôleur d'intégrité lui-même ou modifier sa base de données. Une fois que vous avez une application de ce style configurée, il est conseillé de l'ajouter à vos devoirs d'administrateurs système pour vérifier que rien n'a changé.

Vous pouvez même ajouter un entrée crontab pour lancer le contrôleur depuis votre disquette toute les nuits et vous envoyer un message le matin. Quelque chose comme :

# set mailto
     MAILTO=kevin
     # run Tripwire
     15 05 * * * root /usr/local/adm/tcheck/tripwire 

Vous enverra un rapport tous les matins à 5H15.

Les contrôleurs d'intégrité peuvent être une aubaine pour détecter des intrusions avant même que vous ne puissiez les remarquer. Comme beaucoup de fichiers changent sur un système moyen, vous devrez faire le discernement entre des activités de cracker et vos propres agissements.

Vous pouvez trouver une version libre et non prise en charge de Tripwire sur le site tripwire.org, gratuitement. Des manuels et de l'assistance technique peuvent être achetés.

Aide peut être trouvé sur Sourceforge.

Osiris peut être trouvé à OSIRIS –– Host Integrity Management.

Les « Chevaux de Troie » tirent leur nom du célèbre stratagème décrit dans l'Iliade d'Homère. L'idée est qu'un cracker distribue un programme ou binaire qui semble intéressant, et encourage d'autres personnes à le télécharger et le lancer en tant que root. Alors, le programme peut compromettre leur système pendant qu'ils n'y prêtent pas attention. Alors qu'ils pensent que le logiciel qu'ils viennent de charger ne fait qu'une seule chose (et parfois très bien), il compromet aussi leur sécurité.

Vous devez prendre garde aux programmes que vous installez sur votre machine. Mandriva fournit les sommes de contrôle MD5 et les signatures PGP de chacun des RPM qu'il fournit, de sorte que vous puissiez vérifier que vous installez la bonne chose. Vous ne devriez jamais lancer un binaire que vous ne connaissez pas, pour lequel vous n'avez pas les sources comme root ! Peu d'attaquants souhaitent publier leur code source pour sondage public.

Bien que cela puisse être complexe, assurez-vous que vous obtenez le code source d'un programme depuis son site réel de distribution. Si le programme doit être lancé par root, assurez vous que vous ou quelqu'un de confiance a regardé les sources et les a vérifiées.

La cryptographie à clé publique, comme celle utilisée par PGP, utilise une clé pour le cryptage, et une autre pour le décryptage. La cryptographie traditionnelle, pourtant, utilise la même clé pour le cryptage, et le décryptage ; cette clé doit être connue des deux côtés, et quelqu'un a donc dû transférer de manière sûre la clé d'un côté à l'autre.

pour soulager le besoin de transférer de manière sûre la clé de chiffrement, la clé publique de cryptage utilise deux clés séparées : Une clé publique et une clé privée. La clé publique de chacun est disponible pour quiconque pour faire le cryptage, alors que cependant, chacun garde sa clé privée pour décrypter les messages cryptés avec la clé publique.

Il y a des avantages aux deux méthodes de cryptage, clé publique ou clé privée, et vous pouvez lire à propos de leurs différences : La FAQ pour la cryptographie RSA, citée à la fin de cette section.

PGP (Pretty Good Privacy, soit intimité plutôt bonne) est bien toléré par GNU/Linux. Les versions 2.6.2 et 5.0 sont reconnues pour leur stabilité. Pour des nouvelles de PGP et comment l'utiliser, jetez un coup d'oeil aux différentes FAQs de PGP : faqs.org

Veillez à utiliser la version autorisée dans votre pays. Du fait des restrictions d'exportation du gouvernement américain, il est interdit de transférer hors de ce pays de la cryptographie lourde sous forme électronique.

Les contrôles d'exportation des US sont maintenant gérés par EAR (Export Administration Regulations), et non plus par ITAR.

Il y a aussi un guide pas à pas pour configurer PGP sous GNU/Linux disponible sur LinuxFocus. Il a été écrit pour la version internationale de PGP, mais est aisément transposable à la version des États-Unis. Vous pourriez aussi avoir besoin de correctifs pour certaines des dernières versions de GNU/Linux; le correctif (patch) est disponible chez metalab.

Il y a un projet travaillant sur une réimplantation libre de PGP sous licence «  open source ». GnuPG est un remplaçant complet et libre pour PGP. Du fait qu'il n'utilise pas IDEA ou RSA il peut être utilisé sans aucune restriction. GnuPG respecte pratiquement OpenPGP. Voir la page Web GNU Privacy Guard pour plus d'information.

Vous trouverez plus de renseignements au sujet de la cryptographie dans la FAQ du site de la cryptographie RSA. Vous trouverez ici toute l'information sur des sujets tels que « Diffie-Hellman », « cryptographie à clé publique », « certificats électroniques », etc.

Les utilisateurs se demandent souvent ce qui différencient les différents protocoles de cryptage, et comment les utiliser. Bien que ce document ne soit pas consacré au cryptage, il est bon d'expliquer brièvement ce qu'est chaque protocole, et où trouver plus d'information.

A côté de CIPE, et d'autres formes de cryptage de données, il y a aussi plusieurs implémentations de IPSEC pour GNU/Linux. IPSEC est une tentative de l'IETF de création de communications cryptées, donc sûres, au niveau du réseau IP, pour assurer authentification, intégrité, contrôle d'accès, et confidentialité. Des informations sur IPSEC le projet Internet peuvent être consultées sur : ipsec Charter. Vous pouvez aussi trouver des liens vers d'autres protocoles impliquant la gestion de clés, et une mailing list IPSEC et son archive.

L'implémentation de GNU/Linux x-kernel, qui était développée à la University of Arizona, utilise une base orientée objet pour implémenter les protocoles réseau appelés x-kernel. En clair, le x-kernel est une méthode pour passer les messages au niveau du noyau, ce qui facilite l'implémentation. Ce projet n'est plus en développement mais des renseignements peuvent être trouvés sur le site The x-Kernel Project.

Une autre implémentation de IPSEC est l'IPSEC « FreeS/WAN » GNU/Linux, qui est librement disponible. Leur page Web indique : « Ces services vous permettent de monter un tuyau sécurisé à travers des réseaux non fiables. Tout ce qui passe à travers le réseau non fiable est crypté par la machine passerelle IPSEC et décrypté par la passerelle à l'autre bout. Cela conduit à un réseau privé virtuel ou VPN (Virtual Private Network). C'est un réseau qui est effectivement privé, même s'il inclut des machines de plusieurs sites différents interconnectés par Internet, non sûrs. »

Elle est disponible en téléchargement sur le site Linux FreeS/WAN.

De même que d'autres formes de cryptographie, elle n'est pas distribuée dans le noyau par défaut, à cause des restrictions à l'exportation.

ssh et stelnet sont des suites de programmes qui permettent de se connecter à un système distant avec des échanges cryptés.

ssh est une suite de programmes utilisée comme remplacement sécurisé de rlogin, rsh et rcp. Elle utilise la cryptographie à clé publique pour crypter les communications entre deux hôtes, ainsi que l'authentification des utilisateurs. Ces outils peuvent être utilisés pour se connecter à un serveur distant ou copier des données entre deux hôtes, tout en empêchant des attaques de tiers («  session hijacking  ») et «  DNS spoofing  ». Ils assurent la compression de données sur vos connections et les communications X11 sécurisées.

Il y a à l'heure actuelle plusieurs implémentations de ssh. L'implémentation commerciale originale par Data Fellows peut être trouvée sur la page ssh de datafellows.com.

L'excellente implémentation Openssh est basée sur une ancienne version de DataFellows ssh et a été entièrement retravaillée pour n'inclure aucun brevet ou partie propriétaire. Elle est libre et sous licence BSD. Elle peut être trouvée sur : http://www.openssh.com.

Il y a aussi un projet « open source » pour réimplémenter ssh depuis le néant appelé « lsh ». Pour plus de renseignements, consulter : LSH.

Vous pouvez aussi utiliser ssh depuis vos stations Windows^® vers votre serveur ssh GNU/Linux. Il y a plusieurs implémentations de clients Windows^® librement disponibles, dont celui de PuTTY, ainsi qu'une version commerciale de DataFellows, sur le site DataFellows.

SSLeay (obsolète, voir OpenSSL plus loin) est une implémentation libre du protocole Secure Sockets Layer de Netscape, développé par Eric Young. Elle comporte plusieurs applications, comme « Secure telnet », un module pour Apache, plusieurs bases de données, ainsi que plusieurs algorithmes dont DES, IDEA et « Blowfish ».

En utilisant cette bibliothèque, un remplacement de telnet sécurisé qui fait de l'encryption par dessus une connexion telnet. Au contraire de SSH, stelnet utilise SSL, le protocole Secure Sockets Layer développé par Netscape. Vous pourrez trouver « Secure telnet » et « Secure FTP » en commençant par la FAQ SSLeay et SSLapps (en anglais).

Note

Le projet OpenSSL basé sur SSLeay a pour but de développer une boîte à outils robuste, de qualité commerciale, entièrement fonctionnelle, et Open Source qui implémente les protocoles Secure Sockets Layer (SSL v2/v3) et Transport Layer Security (TLS v1) ainsi qu'une librairie de cryptographie forte d'usage général. Pour plus d'informations sur ce projet, consultez les Pages OpenSSL. Il y a aussi une liste conséquente d'applications basées sur OpenSSL sur Applications en relation avec OpenSSL.

SRP est une autre implémentation sécurisée de telnet/ftp. Extrait de leur page Web :

« Le projet SRP développe des logiciels Internet sûrs pour une utilisation mondiale gratuite. À partir d'une distribution de Telnet et FTP totalement sécurisés, nous espérons supplanter les systèmes d'authentification réseau vulnérables par des substituts solides qui ne sacrifient en rien la facilité d'utilisation pour la sécurité. La sécurité devrait être de fait et non pas une option !  »

Pour plus de renseignements, visiter stanford.edu.

Votre version de Mandriva Linux est fournie avec une combinaison d'authenti­fications unifiée appelée PAM. PAM vous permet de changer vos méthodes d'authentification et exigences à la volée, et encapsule toutes les méthodes locales d'authentifica­tion sans besoin de recompiler un quelconque binaire. La configuration de PAM est au delà de la portée de ce chapitre, mais allez faire un tour du côté du site Web de PAM : kernel.org.

Juste un aperçu des possibilités de PAM :

En quelques heures d'installation et de configuration de votre système, vous pouvez empêcher plusieurs attaques avant qu'elles ne surviennent. Par exemple, utilisez PAM pour désactiver l'utilisation sur tout le système des fichiers .rhosts dans les répertoires des utilisateurs en ajoutant ces lignes dans /etc/pam.d/rlogin :

#
    # Désactiver rsh/rlogin/rexec pour les utilisateurs
    #
    login auth required pam_rhosts_auth.so no_rhosts

Le premier objectif de ce logiciel est de fournir un moyen de sécuriser (contre l'espionnage, y compris l'analyse de trafic, et l'injection de message truqué) des interconnexions de sous-réseaux au travers d'un réseau par paquets non sûr tel que Internet.

CIPE crypte les données au niveau du réseau. Les paquets voyageant entre les hôtes sur le réseau sont cryptés. Le moteur de cryptage est placé près du périphérique qui envoie et reçoit les paquets.

Cela est différent de SSH, qui crypte les données par connexion, au niveau du port (socket). Une connexion logique entre des programmes tournant sur des hôtes différents est cryptée.

CIPE peut être utilisé pour faire du pontage (tunnelling), afin de créer un réseau privé virtuel (VPN). Le cryptage de bas niveau a l'avantage de pouvoir être rendu transparent entre deux réseaux connectés dans le VPN, sans besoin de changer une quelconque application.

Résumé depuis la documentation de CIPE :

« Le standard IPSEC définit un ensemble de protocoles qui peuvent être utilisés (entre autre) pour monter des VPN cryptés. Cependant, IPSEC est un protocole plutôt lourd et compliqué possédant un grand nombre d'options, les implémentations de l'ensemble complet du protocole sont encore rarement utilisés et plusieurs problèmes (tel que la gestion des clés) ne sont toujours pas complètement résolus. CIPE utilise une approche simple, dans laquelle beaucoup de choses modifiables (comme le choix de l'algorithme de cryptage effectivement utilisé) sont fixées à l'installation. Cela limite la flexibilité, mais permet une implémentation simple (et par là même efficace, facile à déboguer...). »

Plus d'informations peuvent être trouvées chez CIPE Project

De même que d'autres formes de cryptographie, il n'est pas distribué avec le noyau par défaut du fait de restrictions à l'exportation.

Kerberos est un système d'authentification développé par The Athena Project au MIT. Quand un utilisateur se connecte, Kerberos authentifie cet utilisateur (en utilisant un mot de passe), et fournit à cet utilisateur un moyen de prouver son identité aux autres serveurs et hôtes disséminés sur le réseau.

Cette authentification est alors utilisée par des programmes tels que rlogin pour autoriser l'utilisateur à se connecter à d'autres hôtes sans mot de passe (au lieu du fichier .rhosts). Cette méthode d'authentification peut aussi être utilisée par le système de courrier électronique pour garantir que les messages seront délivrés à la bonne personne, ainsi que pour garantir l'authenticité de l'expéditeur.

Kerberos et les programmes qui l'accompagnent, empêchent les utilisateurs de tromper le système en lui faisant croire qu'ils sont quelqu'un d'autre («  spoofing  »). Malheureusement, installer Kerberos est très intrusif, et demande le remplacement ou la modification de nombreux programmes standards.

Vous pourrez trouver plus d'informations à propos de Kerberos en visitant la FAQ Kerberos, et le code peut être obtenu depuis le site mit.edu.

[Stein, Jennifer G., Clifford Neuman, and Jeffrey L. Schiller. "Kerberos : An Authentication Service for Open Network Systems." USENIX Conference Proceedings, Dallas, Texas, Winter 1998.]

Kerberos ne devrait pas être votre premier pas pour améliorer la sécurité de votre hôte. Il est plutôt compliqué, et pas aussi répandu que, disons SSH.

Les mots de passe Shadow sont un moyen de cacher vos informations de cryptage de mots de passe aux utilisateurs normaux. Votre système d'exploitation Mandriva Linux utilise les mots de passe Shadow par défaut, mais d'autres systèmes stockent les mots de passe cryptés dans le fichier /etc/passwd où tout le monde peut les lire. N'importe qui peut alors exécuter des programmes de cassage de mots de passe et ainsi les déterminer. Les mots de passe Shadow, à l'inverse, sont sauvegardés dans le fichier /etc/shadow, que seuls les utilisateurs autorisés peuvent lire. Vous pouvez lire Shadow-Password HOWTO pour obtenir plus de renseignements, si nécessaire. Il date un peu et n'est pas requis pour des distributions supportant PAM, comme votre système Mandriva Linux.

Si pour une raison quelconque votre programme passwd ne force pas l'utilisation de mots de passe difficiles à deviner, vous pourrez souhaiter utiliser un programme de cassage de mots de passe pour vous assurer que les mots de passe de vos utilisateurs sont sûrs.

Les programmes de cassage de mots de passe reposent sur une idée simple : ils essayent tous les mots du dictionnaire, puis des variations sur ces mots, en cryptant chacun d'eux et les comparant à vos mots de passe cryptés. S'ils obtiennent une correspondance, ils ont trouvé le mot de passe

Il y a plusieurs programmes de ce type les deux les plus connus sont Crack et John the Ripper (voir OpenWall). Malheureusement, ils consomment beaucoup de temps CPU, mais vous devriez être capable de vérifier si un attaquant est susceptible de pénétrer en les utilisant vous-même, puis en avertissant les utilisateurs dont le mot de passe est trop faible. Notez qu'un attaquant devra d'abord utiliser un autre trou pour pouvoir lire votre fichier /etc/shadow, mais de tels trous sont plus courants que vous ne le pensez.

Parce que la sécurité n'est aussi forte que si le plus faible des hôtes est protégé, il est bon de mentionner que si vous avez des machines Windows^® sur votre réseau, vous devriez jeter un coup d'œil à L0phtCrack, une implantation de Crack sous Windows^®. Il est disponible depuis le site atstake.com.

CFS (Cryptographic File System) permet de chiffrer une arborescence complète ; pour leur part, les utilisateurs peuvent y enregistrer des fichiers cryptés. Il utilise un serveur NFS tournant sur la machine locale. Pour obtenir plus de renseignements ainsi que les sources visitez le site de att.com.

TCFS (Transparent Cryptographic File System) améliore CFS en lui ajoutant une meilleure intégration dans le système de fichiers, de sorte qu'il devient transparent aux utilisateurs quand le système de fichier est crypté. Plus d'informations sur le site de tcfs.it.

Il n'a pas non plus besoin d'être utilisé sur des systèmes de fichiers complets. Il fonctionne aussi bien sur de simples arborescences.

Lorsque ce document a été écrit, le noyau 2.2 était le nec plus ultra. Encore aujourd'hui, la plupart des pare-feu l'utilisent encore. Toutefois, avec le noyau 2.4, beaucoup de choses ont changé. La plupart des options de compilation contenues dans ce chapitre sont encore valides, mais le masquage et le transfert de port ont été remplacés par les tables IP. Vous obtiendrez de plus amples renseignements en visitant le Linux iptables HOWTO.

Pour les noyaux 2.2.x, les options suivantes s'appliquent. Vous devriez voir ces options pendant le processus de configuration du noyau. La plupart des commentaires sont issus de /usr/src/linux/Documentation/Configure.help, soit le même document utilisé dans l'aide en ligne pendant l'étape make config de la compilation du noyau. Consultez le chapitre Compiling and Installing New Kernels du Reference Manual pour obtenir une description du processus de compilation d'un nouveau noyau.

Il y a plusieurs périphériques en mode bloc et caractère disponibles sous GNU/Linux qui vous aideront aussi pour la sécurité.

Les deux fichiers /dev/random et /dev/urandom sont fournis par le noyau pour offrir des données aléatoires à tout instant.

Aussi bien /dev/random que /dev/urandom devraient être assez sûrs pour générer des clés PGP, des challenges ssh, et autres applications où des nombres aléatoires sont requis. Les attaquants devraient être incapables de prédire le nombre suivant, connaissant une séquence initiale de nombres provenant de ces sources. Beaucoup d'efforts ont étés consentis pour s'assurer que les nombres fournis par ces sources sont aléatoires, dans tous les sens du terme.

La seule différence entre ces deux périphériques, est que /dev/random s'épuise en octets aléatoires, et vous fait attendre jusqu'à ce que d'autres ce soient accumulés. Notez que sur certains systèmes, il peut se bloquer pendant un long moment, attendant que de la nouvelle entropie, générée par l'utilisateur entre dans le système. Vous devez donc faire attention avant d'utiliser /dev/random. (La meilleure chose à faire est sans doute de l'utiliser lorsque vous générez des informations de clés sensibles, et vous demandez à l'utilisateur d'utiliser le clavier intensément jusqu'à ce que vous estimiez que cela suffit.)

/dev/random est de haute qualité entropique, généré en mesurant les temps inter-interruptions, etc. Il se bloquera jusqu'à ce que suffisamment de bits aléatoires aient été générés.

/dev/urandom est semblable, mais lorsque la réserve d'entropie baisse, il retournera un mélange d'un niveau cryptographique élevé de ce qu'il reste. Ce n'est pas aussi sûr, mais cela suffit pour la plupart des applications.

Vous pouvez lire depuis ces périphériques en utilisant quelque chose comme :

 root# head -c 6 /dev/urandom |
     mimencode

Cela imprimera six caractères aléatoires à la console, convenables pour un mot de passe. Vous pourrez trouver mimencode dans le paquetage metamail.

Consultez /usr/src/linux/drivers/char/random.c pour une description de l'algorithme.

Une des manières les plus répandues parmi les intrus pour obtenir l'accès à plus de systèmes sur votre réseau, est d'employer un renifleur de paquets sur un hôte déjà violé. Ce sniffer écoute simplement sur les ports Ethernet et repère des choses comme passwd, login ou su dans le corps du paquet et enregistre alors le trafic qui suit. De cette façon, les attaquants obtiennent des mots de passe pour des systèmes qu'ils n'essayent même pas de casser. Les mots de passe en clair sont évidemment très vulnérables à cette attaque.

Exemple : Un hôte A a été violé. L'attaquant y installe un sniffer. Ce dernier tombe sur l'administrateur en train de se connecter de l'hôte B à l'hôte C. Il obtient alors le mot de passe personnel de l'administrateur sur B. Puis l'administrateur fait un su pour corriger un problème. Il a maintenant le mot de passe de root pour l'hôte B. Plus tard, l'administrateur laisse quelqu'un faire un telnet depuis sa machine vers l'hôte Z sur un autre site, L'attaquant possède désormais un login et mot de passe sur Z...

A l'heure actuelle, les attaquants n'ont même pas besoin de violer un système pour faire cela : Ils peuvent aussi amener un ordinateur (portable ou non) dans un bâtiment et se brancher sur votre réseau.

Utiliser ssh ou une autre méthode pour crypter les mots de passe déjoue cette attaque. Des outils comme comptes APOP au lieu de POP pour le courrier électronique préviennent aussi ces attaques. Les connexions normales POP sont très vulnérables à cela, de même que tout ce qui envoie des mots de passe en clair à travers le réseau.)

Avant que vous ne connectiez votre système GNU/Linux sur un QUELCONQUE réseau, la première chose à déterminer ce sont les services que vous souhaitez offrir. Les services que vous n'avez pas besoin d'offrir devraient être désactivés de sorte que vous aurez moins de choses pour lesquelles vous préoccuper et les attaquants auront moins de chances de pouvoir trouver un trou.

Il y a plusieurs façons de désactiver des services sous GNU/Linux. Vous pouvez regarder le fichier /etc/inetd.conf et noter les fichiers qui sont offerts par inetd. Désactivez tous ceux dont vous n'avez pas besoin en les commentant (# au début de la ligne), et redémarrez alors votre service inetd.

Vous pouvez aussi supprimer (ou commenter) des services dans votre fichier /etc/services. Cela signifiera que les clients locaux seront aussi incapables de trouver ces services (i.e., si vous supprimez ftp, et essayez de faire une connexion FTP vers un site distant depuis cette machine, cela échouera avec un message service inconnu). Cela ne vaut généralement pas la peine de supprimer les services à partir de /etc/services, vu que cela ne fournit pas de sécurité supplémentaire. Si un utilisateur veut utiliser ftp même si vous l'avez commenté, il pourrait faire son propre client qui utilise le port FTP standard, et cela fonctionnerait.

Certains des services que vous pourriez souhaiter activer sont :

Si vous savez que vous n'allez pas utiliser un paquetage en particulier, vous pouvez aussi le supprimer complètement. rpm -e nom_du_paquetageou urpme nom_du_paquetage effacera un paquetage entier.

De plus, vous devriez vraiment désactiver les utilitaires rsh/rlogin/rcp, y compris login (utilisé par rlogin), shell (utilisé par rcp),et exec (utilisé par rsh) depuis /etc/inetd.conf. Ces protocoles sont extrêmement vulnérables et ont été la cause de violations dans le passé.

Vous devriez vérifier les répertoires /etc/rc.d/rc[0-9].d, et regarder si des serveurs présents ne sont pas superflus. Les fichiers de ces répertoires sont en fait des liens symboliques vers des fichiers de /etc/rc.d/init.d. Renommez ces fichiers dans init.d désactive tous les liens symboliques qui pointent vers ce fichier. Si vous ne souhaitez désactiver un service que pour un niveau d'exécution (runlevel) particulier, renommez le lien symbolique approprié en remplaçant le S avec un K, comme cela :

root#  cd /etc/rc6.d
     root#  mv S45dhcpd K45dhcpd

	Note
	Vous pouvez aussi utiliser un petit utilitaire pour faire cela : chkconfig ou l'interface graphique sous KDE : ksysv.

Votre distribution de Mandriva Linux est fournie avec un encapsuleur (wrapper) TCP « encapsulant » tous vos services TCP. L'encapsuleur TCP (tcpd) est appelé depuis inetd au lieu du service réel. tcpd vérifie alors l'hôte demandant le service, et soit exécute le vrai serveur, soit refuse l'accès à cet hôte. tcpd vous permet de restreindre l'accès aux services TCP. Vous devriez éditer /etc/hosts.allow et y ajouter uniquement les hôtes qui ont besoin d'avoir accès aux services de votre machine.

Si vous possédez une connexion par simple modem, nous vous suggérons de refuser tous (ALL). tcpd enregistre aussi les tentatives échouées pour accéder aux services, de sorte que cela peut vous alerter si on est en train de vous attaquer. Si vous ajoutez de nouveaux services, vous devriez vous assurer de les configurer pour utiliser l'encapsuleur TCP s'ils sont basés sur TCP. Par exemple, une machine connectée par modem peut être protégée de l'extérieur, tout en pouvant charger son courrier électronique, et faire des connexions réseau à Internet. Pour faire cela, vous devez ajouter ce qui suit à votre /etc/hosts.allow :

ALL: 127.

Et bien sûr, /etc/hosts.deny contiendra :

ALL: ALL

Ce qui empêchera des connexions extérieures à votre machine, vous permettant néanmoins de vous connecter depuis l'intérieur aux services Internet.

Gardez à l'esprit que les encapsuleurs TCP ne protègent que les services exécutés depuis inetd, et quelques rares autres. Il y a sûrement d'autres serveurs tournant sur votre machine. Vous pouvez utiliser netstat -ta pour afficher la liste de tous les services que votre machine offre.

Garder des informations DNS à jour sur tous les hôtes de votre réseau peut vous aider à améliorer la sécurité. Si un hôte non autorisé se connecte à votre réseau, vous pouvez l'identifier grâce à son absence d'entrées DNS. Beaucoup de services peuvent être configurés de façon à ne pas accepter de connexions d'hôtes qui n'ont pas d'entrées DNS valides.

identd est un petit programme qui est lancé typiquement depuis votre serveur inetd. Il garde la trace de qui utilise quel service TCPet le rapporte alors à qui en fait la demande.

Beaucoup de gens ne comprennent pas l'utilité de identd, et le désactivent ou bloquent toutes le requêtes de l'extérieur qui lui sont destinées. identd n'est pas là pour aider les sites distants. Il n'y a pas moyen de savoir si l'information que vous obtenez de l'identd distant est correcte ou non. Il n'y a pas d'authentification dans les requêtes identd.

Pourquoi voudriez-vous l'utiliser alors ? Parce qu'il vous aide, et est une autre source pour le suivi. Si votre identd n'est pas corrompu, alors, vous savez qu'il informe les sites distants des noms d'utilisateur ou UID des personnes utilisant les services TCP. Si l'administrateur du site distant revient et vous dit que l'utilisateur untel essayait de pénétrer dans leur site, vous pouvez facilement prendre des mesures contre cet utilisateur. Si vous n'utilisez pas identd, vous devrez chercher dans un grand nombre de «  logs  », deviner qui était connecté à ce moment, et en général prendre beaucoup de temps pour rechercher l'utilisateur.

L' identd fourni est plus facile à configurer que beaucoup de gens ne le pensent. Vous pouvez le désactiver pour certains utilisateurs (Ils peuvent créer un fichier .noident file), vous pouvez garder trace de toutes les requêtes identd (recommandé), vous pouvez même faire en sorte que identd retourne un UID au lieu du nom de l'utilisateur, ou même NO-USER.

Il y a plusieurs paquetages de logiciels qui font du balayage de ports et de services sur machines et réseaux. SATAN, ISS, SAINT, et Nessus en sont quelques-uns des plus connus. Ces logiciels se connectent à la machine cible (ou toutes les cibles machines et réseaux) sur tous les ports qui sont ouverts, et essayent de déterminer quels services tournent dessus. Sur la base de ces informations, vous pouvez dire si la machine est vulnérable a une attaque spécifique et sur quels services.

SATAN (Security Administrator's Tool for Analyzing Networks, soit Outil d'admi­nistrateur sécurité pour l'analyse de réseaux) est un analyseur de port avec une interface Web. Il peut être configuré pour effectuer des vérifications légères, moyennes, ou lourdes sur une machine ou un réseau de machines. C'est une bonne idée de se procurer SATAN et de scanner votre machine ou réseau, et de régler les problèmes qu'il rencontre. Assurez-vous d'obtenir une copie de SATAN sur le site metalab ou un site FTP ou Web réputé. Il y avait une copie de SATAN « cheval de Troie » qui était distribuée sur Internet (voir Le site Internet de Trouble). Notez que SATAN n'a pas été mis à jour depuis longtemps et certains des outils ci-dessous pourraient faire du meilleur boulot.

ISS (Scanner de Sécurité Internet) est un autre scanner de port. Il est plus rapide que SATAN, et devrait donc être meilleur pour de grands réseaux. Néanmoins, SATAN tend à fournir plus d'informations.

SAINT^tm est une version mise a jour de SATAN. Il a une interface Web et possède des tests bien plus récents que SATAN. Vous pouvez en apprendre plus sur lui : SAINT

Nessus est un scanner sécurité libre. Il propose une interface graphique GTK pour en faciliter l'utilisation. Il est aussi conçu avec un très bon créateur de modules additionnels pour de nouveaux tests de balayage de ports. Pour plus d'informations, visiter le site Web de Nessus

Un attaque en « Dénis de service » (DoS) essaye de saturer les ressources de sorte que le système ne puisse plus répondre aux requêtes légitimes, ou de refuser l'accès à votre machine aux utilisateurs légitimes.

Les attaques en dénis de service ont beaucoup progressé ces dernières années. Certaines des plus récentes et connues sont listées ci-dessous. Notez que de nouvelles naissent sans arrêt, de sorte qu'il n'y a ici que quelques exemples. Lisez les archives de listes de courriers GNU/Linux sur la sécurité et la liste et les archives de bugtraq pour une information plus à jour.

Vous pouvez trouver le code pour la plupart de ces attaques, et une description plus détaillée de leur fonctionnement sur le site Insecure en utilisant leur moteur de recherche.

Les pare-feu sont un moyen de contrôler les informations autorisées à sortir et à rentrer dans votre réseau local. Généralement, l'hôte pare-feu est connecté à Internet et à votre réseau local, et le seul accès depuis votre réseau vers Internet est à travers le pare-feu. De cette façon, le pare-feu peut contrôler ce qui rentre et sort d'Internet et de votre réseau local.

Plusieurs types de pare-feu et de méthodes pour les mettre en place existent. Les machines GNU/Linux constituent de bons pare-feu. Le code pare-feu peut être inséré directement dans les noyaux 2.0 et supérieurs. Les outils utilisateur ipchains pour les noyaux 2.2, et iptables pour noyau 2.4 vous permettent de changer, à la volée, les types de trafics réseau que vous autorisez. Vous pouvez aussi garder trace de certains trafics réseau.

Les pare-feu sont une technique utile et importante pour sécuriser votre réseau. Néanmoins, ne pensez jamais que, parce que vous avec un pare-feu, vous n'avez pas besoin de sécuriser les machines derrière lui. C'est une erreur fatale. Consultez le très bon Firewall-HOWTO pour plus d'informations sur les pare-feu et GNU/Linux.

Si vous n'avez aucune expérience avec les pare-feu, et envisagez d'en mettre un en place pour plus qu'une simple politique de sécurité, le livre Firewalls de chez O'Reilly and Associates ou tout autre document en ligne sur les pare-feu est indispensable. Consultez O'Reilly pour plus d'informations. Le NIST (National Institute of Standards and Technology) a rassemblé un excellent document sur les pare-feu. Bien que daté de 1995, il est toujours très bon. Vous pouvez le trouver sur nist.gov. Il y a aussi :

Les VPNs (Virtual Private Networks) sont un des moyens d'établir un réseau « virtuel » par dessus un réseau déjà existant. Ce réseau virtuel est souvent crypté et transmet les données uniquement de et vers certaines entités qui ont rejoint le réseau. Les VPNs sont souvent utilisés pour connecter quelqu'un travaillant chez lui par dessus Internet public sur le réseau interne de sa compagnie.

Il y a plusieurs solutions GNU/Linux VPN disponibles:

Consultez aussi la section sur IPSEC pour des références vers plus d'informa­tions.

Discuter des méthodes de sauvegarde et de stockage est hors de la portée de ce chapitre mais voici quelques mots au sujet des sauvegardes et de la sécurité :

Si vous avez moins de 650MB de données sur une partition, une copie sur CD-R de vos données est un bon moyen (difficile à modifier ensuite, et, si stocké correctement, peut durer longtemps). Bandes et autres médias réinscriptibles devraient être protégés contre l'écriture dès que la sauvegarde est complète, puis vérifiés pour empêcher la modification. Assurez vous de stocker vos sauvegardes dans un endroit sûr hors ligne. Une bonne sauvegarde vous fournira un bon point de départ pour restaurer votre système.

Un cycle à six bandes est facile à gérer. Il comprend quatre bandes pour la semaine, une pour chaque vendredi pair, et une dernière pour les vendredis impairs. Faites une sauvegarde incrémentale chaque jour, et une sauvegarde complète sur la bande du vendredi appropriée. Si vous faites un changement particulièrement important ou ajoutez des données importantes à votre système, une sauvegarde complète est recommandée.

Vous devriez faire des tests périodiques de vos copies de sauvegarde pour vous assurer qu'elles fonctionnent correctement. Les restaurations de fichiers et leur vérification auprès des données réelles, la taille et le listage des copies, et la lecture de vieilles copies de sauvegarde devraient être faites sur une base régulière.

Dans l'éventualité d'une intrusion, vous pouvez utiliser votre base de données RPM comme vous utiliseriez tripwire, mais uniquement si vous pouvez être sûr qu'elle n'a pas été modifiée elle non plus. Vous devriez copier votre base de données RPM sur une disquette, et garder tout le temps cette dernière hors-ligne.

Les fichiers /var/lib/rpm/fileindex.rpm et /var/lib/rpm/packages.rpm ne tiendront sans doute pas sur une seule disquette. Mais compressés, ils devraient tenir chacun sur une.

Maintenant, si votre système est corrompu, vous pouvez utiliser la commande :

root#  rpm -Va

pour vérifier tous les fichiers du système. Consultez la page de man de rpm, car il y a quelques autres options qui peuvent être incluses pour le rendre moins verbeux. Gardez à l'esprit que vous devez aussi être sûr que votre binaire RPM n'a pas lui aussi été corrompu.

Cela signifie que chaque fois qu'un nouveau RPM est ajouté au système, la base de données RPM devra être archivée à nouveau. Vous devrez peser les avantages et les inconvénients.

Il est très important que l'information générée par syslog ne soit pas corrompue. Rendre les fichiers de /var/log en lecture et écriture par un seul petit nombre d'utilisateurs est un bon début.

Assurez-vous de garder un œil sur ce qui y est écrit, spécialement sous la rubrique auth. Des échecs de connexion répétés par exemple, peuvent révéler une tentative de viol.

Vous pourrez regarder dans /var/log et consulter messages, mail.log, etc.

Vous voudrez aussi configurer votre script de rotation des logs pour les garder plus longtemps de sorte que vous ayez le temps de les examiner. Jetez un coup d'œil à logrotate(8).

Si vos fichiers de logs ont été corrompus, essayez de déterminer à partir de quand commence la corruption, et quelles choses semblent être corrompues. Y a-t-il de longues périodes sans logs? Regarder dans les sauvegardes les fichiers de logs originels est une bonne idée.

Les intrus modifient généralement les fichiers de logs pour effacer leurs traces, mais on devrait néanmoins y chercher des événements inhabituels. Vous pourriez remarquer l'intrus en train d'essayer d'obtenir l'accès, ou exploiter un programme pour obtenir le compte root. Vous devriez voir des entrées de logs avant que l'intrus n'ait eu le temps de les modifier.

Vous devriez aussi vous assurer de bien séparer les entrées auth des autres données de logs, y compris les tentatives de changer d'utilisateur en utilisant su, tentatives de connexion, et autres informations des comptes utilisateurs.

Si possible, configurez syslog pour envoyer une copie des données les plus importantes vers un système sûr. Cela empêchera un intrus d'effacer ses traces en effaçant ses tentatives de login/su/ftp/etc. Voir la page de man de syslog.conf, et consulter l'option @.

Il y a plusieurs programmes syslogd plus évolués. Consultez security.sdsc.edu pour Secure Syslog. Secure Syslog vous permet de crypter vos entrées syslog et vous assure que personne ne les a modifiées.

Un autre syslogd avec plus de fonctions est syslog-ng. Il permet beaucoup plus de flexibilité dans la journalisation et peut crypter vos flots syslog distants pour empêcher leur corruption.

Enfin, les fichiers de logs sont encore plus inutiles lorsque personne ne les lit. Prenez un peu de temps régulièrement pour parcourir vos fichiers de logs, et imprégnez vous de ce à quoi ils ressemblent les jours normaux. Cela peut vous aider à repérer les choses anormales.

La majorité des utilisateurs installent leur système à partir d'un CD-ROM. A cause du rythme rapide des correctifs de sécurité, de nouveaux programmes (corrigés) sont sans arrêt publiés. Avant de connecter votre machine au réseau, c'est une bonne idée de lancer MandrivaUpdate (sur une autre machine connectées à Internet bien sûr) et installer tous les paquetages mis à jour depuis que vous avez reçu vos CD-ROM. Souvent, ces paquetages contiennent d'importants correctifs de sécurité, c'est donc une bonne idée de les installer.

Repérer une violation de sécurité sur le vif peut être une expérience stressante. Comment vous réagissez peut avoir de graves conséquences.

Si la violation que vous voyez est physique, il y a des chances que vous voyiez quelqu'un en train de violer votre maison, bureau ou laboratoire. Vous devriez avertir les autorités locales. Dans un laboratoire, vous pourriez voir quelqu'un en train d'essayer d'ouvrir un boîtier ou de redémarrer une machine. Suivant votre compétence et le règlement, vous pouvez leur demander d'arrêter ou contacter le personnel de sécurité local.

Si vous avez détecté un utilisateur local en train d'essayer de compromettre votre sécurité, la première chose à faire est de confirmer qu'il est bien celui que vous pensez. Vérifiez le site depuis lequel il est connecté. Est-ce le site habituel? Non? Alors utilisez un moyen non électronique pour rentrer en contact. En l'occurrence, appelez le par téléphone ou allez à leur bureau/maison pour lui parler. S'ils admettent qu'ils sont connectés, vous pouvez leur demander d'expliquer ce qu'ils étaient en train de faire ou leur intimer d'arrêter. S'ils ne sont pas connectés, et n'ont aucune idée de ce dont vous parlez, l'incident demandera sans doute plus d'investigations. Examinez bien chaque incident, et récoltez le plus d'informations possibles avant de faire une quelconque accusation.

Si vous avez détecté une violation réseau, la première chose à faire (si vous le pouvez) est de déconnecter votre réseau. S'ils sont connectés par modem, débranchez le câble du modem; s'ils sont connectés par Ethernet, déconnectez le câble Ethernet. Cela les empêchera de faire plus de dommages, et ils interpréteront cela comme un problème réseau plutôt qu'une détection.

Si vous ne pouvez pas déconnecter le réseau (si vous avez un site occupé, ou n'avez pas le contrôle physique des machines), la meilleure étape suivante est d'utiliser quelque chose comme les encapsuleurs TCP ou ipfwadm pour refuser l'accès au site de l'intrus.

Si vous ne pouvez pas refuser tous les utilisateurs du même hôte que celui de l'intrus, bloquer le compte de cet utilisateur devrait fonctionner. Notez que bloquer un compte n'est pas chose aisée. Vous devez prendre en compte les fichiers .rhosts, accès FTP, et une foule de portes dérobées possibles.

Après que vous ayez fait l'une des choses précédentes (déconnecté le réseau, refusé l'accès depuis leur site, et/ou désactivé leur compte), vous devez tuer tous leurs processus utilisateurs et les déconnecter.

Vous devriez soigneusement surveiller votre site dans les minutes qui suivent, car l'attaquant pourra essayer de revenir. Peut-être en utilisant un autre compte, et/ou en utilisant une autre adresse réseau.

Alors vous avez détecté une violation qui a déjà eu lieu ou vous l'avez détectée et avez mis dehors (espérons-le) l'intrus. Et maintenant?

Le site LinuxSecurity contient de nombreuses références en matière de sécurité Linux et Open Source, lesquelles sont écrites par le personnel de LinuxSecurity ainsi que par des experts à travers le monde.

Le CERT (Computer Emergency Response Team) est l'équipe de réponses aux urgences informatiques. Ils émettent souvent des alertes sur les attaques actuelles et des solutions. Consultez ftp://ftp.cert.org pour plus d'informations.

ZEDZ (anciennement Replay) possède des archives de plusieurs programmes de sécurité. Comme ils sont situés en dehors des États-Unis, ils n'ont pas à respecter les lois de restriction des États-Unis au sujet de la cryptographie.

Matt Blaze est l'auteur de CFS et un grand défenseur de la sécurité. Les archives de Matt sont disponibles sur att.com

Liste de sécurité Mandriva Linux : vous pouvez être informé de chaque correctif de sécurité en vous abonnant à notre liste : security.

Bugtraq : Pour vous abonner à Bugtraq, envoyer un message à listserv@netspace.org contenant dans le corps « subscribe bugtraq ». (voir le lien ci-dessus pour les archives).

CIAC : Envoyez un message à majordomo@tholia.llnl.gov. Dans le corps du message écrivez : « subscribe ciac-bulletin ».

Il y a un certain nombre de bons livres sur la sécurité. Cette section en cite quelques-uns. En plus des livres spécialement sur la sécurité, la sécurité est traitée par bon nombre d'autres livres sur l'administration système.

draksec est une interface graphique à msec (qui signifie Mandriva Linux Security Tool, soit Outil de Sécurisation Mandriva Linux). Il vous permet de changer le niveau de sécurité de votre système et de configurer toutes les options que propose msec.

Les deux fonctions de msec sont la configuration du comportement du système et les vérifications périodiques de l'état du système. Chaque niveau de sécurité modifie la configuration système, le rendant plus sécurisé et vérifiant de plus en plus d'aspects relatifs à la sécurité.

4.13.1.1. Choix du niveau de sécurité

	Note
	Cet outil est seulement disponible en mode expert. Choisissez Options → Mode Expert depuis le menu puis accédez à la section Sécurité du Centre de contrôle Mandriva Linux.

Figure 5.9. Choix du niveau de sécurité de votre système

Vous devez simplement choisir le Niveau de sécurité désiré dans la liste déroulante : les changements prendront effet lorsque vous appuierez sur OK. Lisez attentivement le texte d'aide concernant les niveaux de sécurité afin que vous sachiez ce qu'un niveau de sécurité particulier implique.

Astuce

Si vous souhaitez vérifier quelles options sont activées pour un niveau de sécurité donné, consultez les trois autres onglets : Options réseau, Options système et Vérifications périodiques. Cliquez sur le bouton Aide pour obtenir une présentation des options ainsi que leurs valeurs par défaut. Si ces valeurs ne vous conviennent pas, libre à vous de les modifier. Lisez Section 4.13.1.2, « Modification d'un niveau de sécurité » pour plus de détails.

En cochant la case Alertes de sécurité, les alertes de sécurité générées par msec seront envoyées par courrier électronique à l'Administrateur sécurité défini ici. Vous pouvez utiliser soit un utilisateur local, soit une adresse courriel complète.

	Avertissement
	Il est vivement recommandé d'activer l'option des alertes de sécurité afin que l'administrateur soit immédiatement informé d'éventuels problèmes de sécurité. Dans le cas contraire, l'administrateur devra régulièrement consulter les fichiers journaux relatifs.

4.13.1.2. Modification d'un niveau de sécurité

En cliquant sur chacun des onglets d'Options, vous aurez accès à la liste de toutes les options de sécurité de msec. Cela vous permettra de définir votre propre niveau de sécurité, basé sur le niveau de sécurité prédéfini que vous avez choisi précédemment.

Figure 5.10. Modification des options MSEC standard

Pour chaque onglet, il y a deux colonnes :

1. Liste des options. Toutes les options disponibles sont listées.

2. Valeur. Vous pouvez alors choisir pour chaque option^[1] dans la liste déroulante correspondante :

   • Oui. Activer cette option quelle que soit la valeur initiale.

   • Non. Désactiver cette option quelle que soit la valeur initiale.

   • Choix par défaut. Maintenir le comportement par défaut.

   • Ignorer. Utilisez cette option si vous souhaitez que ce test ne soit pas effectué.

   • TOUS, LOCAL, AUCUN. La signification de ceci dépend de l'option à laquelle elle se rapporte. Lisez l'aide (en cliquant sur le bouton Aide) pour plus d'information.

Cliquez sur OK pour accepter les niveaux courants de sécurité avec les options personnalisées, les appliquer au système et quitter l'application.

drakperm vous permet de configurer les permissions qui devraient être associées à chaque fichier et dossier du système : fichiers de configuration, fichiers personnels, programmes, etc. Si les propriétaires et les permissions répertoriés ne correspondent pas aux permissions actuelles, msec (qui signifie Mandriva Linux Security Tool soit « Outil de Sécurité Mandriva Linux » en français) les changera lors de ses contrôles (effectués toutes les heures). Ces modifications peuvent aider à éviter des trous de sécurité ou une intrusion potentielle.

	Note
	Cet outil ne s'affiche qu'en mode expert. Choisissez Options → Mode Expert depuis le menu, puis accédez à la section Sécurité du Centre de contrôle Mandriva Linux.

Figure 5.11. Configuration des vérifications des permissions des fichiers

La liste des fichiers et dossiers qui apparaît dépend du niveau de sécurité configuré dans msec et des permissions prévues à ce niveau de sécurité. Pour chaque Chemin est spécifié le propriétaire (utilisateur), le groupe propriétaire (Groupe) et les Permissions. Dans le menu déroulant, vous pouvez choisir d'afficher les règles propres à msec (Réglages système), vos règles (Réglages personnalisés) ou les deux (Réglages personnalisés et système) comme montré dans l'exemple Figure 5.11, « Configuration des vérifications des permissions des fichiers ».

	Note
	Les règles système ne sont pas modifiables, comme le montre le symbole « Sens interdit » visible sur la gauche. Toutefois, vous pouvez les redéfinir en ajoutant des règles personnalisées.

Si vous désirez définir des règles précises pour certains fichiers ou modifier le comportement par défaut, choisissez Réglages personnalisés dans la liste, puis cliquez sur le bouton Ajouter une règle.

Figure 5.12. Ajout d'une règle

Imaginons que votre niveau de sécurité soit actuellement configuré à 3 (haut). Cela signifie que les répertoires personnels de vos utilisateurs ne pourront être consultés que par leurs propriétaires. Si vous désirez partager le contenu du dossier personnel de Pierre avec d'autres utilisateurs, vous devez modifier les permissions du répertoire /home/pierre/.

	Avertissement
	msec change uniquement les permissions plus souples que celles requises à un niveau de sécurité donné. Ce qui signifie que pour le changement ci-dessus, les permissions doivent être changées manuellement. Vous pouvez utiliser Konqueror en modifiant les propriétés de permission de votre répertoire personnel et en cochant l'option Appliquer les modifications aux sous-dossiers et à leur contenu.

Si vous créez plusieurs règles, vous pouvez changer leurs priorités en les déplaçant dans la liste. Utilisez les boutons Monter et Descendre après avoir sélectionné vos règles pour avoir plus de contrôle sur les permissions du système.