La sécurité locale commence par l'environnement physique dans lequel l'ordinateur est installé. Installez votre ordinateur de manière dans un endroit où le niveau de sécurité correspond à vos besoins et à vos exigences. L'objectif principal de la sécurité locale consiste à séparer les différents utilisateurs les uns des autres de manière à ce qu'aucun utilisateur ne puisse s'accaparer les droits ou l'identité d'un autre utilisateur. Cela s'applique dans tous les cas, et en particulier, naturellement, aux droits de l'utilisateur root qui possède les pleins pouvoirs dans le système ; il peut notamment, sans mot de passe, prendre l'identité de n'importe quel utilisateur local et lire tous les fichiers locaux.

Votre système Linux n'enregistre pas les mots de passe en texte clair pour ensuite comparer le mot de passe saisi avec celui qui est enregistré. En cas de vol du fichier dans lequel sont enregistrés les mots de passe, tous les comptes de votre système seraient compromis. Au contraire, votre mot de passe est enregistré sous sa forme chiffrée et à chaque fois que vous saisissez votre mot de passe, il est à nouveau chiffré et le résultat est comparé avec ce qui est enregistré en tant que mot de passe chiffré. Cela n'a naturellement un sens que s'il n'est pas possible de calculer le mot de passe en clair à partir du mot de passe chiffré.

On utilise à cet effet un algorithme spécial, appelé algorithme à trappe parce qu'il ne fonctionne que dans un sens. Un attaquant ayant pris possession du mot de passe chiffré ne peut pas simplement calculer et obtenir le mot de passe, il doit en revanche essayer toutes les combinaisons de caractères possibles pour un mot de passe pour trouver une combinaison qui une fois codée ressemble au mot de passe qu'il détient. Avec des mots de passe de huit lettres, il existe un nombre considérable de combinaisons possibles.

L'un des arguments pour la sécurité de cette méthode dans les années 70 était que l'algorithme utilisé était particulièrement lent et qu'il fallait plusieurs secondes pour chiffrer un mot de passe. Cependant, les ordinateurs actuels peuvent sans effort réaliser de plusieurs centaines de milliers à plusieurs millions de chiffrements par seconde. C'est pour cette raison que les mots de passe chiffrés ne doivent pas être visibles de tous les utilisateurs (un utilisateur normal ne peut pas lire /etc/shadow) et les mots de passe ne doivent pas être faciles à deviner dans le cas où les mots de passe chiffrés deviendraient lisibles suite à une erreur. Il n'est pas très utile de « transformer » un mot de passe tel que « tantelise » en « t@nt31ls3 ».

Le remplacement de certaines lettres d'un mot par des chiffres leur ressemblant n'est pas très sûr et peut facilement être déchiffré par des programmes de craquage qui utilisent des dictionnaires. Il est préférable d'utiliser des combinaisons de lettres qui ne constituent pas un mot connu et qui n'ont une signification personnelle que pour l'utilisateur, comme les premières lettres des mots d'une phrase ou par exemple un titre de livre comme « Le nom de la rose d'Umberto Eco ». Vous pourriez ainsi obtenir un bon mot de passe : « LNdlRdUE9 ». Un mot de passe tel que « bonvin » ou « Jasmin76 » pourrait facilement être deviné par quelqu'un vous connaissant ne serait-ce que superficiellement.

Configurez votre système de façon à interdire tout démarrage à partir d'une disquette ou d'un CD en supprimant les lecteurs correspondants ou en définissant un mot de passe du BIOS et en n'autorisant dans le BIOS que l'amorçage à partir du disque dur. Généralement, les systèmes Linux démarrent avec un gestionnaire de démarrage qui permet de passer des options supplémentaires au noyau à démarrer. Interdisez aux autres l'utilisation de ces paramètres en configurant un mot de passe supplémentaire dans /boot/grub/menu.lst (voir Chapitre 8, Le gestionnaire d'amorçage). Ces options sont périlleuses en termes de sécurité car non seulement le noyau s'exécute avec les droits de l'utilisateur root mais il est la première autorité qui offre, dès l'amorçage, les droits de l'utilisateur root.

Un principe général consiste à toujours travailler avec les privilèges les plus bas possibles pour une tâche donnée. Il n'est effectivement absolument pas nécessaire de lire et d'écrire son courrier en tant que root. Si le programme de messagerie que vous utilisez comporte un bogue, celui-ci peut être exploité pour une attque qui agit alors avec exactement les droits que vous aviez au moment de l'accès au profgramme. En suivant le principe énoncé ici, vous pouvez limiter les dégâts.

Les droits individuels des plus de 200 000 fichiers d'une distribution SUSE sont attribués avec soin. L'administrateur d'un système ne doit installer de logiciels supplémentaires ou d'autres fichiers qu'avec la plus grande précaution et faire particulièrement attention aux droits attribués aux fichiers. Les administrateurs expérimentés et soucieux de la sécurité utilisent toujours l'option -l de la commande ls pour obtenir une liste complète des fichiers et de leurs droits d'accès afin de pouvoir reconnaître immédiatement les droits de fichiers mal définis. Un attribut mal défini ne signifie pas seulement que les fichiers peuvent être modifiés ou supprimés, mais également que les fichiers modifiés peuvent être exécutés par l'utilisateur root ou, dans le cas de fichiers de configuration de programmes, utilisés en tant qu'utilisateur root. Cela permettrait à un attaquent d'augmenter ses possibilités de façon considérable. On appelle ce genre d'attaque des œufs de coucou parce que le programme (l'œuf) est exécuté (couvé) par un utilisateur étranger (l'oiseau), un peu comme un coucou se débrouille pour faire couver ses œufs par d'autres oiseaux.

Les systèmes SUSE LINUX disposent des fichiers permissions, permissions.easy, permissions.secure et permissions.paranoid dans le répertoire /etc. Dans ces fichiers sont définis des droits importants tels que les répertoires dans lesquels tout utilisateur a des droits d'écriture, ou les bits « setuser ID » des fichiers. Ces bits de changement d'identité font qu'un programme ne s'exécute pas avec les droits du propriétaire du processus qui l'a démarré mais avec les droits du propriétaire du fichier, et c'est généralement l'utilisateur root). L'administrateur dispose du fichier /etc/permissions.local dans lequel il peut procéder à ses propres modifications.

Vous pouvez également choisir confortablement avec YaST dans l'option de menu ‘Sécurité’ lequel de ces fichiers sera utilisé par les programmes de configuration de SUSE pour l'attribution des droits. Vous trouverez plus d'informations à ce sujet directement dans le fichier /etc/permissions et la page de manuel de la commande chmod (man chmod).

À chaque fois qu'un programme traite des données qui se trouvent ou se trouvaient sous le contrôle d'un utilisateur dans un format donné, nous vous recommandons la plus grande vigilance. Le programmeur de l'application aussi doit faire preuve de vigilance : il doit s'assurer que les données sont correctement interprétées par le programme, qu'elles n'ont à aucun moment été écrites dans un espace mémoire trop petit et qu'il transmet les données d'une manière cohérente à l'aide de son propre programme et des interfaces définies à cet effet.

Il y a débordement de tampon (buffer overflow) quand, lors de l'écriture à l'intérieur d'une mémoire tampon, on ne fait pas attention à la taille réelle du tampon. Il se peut que les données (qui proviennent de l'utilisateur) nécessitent un peu plus de place que disponible dans le tampon. Avec ce débordement de tampon au delà de ses capacités, il se peut qu'un programme, du fait des données qu'il doit en théorie seulement traiter, exécute des morceaux de code choisis par l'utilisateur et non par le programmeur. Il s'agit d'une erreur grave notamment quand le programme fonctionne avec des droits particuliers voir Section 34.4.1.4, « Droits d'accès »).

Les bogues dans les chaînes de format fonctionnent quelque peu différemment mais à nouveau les données saisies par l'utilisateur peuvent détourner le programme de sa vocation d'origine. Ces erreurs de programmation sont normalement exploitées par les programmes exécutés avec des privilèges élevés, comme par exemple les programmes setuid et setgid. Vous pouvez donc vous protéger ainsi que votre système contre ce type d'erreurs en éliminant les droits d'exécution particuliers des programmes. Ici aussi s'applique donc le principe des privilèges les plus restreints possibles (voir Section 34.4.1.4, « Droits d'accès »).

Comme les débordements de tampon et les bogues dans les chaînes de format sont des erreurs qui se présentent lors du traitement des données utilisateur, elles ne sont pas nécessairement exploitables uniquement quand on dispose déjà d'un accès à un login local. Beaucoup des erreurs connues peuvent être exploitées par l'intermédiaire d'une connexion réseau. C'est pour cette raison que l'on ne peut pas associer les débordements de tampon et les bogues dans les chaînes de format directement à l'ordinateur local ou au réseau.

Contrairement à ce que l'on croit généralement, il existe aussi des virus pour Linux. Cependant, les virus connus ont été créés par leurs auteurs en tant que proof of concept, à savoir une démonstration du bien-fondé d'une technique. Aucun de ces virus n'a encore été observé dans la nature.

Pour se propager, les virus ont besoin d'un hôte sans lequel ils ne peuvent survivre. Cet hôte est un programme ou un emplacement sur le disque important pour le système, comme par exemple l'enregistrement d'amorçage maître et le code de programme du virus doit pouvoir y écrire. Linux, du fait de ses fonctionnalités multi-utilisateurs, peut limiter l'accès en écriture aux fichiers et notamment aux fichiers système. Si vous travaillez en tant qu'utilisateur root vous augmentez la probabilité d'infecter votre système avec ce type de virus. Si vous observez cependant la règle des privilèges les plus restreints possibles, il devient difficile d'être infecté par un virus sous Linux.

En outre, vous ne devriez jamais exécuter à la légère un programme que vous avez récupéré sur l'Internet et dont vous ne connaissez pas l'origine. Les paquetages rpm SUSE portent une signature cryptographique et témoignent avec cette signature numérique du soin apporté par SUSE lors de l'élaboration de ses paquetages. Les virus sont l'un des symptômes classiques d'un système hautement sécurisé devenu non sûr lorsque l'administrateur ou même l'utilisateur n'ont pas une parfaite conscience de la sécurité.

Il ne faut pas confondre les virus avec les vers qui sont également des phénomènes de la sécurité réseau mais qui n'ont en revanche pas besoin d'hôte pour se propager.

Dans le domaine de la sécurité locale il fallait séparer les utilisateurs travaillant sur le même ordinateur, notamment l'utilisateur root. En matière de sécurité réseau, en revanche, c'est l'intégralité du système qu'il faut protéger contre les attaques en provenance du réseau. L'authentification des utilisateurs dans le cas de la connexion classique avec un nom d'utilisateur et un mot de passe relève de la sécurité locale. En cas de connexion par le réseau, il faut différencier les deux aspects de la sécurité : avant la réussite de l'authentification, on parle de sécurité réseau, après le login, il s'agit de sécurité locale.

Comme déjà mentionné précédemment, la transparence du réseau est une caractéristique fondamentale d'un système Unix. Avec X11, le système de fenêtrage d'Unix, cela l'est au plus haut point ! Vous pouvez ainsi simplement vous connecter à un ordinateur distant et y démarrer un programme qui s'affichera alors via le réseau sur votre ordinateur.

Si un client X doit être affiché via le réseau sur notre serveur X, alors le serveur doit protéger la ressource qu'il gère (l'affichage) contre les accès non autorisés. Concrètement, cela signifie ici que le programme client doit obtenir des droits. Pour X Window, cela se passe de deux manières différentes : un contrôle d'accès fondé sur un ordinateur ou sur un cookie. Le premier se fonde sur l'adresse IP de l'ordinateur sur lequel le programme client doit être exécuté et est contrôlé avec le programme xhost. Le programme xhost inscrit une adresse IP d'un client légitime dans une mini-base de données sur le serveur X. Une authentification uniquement fondée sur une adresse IP n'est cependant pas considérée comme sûre. Il pourrait très bien y avoir un deuxième utilisateur actif sur l'ordinateur avec le programme client et celui-ci aurait, comme quiconque qui déroberait l'adresse IP, accès au serveur X. C'est pour cette raison qu'il est inutile d'aller plus loin au sujet de ces méthodes. Les pages du manuel obtenues avec la commande  xhost donnent davantage d'explications sur leur fonctionnement.

Dans le cas d'un contrôle d'accès fondé sur un cookie, une chaîne de caractères connue uniquement par le serveur X et l'utilisateur connecté de manière légitime est utilisée comme preuve d'identité, un peu à l'instar d'un mot de passe. Ce cookie (le mot anglais cookie signifie biscuit et désigne ici les biscuits porte-bonheur chinois qui contiennent une maxime) est enregistré dans le fichier .Xauthority dans le répertoire personnel de l'utilisateur lors du login et est ainsi à la disposition de chaque client X Window qui souhaite afficher une fenêtre sur le serveur X. Le programme xauth fournit à l'utilisateur l'outil pour analyser le fichier .Xauthority. Si vous supprimez ou renommez le fichier .Xauthority de votre répertoire personnel, vous ne pourrez plus ouvrir d'autres fenêtres ou de nouveaux clients X. Vous trouverez plus d'informations sur les aspects liés à la sécurité de X Window dans la page de manuel de Xsecurity (man Xsecurity).

SSH (secure shell) peut être utilisé pour chiffrer complètement une connexion réseau et la rediriger vers un serveur X de façon transparente sans que le mécanisme de chiffrement soit perçu par l'utilisateur. Ceci est également appelé redirection X. La redirection X est réalisée en simulant un serveur X du côté du serveur et en définissant une variable DISPLAY pour l'interpréteur de commandes sur l'hôte distant. Vous trouverez plus de détails sur SSH dans Section 34.2, « SSH – travailler en réseau en toute sécurité ».

	Avertissement
Si vous pensez que l'ordinateur auquel vous vous connectez n'est pas sûr, vous ne devez alors pas autoriser la redirection X. Lorsque la redirection X est activée, des attaquants peuvent aussi se connecter en s'authentifiant auprès de votre serveur X via votre connexion SSH et, par exemple, épier votre clavier.

Comme évoqués dans Section 34.4.1.5, « Débordements de tampon et bogues dans des chaînes de format », les débordements de tampon et bogues dans les chaînes de format devraient être considérées comme des thèmes concernant à la fois la sécurité locale et la sécurité en réseau. Comme pour les variantes locales de ces erreurs de programmation, les débordements de tampon des services réseau sont la plupart du temps utilisés pour obtenir les droits de l'utilisateur root. Si tel n'est pas le cas, l'attaquant peut alors au moins réussir à accéder à un compte local sans privilèges d'où il pourrait par la suite exploiter les éventuels problèmes de sécurité locale.

Les débordements de tampon et les bogues dans les chaînes de format sont probablement les variantes les plus fréquentes d'attaques distantes exploitables sur le réseau. On trouve sur les listes de diffusion relatives à la sécurité des exploits (des programmes qui utilisent les brèches qui viennent d'être découvertes). Même une personne ne connaissant pas les détails précis de la faille de sécurité peut l'exploiter. L'expérience a montré que la libre disposition des codes d'exploit (exploit codes) a, de manière générale, amélioré la sécurité des systèmes d'exploitation, ce qui est probablement dû au fait que les éditeurs de systèmes d'exploitation ont été obligés de régler les problèmes de leurs logiciels. Comme dans le cas des logiciels libres le code source est à la disposition de tous, (SUSE LINUX fournit toutes les sources disponibles), quelqu'un qui découvre une brèche et le code exploit correspondant peut aussitôt faire une proposition de correctif pour le problème en question.

Le but de ce type d'attaques est d'interrompre un programme d'un serveur (voire le système tout entier). Cela peut être provoqué par différentes méthodes : en provoquant une surcharge du serveur, en l'occupant en lui envoyant des paquets dont le contenu n'a pas de signification ou en exploitant un débordement de tampon distant. L'objectif d'un déni de service peut souvent tout simplement être que le service ne soit plus disponible. L'absence d'un service peut toutefois avoir d'autres conséquences : les communications peuvent devenir vulnérables à des attaques de l'homme au milieu (reniflage de paquets, détournement de connexion TCP, usurpation) et corruption de DNS.

De manière générale, une attaque distante réalisée par un attaquant qui a pris une position entre deux partenaires de communication s'appelle une attaque de l'homme au milieu (man in the middle). Les attaques de l'homme au milieu présentent pratiquement comme point commun le fait que la victime ne se doute généralement de rien. Il existe plusieurs variantes. Par exemple, l'attaquant peut prendre la main sur la requête de connexion et la diriger lui-même vers la machine cible. La victime a donc sans le savoir établi une connexion avec le mauvais ordinateur parce que ce dernier s'identifie comme étant la cible légitime.

L'attaque de l'homme au milieu la plus simple est le reniflage de paquets (sniffing). L'attaquant épie « simplement » le trafic réseau. Dans une attaque plus complexe, « l'homme au milieu » peut essayer de prendre la main sur une connexion déjà établie (détournement, en anglais hijacking). L'attaquant doit, pour ce faire, analyser pendant un moment les paquets qui lui sont adressés pour pouvoir pronostiquer les numéros de séquence TCP corrects de la connexion. Quand il prend ensuite le rôle de la cible de la connexion, les victimes s'en aperçoivent car ils reçoivent un message d'erreur annonçant que la connexion a été interrompue en raison d'une défaillance.

L'attaquant peut tout particulièrement tirer profit de cette technique car il existe des protocoles non protégés contre le détournement par le chiffrement pour lesquels une authentification ne se produit qu'au début de la connexion.

On parle d'usurpation lors d'une attaque avec modification des paquets pour qu'ils contiennent des données sources contrefaites, généralement l'adresse IP. La plupart des variantes d'attaques actives impliquent l'envoi de paquets falsifiés ce qui sous Linux ne peut être effectué que par le super-utilisateur (root).

La plupart des possibilités d'attaques sont souvent combinées avec un déni de service. Si l'attaquant a une possibilité de séparer un ordinateur brusquement du réseau, même si ce n'est que pour une courte période, cela lui rend une attaque active plus facile parce que l'hôte ne pourra pas perturber l'attaque pendant un certain temps.

L'attaquant essaie de corrompre le cache d'un serveur DNS avec des paquets de réponse DNS falsifiés pour qu'il transmette certaines données à une victime demandant des informations à ce serveur. Pour passer ce type de fausses informations de manière crédible à un serveur DNS, l'attaquant doit normalement obtenir quelques paquets du serveur et les analyser. Comme de nombreux serveurs ont établi un rapport de confiance vis-à-vis des autres ordinateurs basé sur leur adresse IP ou leur nom d'ordinateur, une telle attaque peut très rapidement porter ses fruits, même si les précautions nécessaires ont été prises. La condition essentielle est une bonne connaissance des relations de confiance entre les ordinateurs. Du point de vue de l'attaquant, il est la plupart du temps inévitable de programmer précisément dans le temps un déni de service contre un serveur DNS dont les données doivent être falsifiées. Pour y remédier, il convient à nouveau d'utiliser une connexion chiffrée avec une technique cryptographique capable de vérifier l'identité de la cible de la connexion.

On fait souvent l'amalgame entre les vers et les virus. Il existe cependant une différence sensible entre les deux : un ver n'a nullement besoin d'infecter un programme hôte et il est conçu pour se propager le plus rapidement possible sur le réseau. Les vers les plus connus comme Ramen, Lion ou Adore utilisent les brèches de sécurité de programmes serveur tels que bind8 ou lprNG. Il est relativement facile de se protéger contre les vers, car entre le moment de la découverte des brèches utilisées et le moment de la naissance du vers, il s'écoule généralement quelques jours qui laissent suffisamment de temps pour développer des paquetages de mise à jour ; en partant du principe, naturellement, que l'administrateur applique aussi les mises à jour de sécurité à son système.