Chapitre 14. Sécurité

This translation may be out of date. To help with the translations please access the FreeBSD translations instance.

14.1. 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®.

  • 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 Mandatory Access Control et les coupe-feux Internet sont développés dans le Firewalls.

14.2. 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® 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® 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:

  1. Attaques par déni de service.

  2. Compte utilisateur compromis.

  3. Le compte root compromis par l’intermédiaire de serveurs accessibles.

  4. Le compte root compromis par l’intermédiaire de comptes utilisateur.

  5. 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:

  1. Sécuriser les comptes root et d’administration.

  2. Sécuriser les serveurs exécutés avec les droits de root et les binaires suid/sgid.

  3. Sécuriser les comptes utilisateurs.

  4. Sécuriser le fichier des mots de passe.

  5. Sécuriser le noyau, les périphériques et les systèmes de fichiers.

  6. Installer un mécanisme de détection rapide des modifications inappropriées apportées au système.

  7. La paranoïa.

La section suivante de ce chapitre abordera de manière plus approfondie les points énoncés ci-dessus.

14.3. Securing FreeBSD Traduction en Cours

14.4. DES, MD5, et chiffrement

Chaque utilisateur d’un système UNIX® 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® 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® 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é.

14.4.1. Identifier votre mécanisme de chiffrement

Avant FreeBSD 4.4 libcrypt.a était un lien symbolique pointant sur la bibliothèque utilisée pour le chiffrement. FreeBSD 4.4 modifia 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 /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 /etc/login.conf, qui prend comme valeur des, md5 ou blf. Voir la page de manuel login.conf(5) pour plus d’information sur les capacités de classe de session.

14.5. 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® habituel ou mot de passe Kerberos; nous appellerons "mot de passe UNIX®". Le deuxième type est le mot de passe généré par les programmes S/Key key ou OPIE opiekey(1) et reconnu par les programmes keyinit ou 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®; 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®, 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®.

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 (/etc/skeykeys ou /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.

14.5.1. 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:

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

% 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.

14.5.2. 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:

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

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

% key 100 to17759
Reminder - Do not use this program while logged in via telnet or rlogin.
Enter secret password: <secret password>
CURE MIKE BANE HIM RACY GORE

Ou pour OPIE:

% 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é.

14.5.3. 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:

% telnet example.com
Trying 10.0.0.1...
Connected to example.com
Escape character is '^]'.

FreeBSD/i386 (example.com) (ttypa)

login: <username>
s/key 97 fw13894
Password:

Ou pour OPIE:

% telnet example.com
Trying 10.0.0.1...
Connected to example.com
Escape character is '^]'.

FreeBSD/i386 (example.com) (ttypa)

login: <username>
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 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:

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

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

login: <username>
s/key 97 fw13894
Password: <return to enable echo>
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 ...

14.5.4. 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:

% key -n 5 30 zz99999
Reminder - Do not use this program while logged in via telnet or rlogin.
Enter secret password: <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:

% 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: <secret password>
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.

14.5.5. Restreindre l’utilisation des mots de passe UNIX®

S/Key peut placer des restrictions sur l’utilisation des mots de passe UNIX® 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 /etc/skey.access. La page de manuel 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 /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®. 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 /etc/skey.access. Dans tous les cas l’usage des mots de passe UNIX® est autorisé sur la console.

Voici un exemple de configuration du fichier skey.access qui illustre les trois types d’instructions les plus courantes:

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®. 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®. 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®; cela devrait être employé pour les connexions téléphoniques.

OPIE peut restreindre l’usage des mots de passe UNIX® sur la base de l’adresse IP lors de l’ouverture d’une session comme peut le faire S/Key. Le fichier impliqué est /etc/opieaccess, qui est présent par défaut sous FreeBSD 5.0 et versions suivantes. Veuillez consulter la page de manuel 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 opieaccess:

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® à tout moment.

Si aucune règle du fichier opieaccess ne correspond, le comportement par défaut est de refuser toute ouverture de session non-OPIE.

14.6. L’encapsuleur TCP ("TCP Wrappers")

Toute personne familière avec 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 configuration d’inetd.

Bien que les programmes lancés par 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.

14.6.1. 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 rc.conf avec l’option -Ww; c’est la configuration par défaut. Bien évidemment une configuration correcte du fichier /etc/hosts.allow est également sous-entendue, mais dans le cas contraire syslogd(8) émettra des messages d’avertissement dans les journaux du système.

Contrairement à d’autres implémentations de l’encapsuleur TCP, l’emploi du fichier hosts.deny est obsolète. Toutes les options de configuration doivent être placées dans le fichier /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 /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"mail/qpopper, les lignes suivantes doivent être ajoutées au fichier hosts.allow:

# 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 kill(1), ou avec le passage du paramètre restart à la commande /etc/rc.d/inetd.

14.6.2. 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.

14.6.2.1. 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 hosts.allow:

# 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.

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:

# 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 /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 hosts_access(5) pour une liste complète.

14.6.2.2. 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:

# 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.

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 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 hosts.allow devra être dé-commentée. Cela a été noté en début de section.

14.7. 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.

14.7.1. 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 security/krb5.

14.7.2. 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 /etc/kerberosIV et assurez-vous qu’il ne contient que les fichiers suivants:

# cd /etc/kerberosIV
# ls
README		krb.conf        krb.realms

S’il y a d’autres fichiers (comme principal.* ou 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 krb.conf et 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 krb.conf:

# 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 krb.realms aura alors l’allure suivante:

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

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

# 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 /etc/kerberosIV/master_key.

14.7.3. 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 rcp(1), rlogin(1), et rsh(1).

Ajoutons donc maintenant ces entrées:

# 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

<Not found>, 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

<Not found>, 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

14.7.4. 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 /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.

# 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 srvtab pour que tous les serveurs puissent y accéder. Utilisez la commande mv(1) pour l’installer sur le système d’origine:

# 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 client-new-srvtab sur un support amovible et transportez-le par un moyen physiquement sûr. Assurez-vous de le renommer en srvtab dans le répertoire /etc/kerberosIV du client, et mettez-le bien en mode 600:

# mv grumble-new-srvtab srvtab
# chmod 600 srvtab

14.7.5. 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:

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

<Not found>, 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

14.7.6. Tester l’ensemble

Il faut tout d’abord démarrer les "daemons" Kerberos. Notez que si vous avez correctement modifié votre fichier /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 /etc/kerberosIV.

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

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

% 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 passwd(1) pour vérifier si le "daemon" kpasswd est autorisé à accéder à la base de données Kerberos:

% passwd
realm EXAMPLE.COM
Old password for jane:
New Password for jane:
Verifying password
New Password for jane:
Password changed.

14.7.7. 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 su(1). Nous pouvons créer un identifiant qui est autorisé à utiliser 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:

# 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

<Not found>, 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:

# kinit jane.root
MIT Project Athena (grunt.example.com)
Kerberos Initialization for "jane.root"
Password:

Nous devons maintenant ajouter l’utilisateur au fichier .klogin de root:

# cat /root/.klogin
jane.root@EXAMPLE.COM

Essayons maintenant la commande su(1):

% su
Password:

et voyons quelles sont nos caractéristiques:

# 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

14.7.8. 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 su(1) pour devenir root si le fichier .klogin du répertoire personnel de l’utilisateur root est correctement renseigné:

# cat /root/.klogin
jane.root@EXAMPLE.COM

De même, si un utilisateur a dans son répertoire des lignes de la forme:

% 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 rlogin(1) au compte de jane ou à ses fichiers sur le système (grunt) via rlogin(1), rsh(1) ou rcp(1).

Par exemple, jane ouvre maintenant une session sur un autre système en utilisant Kerberos:

% 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 .klogin comme décrit plus haut, et la personne an charge de Kerberos ayant défini une entrée principale jack sans instance):

% 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

14.8. Kerberos5 Traduction en Cours

14.9. 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 www/apache13-ssl, et mail/sylpheed-claws offriront un support pour OpenSSL lors de leur compilation.

Dans la plupart des cas le catalogue des logiciels portés tentera de compiler le logiciel porté security/openssl à moins que la variable 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.

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 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 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.

14.9.1. Générer des certificats

Pour générer un certificat, la commande suivante est disponible:

# 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 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, 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 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:

# openssl dsaparam -rand -genkey -out myRSA.key 1024

Générez ensuite la clé de la CA:

# openssl gendsa -des3 -out myca.key myRSA.key

Utilisez cette clé pour créer le certificat:

# 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, myca.key, et le certificat lui-même, new.crt. Ces fichiers doivent être placés dans un répertoire, de préférence sous /etc, qui est uniquement lisible que par root. Les permissions 0700 devraient convenir et peuvent être fixées à l’aide de l’utilitaire chmod.

14.9.2. 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.

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 .mc local:

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

/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 .cf. Cela se fait facilement en tapant makeinstall à l’intérieur du répertoire /etc/mail. Suivi d’un makerestart qui devrait relancer le "daemon"sendmail.

Si tout s’est bien passé il n’y aura pas de message d’erreur dans le fichier /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 telnet(1):

# 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.

14.10. IPsec

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 Ctrl enfoncée et appuyer sur la touche D. Un autre caractère couramment utilisé est "^C", qui signifie de maintenir enfoncé la touche Ctrl et d’appuyer sur C.

Pour d’autres documents détaillant l’implémentation d’IPsec, jetez un oeil à http://www.daemonnews.org/200101/ipsec-howto.html et 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 Manuel du développeur.

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

options          IPSEC              #IP security
options          IPSEC_ESP          #IP security (crypto; define w/IPSEC)

14.10.1. 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 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.

	          (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 setkey(8) sur la Machine A et la Machine B:

# 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.

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 =========

14.10.2. 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.

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

# setkey -c <<EOF
    spdadd fec0::10[any] fec0::11[110] tcp -P out ipsec
	esp/transport/fec0::10-fec0::11/use ;
    spdadd fec0::11[110] fec0::10[any] tcp -P in ipsec
	esp/transport/fec0::11-fec0::10/use ;
    add fec0::10 fec0::11 esp 0x10001
	-m transport
	-E blowfish-cbc "kamekame"
	-A hmac-sha1 "this is the test key" ;
    add fec0::11 fec0::10 esp 0x10002
	-m transport
	-E blowfish-cbc "kamekame"
	-A hmac-sha1 "this is the test key" ;
    EOF

et de la Machine-B:

# setkey -c <<EOF
    spdadd fec0::11[110] fec0::10[any] tcp -P out ipsec
	esp/transport/fec0::11-fec0::10/use ;
    spdadd fec0::10[any] fec0::11[110] tcp -P in ipsec
	esp/transport/fec0::10-fec0::11/use ;
    add fec0::10 fec0::11 esp 0x10001 -m transport
	-E blowfish-cbc "kamekame"
	-A hmac-sha1 "this is the test key" ;
    add fec0::11 fec0::10 esp 0x10002 -m transport
	-E blowfish-cbc "kamekame"
	-A hmac-sha1 "this is the test key" ;
    EOF

Remarquez la direction de SP.

14.10.3. Exemple en mode tunnel avec IPv4

Mode tunnel entre deux passerelles de sécurité

Le protocole de sécurité est l’ancien mode tunnel AH, i.e. spécifié par la RFC1826, avec keyed-md5 comme algorithme d’authentification et "this is the test" comme clé.

                             ======= AH =======
                             |                |
         Réseau-A       Passerelle-A     Passerelle-B       Réseau-B
        10.0.1.0/24 ---- 172.16.0.1 ----- 172.16.0.2 ---- 10.0.2.0/24

Configuration de la Passerelle-A:

# setkey -c <<EOF
    spdadd 10.0.1.0/24 10.0.2.0/24 any -P out ipsec
	ah/tunnel/172.16.0.1-172.16.0.2/require ;
    spdadd 10.0.2.0/24 10.0.1.0/24 any -P in ipsec
	ah/tunnel/172.16.0.2-172.16.0.1/require ;
    add 172.16.0.1 172.16.0.2 ah-old 0x10003 -m any
	-A keyed-md5 "this is the test" ;
    add 172.16.0.2 172.16.0.1 ah-old 0x10004 -m any
	-A keyed-md5 "this is the test" ;

EOF

Si le numéro de port n’est pas précisé comme ci-dessus, alors [any] est utilisé. -m définit le mode de SA à utiliser. -m any signifie tout mode de protocole de sécurité. Vous pouvez utiliser cette SA à la fois en mode transport et en mode tunnel.

et de la Passerelle-B:

# setkey -c <<EOF
    spdadd 10.0.2.0/24 10.0.1.0/24 any -P out ipsec
	ah/tunnel/172.16.0.2-172.16.0.1/require ;
    spdadd 10.0.1.0/24 10.0.2.0/24 any -P in ipsec
	ah/tunnel/172.16.0.1-172.16.0.2/require ;
    add 172.16.0.1 172.16.0.2 ah-old 0x10003 -m any
	-A keyed-md5 "this is the test" ;
    add 172.16.0.2 172.16.0.1 ah-old 0x10004 -m any
	-A keyed-md5 "this is the test" ;

EOF

Etablir une SA regroupée entre deux passerelles de sécurité

On désire le mode de transport AH et le mode tunnel ESP entre Passerelle-A et Passerelle-B. Dans ce cas, on applique d’abord le mode tunnel ESP puis le mode de transport AH.

                            ========== AH =========
                            |  ======= ESP =====  |
                            |  |               |  |
       Réseau-A         Passerelle-A        Passerelle-B        Réseau-B
    fec0:0:0:1::/64 --- fec0:0:0:1::1 ---- fec0:0:0:2::1 --- fec0:0:0:2::/64

14.10.4. Exemple en mode tunnel avec IPv6

L’algorithme de chiffrement est 3des-cbc, et l’algorithme d’authentification est hmac-sha1. L’algorithme d’authentification pour AH est hmac-md5. Configuration de la Passerelle-A:

# setkey -c <<EOF
    spdadd fec0:0:0:1::/64 fec0:0:0:2::/64 any -P out ipsec
	esp/tunnel/fec0:0:0:1::1-fec0:0:0:2::1/require
	ah/transport/fec0:0:0:1::1-fec0:0:0:2::1/require ;
    spdadd fec0:0:0:2::/64 fec0:0:0:1::/64 any -P in ipsec
	esp/tunnel/fec0:0:0:2::1-fec0:0:0:1::1/require
	ah/transport/fec0:0:0:2::1-fec0:0:0:1::1/require ;
    add fec0:0:0:1::1 fec0:0:0:2::1 esp 0x10001 -m tunnel
	-E 3des-cbc "kamekame12341234kame1234"
	-A hmac-sha1 "this is the test key" ;
    add fec0:0:0:1::1 fec0:0:0:2::1 ah 0x10001 -m transport
	-A hmac-md5 "this is the test" ;
    add fec0:0:0:2::1 fec0:0:0:1::1 esp 0x10001 -m tunnel
	-E 3des-cbc "kamekame12341234kame1234"
	-A hmac-sha1 "this is the test key" ;
    add fec0:0:0:2::1 fec0:0:0:1::1 ah 0x10001 -m transport
	-A hmac-md5 "this is the test" ;

    EOF

Etablir des SAs avec les différentes extrémités

On désire un mode tunnel ESP entre Machine-A et Passerelle-A. L’algorithme de chiffrement est cast128-cbc, et l’algorithme d’authentification pour ESP est hmac-sha1. Le mode de transport ESP est recommandé entre Machine-A et Machine-B. L’algorithme de chiffrement est rc5-cbc, et l’algorithme d’authentification pour ESP est hmac-md5.

              ================== ESP =================
              |  ======= ESP =======                 |
              |  |                 |                 |
            Machine-A        Passerelle-A         Machine-B
          fec0:0:0:1::1 ---- fec0:0:0:2::1 ---- fec0:0:0:2::2

Configuration de la Machine-A:

# setkey -c <<EOF
    spdadd fec0:0:0:1::1[any] fec0:0:0:2::2[80] tcp -P out ipsec
	esp/transport/fec0:0:0:1::1-fec0:0:0:2::2/use
	esp/tunnel/fec0:0:0:1::1-fec0:0:0:2::1/require ;
    spdadd fec0:0:0:2::1[80] fec0:0:0:1::1[any] tcp -P in ipsec
	esp/transport/fec0:0:0:2::2-fec0:0:0:l::1/use
	esp/tunnel/fec0:0:0:2::1-fec0:0:0:1::1/require ;
    add fec0:0:0:1::1 fec0:0:0:2::2 esp 0x10001
	-m transport
	-E cast128-cbc "12341234"
	-A hmac-sha1 "this is the test key" ;
    add fec0:0:0:1::1 fec0:0:0:2::1 esp 0x10002
	-E rc5-cbc "kamekame"
	-A hmac-md5 "this is the test" ;
    add fec0:0:0:2::2 fec0:0:0:1::1 esp 0x10003
	-m transport
	-E cast128-cbc "12341234"
	-A hmac-sha1 "this is the test key" ;
    add fec0:0:0:2::1 fec0:0:0:1::1 esp 0x10004
	-E rc5-cbc "kamekame"
	-A hmac-md5 "this is the test" ;

    EOF

14.11. OpenSSH

OpenSSH est un ensemble d’outils de connexion réseau utilisés pour accéder à des machines distantes de façon sécurisée. Ils peuvent être utilisés comme remplaçants directs de rlogin, rsh, rcp, et telnet. De plus, OpenSSH peut sécuriser n’importe quelle connexion TCP/IP via un tunnel. OpenSSH chiffre tout le trafic de façon à déjouer les écoutes réseau, les prises de contrôle de connexion, et aux attaques au niveau du réseau.

OpenSSH est maintenu par le projet OpenBSD, et est basé sur SSH v1.2.12 avec tous les récentes corrections et mises à jour. Il est compatible avec les protocoles SSH 1 et 2. OpenSSH est présent dans le système de base depuis FreeBSD 4.0.

14.11.1. Les avantages à utiliser OpenSSH

Normalement, quand on utilise telnet(1) ou rlogin(1), les données sont envoyées sur le réseau en clair, sous forme non chiffrée. Des "renifleurs de paquets" placés n’importe où entre le client et le serveur peuvent prendre connaissance de votre nom d’utilisateur, de votre mot de passe et des données transmises lors de votre session. OpenSSH offre une variété de méthodes d’authentification et de chiffrage pour éviter ce genre de problème.

14.11.2. Activer sshd

Assurez-vous d’ajouter la ligne suivante à votre fichier rc.conf:

sshd_enable="YES"

Cela chargera le "daemon" ssh à l’initialisation suivante du système. Alternativement, vous pouvez tout simplement exécuter le "daemon" sshd directement en tapant sshd sur la ligne de commande.

14.11.3. Client SSH

L’utilitaire ssh(1) fonctionne de la même manière que rlogin(1):

# ssh user@example.com
Host key not found from the list of known hosts.
Are you sure you want to continue connecting (yes/no)? yes
Host 'example.com' added to the list of known hosts.
user@example.com's password: *******

L’ouverture de session se poursuit comme si elle avait lancée par rlogin(1) ou telnet(1). Le système SSH utilise un système d’empreinte de clé pour vérifier l’authenticité du serveur quand le client se connecte. L’utilisateur est invité à entrer yes uniquement à la première connexion. Lors des futures connexions, l’empreinte de la clé sauvegardé est vérifiée. Le client SSH vous avertira si l’empreinte sauvée diffère de l’empreinte reçue lors de futures tentatives de connexion. Les empreintes sont sauvées dans le fichier ~/.ssh/known_hosts, ou ~/.ssh/known_hosts2 pour les empreintes du protocole SSH 2.

Par défaut, les serveurs OpenSSH sont configurés pour accepter les connexions dans les deux protocoles SSH 1 et 2. Le client peut, cependant, choisir entre les deux. Le protocole 2 est connu pour être plus robuste et plus sécurisé que son prédécesseur.

ssh peut être forcé à utilisé l’un des protocole en passant l’argument -1 ou -2 pour le protocole 1 ou 2 respectivement.

14.11.4. Copie sécurisée

La commande scp(1) fonctionne de la même manière que rcp(1); elle copie un fichier vers ou à partir d’une machine distante à la différence qu’elle le fait d’une façon sécurisé.

#  scp user@example.com:/COPYRIGHT COPYRIGHT
user@example.com's password: *******
COPYRIGHT            100% |*****************************|  4735
00:00
#

Puisque l’empreinte a déjà été sauvée pour cette machine dans l’exemple précédent, cela se vérifie ici quand on utilise scp(1).

Les arguments passés à scp(1) sont similaires à ceux de cp(1), avec le ou les fichiers en premier argument, et la destination en second. Puisque que le fichier est copié via le réseau, par l’intermédiaire de SSH, un ou plusieurs des arguments prennent la forme utilisateur@machine_distante:chemin_du_fichier.

14.11.5. Configuration

Les fichiers de configuration général au système pour le "daemon" et le client OpenSSH résident dans le répertoire /etc/ssh.

ssh_config permet de paramétrer le client, tandis que sshd_config s’occupe de la configuration du "daemon".

De plus, les options sshd_program (/usr/sbin/sshd par défaut), et sshd_flags du fichier rc.conf peut fournir un niveau supplémentaire de configuration.

14.11.6. ssh-keygen

Au lieu d’utiliser des mots de passe, ssh-keygen(1) peut être employé pour générer des clés RSA pour authentifier un utilisateur:

% ssh-keygen -t rsa1
Initializing random number generator...
Generating p:  .++ (distance 66)
Generating q:  ..............................++ (distance 498)
Computing the keys...
Key generation complete.
Enter file in which to save the key (/home/user/.ssh/identity):
Enter passphrase:
Enter the same passphrase again:
Your identification has been saved in /home/user/.ssh/identity.
...

ssh-keygen(1) créera une paire de clés publique et privée à utiliser pour l’authentification. La clé privée est stockée dans le fichier ~/.ssh/identity, alors que la clé publique l’est dans le fichier ~/.ssh/identity.pub. La clé publique doit être placée dans le fichier ~/.ssh/authorized_keys sur la machine distante pour que cela fonctionne.

Ceci autorisera les connexions sur la machine distante en utilisant l’authentification RSA à la place des mots de passe.

L’option -t rsa1 créera des clés RSA pour le protocole SSH 1. Si vous désirez utiliser des clés RSA avec le protocole SSH 2, vous devez employer la commande ssh-keygen -t rsa.

Si une phrase d’authentification est utilisée avec ssh-keygen(1), l’utilisateur se verra demandé d’entrer un mot de passe à chaque utilisation de la clé privé.

Une clé DSA SSH protocole 2 peut être créée pour le même objectif en utilisant la commande ssh-keygen -t dsa. Cela créera une paire de clés DSA pour les sessions SSH utilisant le protocole 2. La clé publique est conservée dans ~/.ssh/id_dsa.pub, tandis que la clé privée se trouve dans ~/.ssh/id_dsa.

Les clés publiques DSA sont placées dans le fichier ~/.ssh/authorized_keys sur la machine distante.

ssh-agent(1) et ssh-add(1) sont des utilitaires employés pour la gestion de multiples clés privées protégées par mots de passe.

Les divers fichiers et options peuvent être différents selon la version d’OpenSSH dont vous disposez, pour éviter les problèmes vous devez consultez la page de manuel ssh-keygen(1).

14.11.7. Tunnels SSH

OpenSSH a la capacité de créer un tunnel pour encapsuler un autre protocole dans une session chiffrée.

La commande suivante demande à ssh(1) de créer un tunnel pour telnet:

% ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com
%

La commande ssh est utilisée avec les options suivantes:

-2

Force ssh à utiliser la version du protocole (à ne pas utiliser si vous travaillez avec de vieux serveurs SSH).

-N

N’exécute aucune commande à distance, ou mode se place en mode tunnel. Si cette option est omise ssh initiera une session normale.

-f

Force ssh à s’exécuter en arrière-plan.

-L

Spécifie un tunnel local de la manière port_local:machine_distante:port_distant.

user@foo.example.com

Le serveur SSH distant.

Un tunnel SSH fonctionne grâce à l’allocation d’une "socket" qui écoute sur le port spécifié de la machine localhost. Il transfère ensuite toute connexion reçue sur la/le machine/port local(e) via la connexion SSH vers la machine et le port distants spécifiés.

Dans l’exemple, le port 5023 sur la machine locale transfère toute connexion sur ce port vers le port 23 de la machine distante (le localhost de la commande). Puisque le port 23 est celui de telnet, cela créerai une session telnet sécurisée par l’intermédiaire d’un tunnel SSH.

Cela peut être utilisé pour encapsuler n’importe quel nombre de protocoles TCP non sécurisé comme SMTP, POP3, FTP, etc.

Exemple 1. Utiliser SSH pour créer un tunnel sécurisé pour SMTP
% ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com
user@mailserver.example.com's password: *****
% telnet localhost 5025
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mailserver.example.com ESMTP

Ceci peut être utilisé en conjonction avec ssh-keygen(1) et des comptes utilisateurs supplémentaires pour la création et l’accès au tunnel SSH sans trop de problème. Des clés peuvent être utilisées à la place de la saisie d’un mot de passe, et les tunnels peuvent être exécutés sous un utilisateur séparé.

14.11.7.1. Exemples pratiques de tunnels SSH

14.11.7.1.1. Accès sécurisé à un serveur POP3

Au travail, il y a un serveur SSH qui accepte les connexions de l’extérieur. Sur le même réseau d’entreprise réside un serveur de courrier électronique faisant fonctionner un serveur POP3. Le réseau ou le chemin entre chez vous et le bureau peut ou peut ne pas être complètement sûr. Pour cette raison, vous devez récupérer votre courrier électronique d’une façon sécurisée. La solution est de créer une connexion SSH vers le serveur SSH de votre entreprise, et d’utiliser ce tunnel vers le serveur de courrier.

% ssh -2 -N -f -L 2110:mail.example.com:110 user@ssh-server.example.com
user@ssh-server.example.com's password: ******

Quand le tunnel est configuré et fonctionne, vous pouvez demander à votre client de courrier électronique d’envoyer ses requêtes POP3 sur le port 2110 de la machine locale: localhost. Les connexions seront transférées de façon sécurisé à travers le tunnel jusqu’à mail.example.com.

14.11.7.1.2. Passer à travers un coupe-feu restrictif

Certains administrateurs réseau imposent des règles draconiennes au niveau du coupe-feu, filtrant non seulement les connexions entrantes, mais également les connexions sortantes. Il se peut que vous n’ayez accès qu’aux ports 22 et 80 de machines distantes pour SSH ou la navigation Internet.

Vous pouvez vouloir accéder à un autre (n’ayant peut-être aucun rapport avec votre travail) service, comme un serveur Ogg Vorbis pour écouter de la musique. Si le serveur Ogg Vorbis diffuse ("streaming") ses données à partir d’un port différent des ports 22 ou 80, vous ne serez alors pas en mesure d’y accéder.

La solution est de créer une connexion SSH vers une machine à l’extérieur du réseau protégé par le coupe-feu, et l’utiliser pour créer un tunnel vers le serveur Ogg Vorbis.

% ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled-system.example.org
user@unfirewalled-system.example.org's password: *******

Vous pouvez maintenant faire pointer votre client pour la récupération du flux de données sur le port 8888 de la machine locale, qui sera transféré jusqu’au port 8000 de la machine music.example.com, passant ainsi outre les restrictions du coupe-feu.

14.12. Listes de contrôle d’accès au système de fichiers

Avec les améliorations des systèmes de fichiers comme les "snapshots", FreeBSD 5.0 et versions suivantes offrent une nouveauté en matière de sécurité: les listes de contrôle d’accès au système de fichiers (ACLs - "Access Control Lists").

Les listes de contrôle d’accès étendent le système de permission standard d’UNIX d’une manière hautement compatible (POSIX.1e). Cette caractéristique permet à un administrateur d’utiliser avantageusement un modèle de sécurité plus sophistiqué.

Pour activer le support ACL pour les systèmes de fichiers UFS, ce qui suit:

options UFS_ACL

doit être compilé dans le noyau. Si cette option n’a pas été ajoutée, un avertissement sera affiché lors d’une tentative de montage d’un système de fichiers supportant les ACLs. Cette option est présente dans le noyau GENERIC. Les ACLs reposent sur des attributs étendus rajoutés au système de fichiers. Les attributs étendus sont nativement supportés par la prochaine génération du système de fichiers UNIX, UFS2.

Un supplément de travail d’administration est requis pour configurer les attributs étendus sous UFS1 par rapport à UFS2. Les performances des attributs étendus sous UFS2 sont sensiblement meilleures également. Il en résulte donc, que l’UFS2 est généralement recommandé par rapport à l’UFS1 pour une utilisation des listes de contrôle d’accès.

Les ACLs sont activés grâce l’option utilisée lors du montage, acls, qui peut être ajouté dans le fichier /etc/fstab. Cette option de montage peut être également automatiquement fixée d’une manière définitive en utilisant tunefs(8) pour modifier l’indicateur ACL du "superblock" dans l’entête du système de fichiers. Il est en général préférable d’utiliser cet indicateur pour plusieurs raisons:

  • L’option de montage pour les ACLs ne peut être modifiée par un simple remontage (mount(8) -u), mais uniquement par un umount(8) complet et suivi d’un mount(8). Cela signifie que les ACLs ne peuvent être activées sur le système de fichiers racine après le démarrage. Cela signifie également que vous ne pouvez pas modifier la disposition d’un système de fichier une fois que c’est activé.

  • Positionner l’indicateur du "superblock" fera que le système de fichiers sera toujours monté avec les ACLs activées même s’il n’y a pas d’entrée dans le fichier fstab, ou s’il y a une réorganisation des périphériques. Cela prévient le montage accidentel du système de fichiers sans les ACLs activées, ce qui peut provoquer une activation impropre des ACLs et par conséquent des problèmes de sécurité.

Nous pourrions modifier le comportement des ACLs pour permettre l’activation de l’indicateur sans le besoin d’un nouveau mount(8) complet, mais nous considérons qu’il est préférable d’éviter un montage accidentel sans les ACLs activées, parce que vous pouvez vous "tirer facilement dans les pieds" si vous activez les ACLs, puis les désactivez, et ensuite les réactivez à nouveau sans réinitialiser les attributs étendus. En général, une fois que vous avez activé les ACLs sur un système de fichiers, elles ne devraient pas être désactivées étant donné que les protections de fichiers résultantes peuvent ne pas être compatible avec celles prévues par les utilisateurs du système, et réactiver les ACLs peut réaffecter les précédentes ACLs aux fichiers qui ont depuis eût leur permissions modifiées, avec pour résultat un comportement imprévisible.

Les systèmes de fichiers avec les ACLs activées présenteront un signe + au niveau de leurs permissions quand elles seront affichées. Par exemple:

drwx------  2 robert  robert  512 Dec 27 11:54 private
drwxrwx---+ 2 robert  robert  512 Dec 23 10:57 directory1
drwxrwx---+ 2 robert  robert  512 Dec 22 10:20 directory2
drwxrwx---+ 2 robert  robert  512 Dec 27 11:57 directory3
drwxr-xr-x  2 robert  robert  512 Nov 10 11:54 public_html

Ici nous voyons que les répertoires directory1, directory2, et directory3 utilisent les ACLs. Ce n’est pas le cas du répertoire public_html.

14.12.1. Utilisation des ACLs

Les ACLs peuvent être affichées par l’utilitaire getfacl(1). Par exemple pour voir les ACLs sur le fichier test, on utilisera la commande:

% getfacl test
	#file:test
	#owner:1001
	#group:1001
	user::rw-
	group::r--
	other::r--

Pour modifier le paramétrage des ACLs sur ce fichier, invoquez la commande setfacl(1). Intéressons-nous à la ligne:

% setfacl -k test

L’indicateur -k supprimera toutes les ACLs actuellement définies pour un fichier ou un système de fichiers. Une méthode plus adaptée est d’utiliser l’option -b étant donné qu’elle conserve les champs de base nécessaires au bon fonctionnement des ACLs.

% setfacl -m u:trhodes:rwx,group:web:r--,o::--- test

Dans la commande ci-dessus, l’option -m a été utilisée pour modifier les entrées ACL par défaut. Comme il n’y avait pas d’entrées pré-définies, puisqu’elles ont été supprimées par la commande précédente, cela restaurera les options par défaut et prendra en compte les options précisées. Prenez soin de noter que si vous ajoutez un utilisateur ou un groupe qui n’existe pas sur le système, une erreur Invalid argument sera affichée sur la sortie standard.

14.13. Surveillance des problèmes de sécurité relatifs aux programmes tierce-partie

Ces dernières années, le monde de la sécurité a fait beaucoup de progrès dans la manière d’évaluer les vulnérabilités. Le risque d’une intrusion dans le système augmente avec l’installation et la configuration d’utilitaires tierce-partie et cela pour quasiment n’importe quel système d’exploitation disponible aujourd’hui.

L’évaluation des vulnérabilités est un facteur clé de la politique de sécurité, alors que FreeBSD publie des avis pour le système de base, faire de même pour les programmes tierce-partie dépasse les capacités du projet FreeBSD. Il existe un moyen d’atténuer les vulnérabilités des logiciels tierce-partie et de prévenir les administrateurs des problèmes de sécurité connus. Un outil FreeBSD connu sous le nom de Portaudit existe dans cet unique but.

Le logiciel porté ports-mgmt/portaudit consulte une base de données, mise à jour et maintenue par l’équipe de sécurité de FreeBSD et les développeurs des logiciels portés, à la recherche de problèmes de sécurité connus.

Pour utiliser Portaudit, ce dernier doit être installé à partir du catalogue des logiciels portés:

# cd /usr/ports/ports-mgmt/portaudit && make install clean

Lors du processus d’installation, les fichiers de configuration de periodic(8) seront mis à jour, autorisant l’ajout des résultats de Portaudit dans l’exécution quotidienne du rapport de sécurité. Assurez-vous que les rapports de sécurité quotidiens, qui sont envoyés au compte messagerie de root, sont bien lus. Pas plus de configuration ne sera nécessaire.

Après l’installation, un administrateur peut mettre à jour la base de données et afficher les vulnérabilités connues des logiciels installés en invoquant la commande suivante:

# portaudit -Fda

La base de données sera automatiquement mise à jour lors de l’exécution de periodic(8), cela rendant par conséquent facultative la commande précédente. Elle n’est requise que pour les exemples qui vont suivre.

Pour contrôler à n’importe quel moment les programmes tierce-partie installés à partir du catalogue des logiciels portés, un administrateur n’aura qu’à exécuter la commande suivante:

# portaudit -a

Portaudit produira pour les logiciels vulnérables quelque chose comme ceci:

Affected package: cups-base-1.1.22.0_1
Type of problem: cups-base -- HPGL buffer overflow vulnerability.
Reference: http://www.FreeBSD.org/ports/portaudit/40a3bca2-6809-11d9-a9e7-0001020eed82.html

1 problem(s) in your installed packages found.

You are advised to update or deinstall the affected package(s) immediately.

En faisant pointer un navigateur Web sur l’URL proposée, un administrateur pourra obtenir plus d’information au sujet de la vulnérabilité en question. Cela comprendra les versions affectées, listées par version du logiciel porté FreeBSD, ainsi que des liens vers d’autres sites Web pouvant contenir des avis de sécurité.

En résumé, Portaudit est un outil puissant et extrêmement utile quand il est employé conjointement avec le logiciel Portupgrade.

14.14. Avis de sécurité de FreeBSD

Comme plusieurs systèmes d’exploitation destinés à la production, FreeBSD publie des "Avis de sécurité". Ces avis sont généralement envoyés aux listes de diffusion traitant de la sécurité et ajoutés dans l’errata une fois seulement que les versions correspondantes ont été corrigées. Cette section aura pour objectif d’expliquer ce qu’est un avis, comment le comprendre, et quelles mesures sont à prendre pour appliquer des correctifs à un système.

14.14.1. A quoi ressemble un avis de sécurité?

Les avis de sécurité de FreeBSD ressemblent à celui présenté ci-dessous qui provient de la liste de diffusion liste de diffusion des avis de sécurité pour FreeBSD.

=============================================================================
FreeBSD-SA-XX:XX.UTIL                                     Security Advisory
                                                          The FreeBSD Project

Topic:          denial of service due to some problem (1)

Category:       core (2)
Module:         sys (3)
Announced:      2003-09-23 (4)
Credits:        Person@EMAIL-ADDRESS (5)
Affects:        All releases of FreeBSD (6)
                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) (7)
FreeBSD only:   NO (8)

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 (9)

II.  Problem Description (10)

III. Impact (11)

IV.  Workaround (12)

V.   Solution (13)

VI.  Correction details (14)

VII. References (15)
1Le 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é.
2Le 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.
3Le 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.
4Le 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.
5Le 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.
6Le 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 /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.
7Le champ Corrected indique la date, l’heure, le fuseau horaire, et la version de publication qui a été corrigée.
8Le champ FreeBSD only précise si cette vulnérabilité affecte juste FreeBSD, ou si elle concerne d’autres systèmes d’exploitation également.
9Le 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.
10Le 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é.
11Le 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.
12Le 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é.
13Le 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.
14Le 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.
15Le 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.

14.15. 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.

14.15.1. 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:

# 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 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 lastcomm(1). La commande lastcomm peut être employée pour afficher les commandes tapées par les utilisateurs sur des terminaux (ttys(5)) spécifiques; par exemple:

# 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 lastcomm(1), acct(5) et sa(8).


Last modified on: 9 mars 2024 by Danilo G. Baio