Matthew Dillon Une grande partie de ce chapitre provient de la page de manuel security(7) écrite par sécurité &trans.a.fonvieille; 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 &os;. De nombreux sujets abordés ici peuvent être appliqués à la sécurité système et 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. &os; 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 &os;. Les différents mécanismes de chiffrement disponibles sous &os;, comme DES et MD5. Comment mettre en place une authentification par mot de passe non réutilisable. Comment configurer Kerberos, un autre système d'authentification. Comment créer des coupe-feux en utilisant IPFW. Comment configurer IPsec. Comment configurer et utiliser OpenSSH, la version de SSH implémentée sous &os;. Comment configurer et charger les modules d'extension de contrôle d'accès en utilisant l'ensemble TrustedBSD MAC. Ce que sont les ACLs et comment les utiliser. Avant de lire ce chapitre, vous devrez: Comprendre les concepts de base de &os; et d'Internet. Bill Swingle En partie réécrit et mis à jour par sécurité chiffrement chiffrement DES MD5 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, &os; 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 &os; 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é. 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 &os; utilise MD5 pour chiffrer les mots de passe. Il est relativement facile d'identifier quelle méthode de chiffrement &os; 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 &man.login.conf.5; pour plus d'information sur les capacités de classe de session. mots de passe non réutilisables sécurité 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. &os; 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 &os; 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 &os;, 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 &man.opiekey.1; et reconnu par les programmes keyinit ou &man.opiepasswd.1; et l'invite de session; nous appellerons ceci un “mot de passe non réutilisable”. Le dernier type de mot de passe est le mot de passe secret que vous donnez aux programmes key/opiekey (et parfois aux programmes keyinit/opiepasswd) qui l'utilisent pour générer des mots de passe non réutilisable; nous l'appellerons “mot de passe secret” ou tout simplement “mot de passe”. Le mot de passe secret n'a rien à voir avec votre mot de passe &unix;; 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;Sous &os; le mot de passe standard peut avoir une longueur de 128 caractères maximum., 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. 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: &prompt.user; 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: &prompt.user; 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. 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: &prompt.user; 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: &prompt.user; 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: &prompt.user; 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: &prompt.user; 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é. Une fois que vous avez initialisé S/Key ou OPIE, lorsque que vous ouvrez une session, une invite de ce type apparaîtra: &prompt.user; 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: &prompt.user; 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. MS-DOS Windows MacOS 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: &prompt.user; 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: &prompt.user; 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 ... 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: &prompt.user; 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: &prompt.user; 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. 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 &man.skey.access.5; donne de plus amples informations sur le format de ce fichier et elle détaille également certains avertissements relatifs à la sécurité qu'il faut lire avant de se fier à ce fichier pour sa sécurité. S'il n'y a pas de fichier /etc/skey.access (ce qui est le cas par défaut sur les systèmes &os; 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 &os; 5.0 et versions suivantes. Veuillez consulter la page de manuel &man.opieaccess.5; pour plus d'information sur ce fichier et certaines considérations sur la sécurité dont vous devez être au courant en l'utilisant. Voici un exemple de fichier 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. Mark Murray Contribution de Mark Dapoz Basée sur une contribution de 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 &os;. Vous devriez cependant vous référer aux pages de manuel correspondantes pour avoir une description complète. MIT Kerberos installation Kerberos est un composant optionnel de &os;. 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 &os;. 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. 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: &prompt.root; cd /etc/kerberosIV &prompt.root; 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: &prompt.root; 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: &prompt.root; 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: &prompt.root; 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: &prompt.root; 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. Il faut ajouter deux entrées (“principals”) à la base de données pour chaque système qui sera sécurisé par Kerberos. Ce sont kpasswd et rcmd. Ces deux entrées sont définies pour chaque système, chacune de leurs instances se voyant attribuer le nom du système. Ces “daemons”, kpasswd et rcmd permettent aux autres systèmes de changer les mots de passe Kerberos et d'exécuter des commandes comme &man.rcp.1;, &man.rlogin.1;, et &man.rsh.1;. Ajoutons donc maintenant ces entrées: &prompt.root; 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 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. &prompt.root; 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 &man.mv.1; pour l'installer sur le système d'origine: &prompt.root; 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: &prompt.root; mv grumble-new-srvtab srvtab &prompt.root; chmod 600 srvtab 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: &prompt.root; 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 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. &prompt.root; 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 &prompt.root; 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: &prompt.user; 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: &prompt.user; klist Ticket file: /tmp/tkt245 Principal: jane@EXAMPLE.COM Issued Expires Principal Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.EXAMPLE.COM@EXAMPLE.COM Essayons maintenant de modifier le mot de passe en utilisant la commande &man.passwd.1; pour vérifier si le “daemon” kpasswd est autorisé à accéder à la base de données Kerberos: &prompt.user; passwd realm EXAMPLE.COM Old password for jane: New Password for jane: Verifying password New Password for jane: Password changed. Kerberos permet d'attribuer à chaque utilisateur qui a besoin des droits du super-utilisateur son propre mot de passe &man.su.1;. Nous pouvons créer un identifiant qui est autorisé à utiliser &man.su.1; pour devenir root. Cela se fait en associant une instance root un identificateur (“principal”) de base. En utilisant la commande kdb_edit nous pouvons créer l'entrée jane.root dans la base de données Kerberos: &prompt.root; 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: &prompt.root; 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: &prompt.root; cat /root/.klogin jane.root@EXAMPLE.COM Essayons maintenant la commande &man.su.1;: &prompt.user; su Password: et voyons quelles sont nos caractéristiques: &prompt.root; 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 Dans l'exemple précédent, nous avons créé une entrée principale nommée jane avec une instance root. Cette entrée reposait sur un utilisateur ayant le même nom que l'entrée principale, c'est ce que fait par défaut Kerberos; une <entrée_principale>.<instance> de la forme <nom_d_utilisateur>.root autorisera <nom_d_utilisateur>. à utiliser &man.su.1; pour devenir root si le fichier .klogin du répertoire personnel de l'utilisateur root est correctement renseigné: &prompt.root; cat /root/.klogin jane.root@EXAMPLE.COM De même, si un utilisateur a dans son répertoire des lignes de la forme: &prompt.user; cat ~/.klogin jane@EXAMPLE.COM jack@EXAMPLE.COM Cela permet à quiconque dans le domaine EXAMPLE.COM s'étant authentifié en tant que jane ou jack (via kinit, voir plus haut) d'accéder avec &man.rlogin.1; au compte de jane ou à ses fichiers sur le système (grunt) via &man.rlogin.1;, &man.rsh.1; ou &man.rcp.1;. Par exemple, jane ouvre maintenant une session sur un autre système en utilisant Kerberos: &prompt.user; kinit MIT Project Athena (grunt.example.com) Password: &prompt.user; 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): &prompt.user; kinit &prompt.user; 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 sécurité OpenSSL OpenSSL Depuis FreeBSD 4.0, la bibliothèque OpenSSL fait partie du système de base. OpenSSL fournit une bibliothèque de chiffrement d'usage général, ainsi que les protocoles de sécurité réseau Secure Sockets Layer v2/v3 (SSLv2/SSLv3) et Transport Layer Security v1 (TLSv1). Cependant, un des algorithmes (précisément IDEA) inclus dans OpenSSL est protégé par des brevets aux USA et ailleurs, et n'est pas utilisable sans restriction. IDEA est inclu dans la version &os; d'OpenSSL, mais n'est pas compilé par défaut. Si vous désirez l'utiliser, et que vous acceptez les termes de la licence, activez l'option MAKE_IDEA dans le fichier /etc/make.conf et recompilez vos sources en utilisant la commande make world. Aujourd'hui, l'algorithme RSA est libre d'utilisation aux USA et ailleurs. Il fut protégé par un brevet dans le passé. OpenSSL installation OpenSSL fait partie des catalogues CVSup src-crypto et src-secure. Reportez-vous à la section Se procurer FreeBSD pour savoir comment se procurer et mettre à jour le code source de &os;. Yoshinobu Inoue Contribution de IPsec sécurité IPsec 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 à et . 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. 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) Configurons une association de sécurité pour déployer un canal sécurisé entre la Machine A (10.2.3.4) et la Machine B (10.6.7.8). Notre exemple est un peu compliqué. De A vers B, nous n'utilisons que l'ancien AH. De B vers A, le nouvel AH et le nouvel ESP sont combinés. Nous devons maintenant choisir les algorithmes correspondant à “AH”/“nouvel AH”/“ESP”/ “nouvel ESP”. Reportez-vous à la page de manuel &man.setkey.8; pour connaître les noms des algorithmes. Nous utiliserons MD5 pour AH, new-HMAC-SHA1 pour le nouvel AH, et new-DES-expIV avec 8 octets IV pour le nouvel ESP. La longueur de la clé dépend de chaque algorithme. Par exemple, elle doit être égale à 16 octets pour MD5, 20 pour new-HMAC-SHA1, et 8 pour new-DES-expIV. Nous choisissons maintenant “MYSECRETMYSECRET”, “KAMEKAMEKAMEKAMEKAME”, “PASSWORD”, respectivement. Définissons maintenant le SPI (Security Parameter Index) pour chaque protocole. Remarquez qu'il nous faut 3 SPIs pour ce canal sécurisé puisqu'il y aura trois entêtes de sécurité (une de la Machine A vers la Machine B et deux de la Machine B vers la Machine A). Notez également que les SPIs doivent être supérieurs à 256. Nous choisirions 1000, 2000 et 3000 respectivement. (1) Machine A ------> Machine B (1)PROTO=AH ALG=MD5(RFC1826) KEY=MYSECRETMYSECRET SPI=1000 (2.1) Machine A <------ Machine B <------ (2.2) (2.1) PROTO=AH ALG=new-HMAC-SHA1(new AH) KEY=KAMEKAMEKAMEKAMEKAME SPI=2000 (2.2) PROTO=ESP ALG=new-DES-expIV(new ESP) IV length = 8 KEY=PASSWORD SPI=3000 Maintenant, définissons l'association de sécurité. Exécutons &man.setkey.8; sur la Machine A et la Machine B: &prompt.root; 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: &prompt.root; 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: &prompt.root; 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 ========= 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: &prompt.root; 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: &prompt.root; 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. 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: &prompt.root; 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: &prompt.root; 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 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: &prompt.root; 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: &prompt.root; 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 Chern Lee Contribution de OpenSSH sécurité OpenSSH OpenSSH est un ensemble d'outils de connexion réseau utilisés pour accéder à des machines distantes de façon sécurisé. Ils peuvent être utilisé 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 &os; 4.0. Normalement, quand on utilise &man.telnet.1; ou &man.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. OpenSSH activation 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. OpenSSH client L'utilitaire &man.ssh.1; fonctionne de la même manière que &man.rlogin.1;: &prompt.root; 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 &man.rlogin.1; ou &man.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. OpenSSH copie sécurisée scp La commande &man.scp.1; fonctionne de la même manière que &man.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é. &prompt.root; scp user@example.com:/COPYRIGHT COPYRIGHT user@example.com's password: ******* COPYRIGHT 100% |*****************************| 4735 00:00 &prompt.root; 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 &man.scp.1;. Les arguments passés à &man.scp.1; sont similaires à ceux de &man.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>. OpenSSH 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. Au lieu d'utiliser des mots de passe, &man.ssh-keygen.1; peut être employé pour générer des clés RSA pour authentifier un utilisateur: &prompt.user; 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. ... &man.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 &man.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é publique se trouve dans ~/.ssh/id_dsa. Les clés publiques DSA sont placées dans le fichier ~/.ssh/authorized_keys sur la machine distante. &man.ssh-agent.1; et &man.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 &man.ssh-keygen.1;. OpenSSH tunnel OpenSSH a la capacité de créer un tunnel pour encapsuler un autre protocole dans une session chiffrée. La commande suivante demande à &man.ssh.1; de créer un tunnel pour telnet: &prompt.user; ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com &prompt.user; 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. &prompt.user; ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com user@mailserver.example.com's password: ***** &prompt.user; 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 &man.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é. 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. &prompt.user; 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 tranférées de façon sécurisé à travers le tunnel jusqu'à mail.example.com. Certains administrateurs réseau imposent des règles draconiènes 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. &prompt.user; 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. OpenSSH &man.ssh.1; &man.scp.1; &man.ssh-keygen.1; &man.ssh-agent.1; &man.ssh-add.1; &man.sshd.8; &man.sftp-server.8; Tom Rhodes Contribution de ACL 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 récommandé par rapport à l'UFS1 pour une utilisation des listes de contô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 &man.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 (&man.mount.8; -u), mais uniquement par un &man.umount.8; complet et suivi d'un &man.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 &man.mount.8; complet, mais nous considerons 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.