--- title: Chapitre 14. Sécurité part: Partie III. Administration Système prev: books/handbook/users next: books/handbook/jails showBookMenu: true weight: 18 params: path: "/books/handbook/security/" --- [[security]] = Sécurité :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :sectnumoffset: 14 :partnums: :source-highlighter: rouge :experimental: :images-path: books/handbook/security/ ifdef::env-beastie[] ifdef::backend-html5[] :imagesdir: ../../../../images/{images-path} endif::[] ifndef::book[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] toc::[] endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] toc::[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [[security-synopsis]] == Synopsis Ce chapitre sera une introduction aux concepts de base de la sécurité système, à certaines règles empiriques, et à des sujets avancés sous FreeBSD. De nombreux sujets abordés ici peuvent être appliqués à la sécurité système et à l'Internet en général. L'Internet n'est plus un endroit "amical" dans lequel chacun désire être votre gentil voisin. Sécuriser votre système est impératif pour protéger vos données, la propriété intellectuelle, votre temps, et bien plus des mains des "hackers" et équivalents. FreeBSD fournit un ensemble d'utilitaires et de mécanismes pour assurer l'intégrité et la sécurité de votre système et votre réseau. Après la lecture de ce chapitre, vous connaîtrez: * Les concepts de base de la sécurité système en ce qui concerne FreeBSD. * Les différents mécanismes de chiffrement disponibles sous FreeBSD, comme DES et MD5. * Comment mettre en place une authentification par mot de passe non réutilisable. * Comment configurer l'encapsuleur TCP pour une utilisation avec inetd. * Comment configurer KerberosIV sous les versions de FreeBSD antérieures à la 5.0. * Comment configurer Kerberos5 sous FreeBSD. * Comment configurer IPsec et mettre en place un VPN entre machines FreeBSD et Windows(R). * Comment configurer et utiliser OpenSSH, la version de SSH implémentée sous FreeBSD. * Ce que sont les ACLs et comment les utiliser. * Comment employer l'utilitaire Portaudit pour l'audit des logiciels tierce-partie installés à partir du catalogue des logiciels portés. * Comment utiliser les avis de sécurité de FreeBSD. * Ce qu'est la comptabilité des processus et comment l'activer sous FreeBSD. Avant de lire ce chapitre, vous devrez: * Comprendre les concepts de base de FreeBSD et d'Internet. D'autres sujets relatifs à la sécurité sont abordés par ailleurs dans ce Manuel. Par exemple, le contrôle d'accès obligatoire est présenté dans le crossref:mac[mac,Mandatory Access Control] et les coupe-feux Internet sont développés dans le crossref:firewalls[firewalls,Firewalls]. [[security-intro]] == Introduction La sécurité est un domaine qui débute et se termine au niveau de l'administrateur système. Alors que tous les systèmes multi-utilisateurs UNIX(R) BSD ont des sécurités inhérentes, la mise en place et la maintenance des mécanismes supplémentaires de sécurité pour conserver des utilisateurs "honnêtes" est probablement une des tâches les plus vastes de l'administrateur système. La sécurité des machines est celle que vous voulez bien mettre en oeuvre, de plus les préoccupations en matière de sécurité sont plus que jamais en concurrence avec les besoins de confort des utilisateurs. Les systèmes UNIX(R) sont, en général, capables d'exécuter un nombre important de processus simultanément et plusieurs de ces processus fonctionnent en tant que serveur - cela signifiant que des entités extérieures peuvent se connecter et échanger avec ces processus. Comme les mini-ordinateurs et les gros ordinateurs d'hier deviennent aujourd'hui nos ordinateurs de bureau, et comme les ordinateurs sont désormais en réseau et reliés à Internet, la sécurité devient d'autant plus un problème majeur. La sécurité système concerne également la lutte contre les diverses formes d'attaque, y compris les attaques destinées à faire planter, ou à rendre inutilisable le système, mais qui ne cherchent pas à compromettre le compte `root`. Les problèmes de sécurité peuvent être divisés en plusieurs catégories: . Attaques par déni de service. . Compte utilisateur compromis. . Le compte `root` compromis par l'intermédiaire de serveurs accessibles. . Le compte `root` compromis par l'intermédiaire de comptes utilisateur. . Création d'une "Backdoor" (porte dérobée). Une attaque par déni de service ("DoS") est une action qui prive la machine de ressources nécessaires à son bon fonctionnement. Généralement, les attaques par déni de service sont des mécanismes de force brute qui tentent de faire planter ou tout au moins de rendre inutilisable la machine en saturant ses serveurs ou sa pile réseau. Certaines attaques par déni de service peuvent se servir de bogues présents dans la pile réseau pour faire planter une machine avec un seul paquet. Ces problèmes ne peuvent être corrigés que par l'application d'un correctif sur le noyau. On peut souvent remédier aux attaques sur les serveurs en fixant correctement des options pour limiter la charge que provoquent ces serveurs sur le système lors de conditions critiques. Les attaques réseau par force brute sont plus difficiles à traiter. Une attaque par paquets usurpés ("spoofed-packet"), par exemple, est quasi-impossible à arrêter, à moins de déconnecter de l'Internet votre système. Elle peut ne pas être en mesure de stopper votre machine, mais elle peut saturer votre connexion Internet. La compromission d'un compte utilisateur est bien plus fréquente qu'une attaque de type DoS. De nombreux administrateurs utilisent toujours sur leurs machines les versions standards des serveurs telnetd, rlogind, rshd, et ftpd. Par défaut, ces serveurs ne fonctionnent pas avec des connexions chiffrées. Cela aura pour résultat si vous disposez d'un nombre d'utilisateurs conséquent qu'un ou plusieurs de ces utilisateurs ayant l'habitude de se connecter à partir d'une machine distante (ce qui représente la manière la plus courante et la plus pratique pour ouvrir une session sur un système) auront leur mot de passe "sniffé". L'administrateur système méticuleux analysera ses journaux de connexions effectuées à partir de machines distantes à la recherche d'adresses sources suspectes même pour les ouvertures de sessions ayant réussies. Il faut toujours supposer qu'une fois l'attaquant a l'accès à un compte utilisateur, il pourra s'attaquer et avoir accès au compte `root`. Cependant, la réalité est que dans un système bien sécurisé et surveillé, l'accès à un compte utilisateur ne donne pas nécessairement à l'attaquant l'accès au compte `root`. Cette distinction est importante car sans accès aux droits de `root`, l'attaquant ne peut généralement pas dissimuler ses traces et peut, dans le meilleur des cas, ne rien faire d'autre que mettre la pagaille dans les fichiers de l'utilisateur ou faire planter la machine. La compromission de comptes utilisateur est très fréquente parce que les utilisateurs n'ont pas l'habitude de prendre les précautions que prennent les administrateurs système. Les administrateurs doivent garder à l'esprit qu'il existe potentiellement de nombreuses manières d'avoir accès au compte `root` sur une machine. L'attaquant peut connaître le mot de passe `root`, l'attaquant peut trouver un bogue dans un serveur tournant avec les droits de `root` et être en mesure de devenir `root` par l'intermédiaire d'une connexion réseau à ce serveur, ou l'attaquant peut connaître un bogue dans un programme suid-root qui permet de devenir `root` une fois qu'il a accédé à un compte utilisateur. Si un attaquant a trouvé un moyen de devenir `root` sur une machine, il n'aura peut-être pas besoin d'installer une "backdoor" (porte dérobée). De nombreux trous de sécurité `root` trouvés et fermés à temps demandent un travail considérable à l'attaquant pour effacer ses traces, aussi la plupart des attaquants installe des portes dérobées. Une porte dérobée offre à l'attaquant un moyen aisé d'avoir à nouveau accès aux droits de `root` sur le système, mais cela donne également à l'administrateur système intelligent un bon moyen de détecter l'intrusion. Rendre impossible à un attaquant l'installation d'une porte dérobée peut en fait être préjudiciable à votre sécurité, parce que cela ne fermera pas le trou qu'a découvert en premier lieu l'attaquant pour pénétrer sur le système. Les solutions aux problèmes de sécurité devraient toujours être mises en place suivant l'approche multi-couches de "la pelure d'oignon", elles peuvent être classées comme suit: . Sécuriser les comptes `root` et d'administration. . Sécuriser les serveurs exécutés avec les droits de `root` et les binaires suid/sgid. . Sécuriser les comptes utilisateurs. . Sécuriser le fichier des mots de passe. . Sécuriser le noyau, les périphériques et les systèmes de fichiers. . Installer un mécanisme de détection rapide des modifications inappropriées apportées au système. . La paranoïa. La section suivante de ce chapitre abordera de manière plus approfondie les points énoncés ci-dessus. [[securing-freebsd]] == Securing FreeBSD ** Traduction en Cours ** [[crypt]] == DES, MD5, et chiffrement Chaque utilisateur d'un système UNIX(R) possède un mot de passe associé à son compte. Il semble évident que ces mots de passe ne doivent être connus que de l'utilisateur et du système d'exploitation. Afin de conserver ces mots de passe secrets, ils sont chiffrés avec ce que l'on appelle un "hachage irréversible", ce qui signifie que le mot de passe peut être aisément chiffré mais pas déchiffré. En d'autres mots, ce que nous vous disions précédemment n'est même pas vrai: le système d'exploitation lui-même ne connaît pas _vraiment_ le mot de passe. Il ne connaît que la forme _chiffrée_ du mot de passe. La seule manière d'obtenir le mot de passe en _clair_ est d'effectuer une recherche par force brute de tous les mots de passe possibles. Malheureusement, la seule méthode sécurisée pour chiffrer les mots de passe quand UNIX(R) a vu le jour était basée sur DES, le "Data Encryption Standard" (standard de chiffrement des données). C'était un problème mineur pour les utilisateurs résidants aux Etats-Unis, mais puisque le code source de DES ne pouvait être exporté en dehors des Etats-Unis, FreeBSD dû trouver un moyen de respecter la législation américaine et de rester compatible avec les autres systèmes UNIX(R) qui utilisaient encore DES. La solution fut de séparer les bibliothèques de chiffrement de façon à ce que les utilisateurs américains puissent installer les bibliothèques DES et utiliser DES, mais que les utilisateurs internationaux disposent d'une méthode de chiffrement non restreinte à l'exportation. C'est comment FreeBSD est venu à utiliser MD5 comme méthode de chiffrement par défaut. MD5 est reconnu comme étant plus sure que DES, l'installation de DES est proposée principalement pour des raisons de compatibilité. === Identifier votre mécanisme de chiffrement Avant FreeBSD 4.4 [.filename]#libcrypt.a# était un lien symbolique pointant sur la bibliothèque utilisée pour le chiffrement. FreeBSD 4.4 modifia [.filename]#libcrypt.a# pour fournir une bibliothèque de hachage pour l'authentification des mots de passe configurable. Actuellement la bibliothèque supporte les fonctions de hachage DES, MD5 et Blowfish. Par défaut FreeBSD utilise MD5 pour chiffrer les mots de passe. Il est relativement facile d'identifier quelle méthode de chiffrement FreeBSD utilise. Examiner les mots de passe chiffrés dans le fichier [.filename]#/etc/master.passwd# est une méthode. Les mots de passe MD5 sont plus longs que les mots de passe DES, et commencent par les caractères `$1$`. Les mots de passe débutant par `$2$` sont chiffrés suivant la méthode Blowfish. Les mots de passe DES n'ont pas de caractéristique particulière, mais sont plus courts que les mots de passe MD5 et utilisent un alphabet de 64 caractères qui ne contient pas le caractère `$`, aussi une chaîne relativement courte qui ne commence pas par un dollar a donc de très fortes chances d'être un mot de passe DES. Le format utilisé par les nouveaux mots de passe est contrôlé par la capacité de classe de session `passwd_format` dans [.filename]#/etc/login.conf#, qui prend comme valeur `des`, `md5` ou `blf`. Voir la page de manuel man:login.conf[5] pour plus d'information sur les capacités de classe de session. [[one-time-passwords]] == Mots de passe non réutilisables S/Key est un système de mots de passe non réutilisables basé sur une fonction de hachage irréversible. FreeBSD utilise le hachage MD4 pour des raisons de compatibilité mais d'autres système utilisent MD5 et DES-MAC. S/Key fait partie du système de base de FreeBSD depuis la version 1.1.5 et est aussi utilisé sur un nombre toujours plus important d'autres systèmes d'exploitation. S/Key est une marque déposée de Bell Communications Research, Inc. Depuis la version 5.0 de FreeBSD, S/Key a été remplacé par la fonction équivalente OPIE ("One-time Passwords In Everything" - Mots de passe non réutilisables dans toutes les applications). OPIE utilise le hachage MD5 par défaut. Il existe trois types de mots de passe dont nous parlerons dans ce qui suit. Le premier est votre mot de passe UNIX(R) habituel ou mot de passe Kerberos; nous appellerons "mot de passe UNIX(R)". Le deuxième type est le mot de passe généré par les programmes S/Key `key` ou OPIE man:opiekey[1] et reconnu par les programmes `keyinit` ou man:opiepasswd[1] et l'invite de session; nous appellerons ceci un "mot de passe non réutilisable". Le dernier type de mot de passe est le mot de passe secret que vous donnez aux programmes `key`/`opiekey` (et parfois aux programmes `keyinit`/`opiepasswd`) qui l'utilisent pour générer des mots de passe non réutilisable; nous l'appellerons "mot de passe secret" ou tout simplement "mot de passe". Le mot de passe secret n'a rien à voir avec votre mot de passe UNIX(R); ils peuvent être identique, mais c'est déconseillé. Les mots de passe secret S/Key et OPIE ne sont pas limités à 8 caractères comme les anciens mots de passe UNIX(R), ils peuvent avoir la longueur que vous désirez. Des mots de passe de six ou sept mots de long sont relativement communs. La plupart du temps, le système S/Key ou OPIE fonctionne de façon complètement indépendante du système de mot de passe UNIX(R). En plus du mot de passe, deux autres types de données sont importantes pour S/Key et OPIE. L'une d'elles est connue sous le nom de "germe" ("seed") ou "clé", formé de deux lettres et cinq chiffres. L'autre est ce que l'on appelle le "compteur d'itérations", un nombre compris entre 1 et 100. S/Key génère un mot de passe non réutilisable en concaténant le germe et le mot de passe secret, puis en appliquant la fonction de hachage MD4/MD5 autant de fois qu'indiqué par le compteur d'itérations, et en convertissant le résultat en six courts mots anglais. Ces six mots anglais constituent votre mot de passe non réutilisable. Le système d'authentification (principalement PAM) conserve une trace du dernier mot de passe non réutilisable utilisé, et l'utilisateur est authentifié si la valeur de hachage du mot de passe fourni par l'utilisateur est la même que celle du mot de passe précédent. Comme le hachage utilisé est irréversible, il est impossible de générer de mot de passe non réutilisable si on a surpris un de ceux qui a été utilisé avec succès; le compteur d'itérations est décrémenté après chaque ouverture de session réussie, de sorte que l'utilisateur et le programme d'ouverture de session restent en phase. Quand le compteur d'itération passe à 1, S/Key et OPIE doivent être réinitialisés. Il y a trois programmes impliqués dans chacun des systèmes que nous aborderons plus bas. Les programmes `key` et `opiekey` ont pour paramètres un compteur d'itérations, un germe, et un mot de passe secret, et génère un mot de passe non réutilisable ou une liste de mots de passe non réutilisable. Les programmes `keyinit` et `opiepasswd` sont utilisés pour initialiser respectivement S/Key et OPIE, et pour modifier les mots de passe, les compteurs d'itérations, ou les germes; ils prennent pour paramètres soit un mot de passe secret, soit un compteur d'itérations, soit un germe, et un mot de passe non réutilisable. Le programme `keyinfo` ou `opieinfo` consulte le fichier d'identification correspondant ([.filename]#/etc/skeykeys# ou [.filename]#/etc/opiekeys#) et imprime la valeur du compteur d'itérations et le germe de l'utilisateur qui l'a invoqué. Nous décrirons quatre sortes d'opérations. La première est l'utilisation du programme `keyinit` ou `opiepasswd` sur une connexion sécurisée pour initialiser les mots de passe non réutilisables pour la première fois, ou pour modifier votre mot de passe ou votre germe. La seconde opération est l'emploi des programmes `keyinit` ou `opiepasswd` sur une connexion non sécurisée, en conjonction avec `key` ou `opiekey` sur une connexion sécurisée, pour faire la même chose. La troisième est l'utilisation de `key`/`opiekey` pour ouvrir une session sur une connexion non sécurisée. La quatrième est l'emploi de `key` ou `opiekey` pour générer un certain nombre de clés qui peuvent être notées ou imprimées et emportées avec vous quand vous allez quelque part ou il n'y a aucune connexion sécurisée. === Initialisation depuis une connexion sécurisée Pour initialiser S/Key pour la première fois, changer votre mot de passe, ou changer votre germe quand vous êtes attaché sous votre compte par l'intermédiaire d'une connexion sécurisée (e.g., sur la console d'une machine ou via ssh), utilisez la commande `keyinit` sans paramètres: [source,shell] .... % keyinit Adding unfurl: Reminder - Only use this method if you are directly connected. If you are using telnet or rlogin exit with no password and use keyinit -s. Enter secret password: Again secret password: ID unfurl s/key is 99 to17757 DEFY CLUB PRO NASH LACE SOFT .... Pour OPIE, `opiepasswd` est utilisé à la place: [source,shell] .... % opiepasswd -c [grimreaper] ~ $ opiepasswd -f -c Adding unfurl: Only use this method from the console; NEVER from remote. If you are using telnet, xterm, or a dial-in, type ^C now or exit with no password. Then run opiepasswd without the -c parameter. Using MD5 to compute responses. Enter new secret pass phrase: Again new secret pass phrase: ID unfurl OTP key is 499 to4268 MOS MALL GOAT ARM AVID COED .... A l'invite `Enter new secret pass phrase:` ou `Enter secret password:`, vous devez entrer un mot de passe ou une phrase. Rappelez-vous que ce n'est pas le mot de passe que vous utiliserez pour ouvrir une session, mais celui utilisé pour générer vos clés non réutilisables. La ligne commençant par "ID" liste les paramètres de votre instance: votre nom d'utilisateur, la valeur de votre compteur d'itérations et votre germe. Quand vous ouvrirez une session, le système aura mémorisé ces paramètres et vous les redonnera, vous n'avez donc pas besoin de les retenir. La dernière ligne donne le mot de passe non réutilisable correspondant à ces paramètres et à votre mot de passe secret; si vous devez vous reconnectez immédiatement, c'est ce mot de passe que vous utiliseriez. === Initialisation depuis une connexion non sécurisée Pour initialiser ou changer votre mot de passe secret par l'intermédiaire d'une connexion non sécurisée, il faudra avoir déjà une connexion sécurisée sur une machine où vous pouvez exécuter `key` ou `opiekey`; ce peut être depuis une icone sur le bureau d'un Macintosh ou depuis la ligne de commande d'une machine sûre. Il vous faudra également donner une valeur au compteur d'itération (100 est probablement une bonne valeur), et indiquer un germe ou utiliser la valeur aléatoire générée par le programme. Sur la connexion non sécurisée (vers la machine que vous initialisez), employez la commande `keyinit -s`: [source,shell] .... % keyinit -s Updating unfurl: Old key: to17758 Reminder you need the 6 English words from the key command. Enter sequence count from 1 to 9999: 100 Enter new key [default to17759]: s/key 100 to 17759 s/key access password: s/key access password:CURE MIKE BANE HIM RACY GORE .... Pour OPIE, vous devez utiliser `opiepasswd`: [source,shell] .... % opiepasswd Updating unfurl: You need the response from an OTP generator. Old secret pass phrase: otp-md5 498 to4268 ext Response: GAME GAG WELT OUT DOWN CHAT New secret pass phrase: otp-md5 499 to4269 Response: LINE PAP MILK NELL BUOY TROY ID mark OTP key is 499 gr4269 LINE PAP MILK NELL BUOY TROY .... Pour accepter le germe par défaut (que le programme `keyinit` appelle `key`, ce qui prête à confusion), appuyez sur kbd:[Entrée]. Ensuite avant d'entrer un mot de passe d'accès, passez sur votre connexion sécurisée et donnez lui les mêmes paramètres: [source,shell] .... % key 100 to17759 Reminder - Do not use this program while logged in via telnet or rlogin. Enter secret password: CURE MIKE BANE HIM RACY GORE .... Ou pour OPIE: [source,shell] .... % opiekey 498 to4268 Using the MD5 algorithm to compute response. Reminder: Don't use opiekey from telnet or dial-in sessions. Enter secret pass phrase: GAME GAG WELT OUT DOWN CHAT .... Retournez maintenant sur votre connexion non sécurisée, et copiez le mot de passe non réutilisable généré par le programme adapté. === Générer un unique mot de passe non réutilisable Une fois que vous avez initialisé S/Key ou OPIE, lorsque que vous ouvrez une session, une invite de ce type apparaîtra: [source,shell] .... % telnet example.com Trying 10.0.0.1... Connected to example.com Escape character is '^]'. FreeBSD/i386 (example.com) (ttypa) login: s/key 97 fw13894 Password: .... Ou pour OPIE: [source,shell] .... % telnet example.com Trying 10.0.0.1... Connected to example.com Escape character is '^]'. FreeBSD/i386 (example.com) (ttypa) login: otp-md5 498 gr4269 ext Password: .... Les invites S/Key et OPIE disposent d'une fonction utile (qui n'est pas illustrée ici): si vous appuyez sur la touche kbd:[Entrée] lorsque l'on vous demande votre mot de passe, le programme active l'écho au terminal, de sorte que vous voyez ce que vous êtes en train de taper. Ceci est très utile si vous essayez de taper un mot de passe à la main, à partir d'un résultat imprimé par exemple. A ce moment vous devez générer votre mot de passe non réutilisable pour répondre à cette invite de session. Cela doit être effectué sur une machine de confiance sur laquelle vous pouvez exécuter `key` ou `opiekey` (il y a des versions de ces programmes pour DOS, Windows et MacOS). Ces programmes ont besoin du compteur d'itérations et du germe comme paramètres. Vous pouvez les copier-coller de l'invite de session de la machine sur laquelle vous voulez ouvrir une session. Sur le système sûr: [source,shell] .... % key 97 fw13894 Reminder - Do not use this program while logged in via telnet or rlogin. Enter secret password: WELD LIP ACTS ENDS ME HAAG .... Pour OPIE: [source,shell] .... % opiekey 498 to4268 Using the MD5 algorithm to compute response. Reminder: Don't use opiekey from telnet or dial-in sessions. Enter secret pass phrase: GAME GAG WELT OUT DOWN CHAT .... Maintenant que vous disposez de votre mot de passe non réutilisable vous pouvez continuer et vous connecter: [source,shell] .... login: s/key 97 fw13894 Password: s/key 97 fw13894 Password [echo on]: WELD LIP ACTS ENDS ME HAAG Last login: Tue Mar 21 11:56:41 from 10.0.0.2 ... .... === Générer de multiples mots de passe non réutilisables Il faut parfois se rendre en des endroits où vous n'avez pas accès à une machine de confiance ou à une connexion sécurisée. Dans ce cas, vous pouvez utiliser la commande `key` ou `opiekey` pour générer plusieurs mots de passe non réutilisables que vous pouvez imprimer et transporter avec vous. Par exemple: [source,shell] .... % key -n 5 30 zz99999 Reminder - Do not use this program while logged in via telnet or rlogin. Enter secret password: 26: SODA RUDE LEA LIND BUDD SILT 27: JILT SPY DUTY GLOW COWL ROT 28: THEM OW COLA RUNT BONG SCOT 29: COT MASH BARR BRIM NAN FLAG 30: CAN KNEE CAST NAME FOLK BILK .... Ou pour OPIE: [source,shell] .... % opiekey -n 5 30 zz99999 Using the MD5 algorithm to compute response. Reminder: Don't use opiekey from telnet or dial-in sessions. Enter secret pass phrase: 26: JOAN BORE FOSS DES NAY QUIT 27: LATE BIAS SLAY FOLK MUCH TRIG 28: SALT TIN ANTI LOON NEAL USE 29: RIO ODIN GO BYE FURY TIC 30: GREW JIVE SAN GIRD BOIL PHI .... L'option `-n 5` demande cinq clés en séquence, l'option `30` indique quel doit être le rang de la dernière itération. Notez que les clés sont imprimées dans l'ordre _inverse_ de celui où elles seront éventuellement utilisées. Si vous êtes vraiment paranoïaque, vous pouvez les recopier à la main, sinon vous pouvez les copier-coller vers la commande `lpr`. Remarquez que chaque ligne liste le compteur d'itération et le mot de passe non réutilisable; vous trouverez peut-être utile de rayer les mots de passe au fur et à mesure de leur utilisation. === Restreindre l'utilisation des mots de passe UNIX(R) S/Key peut placer des restrictions sur l'utilisation des mots de passe UNIX(R) en fonction des noms de machine, d'utilisateur, de la ligne utilisée par le terminal ou de l'adresse IP de la machine connectée à distance. Ces restrictions peuvent être trouvées dans le fichier de configuration [.filename]#/etc/skey.access#. La page de manuel man:skey.access[5] donne de plus amples informations sur le format de ce fichier et elle détaille également certains avertissements relatifs à la sécurité qu'il faut lire avant de se fier à ce fichier pour sa sécurité. S'il n'y a pas de fichier [.filename]#/etc/skey.access# (ce qui est le cas par défaut sur les systèmes FreeBSD 4.X), tous les utilisateurs pourront se servir de mots de passe UNIX(R). Si le fichier existe, alors tous les utilisateurs devront passer par S/Key, à moins qu'ils ne soient explicitement autorisés à ne pas le faire par des instructions du fichier [.filename]#/etc/skey.access#. Dans tous les cas l'usage des mots de passe UNIX(R) est autorisé sur la console. Voici un exemple de configuration du fichier [.filename]#skey.access# qui illustre les trois types d'instructions les plus courantes: [.programlisting] .... permit internet 192.168.0.0 255.255.0.0 permit user fnord permit port ttyd0 .... La première ligne (`permit internet`) autorise les utilisateurs dont l'adresse IP (ce qui rend vulnérable en cas d'usurpation) appartient au sous-réseau spécifié à employer les mots de passe UNIX(R). Cela ne doit pas être considéré comme une mesure de sécurité, mais plutôt comme un moyen de rappeler aux utilisateurs autorisés qu'ils sont sur un réseau non sécurisé et doivent utiliser S/Key pour s'authentifier. La seconde ligne (`permit user`) autorise l'utilisateur désigné, dans notre cas `fnord`, à employer n'importe quand les mots de passe UNIX(R). En général, il faut se servir de cette possibilité si les personnes soit n'ont pas moyen d'utiliser le programme `key`, s'ils ont par exemple des terminaux passifs, soit s'ils sont définitivement réfractaires au système. La troisième ligne (`permit port`) autorise tous les utilisateurs d'un terminal sur une liaison particulière à utiliser les mots de passe UNIX(R); cela devrait être employé pour les connexions téléphoniques. OPIE peut restreindre l'usage des mots de passe UNIX(R) sur la base de l'adresse IP lors de l'ouverture d'une session comme peut le faire S/Key. Le fichier impliqué est [.filename]#/etc/opieaccess#, qui est présent par défaut sous FreeBSD 5.0 et versions suivantes. Veuillez consulter la page de manuel man:opieaccess[5] pour plus d'information sur ce fichier et certaines considérations sur la sécurité dont vous devez être au courant en l'utilisant. Voici un exemple de fichier [.filename]#opieaccess#: [.programlisting] .... permit 192.168.0.0 255.255.0.0 .... Cette ligne autorise les utilisateurs dont l'adresse IP (ce qui rend vulnérable en cas d'usurpation) appartient au sous-réseau spécifié à employer les mots de passe UNIX(R) à tout moment. Si aucune règle du fichier [.filename]#opieaccess# ne correspond, le comportement par défaut est de refuser toute ouverture de session non-OPIE. [[tcpwrappers]] == L'encapsuleur TCP ("TCP Wrappers") Toute personne familière avec man:inetd[8] a probablement entendu parlé à un moment ou à un autre de l'encapsuleur TCP ("TCP Wrappers"). Mais peu sont ceux qui semblent saisir complètement son intérêt dans un réseau. Il semble que tout le monde désire installer un coupe-feu pour contrôler les connexions réseaux. Alors qu'un coupe-feu peut avoir de nombreuses utilisations, il existe des choses qu'un coupe-feu ne peut gérer comme renvoyer un message à l'initiateur d'une connexion. L'encapsuleur TCP en est capable ainsi que bien d'autres choses. Dans les sections suivantes plusieurs fonctionnalités de l'encapsuleur TCP seront abordées, et, dès que ce sera possible, un exemple de configuration sera proposé. L'encapsuleur TCP étend les capacités d'inetd au niveau du support pour chaque serveur sous son contrôle. En utilisant cette méthode il est possible d'offrir le support des ouvertures de session, de retourner des messages lors des connexions, de permettre à un "daemon" de n'accepter que les connexions internes, etc. Bien que certaines de ces fonctionnalités peuvent être obtenues par l'implémentation d'un coupe-feu, ce système ajoutera non seulement une couche supplémentaire de protection mais ira plus loin dans le contrôle que ce que peut fournir un coupe-feu. Les fonctionnalités apportées par l'encapsuleur TCP ne peuvent se substituer à l'utilisation d'un bon coupe-feu. L'encapsuleur TCP peut être utilisé de paire avec un coupe-feu ou tout autre système de sécurité et il pourra alors servir comme une couche supplémentaire de protection pour le système. Etant donné que ce programme est une extension à la configuration du programme inetd, le lecteur est supposé avoir pris connaissance de la section de crossref:network-servers[network-inetd,configuration d'inetd]. [NOTE] ==== Bien que les programmes lancés par man:inetd[8] ne soient pas tout à fait des "daemons", ils sont traditionnellement appelés "daemons". C'est le terme que nous utiliserons également dans le reste de cette section. ==== === Configuration initiale Le seul pré-requis à l'utilisation de l'encapsuleur TCP sous FreeBSD est de s'assurer que le serveur inetd est lancé à partir de [.filename]#rc.conf# avec l'option `-Ww`; c'est la configuration par défaut. Bien évidemment une configuration correcte du fichier [.filename]#/etc/hosts.allow# est également sous-entendue, mais dans le cas contraire man:syslogd[8] émettra des messages d'avertissement dans les journaux du système. [NOTE] ==== Contrairement à d'autres implémentations de l'encapsuleur TCP, l'emploi du fichier [.filename]#hosts.deny# est obsolète. Toutes les options de configuration doivent être placées dans le fichier [.filename]#/etc/hosts.allow#. ==== Dans la configuration la plus simple, la politique de connexion aux "daemons" est soit de tout autoriser ou soit de tout bloquer en fonctions des options choisies dans [.filename]#/etc/hosts.allow#. La configuration par défaut sous FreeBSD est d'autoriser les connexions à chaque "daemon" lancé à l'aide d'inetd. La modification de ce réglage par défaut sera discutée une fois que la configuration de base aura été vue. Une configuration de base prend en général la forme `daemon : adresse : action`. Où `daemon` est le nom du "daemon" lancé par inetd. L'``adresse`` peut être un nom de machine valide, une adresse IP ou une adresse IPv6 entre crochets ([ ]). Le champ `action` pourra avoir comme valeur `allow` ou `deny` pour autoriser ou interdire l'accès. Gardez à l'esprit que ce type de configuration fonctionne de manière à honorer la première règle sémantique correspondante, cela signifie que le fichier de configuration est parcouru à la recherche d'une règle correspondant à la requête. Quand une correspondance est trouvée, la règle est appliquée et la recherche s'arrête. Plusieurs autres options existent mais elles seront exposées dans une section ultérieure. Une simple ligne de configuration peut être construite avec peu d'information. Par exemple, pour autoriser les connexions POP3 via le "daemon"package:mail/qpopper[], les lignes suivantes doivent être ajoutées au fichier [.filename]#hosts.allow#: [.programlisting] .... # This line is required for POP3 connections: qpopper : ALL : allow .... Après l'ajout de cette ligne, inetd devra être redémarré. Cela sera fait en utilisant la commande man:kill[1], ou avec le passage du paramètre [parameter]#restart# à la commande [.filename]#/etc/rc.d/inetd#. === Configuration avancée L'encapsuleur TCP dispose également d'options avancées; elles permettrons plus de contrôle sur la manière dont sont gérées les connexions. Dans certains cas cela peut être une bonne idée de renvoyer un commentaire à certaines machines ou lors de connexions à certains "daemon"s. Dans d'autres cas, peut-être qu'un fichier journal pourrait être enregistré ou un courrier électronique pourrait être envoyé à l'administrateur. D'autres situations peuvent nécessiter l'utilisation d'un service uniquement pour les connexions locales. Tout cela est possible à l'aide des options de configuration connues sous le nom de `jokers`, caractères d'expansion et d'exécution de commandes externes. Les deux sections suivantes abordent ces situations. ==== Commandes externes Imaginez une situation dans laquelle une connexion doit être refusée et que la raison de ce refus doit être envoyée à la personne qui a tenté d'établir cette connexion. Comment cela peut-il être mis en place? Ce type d'action est rendu possible par l'emploi de l'option `twist`. Quand une tentative de connexion est faite, `twist` sera appelée pour exécuter une commande ou une procédure d'interpréteur de commande. Un exemple est déjà présent dans le fichier [.filename]#hosts.allow#: [.programlisting] .... # The rest of the daemons are protected. ALL : ALL \ : severity auth.info \ : twist /bin/echo "You are not welcome to use %d from %h." .... Cet exemple montre que le message "You are not allowed to use `daemon` from `hostname`." sera retourné pour tout "daemon" qui n'a pas été précédemment configuré dans le fichier d'accès. Cette fonction est très utile pour envoyer une réponse à l'initiateur de la connexion juste après le refus de la connexion. Notez que tout message à retourner _doit_ être placé entre des guillemets `"`; il n'y a pas d'exception possible à cette règle. [WARNING] ==== Il est possible de lancer une attaque par déni de service sur le serveur si un agresseur, ou un groupe d'agresseurs sont en mesure de submerger ces "daemon"s avec des demandes de connexion. ==== Une autre possibilité dans ce cas est d'employer l'option `spawn`. Tout comme l'option `twist`, `spawn` interdit implicitement les connexions et peut être utilisée pour lancer une commande ou une procédure externe. Contrairement à `twist`, `spawn` n'enverra pas de réponse à la personne qui a établi la connexion. Examinons par exemple la ligne de configuration suivante: [.programlisting] .... # We do not allow connections from example.com: ALL : .example.com \ : spawn (/bin/echo %a from %h attempted to access %d \ /var/log/connections.log) \ : deny .... Cela interdira toute tentative de connexion à partir du domaine `*.example.com`, enregistrant simultanément dans le fichier [.filename]#/var/log/connections.log# le nom de machine, l'adresse IP et le "daemon" auquel on tente d'accéder. Il existe d'autres caractères de substitution en dehors de ceux déjà présentés, par exemple `%a`. Consultez la page de manuel man:hosts_access[5] pour une liste complète. ==== Les options jokers Jusqu'ici l'option `ALL` a été utilisée dans tous les exemples. Il existe d'autres options pour étendre un peu plus les fonctionnalités. Par exemple, l'option `ALL` peut être utilisée pour prendre en compte chaque instance d'un "daemon", d'un domaine ou d'une adresse IP. Un autre joker disponible est l'option `PARANOID` qui peut être employée pour prendre en compte toute machine qui fournirait une adresse IP susceptible d'être falsifiée. En d'autres termes, l'option `PARANOID` peut être utilisée pour définir l'action a effectuer dès qu'une connexion se fait à partir d'une adresse IP qui diffère de celle attachée à une machine. L'exemple suivant apporte un éclairage sur cette option: [.programlisting] .... # Block possibly spoofed requests to sendmail: sendmail : PARANOID : deny .... Dans cet exemple, toutes les requêtes de connexion à sendmail à partir d'adresses IP différentes de celle correspondant au nom de la machine seront refusées. [CAUTION] ==== Utiliser l'option `PARANOID` peut gravement paralyser les serveurs si le client ou le serveur a une configuration de DNS défectueuse. Les administrateurs sont maintenant prévenus. ==== Pour en apprendre plus sur les jokers et leurs fonctionnalités associées, consultez la page de manuel man:hosts_access[5]. Avant que n'importe quelle des lignes de configuration données ci-dessus ne fonctionne, la première ligne de configuration du fichier [.filename]#hosts.allow# devra être dé-commentée. Cela a été noté en début de section. [[kerberosIV]] == Kerberos Kerberos est un protocole réseau supplémentaire qui permet aux utilisateurs de s'authentifier par l'intermédiaire d'un serveur sécurisé. Des services comme l'ouverture de session et la copie à distance, la copie sécurisée de fichiers entre systèmes et autres fonctionnalités à haut risque deviennent ainsi considérablement plus sûrs et contrôlables. Les instructions qui suivent peuvent être utilisées comme guide d'installation de Kerberos dans la version distribuée pour FreeBSD. Vous devriez cependant vous référer aux pages de manuel correspondantes pour avoir une description complète. === Installation de Kerberos Kerberos est un composant optionnel de FreeBSD. La manière la plus simple d'installer ce logiciel est de sélectionner la distribution `krb4` ou `krb5` dans sysinstall lors de l'installation de FreeBSD. Cela installera les implémentations "eBones" (KerberosIV) ou "Heimdal" (Kerberos5) de Kerberos. Ces implémentations sont distribuées car elles sont développées en dehors des USA ou du Canada et étaient par conséquent disponibles aux utilisateurs hors de ces pays durant l'ère restrictive du contrôle des exportations de code de chiffrement à partir des USA. Alternativement, l'implémentation du MIT de Kerberos est disponible dans le catalogue des logiciels portés sous package:security/krb5[]. === Créer la base de données initiale Cela se fait uniquement sur le serveur Kerberos. Vérifiez tout d'abord qu'il ne traîne pas d'anciennes bases Kerberos. Allez dans le répertoire [.filename]#/etc/kerberosIV# et assurez-vous qu'il ne contient que les fichiers suivants: [source,shell] .... # cd /etc/kerberosIV # ls README krb.conf krb.realms .... S'il y a d'autres fichiers (comme [.filename]#principal.*# ou [.filename]#master_key#), utilisez alors la commande `kdb_destroy` pour supprimer l'ancienne base de données Kerberos, ou si Kerberos ne tourne pas, effacez simplement les fichiers supplémentaires. Vous devez maintenant éditer les fichiers [.filename]#krb.conf# et [.filename]#krb.realms# pour définir votre domaine Kerberos. Dans notre cas, le domaine sera `EXAMPLE.COM` et le serveur `grunt.example.com`. Nous éditons ou créons le fichier [.filename]#krb.conf#: [source,shell] .... # cat krb.conf EXAMPLE.COM EXAMPLE.COM grunt.example.com admin server CS.BERKELEY.EDU okeeffe.berkeley.edu ATHENA.MIT.EDU kerberos.mit.edu ATHENA.MIT.EDU kerberos-1.mit.edu ATHENA.MIT.EDU kerberos-2.mit.edu ATHENA.MIT.EDU kerberos-3.mit.edu LCS.MIT.EDU kerberos.lcs.mit.edu TELECOM.MIT.EDU bitsy.mit.edu ARC.NASA.GOV trident.arc.nasa.gov .... Dans notre cas les autres domaines n'ont pas besoin d'être mentionnés. Ils ne sont là que pour montrer comment une machine peut avoir connaissance de plusieurs domaines. Pour plus de simplicité, vous pouvez ne pas les inclure. La première ligne indique pour quel domaine cette machine agit. Les autre lignes définissent les autres domaines/machines. Le premier élément sur une ligne est le domaine, le second le nom de la machine qui est le "centre de distribution de clés" de ce domaine. Les mots `admin server` qui suivent un nom de machine signifient que la machine est aussi serveur d'administration de la base de données. Pour plus d'explication sur cette terminologie, consultez les pages de manuel de Kerberos. Nous devons maintenant ajouter `grunt.example.com` au domaine `EXAMPLE.COM` et ajouter une entrée pour mettre toutes les machines du domaine DNS `.example.com` dans le domaine Kerberos `EXAMPLE.COM`. Le fichier [.filename]#krb.realms# aura alors l'allure suivante: [source,shell] .... # cat krb.realms grunt.example.com EXAMPLE.COM .example.com EXAMPLE.COM .berkeley.edu CS.BERKELEY.EDU .MIT.EDU ATHENA.MIT.EDU .mit.edu ATHENA.MIT.EDU .... Encore une fois, les autres domaines n'ont pas besoin d'être mentionnés. Ils ne sont là que pour montrer comment une machine peut avoir connaissance de plusieurs domaines. Pour plus de simplicité, vous pouvez ne pas les inclure. La première ligne assigne un système _particulier_ au domaine désigné. Les lignes restantes montrent comment affecter par défaut les systèmes d'un sous-domaine DNS particulier à un domaine Kerberos donné. Nous sommes maintenant prêt pour la création de la base de données. Il n'y a à le faire que sur le serveur Kerberos (ou Centre de Distribution de Clés). Cela se fait avec la commande `kdb_init`: [source,shell] .... # kdb_init Realm name [default ATHENA.MIT.EDU ]: EXAMPLE.COM You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter Kerberos master key: .... Nous devons maintenant sauvegarder la clé pour que les serveurs sur la machine locale puissent la lire. Utilisons la commande `kstash` pour faire cela: [source,shell] .... # kstash Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! .... Le mot de passe maître chiffré est sauvegardé dans [.filename]#/etc/kerberosIV/master_key#. === Installer les services Il faut ajouter deux entrées ("principals") à la base de données pour _chaque_ système qui sera sécurisé par Kerberos. Ce sont `kpasswd` et `rcmd`. Ces deux entrées sont définies pour chaque système, chacune de leurs instances se voyant attribuer le nom du système. Ces "daemons", kpasswd et rcmd permettent aux autres systèmes de changer les mots de passe Kerberos et d'exécuter des commandes comme man:rcp[1], man:rlogin[1], et man:rsh[1]. Ajoutons donc maintenant ces entrées: [source,shell] .... # kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: passwd Instance: grunt , Create [y] ? y Principal: passwd, Instance: grunt, kdc_key_ver: 1 New Password: <---- entrez RANDOM ici Verifying password New Password: <---- enter RANDOM here Random password [y] ? y Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: rcmd Instance: grunt , Create [y] ? Principal: rcmd, Instance: grunt, kdc_key_ver: 1 New Password: <---- entrez RANDOM ici Verifying password New Password: <---- entrez RANDOM ici Random password [y] ? Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- ne rien entrer ici permet de quitter le programme .... === Créer le fichier des services Il faut maintenant extraire les instances qui définissent les services sur chaque machine. Pour cela on utilise la commande `ext_srvtab`. Cela créera un fichier qui doit être copié ou déplacé _par un moyen sûr_ dans le répertoire [.filename]#/etc/kerberosIV# de chaque client Kerberos. Ce fichier doit être présent sur chaque serveur et client, et est crucial au bon fonctionnement de Kerberos. [source,shell] .... # ext_srvtab grunt Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Generating 'grunt-new-srvtab'.... .... Cette commande ne génère qu'un fichier temporaire qui doit être renommé en [.filename]#srvtab# pour que tous les serveurs puissent y accéder. Utilisez la commande man:mv[1] pour l'installer sur le système d'origine: [source,shell] .... # mv grunt-new-srvtab srvtab .... Si le fichier est destiné à un client, et que le réseau n'est pas considéré comme sûr, alors copiez le fichier [.filename]#client-new-srvtab# sur un support amovible et transportez-le par un moyen physiquement sûr. Assurez-vous de le renommer en [.filename]#srvtab# dans le répertoire [.filename]#/etc/kerberosIV# du client, et mettez-le bien en mode 600: [source,shell] .... # mv grumble-new-srvtab srvtab # chmod 600 srvtab .... === Renseigner la base de données Nous devons maintenant créer des entrées utilisateurs dans la base de données. Tout d'abord créons une entrée pour l'utilisateur `jane`. Utilisez la commande `kdb_edit` pour cela: [source,shell] .... # kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: jane Instance: , Create [y] ? y Principal: jane, Instance: , kdc_key_ver: 1 New Password: <---- entrez un mot de passe sûr ici Verifying password New Password: <---- réentrez le mot de passe sûr là Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- ne rien entrer ici permet de quitter le programme .... === Tester l'ensemble Il faut tout d'abord démarrer les "daemons" Kerberos. Notez que si vous avez correctement modifié votre fichier [.filename]#/etc/rc.conf#, cela se fera automatiquement au redémarrage du système. Ceci n'est nécessaire que sur le serveur Kerberos. Les clients Kerberos récupéreront automatiquement les informations dont ils ont besoin via leur répertoire [.filename]#/etc/kerberosIV#. [source,shell] .... # kerberos & Kerberos server starting Sleep forever on error Log file is /var/log/kerberos.log Current Kerberos master key version is 1. Master key entered. BEWARE! Current Kerberos master key version is 1 Local realm: EXAMPLE.COM # kadmind -n & KADM Server KADM0.0A initializing Please do not use 'kill -9' to kill this job, use a regular kill instead Current Kerberos master key version is 1. Master key entered. BEWARE! .... Nous pouvons maintenant utiliser la commande `kinit` pour obtenir un "ticket d'entrée" pour l'utilisateur `jane` que nous avons créé plus haut: [source,shell] .... % kinit jane MIT Project Athena (grunt.example.com) Kerberos Initialization for "jane" Password: .... Essayons de lister les informations associées avec la commande `klist` pour voir si nous avons vraiment tout ce qu'il faut: [source,shell] .... % klist Ticket file: /tmp/tkt245 Principal: jane@EXAMPLE.COM Issued Expires Principal Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.EXAMPLE.COM@EXAMPLE.COM .... Essayons maintenant de modifier le mot de passe en utilisant la commande man:passwd[1] pour vérifier si le "daemon" kpasswd est autorisé à accéder à la base de données Kerberos: [source,shell] .... % passwd realm EXAMPLE.COM Old password for jane: New Password for jane: Verifying password New Password for jane: Password changed. .... === Autoriser l'utilisation de la commande `su` Kerberos permet d'attribuer à _chaque_ utilisateur qui a besoin des droits du super-utilisateur son _propre_ mot de passe man:su[1]. Nous pouvons créer un identifiant qui est autorisé à utiliser man:su[1] pour devenir `root`. Cela se fait en associant une instance `root` un identificateur ("principal") de base. En utilisant la commande `kdb_edit` nous pouvons créer l'entrée `jane.root` dans la base de données Kerberos: [source,shell] .... # kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: jane Instance: root , Create [y] ? y Principal: jane, Instance: root, kdc_key_ver: 1 New Password: <---- entrez un mot de passe SUR ici Verifying password New Password: <---- réentrez le mot de passe ici Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- Laissez une valeur faible! Attributes [ 0 ] ? Edit O.K. Principal name: <---- ne rien entrer ici permet de quitter le programme .... Vérifions maintenant les caractéristiques associées pour voir si cela fonctionne: [source,shell] .... # kinit jane.root MIT Project Athena (grunt.example.com) Kerberos Initialization for "jane.root" Password: .... Nous devons maintenant ajouter l'utilisateur au fichier [.filename]#.klogin# de `root`: [source,shell] .... # cat /root/.klogin jane.root@EXAMPLE.COM .... Essayons maintenant la commande man:su[1]: [source,shell] .... % su Password: .... et voyons quelles sont nos caractéristiques: [source,shell] .... # klist Ticket file: /tmp/tkt_root_245 Principal: jane.root@EXAMPLE.COM Issued Expires Principal May 2 20:43:12 May 3 04:43:12 krbtgt.EXAMPLE.COM@EXAMPLE.COM .... === Utiliser d'autres commandes Dans l'exemple précédent, nous avons créé une entrée principale nommée `jane` avec une instance `root`. Cette entrée reposait sur un utilisateur ayant le même nom que l'entrée principale, c'est ce que fait par défaut Kerberos; une `entrée_principale.instance` de la forme `nom_d_utilisateur`. `root` autorisera `nom_d_utilisateur.` à utiliser man:su[1] pour devenir `root` si le fichier [.filename]#.klogin# du répertoire personnel de l'utilisateur `root` est correctement renseigné: [source,shell] .... # cat /root/.klogin jane.root@EXAMPLE.COM .... De même, si un utilisateur a dans son répertoire des lignes de la forme: [source,shell] .... % cat ~/.klogin jane@EXAMPLE.COM jack@EXAMPLE.COM .... Cela permet à quiconque dans le domaine `EXAMPLE.COM` s'étant authentifié en tant que `jane` ou `jack` (via `kinit`, voir plus haut) d'accéder avec man:rlogin[1] au compte de `jane` ou à ses fichiers sur le système (`grunt`) via man:rlogin[1], man:rsh[1] ou man:rcp[1]. Par exemple, `jane` ouvre maintenant une session sur un autre système en utilisant Kerberos: [source,shell] .... % kinit MIT Project Athena (grunt.example.com) Password: % rlogin grunt Last login: Mon May 1 21:14:47 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 .... Ou bien `jack` ouvre une session sur le compte de `jane` sur la même machine (`jane` ayant modifié son fichier [.filename]#.klogin# comme décrit plus haut, et la personne an charge de Kerberos ayant défini une entrée principale _jack_ sans instance): [source,shell] .... % kinit % rlogin grunt -l jane MIT Project Athena (grunt.example.com) Password: Last login: Mon May 1 21:16:55 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 .... [[kerberos5]] == Kerberos5 ** Traduction en Cours ** [[openssl]] == OpenSSL Une des caractéristiques que de nombreux utilisateurs ignorent souvent est la présence des outils OpenSSL dans le système FreeBSD. OpenSSL fournit une couche de transport des données chiffrée par-dessus la couche de communication, lui permettant ainsi d'être liée à de nombreux services et applications réseau. Les applications d'OpenSSL pourront être l'authentification chiffrée de clients de messagerie, les transactions via le Web comme les paiements par carte bancaire et bien plus encore. De nombreux logiciels portés tels que package:www/apache13-ssl[], et package:mail/sylpheed-claws[] offriront un support pour OpenSSL lors de leur compilation. [NOTE] ==== Dans la plupart des cas le catalogue des logiciels portés tentera de compiler le logiciel porté package:security/openssl[] à moins que la variable man:make[1] `WITH_OPENSSL_BASE` ne soit explicitement fixée à la valeur "yes". ==== La version d'OpenSSL fournie avec FreeBSD supporte les protocoles de sécurité réseau _Secure Sockets Layer v2/v3_ (SSLv2/SSLv3), et _Transport Layer Security v1_ (TLSv1) et peut être utilisée comme bibliothèque de chiffrement d'usage général. [NOTE] ==== Bien que OpenSSL supporte l'algorithme IDEA, il est désactivé par défaut en raison des problèmes de brevets aux USA. Pour l'utiliser, le texte de la licence devrait être consulté et si les termes de cette licence sont acceptables, la variable `MAKE_IDEA` doit être activée dans le fichier [.filename]#make.conf#. ==== Une des utilisations les plus courantes d'OpenSSL est de fournir des certificats utilisables avec des applications logicielles. Ces certificats assurent que les références de la société ou d'un individu sont valides et non frauduleuses. Si le certificat en question n'a pas été vérifié par une des nombreuses "autorité de certification" ("Certificate Authorities") ou CAs, une alerte est généralement produite. Une autorité de certification est une société, comme http://www.verisign.com[VeriSign], qui signera les certificats afin de valider les références d'individus ou de sociétés. Ce processus a un coût et n'est pas obligatoire pour utiliser des certificats, cependant cela pourra mettre plus à l'aise les utilisateurs les plus paranoïaques. === Générer des certificats Pour générer un certificat, la commande suivante est disponible: [source,shell] .... # openssl req -new -nodes -out req.pem -keyout cert.pem Generating a 1024 bit RSA private key ................++++++ .......................................++++++ writing new private key to 'cert.pem' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:PA Locality Name (eg, city) []:Pittsburgh Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company Organizational Unit Name (eg, section) []:Systems Administrator Common Name (eg, YOUR name) []:localhost.example.org Email Address []:trhodes@FreeBSD.org Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []:SOME PASSWORD An optional company name []:Another Name .... Notez la réponse à la question "Common Name" qui est un nom de domaine. Cette question demande l'entrée d'un serveur de noms à des fins de vérification; entrer autre chose qu'un nom de domaine produira un certificat inutilisable. D'autres options sont disponibles comme par exemple: la date d'expiration, des algorithmes de chiffrement alternatifs, etc. Une liste complète peut être obtenue en consultant la page de manuel man:openssl[1]. Deux fichiers doivent maintenant être présents dans le répertoire dans lequel la commande a été exécutée. La demande de certificat, [.filename]#req.pem#, peut être envoyée à une autorité de certification qui validera les références que vous avez saisies, signera la demande et vous retournera le certificat. Le deuxième fichier s'appellera [.filename]#cert.pem# et sera la clé privée du certificat et devra être à tout prix protégée; si ce fichier tombe dans d'autres mains, il pourra être utilisé pour imiter votre identité (ou votre serveur). Pour les cas où une signature d'une CA n'est pas indispensable, un certificat auto-signé peut être créé. Générez tout d'abord la clé RSA: [source,shell] .... # openssl dsaparam -rand -genkey -out myRSA.key 1024 .... Générez ensuite la clé de la CA: [source,shell] .... # openssl gendsa -des3 -out myca.key myRSA.key .... Utilisez cette clé pour créer le certificat: [source,shell] .... # openssl req -new -x509 -days 365 -key myca.key -out new.crt .... Deux fichiers devraient être présents maintenant dans le répertoire: un fichier de signature de l'autorité de certification, [.filename]#myca.key#, et le certificat lui-même, [.filename]#new.crt#. Ces fichiers doivent être placés dans un répertoire, de préférence sous [.filename]#/etc#, qui est uniquement lisible que par `root`. Les permissions 0700 devraient convenir et peuvent être fixées à l'aide de l'utilitaire `chmod`. === Utilisation des certificats, un exemple A quoi peuvent servir ces fichiers? Un bon exemple serait le chiffrage des connexions au MTAsendmail. Cela permettra de faire disparaître l'utilisation d'une authentification en clair pour les utilisateurs qui envoient du courrier via le MTA local. [NOTE] ==== Ce n'est pas la meilleure utilisation au monde étant donné que certains clients de messagerie afficheront une erreur si le certificat n'a pas été installé localement. Reportez-vous à la documentation du logiciel pour plus d'information sur l'installation de certificats. ==== Les lignes suivantes doivent être ajoutées dans le fichier [.filename]#.mc# local: [.programlisting] .... dnl SSL Options define(`confCACERT_PATH',`/etc/certs')dnl define(`confCACERT',`/etc/certs/new.crt')dnl define(`confSERVER_CERT',`/etc/certs/new.crt')dnl define(`confSERVER_KEY',`/etc/certs/myca.key')dnl define(`confTLS_SRV_OPTIONS', `V')dnl .... Où [.filename]#/etc/certs/# est le répertoire à utiliser pour stocker localement les certificats et les clés. La dernière condition nécessaire étant une reconstruction du fichier [.filename]#.cf#. Cela se fait facilement en tapant `make`[parameter]#install# à l'intérieur du répertoire [.filename]#/etc/mail#. Suivi d'un `make`[parameter]#restart# qui devrait relancer le "daemon"sendmail. Si tout s'est bien passé il n'y aura pas de message d'erreur dans le fichier [.filename]#/var/log/maillog# et sendmail apparaîtra dans la liste des processus. Comme test simple, connectez vous au serveur de messagerie à l'aide de l'utilitaire man:telnet[1]: [source,shell] .... # telnet example.com 25 Trying 192.0.34.166... Connected to example.com. Escape character is '^]'. 220 example.com ESMTP Sendmail 8.12.10/8.12.10; Tue, 31 Aug 2004 03:41:22 -0400 (EDT) ehlo example.com 250-example.com Hello example.com [192.0.34.166], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH LOGIN PLAIN 250-STARTTLS 250-DELIVERBY 250 HELP quit 221 2.0.0 example.com closing connection Connection closed by foreign host. .... Si la ligne "STARTTLS" apparaît dans la sortie, cela signifie alors que tout fonctionne correctement. [[ipsec]] == IPsec [NOTE] .Caractères de terminaison ==== Dans tous les exemples de cette section, et d'autres sections, vous remarquerez qu'il y aura un "^D" à la fin de certains exemples. Cela signifie qu'il faut maintenir la touche kbd:[Ctrl] enfoncée et appuyer sur la touche kbd:[D]. Un autre caractère couramment utilisé est "^C", qui signifie de maintenir enfoncé la touche kbd:[Ctrl] et d'appuyer sur kbd:[C]. ==== [TIP] ==== Pour d'autres documents détaillant l'implémentation d'IPsec, jetez un oeil à http://www.daemonnews.org/200101/ipsec-howto.html[http://www.daemonnews.org/200101/ipsec-howto.html] et http://www.freebsddiary.org/ipsec.php[http://www.freebsddiary.org/ipsec.php]. ==== Le mécanisme IPsec fournit des communications sécurisées sur couche IP ou à travers les _sockets_. Cette section explique comment l'utiliser. Pour des détails concernant l'implémentation d'IPsec, reportez-vous au extref:{developers-handbook}[Manuel du développeur, ipv6]. L'implémentation actuelle d'IPsec supporte le mode transport et le mode tunnel. Cependant, il y a des restrictions au mode tunnel. http://www.kame.net/newsletter/[http://www.kame.net/newsletter/] fournit des exemples plus exhaustifs. Soyez informé que pour utiliser cette fonctionnalité, vous devez avoir les options suivantes présentes dans votre fichier de configuration du noyau: [.programlisting] .... options IPSEC #IP security options IPSEC_ESP #IP security (crypto; define w/IPSEC) .... === Exemple en mode transport avec IPv4 Configurons une association de sécurité pour déployer un canal sécurisé entre la Machine A (`10.2.3.4`) et la Machine B (`10.6.7.8`). Notre exemple est un peu compliqué. De A vers B, nous n'utilisons que l'ancien AH. De B vers A, le nouvel AH et le nouvel ESP sont combinés. Nous devons maintenant choisir les algorithmes correspondant à "AH"/"nouvel AH"/"ESP"/ "nouvel ESP". Reportez-vous à la page de manuel man:setkey[8] pour connaître les noms des algorithmes. Nous utiliserons MD5 pour AH, new-HMAC-SHA1 pour le nouvel AH, et new-DES-expIV avec 8 octets IV pour le nouvel ESP. La longueur de la clé dépend de chaque algorithme. Par exemple, elle doit être égale à 16 octets pour MD5, 20 pour new-HMAC-SHA1, et 8 pour new-DES-expIV. Nous choisissons maintenant "MYSECRETMYSECRET", "KAMEKAMEKAMEKAMEKAME", "PASSWORD", respectivement. Définissons maintenant le SPI (_Security Parameter Index_) pour chaque protocole. Remarquez qu'il nous faut 3 SPIs pour ce canal sécurisé puisqu'il y aura trois entêtes de sécurité (une de la Machine A vers la Machine B et deux de la Machine B vers la Machine A). Notez également que les SPIs doivent être supérieurs à 256. Nous choisirions 1000, 2000 et 3000 respectivement. [source,shell] .... (1) Machine A ------> Machine B (1)PROTO=AH ALG=MD5(RFC1826) KEY=MYSECRETMYSECRET SPI=1000 (2.1) Machine A <------ Machine B <------ (2.2) (2.1) PROTO=AH ALG=new-HMAC-SHA1(new AH) KEY=KAMEKAMEKAMEKAMEKAME SPI=2000 (2.2) PROTO=ESP ALG=new-DES-expIV(new ESP) IV length = 8 KEY=PASSWORD SPI=3000 .... Maintenant, définissons l'association de sécurité. Exécutons man:setkey[8] sur la Machine A et la Machine B: [source,shell] .... # setkey -c add 10.2.3.4 10.6.7.8 ah-old 1000 -m transport -A keyed-md5 "MYSECRETMYSECRET" ; add 10.6.7.8 10.2.3.4 ah 2000 -m transport -A hmac-sha1 "KAMEKAMEKAMEKAMEKAME" ; add 10.6.7.8 10.2.3.4 esp 3000 -m transport -E des-cbc "PASSWORD" ; ^D .... En fait, la communication IPsec n'aura pas lieu avant que les entrées de politique de sécurité ne soient définies. Dans notre cas, il faut le faire sur les deux machines. [source,shell] .... Côté A: # setkey -c spdadd 10.2.3.4 10.6.7.8 any -P out ipsec ah/transport/10.2.3.4-10.6.7.8/require ; ^D Côté B: # setkey -c spdadd 10.6.7.8 10.2.3.4 any -P out ipsec esp/transport/10.6.7.8-10.2.3.4/require ; spdadd 10.6.7.8 10.2.3.4 any -P out ipsec ah/transport/10.6.7.8-10.2.3.4/require ; ^D Machine A --------------------------> Machine E 10.2.3.4 10.6.7.8 | | ========= ancien AH keyed-md5 ========> <======== nouveau AH hmac-sha1 ======== <======== nouveau ESP des-cbc ========= .... === Exemple en mode transport avec IPv6 Un autre exemple utilisant IPv6. Le mode de transport ESP est recommandé pour le port TCP numéro 110 entre la Machine-A et la Machine-B. [source,shell] .... ============ ESP ============ | | Machine-A Machine-B fec0::10 -------------------- fec0::11 .... L'algorithme de chiffrement est blowfish-cbc avec la clé "kamekame", et l'algorithme d'authentification est hmac-sha1 avec la clé "this is the test key". Configuration de la Machine-A: [source,shell] .... # setkey -c < Category: core <.> Module: sys <.> Announced: 2003-09-23 <.> Credits: Person@EMAIL-ADDRESS <.> Affects: All releases of FreeBSD <.> FreeBSD 4-STABLE prior to the correction date Corrected: 2003-09-23 16:42:59 UTC (RELENG_4, 4.9-PRERELEASE) 2003-09-23 20:08:42 UTC (RELENG_5_1, 5.1-RELEASE-p6) 2003-09-23 20:07:06 UTC (RELENG_5_0, 5.0-RELEASE-p15) 2003-09-23 16:44:58 UTC (RELENG_4_8, 4.8-RELEASE-p8) 2003-09-23 16:47:34 UTC (RELENG_4_7, 4.7-RELEASE-p18) 2003-09-23 16:49:46 UTC (RELENG_4_6, 4.6-RELEASE-p21) 2003-09-23 16:51:24 UTC (RELENG_4_5, 4.5-RELEASE-p33) 2003-09-23 16:52:45 UTC (RELENG_4_4, 4.4-RELEASE-p43) 2003-09-23 16:54:39 UTC (RELENG_4_3, 4.3-RELEASE-p39) <.> FreeBSD only: NO <.> For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit http://www.freebsd.org/security/. I. Background <.> II. Problem Description <.> III. Impact <.> IV. Workaround <.> V. Solution <.> VI. Correction details <.> VII. References <.> .... <.> Le champ `Topic` indique exactement quel est le problème. C'est basiquement une introduction à l'avis de sécurité en tant que tel et mentionne l'utilitaire contenant la vulnérabilité. <.> Le champ `Category` fait référence à la partie du système affectée qui peut être une parmi `core`, `contrib`, ou `ports`. La catégorie `core` signifie que la vulnérabilité affecte un composant système du système d'exploitation FreeBSD. La catégorie `contrib` précise que la vulnérabilité affecte du logiciel contribué au projet FreeBSD, comme sendmail. Et enfin la catégorie `ports` indique que la vulnérabilité affecte un logiciel du catalogue des logiciels portés. <.> Le champ `Module` fait référence à l'emplacement du composant, par exemple `sys`. Dans notre exemple, nous voyons que le module `sys` est affecté, par conséquent, cette vulnérabilité concerne un composant utilisé dans le noyau. <.> Le champ `Announced` reflète la date à laquelle l'avis de sécurité a été publié, ou annoncé au monde entier. Cela signifie que l'équipe de sécurité a vérifié que le problème existait vraiment et qu'un correctif a été ajouté au référentiel des sources de FreeBSD. <.> Le champ `Credits` donne le crédit de la découverte du problème à la personne ou l'organisation qui a constaté et rapporté le problème. <.> Le champ `Affects` explique quelles versions de FreeBSD sont affectées par cette vulnérabilité. Pour le noyau, un coup d'oeil rapide à la sortie de la commande `ident` sur les fichiers affectés aidera à déterminer la révision. Pour les logiciels portés, le numéro de version est listé après le nom du logiciel dans [.filename]#/var/db/pkg#. Si le système ne se synchronise pas avec le référentiel CVS FreeBSD et ne recompile pas les sources quotidiennement, il y a des chances qu'il soit affecté par le problème. <.> Le champ `Corrected` indique la date, l'heure, le fuseau horaire, et la version de publication qui a été corrigée. <.> Le champ `FreeBSD only` précise si cette vulnérabilité affecte juste FreeBSD, ou si elle concerne d'autres systèmes d'exploitation également. <.> Le champ `Background` donne une information précise sur ce qu'est l'utilitaire affecté. La plupart du temps, ce champ indique pourquoi l'utilitaire existe sous FreeBSD, son rôle, et quelques informations sur la naissance de l'utilitaire. <.> Le champ `Problem Description` explique en profondeur le problème de sécurité. Cela peut comprendre des informations sur le code défectueux, ou même comment l'utilitaire pourrait être utilisé pour ouvrir un faille de sécurité. <.> Le champ `Impact` décrit l'impact sur le système du problème de sécurité. Par exemple, cela peut aller de l'attaque par refus de service, au gain de droits supplémentaires par les utilisateurs, en passant par l'obtention des droits de super-utilisateur par l'attaquant. <.> Le champ `Workaround` offre une solution de contournement possible pour les administrateurs qui ne sont pas en mesure de mettre à jour le système. Cela pouvant être due à des contraintes de temps, à une disponibilité réseau, ou une tout autre raison. Cependant, la sécurité ne devrait pas être prise à la légère, et un système affecté devrait soit être corrigé soit implémenter une solution de contournement du problème de sécurité. <.> Le champ `Solution` donne les instructions sur l'application de correctifs sur le système affecté. C'est une méthode pas à pas vérifiée et testée pour obtenir un système corrigé et fonctionnant de manière sécurisée. <.> Le champ `Correction Details` liste la branche CVS ou la version de publication avec les points remplacés par des caractères souligné. Il donne également le numéro de révision des fichiers affectés sur chaque branche. <.> Le champ `References` donne en général d'autres sources d'informations. Cela peut être des URLs web, des ouvrages, des listes de diffusions, et des forums de discussion. [[security-accounting]] == Comptabilité des processus La comptabilité des processus est une mesure de sécurité avec laquelle un administrateur peut suivre l'utilisation des ressources du système, leur répartition entre les utilisateurs, surveiller le système et avoir un suivi minimal des commandes exécutées par un utilisateur. Ce système possède des avantages et des inconvénients. Un de ses avantages est qu'une intrusion pourra être remontée jusqu'à son point d'entrée. Un des inconvénients est la quantité de journaux générée par cette comptabilité et l'espace disque que cela peut demander. Cette section guidera l'administrateur au travers des bases de la comptabilité des processus. === Activer et utiliser la comptabilité des processus Avant de pouvoir utiliser la comptabilité des processus, il faut l'activer. Cela se fait en exécutant les commandes suivantes: [source,shell] .... # touch /var/account/acct # accton /var/account/acct # echo 'accounting_enable="YES"' >> /etc/rc.conf .... Une fois activée, les statistiques concernant le CPU, les commandes, etc. commenceront à être comptabilisée. Tous les journaux de comptabilisation des processus sont dans un format directement illisible pour l'utilisateur, ils pourront être examinés à l'aide de l'utilitaire man:sa[8]. Si elle est utilisée sans paramètre, la commande `sa` affichera les informations relatives au nombre d'appels par utilisateur, le temps écoulé en minutes, la durée totale des temps CPU et utilisateur en minutes, le nombre moyen des opérations d'E/S, etc. Pour afficher les informations sur les commandes utilisées, on emploiera l'utilitaire man:lastcomm[1]. La commande `lastcomm` peut être employée pour afficher les commandes tapées par les utilisateurs sur des terminaux (man:ttys[5]) spécifiques; par exemple: [source,shell] .... # lastcomm ls trhodes ttyp1 .... imprimera toute utilisation de la commande `ls` par l'utilisateur `trhodes` sur le terminal `ttyp1`. De nombreuses autres options utiles existent et sont détaillées dans les pages de manuel man:lastcomm[1], man:acct[5] et man:sa[8].