4.5. Sécurité et confidentialité

L'une des principales caractéristiques d'un système Linux ou UNIX est sa capacité à gérer plusieurs utilisateurs simultanément et à les autoriser à effectuer plusieurs tâches en même temps sur le même ordinateur. De plus, le système d'exploitation est transparent vis-à-vis du réseau. Ainsi, il arrive fréquemment que les utilisateurs ne sachent pas si les données et les applications qu'ils utilisent sont fournies localement à partir de leur machine ou si elles sont mises à disposition via le réseau.

Si vous utilisez la fonctionnalité multi-utilisateur, les données des différents utilisateurs doivent être stockées séparément. La sécurité et la confidentialité doivent être garanties. La sécurité des données a toujours été un sujet important, même avant que les ordinateurs soient reliés en réseau. Tout comme aujourd'hui, la principale préoccupation était de pouvoir conserver les données malgré la perte ou la défaillance du support de données, généralement le disque dur.

Cette section concerne essentiellement la confidentialité des données et la protection de la vie privée de l'utilisateur. Rappelons tout de même qu'une politique de sécurité globale doit toujours comprendre un système de sauvegarde régulier, éprouvé et en bon état de marche. Sans cela, vous risquez d'avoir de grandes difficultés à récupérer vos données en cas de défaillance matérielle ou si vous suspectez un individu d'avoir accédé de façon frauduleuse à vos fichiers, et de les avoir manipulés ou modifiés.

4.5.1. Sécurité locale et sécurité réseau

Il existe plusieurs moyens d'accéder aux données :

  • la communication personnelle avec les individus qui possèdent les informations souhaitées ou accèdent aux données sur un ordinateur ;

  • directement à partir de la console d'un ordinateur (accès physique) ;

  • via une ligne série ;

  • à l'aide d'une connexion réseau.

Quelle que soit la situation, l'utilisateur doit être authentifié pour pouvoir accéder aux ressources ou aux données en question. À cet égard, un serveur Web peut être moins limité mais vous ne souhaitez pas pour autant qu'il divulgue toutes vos données personnelles à n'importe quel internaute.

Le premier des cas mentionnés ci-dessus est celui qui fait le plus appel au facteur humain, comme lorsque vous êtes en relation avec un employé de banque et que vous devez prouver que vous êtes le titulaire du compte bancaire. Il vous demande alors de fournir une signature, un numéro d'identification ou un mot de passe pour prouver que vous êtes la personne que vous affirmez être. Il est parfois possible de soutirer des renseignements à une personne informée, en mentionnant simplement quelques fragments d'informations connues pour gagner sa confiance grâce à une rhétorique intelligente. La victime peut être amenée à révéler progressivement davantage d'informations, peut-être même sans en avoir conscience. Les pirates informatiques appellent cette technique l'ingénierie sociale (social engineering en anglais). Contre ce type d'attaque, le seul remède consiste à éduquer les personnes, à manipuler avec précaution vos informations et à prendre garde aux renseignements que vous communiquez. Avant de pénétrer dans les systèmes informatiques, les pirates tentent souvent de s'attaquer aux réceptionnistes, aux prestataires de services de la société, voire aux membres de la famille. Basées sur l'ingénierie sociale, ces attaques ne sont généralement découvertes que bien plus tard.

Une personne qui souhaite accéder à vos données de manière illégale peut également utiliser la méthode traditionnelle et tenter de pénétrer directement dans votre ordinateur. Vous devez donc le protéger contre toute falsification, afin que personne ne puisse supprimer, remplacer ou bloquer ses composants. Cette règle s'applique également aux sauvegardes, et même aux câbles réseau ou aux câbles d'alimentation. Vous devez également sécuriser la procédure d'amorçage puisque des combinaisons de touches connues peuvent provoquer un comportement anormal. Pour vous protéger, créez des mots de passe pour le BIOS et le chargeur d'amorçage.

Les terminaux série reliés aux ports série sont encore fréquemment utilisés aujourd'hui. Contrairement aux interfaces réseau, ils n'ont pas recours à un protocole réseau pour communiquer avec l'hôte. Un simple câble ou un port infrarouge permet de transmettre du texte en clair entre les périphériques. Le câble est le maillon faible de ce type de système : il suffit d'y connecter une vieille imprimante pour enregistrer tout ce qui passe par les câbles. Ce que l'on peut faire avec une imprimante peut aussi être effectué différemment, selon les efforts mis en oeuvre dans le cadre de l'attaque.

La lecture locale d'un fichier sur un hôte requiert l'application d'autres règles d'accès que l'ouverture d'une connexion réseau avec un serveur sur un hôte différent. Il y a une différence entre sécurité locale et sécurité réseau. Cette différence est le point où les données doivent être mises en paquets pour pouvoir être envoyées ailleurs.

4.5.1.1. Sécurité locale

La sécurité locale commence par l'environnement physique du lieu où est situé l'ordi­nateur. Installez votre machine à un endroit où la sécurité est conforme à vos attentes et vos besoins. La sécurité locale vise essentiellement à séparer les utilisateurs les uns des autres, de façon à ce qu'aucun d'eux ne puisse deviner les autorisations ou l'identité d'un autre. Il s'agit d'une règle générale à respecter mais qui s'applique plus particulièrement à l'utilisateur root, qui possède les pleins pouvoirs sur le système. Il peut ainsi prendre l'identité de n'importe quel autre utilisateur local sans devoir saisir de mot de passe et lire tous les fichiers locaux.

4.5.1.2. Mots de passe

Sous Linux, les mots de passe ne sont pas stockés en clair et la chaîne de caractères saisie n'est pas simplement mise en correspondance avec le modèle enregistré. Si tel était le cas, tous les comptes de votre système seraient exposés à un risque dès qu'un individu accéderait au fichier correspondant. Chaque mot de passe stocké est donc codé. Il est de nouveau codé lors de chaque saisie et les deux chaînes codées sont comparées. Cette technique n'est utile que s'il est impossible de recomposer le mot de passe en clair à partir du mot de passe codé.

On utilise à cet effet un algorithme particulier, appelé algorithme à trappe, parce qu'il ne fonctionne que dans un sens. Un pirate qui s'est emparé de la chaîne codée ne peut pas obtenir votre mot de passe en appliquant simplement le même algorithme. Il lui faudrait tester toutes les combinaisons de caractères possibles jusqu'à ce qu'il trouve une combinaison similaire à votre mot de passe lorsqu'il est codé. Avec des mots de passe de huit caractères, il existe un nombre considérable de combinaisons possibles.

Dans les années 70, cette méthode était considérée comme la plus sûre en raison de la vitesse relative de l'algorithme utilisé, qui mettait quelques secondes à coder un mot de passe. Depuis, les ordinateurs sont devenus suffisamment puissants pour effectuer plusieurs centaines de milliers, voire plusieurs millions de codages par seconde. Les utilisateurs standard ne doivent donc pas avoir accès aux mots de passe codés (ils ne peuvent pas lire le fichier /etc/shadow). Il est encore plus important que les mots de passe ne soient pas faciles à deviner, au cas où le fichier de mots de passe deviendrait accidentellement visible. Il n'est donc pas vraiment utile de « transformer » un mot de passe comme « intrigue » en « 1ntr1gu3 ».

Le remplacement de certaines lettres d'un mot par des chiffres qui leur ressemblent n'est pas suffisant. Les programmes de craquage qui utilisent des dictionnaires pour deviner les mots de passe connaissent ce genre de remplacement. Il est donc plus judicieux de créer un mot qui n'a aucun sens, sauf pour vous, par exemple les premières lettres d'une phrase ou le titre d'un livre, comme « Le Nom de la Rose » d'Umberto Eco. Vous obtiendriez un mot de passe très sûr : « LNdlRdUE ». En revanche, des mots de passe tels que « bordeaux » ou « xavier76 » pourraient facilement être devinés par quelqu'un qui vous connaît, ne serait-ce que superficiellement.

4.5.1.3. La procédure d'amorçage

Configurez votre système de façon à interdire tout démarrage à partir d'une disquette ou d'un CD. Pour ce faire, supprimez les lecteurs correspondants ou définissez un mot de passe BIOS et configurez le BIOS pour n'autoriser l'amorçage qu'à partir du disque dur. Un système Linux est généralement démarré par un chargeur d'amorçage, ce qui permet de transmettre des options supplémentaires au kernel démarré. Pour éviter que des tiers utilisent ces paramètres lors de l'amorçage, créez un mot de passe supplémentaire dans /boot/grub/menu.lst (reportez-vous au Chapitre 9, Chargeur d'amorçage). Cette procédure est déterminante pour la sécurité de votre système. Le kernel lui-même est exécuté avec les autorisations racine (root), mais la première autorité est celle qui accorde des autorisations de ce type lors du démarrage du système.

4.5.1.4. Autorisations de fichier

En règle générale, utilisez toujours les privilèges les plus restrictifs pour une tâche donnée. Par exemple, il n'est absolument pas nécessaire d'être un utilisateur root pour lire ou écrire un message. Si le programme de messagerie comporte un bogue, celui-ci peut être exploité pour une attaque qui agit alors avec exactement les mêmes autorisations que celles que vous aviez au lancement du programme. Vous limiterez les éventuels dégâts en suivant la règle ci-dessus.

Les autorisations associées aux plus de 200 000 fichiers inclus dans la distribution SUSE font l'objet d'un choix minutieux. Un administrateur système qui installe des logiciels supplémentaires ou d'autres fichiers doit être particulièrement prudent, notamment lorsqu'il définit les bits d'autorisation. Les administrateurs expérimentés et soucieux de la sécurité utilisent toujours l'option -l avec la commande ls pour obtenir une longue liste de fichiers, ce qui leur permet de détecter immédiatement toute autorisation de fichier incorrecte. Un attribut de fichier incorrect ne signifie pas uniquement que les fichiers ont pu être modifiés ou supprimés. Ces fichiers modifiés peuvent être exécutés par l'utilisateur root ou, dans le cas des fichiers de configuration, des programmes peuvent les utiliser avec les autorisations de l'utilisateur root. Cela offre encore plus de possibilités aux pirates informatiques. On appelle ce genre d'attaque des oeufs de coucou parce que le programme (l'oeuf) est exécuté (couvé) par un utilisateur étranger (l'oiseau), un peu comme un coucou se débrouille pour faire couver ses oeufs par d'autres oiseaux.

Un système SUSE Linux contient les fichiers permissions, permissions.easy, permissions.secure et permissions.paranoid, tous situés dans le répertoire /etc. Le but de ces fichiers est de définir des autorisations spéciales, notamment des répertoires pour lesquels tout utilisateur dispose de droits en écriture ou, pour les fichiers, le bit « setuser ID ». Grâce à ces bits de changement d'identité, un programme ne s'exécute pas avec les autorisations de l'utilisateur qui l'a démarré mais avec celles du propriétaire du fichier, qui est généralement l'utilisateur root. Un administrateur peut utiliser le fichier /etc/permissions.local pour ajouter ses propres paramètres.

Pour déterminer, parmi les fichiers ci-dessus, ceux qui seront utilisés par les programmes de configuration de SUSE pour définir les autorisations, sélectionnez Sécurité dans YaST. Pour en savoir plus à ce sujet, lisez les commentaires de /etc/permissions ou reportez-vous à la page de manuel sur chmod (man chmod).

4.5.1.5. Dépassement de tampon et bogues de chaîne de format

Vous devez être particulièrement attentif lorsqu'un programme est censé traiter des données susceptibles d'être modifiées par un utilisateur. Toutefois, ce conseil s'adresse davantage aux programmeurs d'application qu'aux utilisateurs standard. Le programmeur doit s'assurer que son application interprète correctement les données, sans les écrire dans un espace mémoire trop petit. En outre, le programme doit transmettre les données de façon homogène, à l'aide des interfaces définies à cet effet.

Un dépassement de tampon peut se produire si la taille réelle de la mémoire tampon n'est pas prise en compte lors de l'écriture des données dans ce tampon. Dans certains cas, ces données (telles qu'elles sont générées par l'utilisateur) utilisent plus d'espace que l'espace disponible dans le tampon. Les données sont donc écrites au-delà de l'extrémité de cette zone de tampon. Ainsi, il arrive qu'un programme soit en mesure d'exécuter des séquences de programme choisies par l'utilisateur (et non par le programmeur), au lieu de traiter simplement les données de l'utilisateur. Ce type de bogue peut avoir de graves conséquences, notamment si le programme est exécuté avec des privilèges particuliers (reportez-vous à Section 4.5.1.4, « Autorisations de fichier »).

Le fonctionnement des bogues de chaîne de format est légèrement différent mais, là encore, les données saisies par l'utilisateur peuvent détourner le programme. Ces erreurs de programmation sont généralement exploitées par les programmes exécutés avec des autorisations spéciales (par exemple, les programmes setuid et setgid). Vous pouvez donc protéger votre système et vos données contre ce type de bogue, en supprimant les autorisations d'exécution correspondantes des programmes. La meilleure méthode est encore une fois d'appliquer la stratégie d'utilisation des privilèges les plus limités possibles (reportez-vous à Section 4.5.1.4, « Autorisations de fichier »).

Le dépassement de tampon et les bogues de chaîne de format sont des bogues liés à la gestion des données utilisateur. Ils ne sont donc pas uniquement exploitables si l'accès a été accordé à un compte local. En effet, la plupart des bogues connus peuvent aussi être exploités sur une liaison réseau. Par conséquent, le dépassement de tampon et les bogues de chaîne de format concernent aussi bien la sécurité locale que la sécurité réseau.

4.5.1.6. Virus

Contrairement à ce que l'on pense, certains virus peuvent être exécutés sous Linux. Toutefois, les virus connus ont été créés par leurs auteurs dans le cadre d'une validation technique, pour démontrer que la technique fonctionne comme prévu. Jusqu'à présent, aucun de ces virus n'a été détecté dans la nature.

Pour se propager, les virus ont besoin d'un hôte, sans lequel ils ne peuvent pas survivre. Cet hôte est un programme ou une importante zone de stockage du système, comme le secteur d'amorçage principal, sur lequel le code programme du virus doit pouvoir écrire. Du fait de ses fonctionnalités multi-utilisateurs, Linux peut limiter l'accès en écriture à certains fichiers, et notamment aux fichiers système. Par conséquent, si vous travaillez en tant qu'utilisateur root, vous augmentez le risque d'infecter votre système avec ce type de virus. En revanche, si vous respectez le principe qui consiste à utiliser les privilèges les plus limités possibles, comme indiqué ci-dessus, le risque d'infection est faible.

D'autre part, vous devez toujours être prudent avant d'exécuter un programme provenant d'un site Internet que vous ne connaissez pas vraiment. Les paquetages RPM de SUSE comportent une signature cryptographique qui démontre le soin avec lequel ils ont été élaborés. Les virus prouvent généralement que l'administrateur ou l'utilisateur n'accorde pas une attention suffisante à la sécurité, et met en péril un système dont la conception même devrait lui conférer une sécurité à toute épreuve.

Ne confondez pas les virus et les vers, qui appartiennent entièrement au monde des réseaux. Les vers n'ont pas besoin d'un hôte pour se propager.

4.5.1.7. Sécurité réseau

La sécurité réseau permet de se protéger contre les attaques provenant de l'extérieur. La procédure de login classique, qui exige l'authentification de l'utilisateur à l'aide d'un nom d'utilisateur et d'un mot de passe, reste un problème de sécurité locale. En cas de login via un réseau, vous devez différencier les deux aspects de la sécurité. Ce qui se passe jusqu'à l'authentification proprement dite correspond à la sécurité réseau et tout ce qui se passe après correspond à la sécurité locale.

4.5.1.8. Système X Window et authentification X

Comme nous l'avons vu, la transparence du réseau est une caractéristique fondamentale du système UNIX. Elle l'est d'autant plus avec X, le système de fenêtrage des systèmes d'exploitation UNIX. En effet, vous n'aurez aucun problème pour vous loguer à un hôte distant et lancer un programme graphique, qui sera ensuite envoyé sur le réseau pour s'afficher sur votre ordinateur.

Si vous souhaitez afficher un client X à distance à l'aide d'un serveur X, ce dernier doit protéger les ressources qu'il gère (l'affichage) contre les accès non autorisés. En d'autres termes, certaines autorisations doivent être octroyées au programme client. X Window propose deux méthodes : le contrôle d'accès basé sur l'hôte et le contrôle d'accès basé sur les cookies. La première a recours à l'adresse IP de l'hôte sur lequel le client doit être exécuté. Cette opération est assurée par le programme xhost, qui entre l'adresse IP d'un client légitime dans une minuscule base de données qui appartient au serveur X. L'authentification à l'aide d'adresses IP n'est toutefois pas très sûre. Par exemple, en cas de présence d'un deuxième utilisateur travaillant sur l'hôte qui envoie le programme client, il aurait également accès au serveur X, comme une personne qui déroberait l'adresse IP. En raison de ces défauts, nous ne décrirons pas cette méthode d'authentification plus en détail. Pour en savoir plus, reportez-vous à la page de manuel sur man xhost.

Dans le cadre du contrôle d'accès basé sur les cookies, une chaîne de caractères connue uniquement par le serveur X et l'utilisateur autorisé est générée, un peu comme un badge d'identification. Le mot anglais cookie signifie biscuit et désigne ici les biscuits porte-bonheur chinois qui contiennent une maxime. Ce cookie est enregistré lors du login dans le fichier .Xauthority (dans le répertoire privé de l'utilisateur) et est mis à disposition de tout client X qui souhaite utiliser le serveur X pour afficher une fenêtre. L'utilisateur peut examiner le fichier .Xauthority à l'aide de l'outil xauth. Si vous renommez .Xauthority ou si vous le supprimez accidentellement de votre répertoire privé, vous ne pouvez plus ouvrir aucune nouvelle fenêtre ni aucun client X. Pour plus d'informations sur les mécanismes de sécurité du système X Window, reportez-vous à la page de manuel sur Xsecurity (man Xsecurity).

SSH (shell sécurisé) permet de coder complètement une connexion réseau et de la rediriger vers un serveur X de façon transparente, sans que le mécanisme de codage soit perçu par l'utilisateur. Cette opération est également appelée redirection X. La redirection X est réalisée en simulant un serveur X du côté serveur et en définissant une variable DISPLAY pour le shell sur l'hôte distant. Pour plus d'informations sur SSH, reportez-vous à la Section 4.2, « SSH : sécurisation des opérations réseau ».

[Warning]Avertissement

Si vous pensez que l'hôte auquel vous vous loguez n'est pas sûr, n'utilisez pas la redirection X. Lorsque la redirection X est activée, un pirate peut s'authentifier via votre connexion SSH pour pénétrer dans votre serveur X et épier votre clavier, par exemple.

4.5.1.9. Dépassement de tampon et bogues de chaîne de format

Comme l'indique Section 4.5.1.5, « Dépassement de tampon et bogues de chaîne de format », le dépassement de tampon et les bogues de chaîne de format concernent aussi bien la sécurité locale que la sécurité réseau. Comme pour les variantes locales de ces types de bogues, le dépassement de tampon des programmes réseau est essentiellement utilisé pour s'octroyer les autorisations racine (root), s'il est convena­blement exploité. Même si ce n'est pas le cas, un pirate peut utiliser ce bogue pour accéder à un compte local sans privilège, afin d'exploiter les autres faiblesses éventuelles du système.

Les dépassements de tampon et les bogues de chaîne de format sur une liaison réseau sont probablement les variantes les plus fréquentes d'attaques distantes en général. Les listes de diffusion sur la sécurité publient fréquemment des exploits, programmes qui permettent d'exploiter ces nouvelles failles de sécurité. Ils permettent de cibler la faiblesse sans connaître les détails du code. L'expérience a montré que la libre disposition des codes d'exploit a permis d'améliorer la sécurité des systèmes d'exploitation, puisque les fabricants de systèmes d'exploitation ont été obligés de régler les problèmes de leurs logiciels. Avec les logiciels libres, tout le monde a accès au code source (SUSE Linux est fourni avec tous les codes source disponibles), et toute personne qui découvre une faiblesse et son code d'exploit peut proposer un correctif pour réparer le bogue en question.

4.5.1.10. Déni de service

Le but d'une attaque par déni de service est de bloquer le programme d'un serveur, voire un système entier. Ce type d'attaque s'effectue de plusieurs manières : en surchargeant le serveur, en l'occupant avec des paquets de données inutiles ou en exploitant un dépassement de tampon à distance. Souvent, l'attaque par déni de service vise exclusivement à faire disparaître le service. Toutefois, une fois qu'un service est indisponible, les communications peuvent devenir vulnérables vis-à-vis des attaques de l'intercepteur (reniflage de paquets, détournement de connexions TCP, usurpation d'identité) et de l'empoisonnement DNS.

4.5.1.11. Attaques de l'intercepteur : reniflage, détournement, usurpation

En règle générale, toute attaque perpétrée à distance par un pirate informatique qui se place entre les hôtes en communication porte le nom d'attaque de l'intercepteur. Dans la quasi-totalité de ces attaques, la victime n'est généralement pas consciente de la situation. Il existe de nombreuses variantes. Par exemple, le pirate peut récupérer une requête de connexion et la transmettre à la machine cible. La victime a donc, sans le savoir, établi une connexion avec le mauvais hôte, parce que ce dernier s'identifie comme étant la cible légitime.

La forme d'attaque de l'intercepteur la plus simple porte le nom de reniflage de paquets (sniffer) : le pirate épie « simplement » le trafic réseau. Dans le cadre d'une attaque plus complexe, l'« intercepteur » peut essayer de prendre possession d'une connexion déjà établie (détournement). Pour ce faire, le pirate doit analyser les paquets pendant un certain temps, afin de pouvoir prédire les numéros de séquence TCP de la connexion. Lorsqu'il prend le rôle de l'hôte cible, la victime le remarque, puisqu'elle reçoit un message d'erreur qui indique que la connexion a été interrompue en raison d'une défaillance. Il existe des protocoles non protégés contre le détournement par codage, qui ne suivent qu'une simple procédure d'authentification lors de la connexion, ce qui facilite le travail des pirates.

L'usurpation est une attaque qui consiste à modifier les paquets pour qu'ils contiennent des données source falsifiées (généralement l'adresse IP). Les formes d'attaque les plus actives consistent à envoyer ces paquets falsifiés, tâche que seul le superutilisateur (utilisateur root) peut effectuer sous Linux.

La plupart des attaques mentionnées ci-dessus sont perpétrées en combinaison avec une attaque par déni de service. Si le pirate a la possibilité d'interrompre brusquement un certain hôte, même pour une courte durée, il pourra perpétrer plus facilement son attaque, puisque l'hôte ne sera pas en mesure de la contrer pendant ce délai.

4.5.1.12. Empoisonnement DNS

L'empoisonnement DNS signifie que le pirate corrompt le cache d'un serveur DNS en lui répondant avec des paquets de réponses DNS falsifiés. Il tente ainsi de faire en sorte que le serveur envoie certaines données à la victime qui demande des informations à ce serveur. La plupart des serveurs maintiennent une relation de confiance avec les autres hôtes, basée sur les adresses IP ou les noms d'hôte. Le pirate doit avoir une bonne connaissance de la structure réelle de cette relation de confiance entre les hôtes, afin de se faire lui-même passer pour un hôte digne de confiance. Généralement, il analyse certains paquets reçus du serveur, afin d'obtenir les informations nécessaires. Pour le pirate, il est souvent nécessaire de programmer également une attaque par déni de service opportune contre le serveur de noms. Pour vous protéger, utilisez des connexions codées qui sont capables de vérifier l'identité des hôtes auxquels vous vous connectez.

4.5.1.13. Les vers

On confond souvent les vers et les virus, mais il existe une différence évidente entre les deux. Contrairement aux virus, les vers n'ont pas besoin d'infecter un programme hôte pour vivre. En revanche, ils ont pour caractéristique de se propager le plus rapidement possible sur des structures réseau. Les vers apparus dans le passé, tels que Ramen, Lion ou Adore, utilisent les brèches de sécurité connues de programmes serveur comme bind8 ou lprNG. La protection contre les vers est relativement simple. Un certain laps de temps s'écoule entre la découverte d'une faille de sécurité et le moment où le ver s'attaque à votre serveur. Par conséquent, vous avez généralement le temps de vous procurer la version à jour du programme en question. L'administrateur doit toutefois installer les mises à jour de sécurité sur le système concerné.

4.5.2. Conseils et astuces en matière de sécurité

Pour assurer efficacement la sécurité, vous devez suivre l'évolution des produits et être au fait des derniers problèmes de sécurité. L'un des meilleurs moyens de protéger vos systèmes contre les problèmes de toutes sortes consiste à vous procurer et à installer le plus rapidement possible les paquetages mis à jour et recommandés par les annonces sur la sécurité. Les annonces de sécurité de SUSE sont publiées sur une liste de diffusion. Pour vous y inscrire, cliquez sur le lien suivant : http://www.novell.com/linux/security/securitysupport.html. La liste suse-security-announce@suse.de est une source d'informations de première main sur les paquetages mis à jour. Les membres de l'équipe de sécurité de SUSE comptent parmi ses collaborateurs les plus actifs.

La liste de diffusion suse-security@suse.de est le lieu idéal pour discuter des principaux problèmes de sécurité. Vous pouvez vous y inscrire sur la même page Web.

L'une des listes de diffusion les plus connues au monde en matière de sécurité est la liste bugtraq@securityfocus.com. Nous vous recommandons de vous abonner à cette liste de diffusion, qui reçoit entre 15 et 20 messages par jour. Pour plus d'informations, reportez-vous à http://www.securityfocus.com.

Voici quelques règles utiles en matière de sécurité :

  • Conformément à la règle préconisant d'utiliser l'ensemble d'autorisations le plus limité pour chaque tâche, évitez d'effectuer les tâches classiques en tant qu'utilisateur root. En plus de vous protéger contre vos propres erreurs, vous limiterez ainsi le risque d'oeuf de coucou et de contamination par un virus.

  • Si possible, essayez d'utiliser systématiquement des connexions codées pour travailler sur une machine distante. Il est recommandé d'utiliser ssh (shell sécurisé) à la place de telnet, ftp, rsh et rlogin.

  • Évitez d'utiliser des méthodes d'authentification basées sur les adresses IP uniquement.

  • Essayez de mettre à jour régulièrement les paquetages réseau les plus importants et inscrivez-vous aux listes de diffusion correspondantes pour recevoir les annonces sur les nouvelles versions de ces programmes (bind, sendmail, ssh, etc.). Le même principe s'applique pour les logiciels relatifs à la sécurité locale.

  • Modifiez le fichier /etc/permissions pour optimiser les autorisations des fichiers indispensables à la sécurité de votre système. Si vous supprimez le bit setuid d'un programme, il ne pourra sans doute plus remplir sa fonction correctement. En revanche, le programme ne représentera plus un risque de sécurité potentiel. Vous pouvez utiliser le même processus pour les fichiers et les répertoires pour lesquels tout utilisateur possède des droits en écriture.

  • Désactivez tous les services réseau dont vous n'avez pas absolument besoin pour que votre serveur fonctionne correctement. Votre système sera ainsi plus sûr. Utilisez le programme netstat pour identifier les ports ouverts (ceux dont l'état est LISTEN). Comme pour les options, nous vous recommandons d'utiliser netstat -ap ou netstat -anp. L'option -p permet d'identifier quel processus occupe quel port et sous quel nom.

    Comparez les résultats donnés par netstat et ceux d'une analyse approfondie des ports effectuée par un élément extérieur à votre hôte. Pour ce faire, vous pouvez utiliser l'excellent programme nmap, qui contrôle les ports de votre machine et en tire des conclusions au sujet des services en attente derrière ces ports. Toutefois, l'analyse des ports pouvant être interprétée comme un acte agressif, nous vous recommandons de demander l'autorisation expresse de l'administrateur avant de l'effectuer sur un hôte. Enfin, n'oubliez pas qu'il est important d'analyser les ports TCP, mais également les ports UDP (options -sS et -sU).

  • Pour surveiller l'intégrité des fichiers de votre système de façon fiable, utilisez le programme AIDE (Advanced Intrusion Detection Environment), disponible sur SUSE Linux. Codez la base de données créée par AIDE pour éviter que quelqu'un ne la falsifie. En outre, conservez une sauvegarde de cette base de données en dehors de votre machine, stockée sur un support de données externe non connecté à l'ordinateur par une liaison réseau.

  • Prenez toutes les précautions nécessaires lorsque vous installez un logiciel tiers. Il est déjà arrivé qu'un pirate intègre un cheval de Troie dans l'archive tar d'un logiciel de sécurité. Heureusement, il avait été rapidement détecté. Si vous installez un paquetage binaire, vous devez être sûr de sa provenance.

    Les paquetages RPM de SUSE comportent une signature gpg. Pour signer, SUSE utilise la clé suivante :

    ID:9C800ACA 2000-10-19 SUSE Package Signing Key <build@suse.de>

    Empreinte de la clé = 79C1 79B2 E1C8 20C1 890F 9994 A84E DAE8 9C80 0ACA

    La commande rpm --checksig package.rpm indique si la somme de contrôle et la signature d'un paquetage désinstallé sont correctes. Vous trouverez la clé sur le premier CD de la distribution et sur les principaux serveurs de clés existants.

  • Vérifiez régulièrement les sauvegardes de vos fichiers système et utilisateur. Rappelez-vous que si vous ne testez pas le fonctionnement de votre sauvegarde, elle peut être totalement inutile.

  • Vérifiez vos fichiers journaux. Si vous le pouvez, écrivez un petit script pour rechercher les entrées suspectes dans vos fichiers journaux. Il est vrai que cette tâche n'est pas évidente. Au final, vous seul pouvez déterminer les entrées inhabituelles et celles qui ne le sont pas.

  • Utilisez tcp_wrapper pour restreindre l'accès à chaque service exécuté sur votre machine. Vous disposez ainsi d'un contrôle explicite pour déterminer les adresses IP qui peuvent se connecter à un service. Pour plus d'informations sur tcp_wrapper, reportez-vous aux pages de manuel de tcpd et hosts_access (man 8 tcpd, man hosts_access).

  • Utilisez SuSEfirewall pour optimiser la sécurité offerte par tcpd (tcp_wrapper).

  • N'hésitez pas à être répétitif lorsque vous élaborez vos mesures de sécurité : un message en double est largement préférable à un message qui n'apparaît pas du tout.

4.5.3. Notification centralisée des problèmes de sécurité

Si vous découvrez un problème de sécurité (vérifiez d'abord les paquetages de mise à jour disponibles), envoyez un message électronique à security@suse.de. N'oubliez pas de joindre une description détaillée du problème, ainsi que le numéro de version du paquetage concerné. SUSE vous répondra le plus rapidement possible. Nous vous recommandons de coder vos messages électroniques avec la technologie pgp. La clé pgp de SUSE est la suivante :


ID:3D25D3D9 1999-03-06 SUSE Security Team <security@suse.de>
Key fingerprint = 73 5F 2E 99 DF DB 94 C4 8F 5A A3 AE AF 22 F2 D5

Vous pouvez également télécharger cette clé sur le site http://www.novell.com/linux/security/securitysupport.html.