David Pauillac
OpenSolaris et la sécurité Master 2 SSI Université du Sud, Toulon et du Var
novembre 2007 ii
Copyright c 2007 David PAUILLAC. Ce document est distribué sous Licence GNU Free Documentation License 1. Vous pouvez copier et/ou distribuer ce document à condition de respecter les termes de la GFDL, version 1.2 ou toute version publiée ultérieurement par la Free Software Foundation. Une copie de la licence est incluse en annexe C intitulée “GNU Free Documentation License”. Les nom et logos OpenSolaris sont des marques déposées par Sun Microsystem.
1. GFDL
David Pauillac c novembre 2007 - OpenSolaris et la sécurité Avant-propos
À propos du document
Ce document, à l’origine, était destiné aux étudiants de master2 SSI de l’université de Sud, Toulon et du Var. Cependant, j’espère qu’il pourra ser- vir aussi aux administrateurs devant (ou désirant) utiliser un système basé sur OpenSolaris (tel que le système de Sun Microsystem, Solaris, largement répandu). Il m’a semblé intéressant de comparer, lorsque celà est nécessaire, OpenSo- laris et GNU/Linux ; en effet, ce dernier est bien plus connu dans le monde universitaire que le système ouvert de Sun Microsystem.
Ainsi, le but de ce document n’est pas de remplacer la documentation fournie avec le système Solaris, mais juste de fournir des informations impor- tantes pour installer, configurer et sécuriser un système basé sur OpenSolaris, que ce soit sur un serveur ou sur une station de travail.
Pour toute remarque ou question, vous pouvez contacter l’auteur à l’adresse suivante: [email protected]
En introduction, il m’a semblé important de retracer brièvement l’histoire des systèmes UNIX ainsi que de traiter certains points théoriques de ce type de systèmes d’exploitation.
La Sécurité des Systèmes d’Information - SSI
Afin de ne pas perdre de vue les objectifs à atteindre, un petit rappel sur la SSI est nécessaire. La SSI a pour objet de garantir trois états de l’information (quelque soit la
iiiiiiiii iv Avant-propos
forme de celle-ci) : 1. la Confidentialité 2. L’Intégrité 3. la Disponibilité
À mes yeux c’est cette dernière qui doit avoir toute notre attention. En effet, si l’information (ou le système d’information) n’est plus accessible à personne, quel est l’intérêt d’assurer sa confidentialité ou son intégrité? Imaginez l’impact d’un arrêt de service pour une entreprise d’e-commerce. Bien sûr, l’idéal est de trouver un équilibre entre la disponibilité - l’utilisation au quotidien - et la sécurité. Ainsi, les configurations que je propose dans ce document peuvent entrer en contradiction avec certaines politiques de sécurité - comme le fait de dé- bloquer un compte utilisateur de manière automatique après un certain laps de temps lorsque les x tentatives de connexion sont épuisées.
Il faut aussi prendre en compte le nombre de machines à administrer. On peut se permettre l’établissement de règles nécessitant une intervention humaine sur un parc de cinq stations alors qu’elles seront difficilement appli- cables sur un parc de 5000 !
Convention typographique
Afin de simplifier la lecture de ce document, une convention typogra- phique a été mise en place :
Cette section met en évidence une propriété spécifique au système GNU/LINUX.
Cette section décrit un risque potentiel pour le système ; ou une attaque possible.
David Pauillac c novembre 2007 - OpenSolaris et la sécurité Avant-propos v
Cette section apporte une solution à un risque ou une parade à une attaque.
Présentation du document
Ce document s’articule autour de trois “tomes” ; dans le premier, le plus théorique, le système OpenSolaris sera disséqué et comparé au système GNU/ Linux. Le second s’attardera sur l’aspect serveur, incluant les services ré- seaux, l’administration des utilisateurs. . . Enfin le dernier montrera qu’Open- Solaris peut très bien convenir aux stations de travail. Pour terminer, deux annexes ont été intégrées : la première montrera com- ment faire cohabiter OpenSolaris avec d’autres systèmes tels que GNU/Linux ou MS Windows 2. La deuxième traitera des cas particuliers des ordinateurs portables.
Note à l’intention des élèves de master2 SSI
Dans l’idéal, ce qui se fait très souvent dans le monde industriel, chaque serveur ne doit servir qu’à un seul service réseau - principe de l’unicité. Cependant, dans le cadre universitaire, il me semble peu probable d’avoir 7 machines par étudiant. OpenSolaris offrant le mécanisme de zone, nous n’uti- liserons qu’une machine pour tous les services réseau étudiés dans la partie II. Nous obtenons donc le découpage suivant :
2. Le multi-boot est très fortement déconseillé mais peut parfois être indispen- sable sur une station. Un serveur, quant à lui, n’en a jamais besoin et le multi-boot doit en être banni
David Pauillac c novembre 2007 - OpenSolaris et la sécurité vi Avant-propos
Fig. 1 – Découpage des stations de TP
Remarque 1 Comme il sera vu dans ce document, il est envisageable de ne pas respecter le principe d’unicité pour une plate-forme de production 3. Bien sûr dans ce cas là, le risque d’indisponibilité des services en cas de problème matériel est extrêmement important - prévoir des serveurs redondants semble être une bonne solution - mais ceci dépasse le cadre de ce document. On donc peut imaginer un serveur unique hébergeant serveurs web et d’appli- cation (voire même bases de données) ou encore une plate-forme mail/ldap physiquement unique 4.
3. Première approche sensiblement différente par rapport aux conventions SSI 4. Á voir les associations de services possibles sans élever le risque d’indisponi- bilité de ces derniers
David Pauillac c novembre 2007 - OpenSolaris et la sécurité Table des matières
Avant-propos iii
1 Introduction 1 1.1 UNIX, une longue histoire de systèmes d’exploitation . . . . .1 1.1.1 L’avènement de MULTICS - l’Ancètre ...... 1 1.1.2 De MULTICS à UNIX ...... 1 1.1.3 Les standards d’UNIX ...... 2 1.2 La philosophie d’UNIX ...... 3 1.3 Le système OpenSolaris ...... 6
OpenSolaris - Dissection d’un système 9
I Le système OpenSolaris 11
1 Le noyau et le système 13 1.1 Un noyau ...... 13 1.1.1 L’environnement d’exécution multi-processus ...... 15 1.2 La mémoire virtuelle ...... 17 1.2.1 L’adresse virtuelle ...... 17 1.2.2 L’espace d’adressage ...... 17 1.3 Périphériques ...... 17 1.3.1 Les fichiers spéciaux ...... 17 1.4 Comparaison avec GNU/Linux ...... 18
2 Le système de fichiers 21 2.1 La gestion des disques durs et des partitions ...... 21 2.2 Fichiers et répertoires importants d’OpenSolaris ...... 22
viiviivii viii TABLE DES MATIÈRES
3 Le processus de démarrage 27 3.1 La phase d’initialisation ...... 28 3.2 Le fichier /etc/inittab ...... 28 3.3 Les scripts RC et les niveaux d’exécution ...... 29
4 Les mécanismes de sécurité d’OpenSolaris 31 4.1 Les zones ...... 32 4.1.1 Généralités ...... 32 4.1.2 La sécurité des zones ...... 32 4.1.3 Commandes utiles ...... 33 4.1.4 Création des zones ...... 34 4.1.5 Initialisation des zones ...... 35 4.1.6 Clonage de zone ...... 35 4.2 Les Privilèges ...... 35 4.2.1 Les contrôles de droits ...... 35 4.2.2 Les privilèges de Solaris ...... 36 4.2.3 La gestion des privilèges ...... 37 4.2.3.1 Les commandes importantes ...... 37 4.2.3.2 Les privilèges et leur définition ...... 37 4.3 SCF - Solaris Cryptographic Framework ...... 41 4.4 SMF - Service Management Facilities ...... 42 4.5 RBAC - Role Based Access Control ...... 42 4.5.1 Fichiers de configuration ...... 43 4.6 Trusted Extensions ...... 43 4.6.1 MAC et Labels ...... 44 4.6.2 Trusted Networking - CIPSO ...... 44 4.6.3 Trusted GUI ...... 44
5 Performances et diagnostique 45 5.1 Contrôler les processus ...... 45 5.2 Monitorer les processus ...... 46 5.3 Tracer le système - dtrace ...... 48 5.4 Tracer l’activité du noyau ...... 49
II Installer OpenSolaris 51
1 L’installation d’OpenSolaris 53 1.1 Le programme d’installation ...... 53 1.2 Mise en place du réseau ...... 63 1.2.1 Configurer les interfaces réseau ...... 63
David Pauillac c novembre 2007 - OpenSolaris et la sécurité TABLE DES MATIÈRES ix
1.2.2 Routes et routeur ...... 63 1.3 État du système après l’installation ...... 67 1.4 Suppression des packages inutiles ...... 68
OpenSolaris d’un point de vue serveur 69
I Configurer et sécuriser OpenSolaris 71
1 La gestion des utilisateurs 73 1.1 La gestion des mots de passe ...... 73 1.1.1 Les utilisateurs ...... 73 1.1.2 Les groupes ...... 78 1.1.3 Les rôles ...... 78 1.2 Le système d’authentification ...... 79 1.2.1 Le module PAM ...... 79 1.2.1.1 Mode de fonctionnement ...... 79 1.2.1.2 Hiérarchisation des taches d’authentification . 80 1.2.1.3 Conclusion ...... 82
2 Le contrôle des accès 83 2.1 Suppression des exécutables SUID/SGID ...... 83 2.2 Politique générale sur les fichiers ...... 83 2.3 Suppression des commandes distantes ...... 84
3 Le système 85 3.1 Personnaliser la pile IP ...... 85 3.2 Configurer le pare-feu ...... 86 3.3 Modifier le niveau général de sécurité ...... 87 3.3.1 Renforcer les mots de passe ...... 87 3.3.2 Blocage et suppression des comptes inutiles ...... 91 3.4 Protections diverses ...... 92 3.5 Test de scan ...... 92
II Les services réseau 97
1 Serveur de nom 99 1.1 Généralités ...... 99 1.1.1 Protocole utilisé ...... 101 1.1.2 Application ...... 101
David Pauillac c novembre 2007 - OpenSolaris et la sécurité x TABLE DES MATIÈRES
1.2 Installation ...... 102 1.2.1 Création de la zone dédiée ...... 102 1.2.2 Installation du package BIND et de ses dépendances . . 104 1.2.3 chrooter BIND ...... 104 1.3 Paramétrage et sécurisation ...... 108 1.3.1 Configurer le serveur DNS ...... 108 1.3.2 Sécuriser BIND ...... 109 1.3.3 Exécuter BIND ...... 111
2 Serveur de messagerie 113 2.1 Généralités ...... 113 2.1.1 Protocoles utilisés ...... 113 2.1.2 Application ...... 114 2.2 Installation ...... 114 2.3 Paramétrage et sécurisation ...... 114 2.3.1 Fonctionnement de l’implémentation de TLS dans Postfix115 2.3.2 Configuration de TLS pour Postfix ...... 115
3 Serveur web et application J2EE 117 3.1 Le serveur web ...... 119 3.1.1 Généralités ...... 119 3.1.2 Installation ...... 119 3.1.3 Paramétrage et sécurisation ...... 120 3.2 Le serveur d’application ...... 132 3.2.1 Généralités ...... 132 3.2.2 Installation ...... 132 3.2.3 Paramétrage et sécurisation ...... 133
4 Annuaire LDAP 135 4.1 Généralités ...... 135 4.1.1 Protocole utilisé ...... 135 4.1.2 Application ...... 136 4.2 Installation ...... 137 4.2.1 Création de la zone dédiée ...... 137 4.2.2 Chrooter OpenLDAP ...... 139 4.3 Paramétrage et sécurisation ...... 139 4.3.1 Sécuriser la partie réseau ...... 139 4.3.1.1 Restriction d’accès via le couple adresse/port 139 4.3.1.2 TCP-Wrappers ...... 139 4.3.2 Intégrité et confidentialié ...... 140 4.3.2.1 Security Strength Factors - SSF ...... 140
David Pauillac c novembre 2007 - OpenSolaris et la sécurité TABLE DES MATIÈRES xi
4.3.3 Méthodes d’authentification ...... 141
5 Serveur de fichiers 143 5.1 Généralités ...... 143 5.1.1 Protocole utilisé ...... 143 5.1.2 Application ...... 146 5.2 Installation ...... 147 5.3 Paramétrage et sécurisation ...... 147
OpenSolaris pour une station de travail 149
I Déployer OpenSolaris 151
1 Configurer 153
2 Déployer 155
II La labellisation 157
1 Les principes 159
2 La mise en place 161
3 L’administration 163
Annexes 167
A Exemple de script ndd 167
B Liste des packages 179
C GNU Free Documentation License 221
Références 231
Bibliographie 231
Table des figures 234
David Pauillac c novembre 2007 - OpenSolaris et la sécurité xii TABLE DES MATIÈRES
Liste des tableaux 235
David Pauillac c novembre 2007 - OpenSolaris et la sécurité Chapitre Premier Introduction
1.1 UNIX, une longue histoire de systèmes d’ex- ploitation
1.1.1 L’avènement de MULTICS - l’Ancètre Le concept déclencheur est sans aucun doute le système CTSS (Compa- tible Time Sharing System), dévoilé en 1961 par Fernando Corbato et Robert Fano du MIT et avec le concours des laboratoires BELL. Ce système sera même utilisé en production (au MIT seulement) de 63 à 73. Ce concept, repris et amélioré entre 1962 et 1964 par John Kemeny et Tom Kurtz du Dartmouth College avec le DTSS (Dartmouth Time Sharing System), per- met à 32 personnes de se connecter simultanément sur une même machine. En 1964, date fondatrice selon certains, le MIT et les laboratoires Bell d’AT&T s’associent pour démarrer un projet baptisé MULTICS (MULTi- plexed Information and Computing Service), combinant ordinateur et sys- tème d’exploitation, ayant pour cahier des charges : – de pouvoir être utilisé par plusieurs personnes à la fois : il doit donc s’agir d’un système d’exploitation « à temps partagé 1 » – de pouvoir en plus exécuter des calculs en tâche de fond 2.
1.1.2 De MULTICS à UNIX En 1969, les développement s’éternissant, les laboratoires Bell abandonnent le projet. Cependant, deux de leurs informaticiens, Ken Thompson et Dennis Ritchie, poursuivent sans l’appui de leur hiérarchie des travaux autour d’une sorte de MULTICS simplifié, baptisé UNICS (UNiplexed Information and Computing Services). UNICS reprend les principes introduits par son prédécesseur (les notions de processus, d’arborescence de fichiers, d’interpréteur de lignes de com- 1. tout comme CTSS et DTSS 2. ce qui ressemble étrangement au multithreading. . .
111 2 Introduction mandes en tant qu’application parmi d’autres, etc.) et y ajoute une approche résolument modulaire ainsi qu’une forme simple de communication entre ap- plications (les données en sortie de l’une peuvent être récupérées en entrée par une autre). Rapidement, après avoir été rebaptisé UNIX par Brian Ker- nighan, le système assorti de quelques utilitaires est développé dans une version stable (Unix Time-Sharing System Version 1) autour d’une machine DEC (Digital Equipment Corporation) appelée PDP 7. Un véritable langage de programmation "haut niveau" manque pourtant à UNIX (qui ne dispose pour l’instant que d’un assembleur). Ken Thompson travaille à combler cette lacune à partir de 1970 et crée finalement un langage de toutes pièces, appelée langage B, cette même année 1970. Avec ses premiers succès, grâce à son portage sur PDP 11/20, basé sur des processeurs 16 bits, UNIX convainct Bell. Ce dernier permet aux déve- loppements de se poursuivre, qui aboutiront en 1971 au Unix Time-Sharing System Version 2. Suivra ensuite le langage C, adaptation du langage B (par Thompson et Ritchie), doté d’un compilateur efficace et d’une certaine souplesse lui permettant de gérer facilement le matériel, tout en pouvant être transposé relativement aisément sur d’autres machines. Dès la fin de l’année 1977, des chercheurs de l’Université de Californie apportèrent de nombreuses améliorations au système UNIX fourni par AT&T et le distribuèrent sous le nom de Berkeley Software Distribution (ou BSD). Ainsi BSD fut par exemple le premier système UNIX à exploiter pleinement le mécanisme de mémoire virtuelle paginée du VAX 11/780. Trois branches de développement des sources virent le jour : – La branche de recherche d’AT&T qui développa, toujours aux labora- toires Bell, jusqu’en 1990, les 8ème, 9ème et 10ème éditions du système UNIX – La branche commerciale d’AT&T qui développa System III, puis quatre éditions de System V (System V, SVR2, SVR3, SVR4) – Berkeley Software Distribution développé par l’Université de Californie, jusqu’en 1994.
1.1.3 Les standards d’UNIX
Le grand nombre de systèmes UNIX développés sur la base du System V de AT&T ou bien de BSD conduisit des membres du groupe d’utilisateurs /usr/group, qui a pris depuis le nom de UniForum, à forger un standard UNIX dès 1981 afin d’assurer une portabilité maximale entre les différents
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 1.2 La philosophie d’UNIX 3 systèmes : – en 1984 le groupe /usr/group publie POSIX, une série de standards dé- veloppés sous couvert de l’IEEE (Institute of Electrical and Electronics Engineers). POSIX est ainsi également connu sous le nom IEEE P1003 – en 1985, AT&T publie SVID (System V Interface Definition) décrivant le System V. Cette première définition est différente de POSIX – à la même époque, un consortium de constructeurs (Sun, IBM, HP, DEC, AT&T, Unisys, ICL, etc.) publie le standard X/Open Portability Guide Issue 3 (XPG3). Ce standard s’occupe tout particulièrement des différences issues de la localisation géographique (date, alphabet, etc.).
1.2 La philosophie d’UNIX
Le noyau d’UNIX repose sur quatre concepts élémentaires : les fichiers, les processus, les IPC (communications inter-processus), et les droits d’accès.
Les fichiers Sous UNIX, on entend souvent dire que tout est fichier. En effet même le matériel est géré via des fichiers spéciaux (souvent dans /dev/). Le fichier est la brique élémentaire d’UNIX. UNIX ne type pas ses fichiers, ainsi un fichier peut représenter toute res- source possible et vérifier ainsi la première affirmation.
Définition 1 Un fichier est une entité référencée dans un système de fi- chiers. Cette référence contient toutes les informations nécessaires au trai- tement de ce fichier : propriétaire, groupe, droits d’accès, taille, date de der- nière modification, date du dernier accès, références des blocs de données sur le disque s’il représente une suite de caractères etc.
Les processus Un processus est une instance d’exécution d’un programme. Un processus sous UNIX consiste en un espace adressable et un ensemble de structures de données dans le noyau. L’espace adressable est une section de la mémoire contenant le code à exécuter, comme la pile de processus.
Le noyau doit avoir pour chaque processus du système les informations suivantes : – la carte des espaces adressables
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 4 Introduction
– le status courant du processus – la priorité d’exécution du processus – les ressources du processus – le masque courant du signal – le propriétaire du processus.
Un processus possède un certain nombre d’attributs qui affectent son exécution : – PID - c’est le nombre unique qui définit le processus dans le noyau – PPID - c’est le PID du processus parent, le créateur du processus – UID - c’est le nombre d’identification de l’utilisateur propriétaire du processus – EUID - c’est l’ID effectif de l’utilisateur du processus – GID - c’est l’ID du groupe utilisateur du propriétaire – EGID - c’est l’ID effectif du groupe utilisateur – priority - c’est la priorité avec laquelle le processus s’exécute
Les IPC Il existe trois mécanismes définis par les IPC 3, ayant en commun : – une table de taille fixe est affectée – toute entrée de cette table est associée à une clef numérique choisie par l’utilisateur et servant d’Id global – un appel système “. . . get” permet de créer une nouvelle entrée ou d’ac- céder à une déjà existante. Une référence utilisable par d’autres appels système est retournée. – un appel système “. . . ctl” permet d’interroger, de modifier ou de sup- primer une entrée – des droits d’accès sont associés à chaque entrée – la référence d’une entrée supprimée ne peut être réutilisée sans provo- quer une erreur (hormis après un cycle complet).
Ces mécanismes sont les suivants : – les objets de synchronisation - sémaphores et mutex - permettant l’uti- lisation de ressources partagées entre plusieurs processus – les signaux offrant à un processus ou au noyau de contrôler un processus
3. Apparus avec le System V
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 1.2 La philosophie d’UNIX 5
– les systèmes de communications locaux - pipes, segments de mémoire partagée ou les files d’attente - ou distants - sockets.
Signal Id Description SIGHUP 01 hangup SIGINT 02 interrupt SIGQUIT 03 quit SIGILL 04 illegal instruction (not reset when caught) SIGTRAP 05 trace trap (not reset when caught) SIGABRT 06 abort SIGEMT 07 EMT instruction SIGFPE 08 floating point exception SIGKILL 09 kill (cannot be caught or ignored) SIGBUS 10 bus error SIGSEGV 11 segmentation violation SIGSYS 12 bad argument to system call SIGPIPE 13 write on a pipe with no one to read it SIGALRM 14 alarm clock SIGTERM 15 software termination signal SIGUSR1 16 user-defined signal 1 SIGUSR2 17 user-defined signal 2 SIGCLD 18 death of a child SIGPWR 19 power fail (not reset when caught) SIGSTOP 20 stop (cannot be caught or ignored) SIGTSTP 21 stop signal generated from keyboard SIGPOLL 22 selectable event pending SIGIO 23 input/output possible SIGURG 24 urgent condition on IO channel SIGWINCH 25 window sizechanges SIGVTALRM 26 virtual time alarm SIGPROF 27 profiling alarm SIGCONT 28 continue after stop (cannot be ignored) SIGTTIN 29 background read from control terminal SIGTTOU 30 background write to control terminal SIGXCPU 31 cpu time limit exceeded SIGXFSZ 32 file size limit exceeded
Tab. 1.1 – Liste des signaux des processus sous UNIX
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 6 Introduction
Les droits d’accès Il est inutile de s’attarder sur les droits d’accès dans cette section, ils seront abordés de manière détaillée dans le chapitre 2 page 83
1.3 Le système OpenSolaris
Le projet OpenSolaris est une communauté OpenSource et un site de col- laboration et de conversation autour des technologies OpenSolaris.
En 2005, Sun Microsystems a libéré le code source de son système d’ex- ploitation, Solaris 10, donnant naissance à OpenSolaris. Il est important de noter qu’OpenSolaris n’est pas à proprement parlé un système indépendant. En fait on pourrait faire une similitude avec Linux : Linux n’est pas un système, c’est un noyau qui est la base des distributions GNU/Linux ; OpenSolaris est la base des distributions telles que celle de Sun, Solaris Express ou encore BeleniX.
Remarque 2 La distribution Solaris Express présente l’avantage d’intégrer les fonctionnalités des versions futures de Solaris. C’est donc une excellente plate-forme pour découvrir Solaris mais à déconseiller pour une mise en pro- duction sur un serveur.
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 1.3 Le système OpenSolaris 7
Fig. 1.1 – Arbre généalogique simplifié des systèmes UNIX David Pauillac c novembre 2007 - OpenSolaris et la sécurité 8 Introduction
David Pauillac c novembre 2007 - OpenSolaris et la sécurité TOME I
OPENSOLARIS - DISSECTION D’UN SYSTÈME
999 10
David Pauillac c novembre 2007 - OpenSolaris et la sécurité Première partie
Le système OpenSolaris
111111
Chapitre Premier Le noyau et le système
1.1 Un noyau
Un système moderne a un mode de fonctionnement en étages : 1. le niveau utilisateur (user level). C’est l’étage de fonctionnement pos- sédant le moins de droits ; 2. le niveau noayu (kernel level). C’est à cet étage que le système d’ex- ploitation passe ses requêtes au troisième niveau ; 3. le niveau matériel (hardware level).
Le noyau est un programme qui gère toutes les ressources du système.
Ce principe de fonctionnement permet un contrôle pratiquement total du noyau sur l’ensemble des programmes du système (cf. figure 1.1).
131313 14 Le noyau et le système
Fig. 1.1 – Les étages de fonctionnement d’un système moderne
Le noyau est composé de modules chargés dynamiquement en mémoire lorsqu’ils sont soliicités. Il est l’interface entre les applications et le système physique. Il fournit aux applications les services systèmes essentiels tels que la gestion des entrées/sorties, la mémoire virtuelle et la gestion des processus. La figure 1.2 1 illustre le noyau Solaris avec ses modules gérant les appels systèmes des applications et les modules d’entrées/sorties de communication avec le matériel (voir aussi [19]). Le noyau fournit des accés aux pilotes de périphériques depuis : – une carte périphérique/pilotes : le noyau maintient un arbre de péri- phériques dans lequel chaque noeud représente un périphérique virtuel ou physique. Le noyau relie chaque noeud à un pilote en comparant le nom du noeud du périphérique avec l’ensemble des pilotes installés sur le système. Le périphérique devient accessible aux applications seule- ment s’il existe la relation avec un pilote.
– les interfaces Device Driver Interface Driver Kernel 2 : Ces interfaces
1. Copyright 2005 Richard McDouglas & James Mauro, Sun microsystems - Usenix’05 2. DDI/DDK
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 1.1 Un noyau 15
Fig. 1.2 – Vue globale du noyau Solaris
sont des standards des interactions entre les pilotes et le noyau, les périphériques physiques et le programme de démarrage/configuration. Leur utilisation permet de rendre le pilote indépendant du noyau et le rendre ainsi portable sur des versions successives du système d’exploi- tation sur un système physique particulier.
1.1.1 L’environnement d’exécution multi-processus Définition 2 Un thread est une subdivision d’un processus. Ainsi, les dif- férents threads d’un processus partagent l’espace adressable et les ressources d’un processus. De même, lorsqu’un thread modifie une variable (non locale), tous les autres threads voient la modification ; un fichier ouvert par un thread est accessible aux autres threads (du même processus).
Le noyau Solaris gère les multi-threads. En fait tous les noyaux UNIX sont ce qu’on appelle “multithreadés”, c’est à dire qu’ils peuvent gérer plusieurs processus simultanément. Á noter que cette fonctionnalité est présente de- puis l’origine d’UNIX et que les systèmes à base de RISC exploite pleinement
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 16 Le noyau et le système
cette caractéristique depuis longtemps et donc permet de créer des systèmes massivement parallèles (qu’ils soient au niveau du nombre de processeurs, de coeurs ou encore de machines).
Sur des systèmes multi-processeurs (ou multi-coeurs), les multiples pro- cessus noyau peuvent s’exécuter simultanément sur les différents proces- seurs/coeurs. Le multithreading impose cependant des restrictions additionnelles sur les pilotes des périphériques. Le pilote doit être conçu de sorte qu’il puisse ré- pondre à différents processus simultanés.
Afin qu’un thread du niveau utilisateur puisse exploiter certaines res- sources, il peut faire appel à un thread au niveau noyau par le biais d’un processus léger.
Définition 3 Un processus léger, LightWeight Process (LWP), est l’inter- face entre un thread du niveau utilisateur et un autre du niveau noyau.
Fig. 1.3 – Fonctionnement d’un processus léger
Il y a un thread noyau pour chaque LWP, chaque LWP est lié à son propre thread noyau. Chaque processus doit contenir au moins un LWP.
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 1.2 La mémoire virtuelle 17
1.2 La mémoire virtuelle
Le présent document ne saurait traiter dans son intégralité le système de mémoire virtuelle de Solaris ; cependant, deux notions importantes sont à connaître, en particulier lorsqu’on parle de pilotes de périphériques : l’adresse virtuelle et l’espace d’adressage.
1.2.1 L’adresse virtuelle C’est une adresse reliée par l’unité de gestion de la mémoire - Memory Management Unit (MMU) - à une adresse physique du matériel. Toutes les adresses accessibles directement par le pilote sont en fait des adresses vir- tuelles du noyau ; elles font référence à des esapces virtuels du noyau.
1.2.2 L’espace d’adressage Un espace d’adressage est un ensemble de segments d’adresses virtuelles, dont chacun est un intervalle continu d’adresses virtuelles. Chaque proces- sus utilisateur possède un espace d’adresses appelé espace d’adresses utilisa- teur - user address space. Le noyau a son propre espace d’adresses : l’espace d’adresses noyau - kernel address space .
1.3 Périphériques
1.3.1 Les fichiers spéciaux Les périphériques sont traités comme des fichiers 3. Ils sont représentés dans le système de fichiers par des fichiers spéciaux. Dans le système Solaris, ces fichiers se situent dans le répertoire /devices.
Les fichiers spéciaux peuvent être soit de type block soit de type caractère. Le type indique quel sorte de périphériques le pilote doit gérer. Les pilotes peuvent être conçus pour gérer les deux types. Par exemple, les pilotes de disques utilisent l’interface caractère lors de l’utilisation des utilitaires fsck(1) et mkfs(1). Pour le système de fichiers, ces mêmes pilotes implémentent l’in- terface block. Á chaque fichier spécial est associé un numéro de périphérique (dev_t). Celui consiste en un nombre majeur et un nombre mineur. Le nombre majeur identifie le pilote de périphérique associé au fichier spécial, le mineur quant
3. Comme tout sous UNIX, voir section 1.2 page 3
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 18 Le noyau et le système
à lui est créé et utilisé par le pilote pour identifier le fichier spécial. En règle générale, le nombre mineur est un encodage identifiant une instance du pilote. Il peut servir, par exemple, à identifier un périphérique de bande utilisé pour les sauvegardes et ensuite spécifier quel lecteur de bande devra être retourné quand l’opération de suavegarde sera terminée.
1.4 Comparaison avec GNU/Linux
Description GNU/Linux Solaris Localisation des modules /boot /lib/modules /platform/sparc/kernel /kernel /usr/kernel Déterminer le runlevel courant runlevel who -r Changer de runlevel telinit "runlevel_id" halt, init, poweroff, re- boot, shutdown teli- nit, uadmin (en fonc- tion de ce que l’on veut faire) Localisation des scripts/liens /etc/rc.d/ /sbin/rc"runlevel" de démarrage par runlevel rc"runlevel".d Afficher les infos de boot lilo N/A(grub) Rebooter la machine shutdown -r now shutdown -i 6 Arréter la machine halt poweroff ou halt Affichage du status de la mé- cat /proc/meminfo N/A moire virtuelle Statistiques de la mémoire vir- vmstat vmstat tuelle Affichage de la mémoire phy- cat /proc/meminfo prtconf sique Statistiques d’entrées/ sorties iostat ìostat Rapport d’activité du système sar sar État des verrous du système /var/lock N/A Rapport d’état CPU top prstat Affichage des erreurs système dmesg dmesg Affichage des informations de swapon -s swap -l swap
Tab. 1.1 – Informations sur le Boot, sur le noyau
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 1.4 Comparaison avec GNU/Linux 19
Description GNU/Linux Solaris Configurer un périphérique MAKEDEV drvconfig, dev- links, disks, tapes, ports Créer un périphérique mknod drvconfig, dev- links, disks, tapes, ports Supprimer un périphérique MAKEDEV rem_drv Modifier un périphérique N/A N/A Lister les périphériques cat sysdef /proc/devices Répertoire des périphériques sys- /dev /devices tème
Tab. 1.2 – Configuration des périphériques
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 20 Le noyau et le système
David Pauillac c novembre 2007 - OpenSolaris et la sécurité Chapitre 2 Le système de fichiers
2.1 La gestion des disques durs et des parti- tions
La notation des disques durs et partitions sous Solaris diffèrent de celles de GNU/Linux. Sous Solaris, les partitions physiques sont notées /dev/rdsk/c0t0d0s0 où : – c0 est le numéro du contrôleur – t0 est le numéro du bus – d0 est le numéro du disque – s0 est le numéro de la partition.
Un disque peut ainsi contenir jusqu’à sept partitions (s0, s1, s3, s4, s5, s6 et s7). La partition s2 représente tout le disque. On utilise, en règle générale, la partition s0 pour la racine (/ ) et la parition s1 pour le swap.
GNU/Linux note les partitions physiques /dev/hda1, /dev/hdb2, /dev/sda3, etc. où : – a,b,c,. . . représentent le numéro de disque (a est le premier disque sur le premier contrôleur, etc.) – 1,2,3,. . . est le numéro de la partition – les lettres "h" et "s" sont utilisées respectivement dans le cas d’un disque dur/CDROM IDE et SCSI/SATA.
.
212121 22 Le système de fichiers
Action GNU/Linux Solaris | Formatter un disque fdisk format Vérifier un FS fsck fsck Monter un FS mount mount Démonter un FS umount umount Afficher l’espace disponible d’un df df FS Partitionner un disk fdisk format Lister la table des partitions fdisk prtvtoc Ajouter un FS mkfs mkfs Sauvegarde d’un FS /fichier /ré- dump ufsdump pertoire Restauration d’un FS /fichier /ré- restore ufsrestore pertoire Modification d’un FS resize2ext tunefs Afficher les informations d’un FS cat /etc/fstab cat /etc/vfstab Affiche la table des FS montés mount ou cat mount ou cat /etc/mtab /etc/mtab
Tab. 2.1 – Commandes de gestion d’un système de fichiers
2.2 Fichiers et répertoires importants d’Open- Solaris
/boot
Répertoire contenant tous les fichiers nécessaires au démarrage du système d’exploitation.
/bin
Répertoire regroupant toutes les commandes majeures, ou encore com- mandes systèmes telles que ls ou who. Les commandes placées ici sont celles le plus souvent utilisés 1.
1. aujourd’hui il n’y a pas grand sens à regroupêr ces commandes ; cependant, lorsqu’UNIX étant encore un jeune système, la puissance des ordinateurs était telle que les développeurs devaient trouver des astuces pour réduire les temps d’exécu- tion.
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 2.2 Fichiers et répertoires importants d’OpenSolaris 23
/dev Contient les fichiers spéciaux permettant la gestion des périphériques. Ils permettent aux programmes de communiquer avec les ressources maté- rielles 2.
/etc Répertoire des fichiers de configuration, aussi bien pour le système que pour les autres programmes. Á noter le répertoire /etc/rc.d contrôlant le démarrage du système.
/etc/rc.d /export/home Répertoire personnel des utilisateurs.
Sous GNU/Linux, ce répertoire est localisé sous /home.
/lib Contient les bibliothèques partagées.
/opt Répertoire des programmes complémentaires. Tous les paquetages com- plémentaires d’OpenSolaris seront installés dans ce répertoire.
Les distributions récentes de GNU/Linux n’utilisent que rarement ce répertoire.
/proc C’est en fait un pseudo-système de fichiers. Les fichiers contenus dans ce répertoire ne sont en fait que des constructions logiques, pointant vers des programmes en mémoire vive.
2. voir page 17
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 24 Le système de fichiers
/sbin Emplacement des commandes d’administration telles que ifconfig, fsck, etc.
/tmp Fichiers temporaires.
/var Contient les données variables comme, entre autre, les journaux systèmes (log). Sur un serveur, il est très important de dédié une (ou plusieurs) par- tition à ce système de fichiers et de bien le dimensionner : si le système, ou certains services comme un serveur web, ne peuvent plus écrire de journal, le système, ou le service, risque de s’arrêter.
/usr Répertoire très important, contient des données sensibles.
/usr/X11R6 Répertoire racine de toutes les données d’X Window (gestionnaire gra- phique d’UNIX)
/usr/bin Utilitaires, comme /bin
/usr/games Le nom est suffisemment explicite ;)
/usr/include Répertoire des fichiers en-tête (headers) pour la programmation
/usr/lib Bibliothèques
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 2.2 Fichiers et répertoires importants d’OpenSolaris 25
/usr/local Fichiers et commandes spécifiques à l’ordinateur, souvent utilisé pour l’installation de logiciels
/usr/sbin Commandes systèmes
GNU/Linux Description /root répertoire personnel de l’administrateur, équi- valent de /home pour root. /usr/src sources du noyau du système d’exploitation et d’autres paquetages
Tab. 2.2 – Systèmes de fichiers spécifiques de GNU/Linux
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 26 Le système de fichiers
David Pauillac c novembre 2007 - OpenSolaris et la sécurité Chapitre 3 Le processus de démarrage
La compréhension du processus de démarrage est important afin de ré- soudre des problèmes dès intervenant dès l’initialisation du système.
Le processus de démarrage de Solaris se décompose en différentes phases, faciles à appréhender. La première commence dès le démarrage de la machine. Indépendante du sys- tème d’exploitation, elle initialise tous les périphériques, vérifie la mémoire et permet de choisir sur lequel démarrer (disque dur, CD/DVD, périphériques USB), elle est lancée par le système de base de la machine (BIOS sur les ar- chitectures Intel ou assimilées). Cette première étape est suivie par les tests des différents systèmes de la machine. Ce processus exécute ensuite sur le périphérique de démarrage par défaut (disque dur) le programme de démarrage depuis le block de démarrage (boot block) situé sur les blocks 1-15. Ce block contient le lecteur du système de fichier ufs, requis par le processus de démarrage suivant.
Le lecteur du système de fichier ufs "ouvre" le périphérique de démarrage (boot device) et charge le deuxième programme de démarrage depuis /usr/platform/‘uname -i‘/ufsboot (la commande uname -i retourne le type d’architecture du système)
Le programme de démarrage charge alors le noyau spécifique à la plate- forme avec le noyau généric Solaris.
Le noyau s’initialise lui-même et charge les modules requis pour monter la partition racine (root) et pour continuer le processus de démarrage.
Le processus de démarrage passe ensuite par les phases suivantes : 1. La phase d’initialisation 2. Le fichier inittab 3. les scripts rc et les niveaux d’exécution
272727 28 Le processus de démarrage
4. les étapes suivantes
3.1 La phase d’initialisation
Elle commence par l’exécution du programme /sbin/init et le démarrage des autres processus après la lecture des directives contenues dans le fichier /etc/inittab.
Les deux fonctions les plus importantes d’init sont : 1. l’éxécution des processus pour démarrer le système au niveau d’exécu- tion par défaut (niveau d’exécution 3 dans Solaris, défini par le para- mètre initdefault dans le fichier /etc/inittab) 2. le contrôle de la transition entre différents niveaux d’exécution en exé- cutant les scripts rc adéquats pour démarrer et arrêter les processus pour ce niveau d’exécution.
3.2 Le fichier /etc/inittab
Ce fichier fournit le niveau d’exécution par défaut ainsi que les actions à réaliser lorsque le système passe à ce niveau. Les champs et leurs explications sont les suivants : S3:3:wait:/sbin/rc3 > /dev/console 2>&1 < /dev/console S3 est l’identification de la ligne 3 est le niveau d’exécution wait est l’action à exécuter /sbin/rc3 est la commande à exécuter La ligne complète signifie donc exécuter la commande /sbin/rc3 au niveau d’exécution 3 et attendre jusqu’à la fin du processus rc3.
D’une manière plus générique, les champs du fichiers inittab sont les sui- vants : Identification:niveau d’exécution:action:processus Le champ action peut prendre les valeurs suivantes : – Initdefault : niveau d’exécution par défaut du système – Respawn : démarrer et redémarrer le processus s’il est arrêté – Powerfail : stoppe en cas de problème d’alimentation – Sysinit : démarre et attend jusqu’à ce que la console soit accessible – Wait : attend jusqu’à ce que le processus soit terminé avant d’aller à la ligne suivante.
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 3.3 Les scripts RC et les niveaux d’exécution 29
3.3 Les scripts RC et les niveaux d’exécution
Les scripts RC remplissent les fonctions suivantes : 1. vérification et montage des systèmes de fichiers 2. démarrage et arrêt des différents processus tels que le réseau, NFS, etc. 3. exécution de travaux personnalisés.
Le système peut aller dans un des niveaux d’exécution suivants après avoir démarré dans le niveau par défaut, et exécuter les commandes nécessaires au changement de niveau :
0 Niveau de démarrage "prom" ou prompt sur les machines Sun 1 Niveau d’exécution d’administration. Mode simple utilisateur 2 Mode multiutilisateur sans ressource partagée 3 Mode multiutilisateur avec ressources partagées NFS 4 Non utilisé 5 Arrêt (système et machine) 6 Redémarrage dans le niveau par défaut S s Mode simple utilisateur ; les comptes utilisateurs sont désactivés
Tab. 3.1 – Les niveaux d’exécution de Solaris
Généralement, le système en cours d’exécution peut être dans un de ces états : – Simple utilisateur - exécution minimal des processus, comptes utilisa- teurs désactivé, le mot de passe root est nécessaire pour accéder au terminal
– Multiutilisateur - Tous les processus systèmes sont exécutés et les comptes utilisateurs sont activés.
Chaque ligne du fichier, c’est-à-dire chaque niveau d’exécution, se ter- mine par le numéro des scripts à exécuter par le programme rc. Les scripts rc sont dans les répertoires /etc/rc0.d, /etc/rc1.d, /etc/rc2.d, /etc/rc3.d et /etc/rcS.d. Tous les fichiers de chaque niveau d’exécution sont exécutés dans l’ordre alphanumérique. Les fichiers commençant par la lettre S démarrent les processus alors que ceux commençant par K les arrêtent.
Ces fichiers sont en fait des liens vers les fichiers situés dans /etc/init.d. Cette organisation permet d’avoir tous les scripts dans un répertoire central et de sélectionner seulement ceux nécessaires lors d’un changement vers un
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 30 Le processus de démarrage
niveau d’exécution donné. Ainsi, ces scripts peuvent être exécutés séparé- ment. Les fichiers du répertoire /etc/init.d sont sans les préfixes S ou K.
Par défaut, il y a un certain nombre de scripts rc nécessaires à la transi- tion de niveau d’exécurion mais parfois, il est nécessaire de lancer un script personnalisé au démarrage et à l’arrêt du système. Ces scripts personnali- sés peuvent être placés dans le répertoire rc ad hoc. Cependant, plusieurs élements doivent être pris en consdération dans ce cas là :
– Le numéro de séquence de ce fichier ne doit pas entrer en conflit avec les autres fichiers – Les ressources nécessaires doivent être libérées par les scripts exécutés précédemment – Le fichiers doit être un lien vers le répertoire /etc/init.d – Le système recherche uniquement les fichiers commençant par les lettres S et K, tous les autres sont ignorés 1.
1. Par conséquent, pour désactiver un fichier il suffit de mettre la lettre majuscule S ou K en minuscule
David Pauillac c novembre 2007 - OpenSolaris et la sécurité Chapitre 4 Les mécanismes de sécurité d’OpenSolaris
La sécurité sous Solaris repose sur plusieurs mécanismes détaillés par la figure 4.1.
Ce chapitre abordera ces mécanismes d’un point de vue théorique et de manière succinte. La plupart seront abordés soit dans le tome I soit dans le II.
Fig. 4.1 – Les mécanismes de sécurité de Solaris
313131 32 Les mécanismes de sécurité d’OpenSolaris
Remarque 3 OpenSolaris intègre les fonctionnalités de Trusted Extensions qui seront supportées par Solaris 11.
4.1 Les zones
4.1.1 Généralités Le principe des zones a pour origine le constat suivant : Le compte root n’est pas fiable.
Définition 4 Une zone est une instance système partageant le noyau avec d’autres instances. De ce fait, chaque zone dispose de : – sa propre configuration système et réseau – ses propres applications – son propre comportement La seule différence avec le système initial (la zone globale) réside dans le contrôle absolu de l’instance maître. Un utilisateur externe au système ne peut différencier une zone d’un système physique.
Les zones sont hiérarchisées (comme le montre la figure 4.2) : – la zone globale est l’instance maître et contrôle les autres zones – les zones subsidiaires que l’on appelera "zone" à partir de maintenant.
4.1.2 La sécurité des zones Toutes les zones sont contrôlées la zone globale. De ce fait, elles ne dis- posent pas : – d’un accès direct aux périphériques physiques – de la visibilité sur la zone globale ou sur toute autre zone – de la visibilité sur une resource non expressément accordée par la zone globale – de la totalité des privilèges – de la possibilité de se reconfigurer au niveau système/devices.
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 4.1 Les zones 33
Fig. 4.2 – Les zones dans OpenSolaris
L’administrateur (root) d’une zone ne peut agir que dans celle-ci. Il n’a aucun accès, lecture ou écriture, sur les autres zones (y compris la globale bien sûr).
Concernant l’étanchéité des zones (le point faible de chroot), elle est assu- rée par la communication des zones entre elles. Elles ne peuvent communiquer que par le réseau (la pile IP est partagée et contrôlée par l’instance maître. Ainsi les zones ne peuvent pas partager ou communiquer par les processus. Seule la zone globale a une visibilité totale du système et de toutes les zones, dans la limite des droits et privilèges du processus courant.
4.1.3 Commandes utiles Il existe des commandes pour gérer totalement les zones (cf. figure 4.3).
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 34 Les mécanismes de sécurité d’OpenSolaris
Fig. 4.3 – Les différents états d’une zone
4.1.4 Création des zones
La commande principale est zonecfg. Les pages de manuel sont une très bonne source pour se familiariser avec cette commande.
La procédure suivante décrit les étapes pour créer une zone ma-zone. On part du principe qu’une application doit écrire dans les répertoires systèmes, /lib, /platform, /sbin et /usr.
global# mkdir /rep/myInstallDir // création du répertoire // d’export de la zone global# mkdir /usr/myInstallDir // création du point de montage global# zonecfg -z ma-zone zonecfg:ma-zone> add fs zonecfg:ma-zone:fs> set dir=/usr/myInstallDir zonecfg:ma-zone:fs> set special=/rep/myInstallDir zonecfg:ma-zone:fs> set type=lofs zonecfg:ma-zone:fs> set options=[rw,nodevices] zonecfg:ma-zone:fs> end
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 4.2 Les Privilèges 35
inherit-pkg-dir : Répertoires système loop-back à monter dans la zone fs : Systèmes de fichiers exposés de la zone globale aux zones non glo- bales device : Device à installer dans la zone net : Interfaces réseau de la zone rctl : Voir la man page de prctl pool : Nom de la ressource pool
Tab. 4.1 – Ressources paramétrables d’une zone non globale
4.1.5 Initialisation des zones La commande principale est zoneadm. Les pages de manuel sont une très bonne source pour se familiariser avec cette commande.
4.1.6 Clonage de zone Il est possible de déplacer une zone dans un nouveau répertoire : # zoneadm -z ma-zone move /newpath Il peut être aussi pratique de pouvoir cloner des zones. Ceci se fait avec la commande : # zoneadm -z nouvelle-zone clone [-m méthode] méthode_paramètres
4.2 Les Privilèges
4.2.1 Les contrôles de droits Définition 5 Le moyen conventionnel de contrôler les droits d’un utilisateur sur un objet est le DAC pour Discretionary Access Control. Il utilise l’uid et l’euid.
L’inconvénient du DAC est l’obligation de donner tous les droits pour en accorder un spécifique. Ceci peut se révéler dangereux. Si le processus auquel on a accordé ce droit spécifique (et donc tous les droits) est compromis, c’est tout le système qui l’est comme l’illustre la figure 4.4.
OpenSolaris/Solaris dispose d’un autre type de contrôle :
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 36 Les mécanismes de sécurité d’OpenSolaris
Fig. 4.4 – Exemple simple de compromission avec le DAC
4.2.2 Les privilèges de Solaris Les privilèges sont des droits systèmes de forte granularité intervenant avant les DAC. Le noyau les implémente au moyen de "sets" : – Effective – Permitted – Limit – Inherited.
Ils sont totalement indépendants des DAC et interviennent en amont de ceux-ci (cf figure 4.5).
Remarque 4 Dans la zone globale, les privilèges sont désactivés par défaut.
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 4.2 Les Privilèges 37
Fig. 4.5 – Exemple de compromission avec les privilèges
4.2.3 La gestion des privilèges 4.2.3.1 Les commandes importantes En fait le titre de cette section est mensonger car il n’existe qu’une seule commande pour gérer entièrement les privilèges OpenSolaris : ppriv.
La documentation de référence est donc la page de manuel de cette com- mande.
4.2.3.2 Les privilèges et leur définition
Privilège Status Description cpc_cpu Optionnel Accès à certain compteurs cpc Suite à la page suivante. . .
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 38 Les mécanismes de sécurité d’OpenSolaris
Tab. 4.2 – Suite
Privilège Status Description dtrace_proc Optionnel fournisseurs fasttrap et pid ; plockstat dtrace_user Optionnel Fournisseurs syscall et pro- file gart_access Optionnel ioctl accède à agpgart_io gart_map Optionnel mmap accède à agpgart_io Optionnel dans les zones partagéant l’IP Accès sensible aux paquets net_rawaccess Par défaut dans les PF_INET/PF_INET6 zones à IP exclusive proc_clock_highres Optionnel Utilisation de timers à haute résolution proc_priocntl Optionnel Contrôle du Scheduling ; priocntl sys_ipc_config Optionnel Raising IPC message queue buffer size sys_time Optionnel Manipulation du temps sys- tème ; xntp dtrace_kernel Prohibé Non supporté pour l’instant proc_zone Prohibé Non supporté pour l’instant sys_config Prohibé Non supporté pour l’instant sys_devices Prohibé Non supporté pour l’instant sys_linkdir Prohibé Non supporté pour l’instant sys_net_config Prohibé Non supporté pour l’instant sys_res_config Prohibé Non supporté pour l’instant sys_suser_compat Prohibé Non supporté pour l’instant proc_exec Requis, par défaut Utilisé pour lancer init proc_fork Requis, par défaut Utilisé pour lancer init sys_mount Requis, par défaut Nécessaire pour monter les systèmes de fichiers Requis par défaut dans les Requis pour démarrer la sys_ip_config zones IP exclusive zone exclusive et initialiser Prohibé dans les le réseau IP dans les zones zones partageant l’IP IP Suite à la page suivante. . .
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 4.2 Les Privilèges 39
Tab. 4.2 – Suite
Privilège Status Description contract_event Par défaut Utilisé pour contacter le système de fichiers contract_observer Par défaut Contacter l’observation in- dépendemment de l’UID file_chown Par défaut Changement du proprié- taire du fichier file_chown_self Par défaut Changement du Proprié- taire/Groupe file_dac_execute Par défaut Accès à l’exécution indépen- demment du mode ACL file_dac_read Par défaut Accès à la lecture indépen- demment du mode ACL file_dac_search Par défaut Accès à la recherche indé- pendemment du mode ACL file_dac_write Par défaut Accès à l’écriture indépen- demment du mode ACL file_link_any Par défaut Accès au lien indépendem- ment du propriétaire file_owner Par défaut Autres accès indépendem- ment du propriétaire file_setid Par défaut Changement de permission pour les fichiers setid, set- gid, setuid ipc_dac_read Par défaut Accès à la lecture IPC indé- pendemment du mode ipc_dac_owner Par défaut Accès à l’écriture IPC indé- pendemment du mode ipc_owner Par défaut Autres accès aux IPC indé- pendemment du mode net_icmpaccess Par défaut Accès aux paquets ICMP : ping net_privaddr Par défaut Binding to privileged ports proc_audit Par défaut Generation de journaux d’audit proc_chroot Par défaut Changement du répertoire racine Suite à la page suivante. . .
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 40 Les mécanismes de sécurité d’OpenSolaris
Tab. 4.2 – Suite
Privilège Status Description proc_info Par défaut Liste les informations des processus proc_lock_memory Par défaut Verrouillage de la mémoire ; shmctl et mlock. Si ce pri- vilège est assigné à une zone non globale, il ne faut pas oublier de redimension- ner la ressource zone.max- locked-memory pour préve- nir d’une blocage total de toute la mémoire. proc_owner Par défaut Contrôle du processus in- dépendemment du proprié- taire proc_session Par défaut Contrôle du processus indé- pendemment de la session proc_setid Par défaut Setting of user/group IDs at will proc_taskid Par défaut Assigning of task IDs to cal- ler sys_acct Par défaut Management of accounting sys_admin Par défaut Simple system administra- tion tasks sys_audit Par défaut Management of auditing sys_nfs Par défaut NFS client support sys_resource Par défaut Resource limit manipula- tion Tab. 4.2 – Liste des privilèges de zone
Le tableau suivant liste les privilèges liés aux Trusted Extensions. Si ces dernières ne sont pas configurées, les privilèges ci-dessous ne seront pas in- terprétés par le système.
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 4.3 SCF - Solaris Cryptographic Framework 41
Privilège Status Description sys_trans_label Optionnel Translate labels not dominated by sen- sitivity label win_colormap Optionnel Colormap restrictions override win_config Optionnel Configure or destroy resources that are permanently retained by the X server win_dac_read Optionnel Read from window resource not owned by client’s user ID win_dac_write Optionnel Write to or create window resource not owned by client’s user ID win_devices Optionnel Perform operations on input devices win_dga Optionnel Use direct graphics access X protocol extensions; frame buffer privileges nee- ded win_downgrade_sl Optionnel Change sensitivity label of window re- source to new label dominated by exis- ting label win_fontpath Optionnel Add an additional font path win_mac_read Optionnel Read from window resource with a la- bel that dominates the client’s label win_mac_write Optionnel Write to window resource with a label not equal to the client’s label win_selection Optionnel Request data moves without confirmer intervention win_upgrade_sl Optionnel Change sensitivity label of window re- source to a new label not dominated by existing label net_bindmlp Par défaut Allows binding to a multilevel port (MLP) net_mac_aware Par défaut Allows reading down via NFS Tab. 4.3 – Privilèges des Trusted Extensions
4.3 SCF - Solaris Cryptographic Framework
Cette section ne sera pas développée.
Le SCF est la couche de chiffrement du système Solaris. Le directeur de
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 42 Les mécanismes de sécurité d’OpenSolaris
développement de cette dernière n’est autre que Whitfield Diffie, l’inventeur 1 de la cryptographie à clef publique [16]. Solaris 10, par l’intermédiaire du SCF, gère les fonctions cryptographiques au niveau du noyau et de l’espace utilisateur - éliminant ainsi les risques inhérents à la cryptographie de niveau application.
4.4 SMF - Service Management Facilities
En cours de rédaction ! SMF a été conçu dans le but de simplifier la gestion des nombreux services qu’un administrateur peut rencontrer sur ses machines.
4.5 RBAC - Role Based Access Control
Le mécanisme de RBAC permet d’affiner la sécurité dans les nouvelles applications (ou celles spécialement modifiées). C’est en effet une alternative au concept tout-ou-rien du modèle de sécurité des systèmes traditionnels.
Un administrateur peut, avec les RBAC, assigner des privilèges à des comptes utilisateurs spéciaux - les rôles.
Il existe deux méthodes pour donner des accès aux applications disposant des privilèges importants :
1. l’administrateur peut assigner des attributs spéciaux, comme le setUID, aux applications 2. l’administrateur peut assigner des attributs spéciaux, comme le setUID, aux applications utilisant les profiles d’exécution.
Les autorisations Une autorisation est une chaine de caractères unique représentant les droits d’un utilisateur pour exécuter des opérations ou un classe d’opérations.
1. Ses travaux portent actuellement sur la cryptographie par courbe elliptique (ECC)
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 4.6 Trusted Extensions 43
Les définitions des autorisations sont stockées dans une base de données, auth_attr. Ci-dessous quelques exemples issus de cette base : solaris.jobs.:::Cron and At Jobs::help=JobHeader.html solaris.admin:::Cron \& At Administrator::help=JobsAdmin.html solaris.grant:::Delegate Cron \& At Administration::help=JobsGrant.html solaris.jobs.user:::Cron \& At User::help=JobsUser.html
Pour résumer, des commandes spécifiques sont assignés à des profiles qui sont eux-même assignés à des rôles et/ou des utilisateurs à qui on peut aussi assigné des rôles.
4.5.1 Fichiers de configuration
/etc/user_attr Base de données des associations utili- sateurs/rôles /etc/security/auth_attr Base de données décrivant les autorisa- tions /etc/security/exec_attr Base de données des profiles d’exécu- tion. /etc/security/prof_attr execution Base de données décrivant les profiles.
Tab. 4.4 – Fichiers de configuration RBAC
4.6 Trusted Extensions
Apparues avec Solaris 8, Sun Microsystem les a développées afin d’obtenir les certifications nécessaires 2 pour équiper les agences de renseignement et gouvernementales américaines.
Les Trusted Extensions mettent en jeux de nouveaux mécanismes de sé- curité pour Solaris 10, basés sur les zones : – le support du MAC - Mandatory Access Controls – la séparation des réseaux - CIPSO – la gestion des labels avec extension pour l’interface graphique.
2. Trusted Solaris 8 a reçu la certification EAL4+ en 2004
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 44 Les mécanismes de sécurité d’OpenSolaris
Solaris 10 avec les Trusted Extensions est destiné pour la certification des Critères Communs au niveau EAL4+.
Cette section ne sera traitée qu’en théorie. Les labels seront également vus dans la partie II page 159 si le temps le permet.
4.6.1 MAC et Labels Définition 6 MAC : Mandatory Access Control
Solaris Trusted Extensions utilise le mécanisme de zones pour la labelli- sation. La zone globale est la zone d’administration et donc ne doit pas être accessible par les utilisateurs. Les zones non globales sont appelées pour cette section des zones labelliséeset sont les seules disponibles pour les utilisateurs.
La zone globale partage quelques fichiers systèmes avec les utilisateurs. Quand ces fichiers sont visibles dans une zone labellisé, le label de ces fichiers est ADMIN_LOW. La communication via le réseau est restreinte par la labellisa- tion. Par défaut, les zones ne peuvent pas communiquer entre elles si elles ont des labels différents. Ainsi, une zone ne pourra pas écrire dans une autre. Par contre, la zone administrative peut configurer des zones spécifiques pour aller lire les répertoires spécifiques des autres zones. Ces zones labellisées peuvent être hébergées sur la même machine ou bien sur des machines distantes.
4.6.2 Trusted Networking - CIPSO En cours de rédaction !
4.6.3 Trusted GUI En cours de rédaction !
David Pauillac c novembre 2007 - OpenSolaris et la sécurité Chapitre 5 Les outils de performance et de diagnostique de Solaris
Ce chapitre n’a pas pour but de reécire les pages de manuel des com- mandes présentées ici. Il est juste question de les énumérer et de montrer leur mode de fonctionnement à travers un exemple simple.
Les man pages sont très bien faites et restent la source d’aide indispen- sable à l’administrateur. La phrase de présentation de chaque commande est d’ailleurs celle des pages de manuel.
L’ouvrage [18] est une excellente référence dans ce domaine.
5.1 Contrôler les processus
Les outils suivants permettent d’effectuer des recherches et de modifier l’état des processus.
pgrep - grep pour les processus
Trouve les processus en fonction de leur nom ou d’un autre attribut.
pkill - envoi d’un signal à une liste de processus
Commande sensiblement identique à la précédente : permet d’envoyer un signal à une liste de processus en fonction d’un motif de recherche.
454545 46 Performances et diagnostique
Fig. 5.1 – pgrep sur le groupe daemon
pstop - stoppe les processus Stoppe chaque processus (PR_REQUESTED stop) correspondant à un motif de recherche.
prun - démarre les processus Lance chaque processus (inverse de pstop)
prctl - affiche/affecte les ressources du processus Affiche ou modifie les ressources des processus, tâches et projets.
pwait - attente d’un processus Attend que tous les processus spécifiés soient terminés.
preap - reap un processus zombie Force un processus defunct à être recueilli par son processus parent.
5.2 Monitorer les processus
cputrack - compteurs hw par processeurs Moniteur processus et comportement de ses LWP en utilisant les comp- teurs de performance CPU
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 5.2 Monitorer les processus 47 pargs - arguments du processus Affiche les arguments des processus, les variables d’environnement. pflags - drapeaux du processus Affiche les drapeaux de traçage /proc, les signaux et autres informations sur le status (/proc) pour chaque lwp de chaque processus pcred - process credentials Affiche les informations telles que les UIDs et les GIDs sauvegardés pour chaque processus. pldd - dépendances du processus Liste les liens dynamiques des bibliothèques pour chaque processus, y compris les objets partagés explicitement attachés psig - signal du processus Liste les signaux de chaque processus. pstack - état de la pile d’exécution du processus Affiche les traces de la pile en hexadécimal pour chaque processus. pmap - carte de la mémoire du processus Affiche les informations sur l’espace d’adressage du processus entré en paramètre. pfiles - fichiers ouverts Rapporte les informations en provenance de fstat et fcntl pour tous les fichiers ouverts de chaque processus. prstat - statistiques du processus Affiche les statistiques des processus actifs.
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 48 Performances et diagnostique
ptree - arbre du processus Affiche l’arborescence des processus. Il contient les pids ou utilisateurs spécifiques, avec les processus fils indentés par rapport à leur processus parent respectif.
ptime - process microstate times Commande de temps, identique à time mais plus précis. Á la différence de time, les enfants de cette commande ne sont pas temporisés.
pwdx - répertoire d’exécution du processus Affiche le répertoire courant de chaque processus.
5.3 Tracer le système - dtrace
C’est un logiciel inclus dans le noyau d’OpenSolaris. Il permet de sur- veiller l’exécution d’un logiciel ou du système entier.
Il s’adresse aux développeurs, mais aussi aux administrateurs ou aux in- génieurs support. Il permet une analyse progressive permettant ainsi une analyse de l’ensemble des causes du problème. Grâce à une approche sur chacune des couches logicielles, il permet de connaître avec précision l’im- pact d’une application sur le reste du système.
Il utilise le langage de programmation D, spécialement développement par Sun Microsystem pour dtrace. L’exemple 1 suivant permet de déterminer quel processus efface le fichier .my.cnf :
#!/usr/sbin/dtrace -s
syscall::unlink:entry / ((file = copyinstr(arg0)) == "/root/.my.cnf" || cwd == "/root" && file == ".my.cnf") / { self->y = 1; }
1. provenant de http://solaris-fr.org
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 5.4 Tracer l’activité du noyau 49 syscall::unlink:return / self->y && arg0 == 0 / { printf("%s\n", stringof(curthread->t_procp->p_user.u_psargs)); printf("zone %s UID %d PPID %d %s\n", stringof(curthread->t_procp->p_parent->p_cred->cr_zone->zone_name), curthread->t_procp->p_parent->p_cred->cr_uid, ppid, curthread->t_procp->p_parent->p_user.u_comm); }
5.4 Tracer l’activité du noyau iostat - statistiques Entrées/Sorties & NFS Rapport statistique sur les entrées/sorties kstat - affichage des statistiques du noyau display kernel statistics mpstat - statistiques du processeur Rapport statistique par processeur. netstat - statistiques du réseau Affiche les status réseaux nfsstat - statistiques du serveur nfs Affiche les statistiques NFS sar - utilitaires sink Rapport sur les activités système vmstat - statistiques de la mémoire virtuelle Rapport sur les statistiques de la mémoire virtuelle
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 50 Performances et diagnostique
Fig. 5.2 – Les informations fournies par prctl
David Pauillac c novembre 2007 - OpenSolaris et la sécurité Seconde partie
Installer OpenSolaris
515151
Chapitre Premier L’installation d’OpenSolaris
1.1 Le programme d’installation
Le système OpenSolaris nécessite les pré-requis matériels suivants : – Espace disque – 2 Go minimum pour l’installation minimaliste – 6 Go pour l’installation de tous les paquetages.
– Mémoire vive – 128 Mo minimum (256 Mo pour les systèmes x86) – 512 Mo recommendés.
Le programme d’installation d’OpenSolaris est explicite ; il suffit à l’uti- lisateur de se laisser guider par celui-ci. Les captures d’écrans qui suivent retracent les grandes étapes de l’installation pour une station de développe- ment.
535353 54 L’installation d’OpenSolaris
Fig. 1.1 – Démarrage de l’installation
Fig. 1.2 – Choix d’installation
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 1.1 Le programme d’installation 55
Fig. 1.3 – Choix de la langue
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 56 L’installation d’OpenSolaris
Fig. 1.4 – Choix de la localisation
Fig. 1.5 – Paramétrage de l’heure et de la date
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 1.1 Le programme d’installation 57
Fig. 1.6 – Choix de l’environnement localisé
Fig. 1.7 – Choix du disque
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 58 L’installation d’OpenSolaris
Fig. 1.8 – Choix de la partition
Fig. 1.9 – Modifier les systèmes de fichiers
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 1.1 Le programme d’installation 59
Fig. 1.10 – Systèmes de fichiers
Fig. 1.11 – Récapitulatif de l’installation
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 60 L’installation d’OpenSolaris
Fig. 1.12 – Installation en cours
Fig. 1.13 – Fin de l’installation
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 1.1 Le programme d’installation 61
Une fois le système redémarrer, nous obtenons les écrans suivants.
Fig. 1.14 – Grub en action
Fig. 1.15 – Démarrage du système OpenSolaris
On voit bien que le noyau Solaris est le 5.11 !
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 62 L’installation d’OpenSolaris
Puis au bout de quelques instants, on arrive sur la page d’identification :
Fig. 1.16 – Écran de connexion
Le tableau 1.1 liste les commandes nécessaires pour installer ou mettre à jour des applications pour un système OpenSolaris ainsi que pour un système GNU/Linux basé sur la distribution Red Hat.
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 1.2 Mise en place du réseau 63
Description GNU/Linux Solaris Installer un package rpm -i pkgadd Afficher les packages installés rpm -qa pkginfo Supprimer un package rpm -e pkgrm Mettre à jour un package rpm -U N/A Vérifier l’installation d’un pa- rpm -V pkgchk ckage Installer un patch rpm -F patchadd Supprimer un patch N/A patchrm
Tab. 1.1 – Tâches d’installation et d’upgrade
1.2 Mise en place du réseau
1.2.1 Configurer les interfaces réseau La commande ifconfig -a permet de lister toutes les interfaces recon- nues par le système et obtenir le nom de ces dernières. Ensuite on configure chaque interface de la manière suivante : 1. modifier le fichier /etc/hostname.
1.2.2 Routes et routeur Une fois l’interface réseau configurée, il faut s’assurer que la route par défaut existe, et la créer le cas échéant 1 : 1. si les étapes précédentes n’ont pas été suivies
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 64 L’installation d’OpenSolaris
La route par défaut est renseignée dans le fichier /etc/defaultrouter.
Fig. 1.17 – Fichier définissant la route par défaut
Si la machine n’est pas un routeur - la majorité des cas - il faut désactiver le routage des paquets IP. Pour cela, il faut créer le fichier /etc/notrouter :
Fig. 1.18 – Désactivation du routage de paquets IP
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 1.2 Mise en place du réseau 65
Description GNU/Linux Solaris Configurer TCP/IP gérer les Éditer les fichiers : scripts dans /etc/hostname.* /etc/sysconfig/ /etc/inet.* network-scripts/ /etc/defaultrouter /etc/defaultdomain Informations sur les interfaces ifconfig ifconfig Configurer une interface ifconfig ifconfig Modifier la résolution de noms vi /etc/resolv.conf vi /etc/nsswitch.conf Supprimer la résolution de vi /etc/resolv.conf vi /etc/nsswitch.conf noms Afficher les infos de résolution cat /etc/resolv.conf cat /etc/nsswitch.conf de noms Configurer l’ordre des résolu- vi vi /etc/nsswitch.conf tions de noms /etc/nsswitch.conf Configurer TCP/IP gérer les Éditer les fichiers : scripts dans /etc/hostname.* /etc/sysconfig/ /etc/inet.* network-scripts/ /etc/defaultrouter /etc/defaultdomain Informations sur les interfaces ifconfig ifconfig Configurer une interface ifconfig ifconfig Modifier la résolution de noms vi /etc/resolv.conf vi /etc/nsswitch.conf Supprimer la résolution de vi /etc/resolv.conf vi /etc/nsswitch.conf noms Afficher les infos de résolution cat /etc/resolv.conf cat /etc/nsswitch.conf de noms Configurer l’ordre des résolu- vi vi /etc/nsswitch.conf tions de noms /etc/nsswitch.conf
Tab. 1.2 – Gestion du réseau
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 66 L’installation d’OpenSolaris
Description GNU/Linux Solaris Change le nom d’hôte hostname Modification dans les fichiers : /etc/nodename /etc/hosts /etc/hostname.* /etc/net/*/hosts Liste des services /etc/services /etc/services Liste des protocoles /etc/protocols /etc/protocols Status du réseau netstat netstat Statistiques NFS/RPC nfsstat nfsstat Configuration de l’enregistreur /etc/syslog.conf /etc/syslog.conf d’évènements système Localisation des scripts de démar- /etc/init.d /etc/init.d rage
Tab. 1.3 – Informations diverses
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 1.3 État du système après l’installation 67
Fig. 1.19 – Résultats fournis par Nmap après l’installation
1.3 État du système après l’installation
En effectuant un scan de ports juste après l’installation 2, on obtient le résultat illustré par la figure 1.19 : Nmap a très bien détecté quel système il scannait et on constate que 2 ports sont ouverts :
– le port 22 pour ssh – le port 111 pour rpc
2. C’est-à-dire sans avoir effectué le moindre paramétrage
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 68 L’installation d’OpenSolaris
1.4 Suppression des packages inutiles
Avant de commencer, il faut supprimer tous les programmes inutiles pour le système - et qui pourraient entrer en conflit avec les applications qui seront installées plus tard. Le tableau B.1 3, page 179, liste les différents packages présents (selon le type d’installation certains ne pourraient pas être installés) et détermine s’ils peuvent être supprimés à coup sur (O), selon le cas (M) ou pas du tout (N).
3. issu du site de Sun Microsystem, pour l’architecture x86
David Pauillac c novembre 2007 - OpenSolaris et la sécurité TOME II
OPENSOLARIS D’UN POINT DE VUE SERVEUR
696969 70
David Pauillac c novembre 2007 - OpenSolaris et la sécurité Première partie
Configurer OpenSolaris et le rendre plus sûr
717171
Chapitre Premier La gestion des utilisateurs
Comme tout système UNIX, OpenSolaris est multi-utilisateurs. Les fi- chiers gérant les utilisateurs locaux sont /etc/passwd et /etc/shadow.
Chaque compte utilisateur doit être unique et nominatif. Il existe un cer- tain nombre d’outils permettant à un utilisateur d’exécuter des commandes en tant que root (sudo entre autre). Il est primordial de ne JAMAIS se connecter directement en tant qu’admi- nistrateur pour au moins deux raisons : 1. le fait de se connecter via un autre compte utilisateur permet de tracer les différentes actions effectuées sous root (on sait quel "administrateur" a fait quoi) 2. un individu malveillant devra connaître au moins deux mots de passe pour pouvoir se connecter en tant que root.
Avec le système OpenSolaris, il existe une alternative intéressante : en uti- lisant le mécanisme de rôles, on peut se passer d’un compte administrateur ayant tous les pouvoirs et ne le conserver que dans le cas d’un démarrage en mode simple utilisateur.
1.1 La gestion des mots de passe
1.1.1 Les utilisateurs Comme dans tous les systèmes UNIX, les deux fichiers importants dans la gestion des utilisateurs sont : – le fichier /etc/passwd – le fichier /etc/group Dans l’immédiat, seul le premier nous intéresse, le deuxième traitant des groupes qui sont l’objet de la section 1.1.2.
737373 74 La gestion des utilisateurs
Description GNU/Linux Solaris ajouter un utilisateur useradd useradd supprimer un utilisateur userdel userdel modifier un utilisateur usermod usermod lister les utilisateurs |awk-F ":" ’print listusers $1’ /etc/passwd| Fichiers de passwd /etc/passwd /etc/passwd /etc/shadow /etc/shadow Fichiers de groupes /etc/group /etc/group Définition des limites /etc/security/ N/A limits.conf Définition de l’environnement du /etc/profile N/A système Configuration des informations /etc/login.defs /etc/pam.conf d’authentification
Tab. 1.1 – Gestion des utilisateurs
Le fichier /etc/passwd contient toutes les informations relatives aux uti- lisateurs (login, mots de passe, . . . ). Il est organisé de la manière suivante :
nom_utilisateur : mot_de_passe : uid : gid : commentaire : répertoire : shell Si on utilise le shadowing 1, le mot de passe est remplacé par une étoile dans le fichier etc/passwd et inscrit dans le fichier /etc/shadow, inaccessible à tout utilisateur, même en lecture.
Le durcissement du mot de passe sera vu dans la section 3.3.1, page 87.
Les commandes pour gérer les utilisateurs sont retracées dans le tableau 1.
Bien sûr, il est toujours possible d’utiliser des outils graphiques. Cepen- dant, je ne conseille pas leur utilisation.
1. Ce que tout bon administrateur devrait faire
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 1.1 La gestion des mots de passe 75
Fig. 1.1 – Création d’un utilisateur par l’interface graphique
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 76 La gestion des utilisateurs
Fig. 1.2 – Configurer un compte via l’interface graphique
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 1.1 La gestion des mots de passe 77
Fig. 1.3 – Les privilèges en mode graphique
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 78 La gestion des utilisateurs
1.1.2 Les groupes Le concept de groupe sous UNIX est en relation avec les permissions des fichiers et répertoires. Il permet de donner des accès à un certain nombre d’utilisateurs pour qu’ils puissent partager des fichiers entre eux sans que d’autres y accèdent. Le fichier /etc/group contient la liste des utilisateurs appartenant aux diffé- rents groupes. Sa structure est la suivante : nom_de_groupe : champ_special : gid : membre1, membre2, ... Á noter que le champ spécial est fréquemment vide. Le numéro de groupe est le lien entre les fichiers /etc/group et /etc/passwd.
Tout comme pour la gestion des utilisateurs, il existe des commandes pour gérer les groupes, listées dans le tableau 1.2.
groupadd Ajouter un groupe usermod Modifier un groupe userdel Supprimer un groupe
Tab. 1.2 – Les commandes pour gérer les groupes
1.1.3 Les rôles Les rôles sont des comptes systèmes spéciaux, possédant un identifiant, un mot de passe et même un répertoire de travail. On peut donc les assimiler à des utilisateurs systèmes, à la différence près que les rôles ne peuvent pas se connecter au système. On peut utiliser la commande su pour changer de rôle.
La commande roles quant à elle permet de lister les rôles d’un utilisateur :
roleadd Ajouter un rôle rolemod Modifier un rôle roledel Supprimer un rôle
Tab. 1.3 – Commandes utiles pour gérer les rôles
Le concept de rôle est le point central du Role Based Access Control 2. Les rôles sont associés à des taches spécifiques et possèdent des autorisations qui leur sont assignées.
2. cf. section 4.5 page 42
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 1.2 Le système d’authentification 79
1.2 Le système d’authentification
Pour assurer l’authentification, les systèmes UNIX utilisent par défaut le module PAM - Pluggable Authentication Modules.
Au début d’UNIX, toute la gestion des utilisateurs était centralisée dans le fichier /etc/passwd, et de ce fait tout était stocké dans un fichier lisible par tous les utilisateurs. Comme la puissance des machines est devenue suffisante pour que n’importe quel quidam puisse tenter une attaque par force brute sur les mots de passe UNIX, un nouveau fichier a été créé afin de déplacer le mot de passe dans ce nouveau fichier, /etc/shadow, qui lui n’est pas ac- cessible aux utilisateurs. Cependant cette profonde modification impliqua la réimplémentation du programme login chargé de contrôler le mot de passe. Et de nombreux autres programmes qui aller chercher le mot de passe dans le fichier originel durent être modifiés. C’est ainsi qu’il a été décidé de déporter entièrement la couche d’authentification des programmes en ayant besoin et de créer PAM.
Définition 7 PAM est un framework assurant le lien entre les applications et les mécanismes d’authentification.
1.2.1 Le module PAM 1.2.1.1 Mode de fonctionnement PAM est un jeu de bibliothèques dynamiques gérant des points précis du processus d’authentification. Par authentification il ne faut pas penser seule- ment au couple login/mot de passe, mais à l’ensemble des éléments d’auto- risation.
Un administrateur système peut alors configurer toutes ses applications nécessitant une authentification d’une manière unique. La seule restriction étant que l’application soit « PAM enabled », c’est a dire qu’elle soit dévelop- pée pour utiliser les librairies PAM. La plus grande majorité des applications UNIX sont conçues pour fonctionner avec PAM.
Ainsi un service peut être configuré de telle manière que l’authentification pour y accéder se déroule en trois étapes. Il peut donc choisir exactement sa propre politique d’authentification pour cette application, indépendamment
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 80 La gestion des utilisateurs
Fig. 1.4 – Architecture de base de PAM
de celle-ci.
Remarque 5 Les formats des fichiers de configuration PAM différent entre GNU/Linux et OpenSolaris. De même, les noms des modules standards sont entirèrement différents.
Ainsi, par exemple, le module PAM de GNU/Linux peut être configuré afin d’imiter les propriétés du groupe wheel propre aux systèmes BSD. Ceci n’est pas possible pour les systèmes OpenSolaris, IBM AIX et HP-UX.
Tous les services sont configurés dans le répertoire /etc/pam.d/ où chaque fichier détaille les politiques d’authentification pour chaque service.
1.2.1.2 Hiérarchisation des taches d’authentification Afin de simplifier l’utilisation et la compréhension du rôle de chaque mo- dule, les taches d’authentification sont divisées en 4 groupes indépendants : – Account
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 1.2 Le système d’authentification 81
– Authentification – Passwd – Session Un service est donc divisé en 4 groupes. A chaque groupe, on assigne un ou plusieurs modules.
Malgré l’évidente simplicité de cette division, on peut trouver des modules intervenant dans plusieurs groupes, ce qui a pour conséquence de complexi- fier le choix de son emplacement dans les groupes.
Définition 8 – Un module est un morceau de code capable d’être lié dy- namiquement à une application fournissant un service. Il apporte un certain nombres de fonctionnalités hiérarchisées en quatre groupes liés à leur périmètre d’action. Ces fonctionnalités peuvent couvrir un seul de ces groupes ou bien plusieurs. – Un service est configuré dans un fichier (nommé selon son type de ser- vice) contenu dans le répertoire /etc/pam.d/
Il existe quatre types d’obligation : – required – requisite – sufficient – binding Pour résumer, la configuration d’une politique de sécurité appliquée à un service passe par l’utilisation d’un ou plusieurs modules, renseignés dans le fichier situé dans /etc/pam.conf. Chaque ligne de ce fichier informe PAM d’utiliser une fonctionnalité d’un module selon le groupe, inscrit en début de ligne.
PAM va lire séquentiellement les lignes de chaque groupe et va confronter l’obligation de réussite défini par l’administrateur au code retour renvoyé par la librairie et décider de continuer ou pas, selon le résultat.
Les modules PAM disponibles par défaut se trouvent dans le répertoire /usr/lib/security
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 82 La gestion des utilisateurs
1.2.1.3 Conclusion Le sujet de PAM n’a été qu’effleuré ; il faudrait plusieurs livres pour en faire le tour 3. Cependant, on peut retenir que le fait que la moindre erreur dans la confi- guration de PAM puisse bloquer l’accès au système et le grand nombre de paramètres donnent une apparence complexe à PAM.
Néanmois, il permet d’intégrer facilement et pour toutes les applications souhaitées une authentification personnalisée, provenant d’un LDAP, d’un domaine NT ou d’un système de biométrie et ce sans avoir à modifier les applications concernées.
3. ce qui n’est pas l’objet de ce document en plus
David Pauillac c novembre 2007 - OpenSolaris et la sécurité Chapitre 2 Le contrôle des accès
2.1 Suppression des exécutables SUID/SGID
En utilisant la commande find / -local -type f -perm 4000 - exec ls-ld {} on peut lister tous les fichiers possédant le "fameux" bit setuid. Pour mé- moire, de tels fichiers garantissent à l’utilisateur les exécutant de disposer des accès correspondant à ceux du propriétaire du dit fichier 1. Tous ces fichiers ne doivent avoir comme propriétaire que root, bin ou sys. Si tel n’est pas le cas, le système est sûrement victime d’une intrusion.
Lorsque cela est possible, il faut affecter à un groupe d’administration (par exemple wheel) les fichiers les plus sensibles, tels que su, puis modifier leur accès (750 est suffisant, ce qui correspond à rwxr-x—).
Il faut recommencer les mêmes manipulations avec les fichiers setgid, mais dans ce cas, pour lister ces fichiers il faut utiliser la commande find / -local -type f -perm 2000 - exec ls-ld {}
2.2 Politique générale sur les fichiers
Il faut définir un umask pour tous les utilisateurs (ou un groupe de ceux- ci). Si c’est possible, il est recommandé de le définir à 066 (seul le propriétaire possède tous les accès à son fichier). Pour se faire, il faut modifier les fichiers de login : – /etc/login – /etc/profile –...
1. qui se trouve être la plupart du temps root...
838383 84 Le contrôle des accès
2.3 Suppression des commandes distantes
Il est vivement recommander de supprimer ou de désactiver les com- mandes d’accès à distance telles que rsh, rlogin, telnet,. . . Il faut également supprimer tous les fichiers hosts.equiv, .rhosts, .netrc
David Pauillac c novembre 2007 - OpenSolaris et la sécurité Chapitre 3 Le système
3.1 Personnaliser la pile IP
OpenSolaris possède une commande permettant de durcir la pile IP, ndd. Pour rendre permanents les changements, une solution alternative existe et sera décrite pour chaque cas. On peut aussi créer un script de démarrage regroupant toutes les commandes de cette section.
Le protocle ARP est sujet à de nombreuses attaques : – ARP-poisoning (déni de service) : l’attaquant envoie une adresse IP source (un des postes cible de l’attaque) et son adresse MAC, puis four- nit ensuite l’adresse IP de l’autre poste et une adresse MAC falsifiée (n’importe laquelle) ; le processus répondra ensuite (le plus rapidement possible) à une requête d’ « arp who-has ». Le poste ciblé par l’attaque mettra à jour sa table ARP avec une fausse adresse MAC et ne pourra plus communiquer avec l’autre poste.
– "
– ARP-Spoofing : appelée aussi ARP Redirect, redirige le trafic réseau d’une ou plusieurs machine vers la machine de l’attaquant.
Toutes les attaques touchant le protocole ARP utilisent l’em- poisonnement des tables ARP.
Afin de rendre les attaques ARP plus difficiles, on modifie le temps de rafraîchissement du cache ARP et de la table de routage IP avec
858585 86 Le système
les commandes respectives : #ndd -set /dev/arp arp_cleanup_interval
Les scanners de ports modernes peuvent déterminer le système d’exploitation en fonction de l’implémentation des différents pro- tocoles TCP/IP, normalement spécifique à chaque système.
Sous OpenSolaris, on peut changer le comportement de la pile IP 1 du système. – modifier le Maximum Segment Size (MSS) ; valeur par défaut 536 ndd -set /dev/tcp tcp_mss_def_ipv4
– générer un nombre aléatoire pour la séquence initiale de TCP ndd -set /dev/tcp tcp_strong_iss 2 Ou bien, pour rendre ce paramètre permanent, modifier le fichier /etc/inetinit TCP STRONG ISS 1 en TCP STRONG ISS 2
.
Il existe de nombreux autres paramètres permettant de protéger le sys- tème de diverses attaques. Il sont expliqués dans l’exemple de script à lancer au démarrage de la machine, disponible à l’annexe A.
3.2 Configurer le pare-feu
Il existe plusieurs pare-feux pour OpenSolaris, aussi bien commerciaux que libres. La présente section s’intéressera exclusivement à IP Filter qui est libre et disponible sur de nombreuses plate-formes.
Pour la syntaxe des fichiers de configuration, le site http://coombs.anu.edu.au/~avalon/examples.html#permissions est une excellente source d’information de même que le Howto IPFilter[4].
1. Les différents paramètres de la pile IP ne seront pas expliqués - Internet sera une excellente source d’informations pour les plus curieux
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 3.3 Modifier le niveau général de sécurité 87
Ces fichiers de configuration sont les suivants :
– /etc/ipf/ipf.conf permet de configurer le filtrage à proprement parlé – /etc/ipf/ipnat.conf permet de configurer la translation d’adresses et de ports – /etc/ipf/ippool.conf permet de configurer les pools d’adresses.
Pour activer IP Filter sous Solaris, les commandes d’IP Filter - ipf -e par exemple - peuvent être remplacées en utilisant SMF. Ainsi la com- mande # svcadm enable|disable network/ipfilter permet d’activer ou de désactiver le pare-feu.
Voici un exemple de fichier de configuration d’IPFilter :
3.3 Modifier le niveau général de sécurité
3.3.1 Renforcer les mots de passe Il existe différentes méthodes pour durcir les mots de passe. La première consiste tout simplement à choisir un algorithme de chiffrement plus sûr que le simple DES de 8 caractères sans graine. Pour cela, il suffit de modifier le fichier /etc/security/policy.conf et de choisir de ne plus utiliser l’algorithme standard __unix__ mais un algorithme plus sûr : CRYPT_DEFAULT=__unix__ doit être remplacé par CRYPT\_DEFAULT=x Où x peut prendre les valeurs suivantes : – 1 : cryptosystème des systèmes BSD/Linux, basé sur l’algorithme de hashage md5 – 2a : cryptosystème basé sur l’algortihme blowfish 2.
2. Le détail des cryptosystèmes disponibles se trouve dans le fichier etc/security/crypt.conf
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 88 Le système
Il ne faut pas oublier ensuite de modifier le mot de passe pour que celui-ci utilise le nouvel algorithme de chiffrement. L’exemple ci-dessous a été réalisé avec le même mot de passe. La seule variable est le cryptosystème 3.
Fig. 3.1 – Différence de chiffrement du mot de passe
La politique globale des mots de passe est décrite dans le fichier /etc/default/ passwd. Le tableau ci-dessous décrit les différentes valeurs que l’on peut mo- difier dans ce fichier.
La complexité des mots de passe est un élément crucial pour la sécurité d’un système. C’est pour cela que le système OpenSolaris peut contraindre les utilisateurs à utiliser des mots de passe complexes.
Il est recommandé de positionner une durée de vie du mot de passe à moins de 35 semaines (4 mois). Si on n’utilise pas l’algorithme de chiffrement par défaut, on peut imposer une longueur de mot de passe supérieure à 8 (10 semble être une bonne longueur pour des mots de passe sûrs et pas trop durs à se souvenir sans avoir à le noter sur un papier disposé sur le bureau).
Il faut ensuite déterminer le nombre de mot de passe que le système gar- dera en mémoire afin d’empêcher l’utilisateur de les réutiliser. Il faut faire très attention à bien paramétrer ce champs : si on exige trop des utilisa- teurs, on court le risque que ces derniers les notes sur des feuilles, sous le clavier,. . . Pour ma part, je pense que 5 mots de passe en mémoire sont suf- fisants dans la plupart des cas, les plus "paranoïaques" positionneront ce paramètre à 10 - ils peuvent bien sûrs mettre la valeur maximale, 26, mais
3. On passe de l’algorithme par défaut à l’algorithme blowfish
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 3.3 Modifier le niveau général de sécurité 89
MAXWEEKS durée maximale de validité 35 MINWEEKS durée minimale de validité 1 PASSLENGTH longueur minimale 10 WARNWEEKS période de notification 4 HISTORY nombre de mots de passe en mémoire 5 NAMECHECK contrôle la ressemblance avec le login 1 MINDIFF différence minimale avec l’ancien mot de 3 passe MINALPHA nombre minimal de caractères alphanumé- 2 riques MINNONALPHA nombre minimal de caractères non alphanu- 2 mériques MINUPPER nombre minimal de majuscules 1 MINLOWER nombre minimal de minuscules 1 MAXREPEATS nombre maximal de répétition contiguës d’un 2 caractères
Tab. 3.1 – Les différents champs du fichier /etc/default/passwd je le déconseille vivement.
L’option NAMECHECK, active par défaut, permet de s’assurer que le mot de passe n’est pas identique au login ou une rotation de celui-ci, par exemple, on ne pourra pas avoir le couple root/toro.
L’option MINDIFF permet de s’assurer que le nouveau mot de passe est différent de plusieurs caractères avec l’ancien. Par défaut la valeur est 3, donc 3 caractères doivent être différents. Ainsi, il est impossible de changer son mot de passe "OsSSI987!" par "OsSSI98" par exemple.
Les options MINALPHA (par défaut 2) et MINNONALPHA (par défaut 1) permettent respectivement de choisir un minimum de caractères alphanu- mériques et de caractères non-alphanumériques. De même que MINUPPER (par défaut 0) et MINLOWER (par défaut 0) pour les caractères minuscules et majuscules.
MAXREPEATS, désactivé par défaut, permet de s’assurer qu’un même caractère ne sera pas répété plusieurs fois à la suite.
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 90 Le système
Seules les options les plus utilisées sont présentes dans cette section. Pour plus de détails, la page de manuel de passwd est un bon début.
Remarque 6 Cette solution permet de contraindre un utilisateur à choi- sir un mot de passe complexe. Par contre, l’administrateur root n’est pas contraint et peut utiliser n’importe quel couple login/mot de passe pour n’im- porte quel compte !
D’autres paramètres sont accessibles depuis le fichier /etc/default/login. Le tableau 3.3.1 liste ces paramètres.
ULIMIT Espace disque des utilisa- 0 teurs CONSOLE Console de connexion de /dev/console root PASSREQ Mot de passe requis pour se YES connecter UMASK Masque de permissions par 077 défaut SLEEPTIME Temps d’inactivité après un 5 échec de connexion RETRIES Nombre de tentatives avant 3 blocage SYSLOG_FAILED_LOGINS Nombre d’échecs avant jour- 3 nalisation ALLOW_AGED_PASSWORD Autoriser les mots de passe NO expirés
Tab. 3.2 – Les différents champs du fichier /etc/default/login
Il ne faut pas oublier non plus le fichier /etc/security/policy.conf : Il est possible de bloquer l’accès à un compte à partir d’un certain nombre
CRYPT_DEFAULT Algorithme de chiffrement 2a du mot de passe LOCK_AFTER_RETRIES Bloquer le compte après le YES nombre max de tentatives
Tab. 3.3 – Les différents champs du fichier /etc/security/policy.conf
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 3.3 Modifier le niveau général de sécurité 91 de tentatives (avec les risques de dénis de services que cela comporte).
On paramètre ce blocage soit pour un utilisateur dans le fichier /etc/ user_attr soit pour tous les utilisateurs locaux - sauf valeur différente dans /etc/ user_attr - grâce à la variable LOCK_AFTER_RETRIES dans le fi- chier /etc/security/ policy.conf. Le nombre de tentatives infructueuses est de 5 par défaut, je recommande 3 ou 4, mais il peut prendre des valeurs com- prises entre 0 et 20. Pour cela, il faut modifier le champ RETRIES présente dans le fichier /etc/default/login.
3.3.2 Blocage et suppression des comptes inutiles
On peut distinguer deux types de compte à bloquer : – les comptes qui ne doivent pas se connecter mais peuvent exécuter des tâches comme cron notés NL ; d’une manière ce sont les comptes servant à exécuter un service tel que Apache, MySQL,. . . – les comptes qui sont bloqués sans droits supplémentaires, notés LK ; on peut désactiver quasiment tous les comptes dont l’UID est inférieur à 100 (hormis root bien sûr).
Afin de connaître l’état d’un compte, on utilise la commande : # passwd -s user Pour bloquer un compte, c’est la commande : # passwd -l badguy On peut voir l’état d’un utilisateur dans le fichier /etc/shadow, comme le montre les illustrations précédentes ; on remarque l’ajout de *LK* au début du hash.
De la même façon, on peut mettre l’option non login sur un compte avec la commande : # passwd -N dangerous On peut détecter les comptes sans mot de passe grâce à la commande : # logins -p Enfin, on peut réactiver un compte avec la commande : # passwd -u user Il ne faut pas oublier de supprimer (la désactivation dans ces cas là n’est pas suffisante) les comptes utilisateurs inutiles tels que nobody4 par exemple.
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 92 Le système
Á supprimer Á verrouiller Remarques smtp si le service smtp n’est pas utilisé uucp nuucp nobody4 lp daemon sys bin adm nobody
Tab. 3.4 – Les comptes à supprimer ou verrouiller
3.4 Protections diverses
Sous OpenSolaris, il est possible de supprimer les droits d’exécution de la pile. Malgré certaines préconisations, les cas où la pile doit demeurer exé- cutable sont extrêmement rares. Pour supprimer ces droits, l’administrateur doit modifier le fichier /etc/system pour ajouter la ligne suivante : set noexec_user_stack=1
Remarque 7 Cette option du noyau n’est pas disponible sur les plate-formes autres que SPARC.
OpenSolaris dispose aussi d’une commande bien pratique qui permet d’établir une politique globale sur les fichiers. Elle est inutile sur l’adminis- trateur a établi et mis en place une politique stricte d’accès aux fichiers via l’UMASK et la suppression des programmes SUID/SGID. Cette commande est la suivante : /usr/aset/aset -l niveau Où niveau prend les valeurs low, medium ou high.
3.5 Test de scan
Maintenant que le système est configuré, il faut refaire le scan de ports afin de déterminer si tout ce travail a bien servi à quelque chose : Á partir de maintenant, on peut relier cette machine au réseau Internet sans prendre trop de risques. Il est important aussi de procéder aux mises à jour - surtout celles concernant la correction de vulnérabilités.
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 3.5 Test de scan 93
En cours de rédaction !
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 94 Le système
Fig. 3.2 – Blocage d’un compte utilisateur
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 3.5 Test de scan 95
Fig. 3.3 – Déblocage d’un compte utilisateur
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 96 Le système
David Pauillac c novembre 2007 - OpenSolaris et la sécurité Seconde partie
Les services réseau
979797
Chapitre Premier Serveur de nom
1.1 Généralités
Les ordinateurs connectés à un réseau IP, comme par exemple Inter- net, possèdent tous au moins une adresse IP. Ces adresses sont numériques afin d’être plus facilement traitées par une machine. Selon la norme IPv4, elles prennent la forme xxx.yyy.zzz.aaa, où xxx, yyy, zzz et aaa sont quatre nombres variant entre 0 et 255 (en système décimal). Selon IPv6, les IP sont de la forme aaaa:bbbb:cccc:dddd:eeee:ffff:gggg:hhhh, où a, b, c, d, e, f, g et h représentent des caractères au format hexadécimal. Il n’est évidemment pas simple pour un humain de retenir ce numéro lorsque l’on désire accéder à un ordinateur d’Internet. C’est pourquoi un mécanisme est nécessaire pour permettre d’associer à une adresse IP un nom intelligible, humainement plus simple à retenir, appelé nom de domaine. Résoudre un nom de domaine, comme par exemple www.univ-tln.fr, c’est trouver l’adresse IP qui lui est associée.
Avant l’apparition du protocole DNS (Domain Name System), la réso- lution de nom se faisait par la lecture d’un fichier, hosts, local à chaque ordinateur et contenant les relations nom/adresse IP de toutes les machines du réseau.
Si cette technique est valable pour un petit nombre d’ordinateurs, l’ex- plosion d’Internet a imposé le remplacement de ce principe. C’est dans ces conditions que le protocole DNS a été mis en place.
Avec DNS, la résolution se fait par l’intermédiaire d’un serveur. Quand un utilisateur souhaite accéder à un site, comme par exemple www.opensolaris.org, son ordinateur émet une requête spéciale à un serveur DNS, demandant ’Quelle est l’adresse de www.opensolaris.org?’. Le serveur répond en retour- nant l’adresse IP du serveur, qui est dans ce cas-ci, 72.5.123.5.
999999 100 Serveur de nom
Il est également possible de poser la question inverse, à savoir ’Quel est le nom de domaine ou que sont les noms de domaines de telle adresse IP?’. On parle alors de résolution inverse.
Plusieurs noms de domaine peuvent pointer vers une même adresse IP et réciproquement.
Le protocole DNS permet aussi une répartition de charge dans le cas d’un traffic réseau important. Pour ce faire, le DNS utilise le principe du Round Robin qui consiste à associer plusieurs adresses IP à un même nom de domaine. Ainsi le moteur de recherche www.google.com est associé aux adresses IP 209.85.135.99, 209.85.135.104, 209.85.135.147 et 209.85.135.103. Une rotation circulaire entre ces différentes adresses permet ainsi de répar- tir la charge générée par ce trafic important, entre les différentes machines, ayant ces adresses IP.
Fig. 1.1 – Protocole DNS
DNS est un système massivement réparti. Il existe des centaines de mil- liers de serveurs DNS dans le monde entier. Chaque serveur DNS n’a en réalité à sa disposition qu’un ensemble d’informations restreint.
Afin de garantir des temps de réponse corrects, la plupart des serveurs DNS font aussi office de DNS cache : ils gardent en mémoire la réponse d’une résolution de nom afin de ne pas effectuer le long processus de demande aux serveurs DNS de plus haut niveau.
Concernant la sécurité, DNS, tout comme la plupart des protocoles ré- seaux de cet époque, n’intègre pas de notions de sécurité.
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 1.1 Généralités 101
Pour palier à ces défaut, le protocole DNSSEC, normalisé dans le RFC 4033, a vu le jour et est expérimenté au niveau d’un serveur de niveau maxi- mal (ou Top Level Domain - TLD). Le NIC hollandais, l’office Internet pour la région européenne et NLnetLabs ont créé le premier DNS TLD sécurisé. Cette expérimentation fonctionne avec son propre jeu de serveurs de nom afin de garantir aucune interférence avec les serveurs de nom de production. Le projet a débuté en novembre 2002 en vue d’acquérir l’expérience dans la pratique de DNSSEC pour un service de TLD.
1.1.1 Protocole utilisé DNSSEC permet de sécuriser les données envoyées par le DNS. Contrai- rement à d’autres protocoles comme SSL, il ne sécurise pas juste un canal de communication mais il protège les données, les enregistrements DNS, de bout en bout. Ainsi, il est efficace même lorsqu’un serveur intermédiaire n’est plus fiable.
DNSSEC signe via un mécanisme de chiffrement les enregistrements DNS et met cette signature dans le DNS. Ainsi, un client DNS méfiant peut donc récupérer la signature et, s’il possède la clé du serveur, vérifier que les don- nées sont correctes. La clé peut être récupérée via le DNS lui-même ou bien par un autre moyen (diffusée via le Web et signée avec PGP par exemple).
DNSSEC permet de déléguer des signatures : ainsi, le registre d’un TLD peut annoncer que tel sous-domaine est signé. On peut ainsi bâtir une chaîne de confiance depuis la racine du DNS.
DNSSEC introduit aussi ses propres problèmes, par exemple, le fait qu’un enregistrement spécial indique le prochain domaine de la zone permet d’énu- mérer le contenu complet d’une zone signée, même si le transfert de zone n’est pas permis.
1.1.2 Application L’application BIND (Berkeley Internet Name Domain) est une implémen- tation de DNS et de DNSSEC 1.
Il est largement diffusé et utilisé. Il est distribué sous licence BSD par l’ISC (Internet Systems Consortium[10]).
1. depuis la version 9
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 102 Serveur de nom
1.2 Installation
Il existe deux écoles pour installer une application :
1. via un package ; cette méthode présente l’avantage d’être simple et per- met aussi de mettre à jour rapidement l’application ; par contre, toutes les applications n’existent pas forcement pour le système d’exploita- tion/architecture 2. en recompilant les sources ; cette technique permet d’optimiser l’ap- plication et est disponible pour pratiquement tous les systèmes d’ex- ploitation et architectures ; à l’opposé, elle n’est possible qu’avec les applications Open Source et nécessite un compilateur.
Remarque 8 Dans l’absolu, tout serveur de production ne doit disposer que des applications dont il a besoin. Ainsi, un compilateur ne devrait jamais être installé sur un serveur : on empêche ainsi la compilation de programmes malicieux.
Pour faciliter la maintenance, je recommande, lorsque cela est possible, d’utiliser les packages plutôt que la compilation sources. Pour BIND, le pa- ckage est disponible pour les deux architectures 2 - entre autre - sur sunfree- ware.com.
1.2.1 Création de la zone dédiée Avant toute chose, on crée la zone dnszone : La création des zones ne sera détaillée que dans cette section, pour les autres zones plusieurs options s’offrent à nous : – soit cloner la zone – soit en refaisant les étapes ci-dessous – soit en copiant le fichier de configuration de zones (/etc/zones/
Remarque 9 Comme pour les autres services réseau, il ne faut pas oublier de désinstaller les packages installés par défaut.
2. SPARC et x86
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 1.2 Installation 103
Dans un premier temps on crée le répertoire "
Fig. 1.2 – Création de la zone dnszone - Acte I
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 104 Serveur de nom
On configure ensuite la zone :
Fig. 1.3 – Configuration de la zone dnszone
On installe la zone :
On démarre la zone et on se connecte dessus :
1.2.2 Installation du package BIND et de ses dépen- dances On décompresse l’archive puis on installe le package avec la commande pkgadd :
1.2.3 chrooter BIND Bien que le service DNS soit installé dans une zone dédiée, il est préfé- rable de rendre la tache d’un attaquant toujours plus difficile. Pour cela, on
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 1.2 Installation 105
Fig. 1.4 – Installation de la zone dnszone enferme le service dans une cage.
Définition 9 chroot est une commande qui permet d’isoler l’exécution d’un programme afin d’éviter qu’un fonctionnement non prévu de ce programme n’offre la possibilité à un individu malintentionné d’accéder à des fichiers (en règle générale la racine) sortant du périmètre d’exécution de l’application.
Dans un premier temps, on crée les répertoires pour chroot :
# jail=’/home/dns’; # umask 022; # mkdir $jail;
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 106 Serveur de nom
Fig. 1.5 – Démarrage et connexion dans la zone dnszone
Puis on crée les liens pour l’environnement chrooté : # rm /dns # ln -s $jail /dns # cd /dns; # mkdir -p {dev,opt,usr,var,etc}; # mkdir -p var/{run,log,named} usr/lib; # mkdir -p usr/local/etc # mkdir -p usr/share/lib/zoneinfo; On crée ensuite l’utilisateur, ainsi que son groupe, qui exécutera le service :
# groupadd named; # useradd -d /dns -s /bin/false -g named -c "BIND daemon" -m named # Create an identical user and group account within the chroot: # grep named /etc/passwd >> /dns/etc/passwd # grep named /etc/shadow >> /dns/etc/shadow # grep named /etc/group >> /dns/etc/group Enfin, on ajoute le répertoire /dns/usr/local/bin dans le PATH de root.
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 1.2 Installation 107
Fig. 1.6 – Installation de BIND
Il reste encore à copier les fichiers systèmes indispensables dans l’environ- nement chrooté :
# cp /etc/{syslog.conf,netconfig,nsswitch.conf,resolv.conf,TIMEZONE} /dns/etc # ldd /dns/usr/local/sbin/named # cp -p /usr/lib/libnsl.so.1 \ /usr/lib/libsocket.so.1 /usr/lib/libc.so.1 \ /usr/lib/libthread.so.1 /usr/lib/libpthread.so.1 \ /usr/lib/libdl.so.1 /usr/lib/libmp.so.2 \ /usr/lib/ld.so.1 /usr/lib/nss_files.so.1 \ /usr/platform/SUNW,UltraAX-i2/lib/libc_psr.so.1 \ /dns/usr/lib
Pour utiliser les nombres aléatoires, via /dev/random, on crée un point de montage loopback pour /dns :
# mkdir /dns/dev/random # mount -F lofs /dev/random /dns/dev/random
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 108 Serveur de nom
Enfin, dernière étape de l’installation, on crée le répertoire de données dns, habituellement dans /var/named : # mkdir -p /dns/var/named;
1.3 Paramétrage et sécurisation
1.3.1 Configurer le serveur DNS Avant toute chose, on génère les clefs 3 qui nous servirons pour DNSSEC :
# dnssec-keygen -a RSASHA1 -b 768 -n ZONE nom.mazone Deux fichiers sont issus de cette commande, contenant les clefs pour signer la zone. Ces fichiers sont Knom.mazone.*.key et Knom.mazone.*.private. Ces fichiers contiennent le nom de la clef (nom.mazone), l’algorithme utilisé (1 pour RSAMD5, 3 pour DSA, 5 pour RSASHA1,. . . ) et le drapeau de la clef.
Remarque 10 Chaque paire de clefs est spécifique à une zone dns.
Ensuite on signe la zone :
dnssec-signzone -o nom.mazone zone.nom.mazone Cette commande génère un fichier zone.nom.mazone qui sera référencé par le fichier de configuration de BIND, named.conf.
# cd /dns/etc # touch named.conf # chown root:named named.conf # chmod 640 named.conf
Afin que BIND réponde aux requêtes DNS des clients DNSSEC, dnssec- enable doit être paramétré.
chroot /dns /usr/local/sbin/named-checkconf /etc/named.conf chroot /dns /usr/local/sbin/named-checkzone local /var/named/localhost.zone chroot /dns /usr/local/sbin/named-checkzone local /var/named/localhost.rev
/dns/usr/local/sbin/named-checkzone test1.com /dns/var/named/test1.com 3. clefs de 768 bits avec RSASHA1
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 1.3 Paramétrage et sécurisation 109
1.3.2 Sécuriser BIND Afin de renforcer la sécurité de BIND, il faut définir des permissions strictes sur les fichiers de configuration. De même, les fichiers PID seront mis dans le répertoire /var/run et non dans /usr/local pour éviter que BIND puisse écrire dans /usr/etc. Cette localisa- tion est spécifiée dans le fichier named.conf.
# cd /dns # chgrp -R named * On supprime la permission d’écrire du groupe sur var, opt et usr :
# chmod -R g-w var; # chmod -R a-w opt usr; Pour les serveurs secondaires, on permet l’utilisateur named à créer et chan- ger les fichiers de données :
# chown -R root:named /dns/var/named; # chmod 770 /dns/var/named; Pour les serveurs primaires, on ne donne l’accès à l’utilisateur named qu’en lecture sur les fichiers de données :
# chown -R root:named /dns/var/named; # chmod 750 /dns/var/named; // dans le cas d’un serveur de production, // sinon 770 pour l’écriture des fichiers de // debug et dump. # chmod -R go-w /dns/var/named; On crée des fichiers pid et log vides :
# touch var/log/all.log var/run/named.pid; # chown named:named var/log/all.log var/run/named.pid; On donne l’accès en écriture de ces fichiers à l’utilisateur named :
# chgrp -R named /dns/var/log /dns/var/run; # chmod 770 /dns/var/run /dns/var/log; # chmod -R o-rwx /dns/var/run /dns/var/log; On autorise named à accéder au fichier de configuration BIND :
# chgrp named /dns/etc;
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 110 Serveur de nom
# chown root:named /dns/etc/named.conf; # chmod 640 /dns/etc/named.conf; # chmod 755 /dns/etc; On supprime les fichiers SUID/SGID s’ils existent encore :
# find . -type f -exec chmod ug-s {} \; Et enfin, on supprime les accès à tout utilisateur du répertoire /dns/usr :
# chmod -R o-rwx * /dns/usr Maintenant on va paramétrer Bind : Tout d’abord interdisons tout :
options { also-notify { none; }; allow-transfer { none; }; allow-query { none; }; }; – also-notify contient les DNS secondaires non officiels ce qui leur per- met d’être prévenus d’une mise à jour d’une zone – allow-transfer indique quelles sont les machines autorisées à effectuer un transfert de zone (a priori seuls les serveurs secondaires devraient l’être) – allow-query indique qui peut interroger le serveur pour une zone don- née.
Bind offre un mécanisme issu des systèmes d’exploitation : les ACL. Les ACL (access control lists) permettent de définir des ensembles de ma- chines et/ou de réseaux. Quatre ACL sont pré-définies : any, none, localhost et localnets. Elles correspondent respectivement à tout le monde, personne, le serveur seulement et l’ensemble des réseaux définis par les adresses IP et netmasks de la machine. On définit une ACL : acl name { address_match_list }; On cache la version de BIND et les informations sur le service : zone "bind" chaos { type master;
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 1.3 Paramétrage et sécurisation 111
file "bind"; allow-query { localhost ; }; };
1.3.3 Exécuter BIND Le service dns est maintenant configuré, il faut donc le lancer :
Pour observer l’activité de BIND :
# tail -f /var/adm/messages |grep named # tail -f /var/log/daemonlog |grep named Les journaux peuvent être placés dans /var/adm/messages ou sur un serveur distant en modifiant /etc/syslog.conf
Lancer BIND :
# /usr/sbin/chroot /dns /usr/local/sbin/named -u named Vérifier les erreurs :
1. examiner les journaux (syslog) 2. tester les exemples de domaines : /dns/usr/local/bin/dig @localhost 127.0.0.1 /dns/usr/local/bin/dig @localhost localhost /dns/usr/local/bin/dig @localhost localhost mx /dns/usr/local/bin/dig @localhost localhost ns /dns/usr/local/bin/dig @localhost www.test1.com /dns/usr/local/bin/dig @localhost www1.test1.com /dns/usr/local/bin/dig @localhost test1.com ns /dns/usr/local/bin/dig @localhost test1.com mx Pour que le démon se lance au démarrage de la machine, on effectue les opérations suivantes :
# ln -s /etc/init.d/dns /etc/rc2.d/S50dns # ln -s /etc/init.d/dns /etc/rc2.d/K50dns Remarque 11 Il ne faut pas oublié d’ouvrir les ports UDP 53 et TCP 53 (pour les transferts de zone) via le pare-feu dans la zone globale.
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 112 Serveur de nom
David Pauillac c novembre 2007 - OpenSolaris et la sécurité Chapitre 2 Serveur de messagerie
2.1 Généralités
Un serveur de messagerie électronique a pour vocation de transférer les messages électroniques d’un serveur à un autre. Un utilisateur n’est jamais en contact direct avec ce serveur mais utilise soit un client de messagerie, soit un navigateur web, qui se charge de contacter le serveur pour envoyer ou recevoir les messages.
La plupart des serveurs de messagerie possèdent ces deux fonctions (en- voi/réception), mais elles sont indépendantes et peuvent être dissociées phy- siquement en utilisant plusieurs serveurs.
2.1.1 Protocoles utilisés
L’envoi d’un courrier électronique se déroule généralement via le proto- cole SMTP qui est chargé de la communication entre le client et son serveur de messagerie. Puis c’est au serveur d’envoyer le message au serveur du des- tinataire, cette fonction est appelée Mail Transfer Agent en anglais, ou MTA.
La réception s’effectue elle aussi en deux temps. Le serveur doit recevoir le message du serveur de l’expéditeur, il doit donc gérer des problèmes comme un disque plein ou bien une corruption de la boîte aux lettres et signaler au serveur expéditeur toute erreur dans la délivrance. Il communique avec ce dernier par l’intermédiaire des canaux d’entrée-sortie standard ou bien par un protocole spécialisé comme LMTP (Local Mail Transfer Protocol). Cette fonction de réception est appelée Mail Delivery Agent en anglais, ou MDA. Le serveur doit renvoyer le message au destinataire final lorsque celui le dé- sire, généralement via le protocole POP3 1 ou IMAP.
1. qui sera utilisé ici
113113113 114 Serveur de messagerie
2.1.2 Application Il existe un certain nombre de serveurs de messagerie dont les plus connus sont qmail, sendmail, postfix, exim, Microsoft Exchange Server. . .
Postfix est l’un des serveurs de messagerie pour Unix les plus sécurisés, C’est donc ce serveur de messagerie qui servira pour ce chapitre.
Postfix[11] est disponible pour AIX, BSD, HP-UX, IRIX, LINUX, MacOS- X, Solaris, Tru64 UNIX et tout autre système UNIX. Il est distribué librement (ainsi que son code source) sous licence IBM Public License.
2.2 Installation
Pour cette application, il existe plusieurs packetages sur Internet ; la ver- sion utilisée ici est la distribution d’Ishan Dogan (http://ishan.dogan.ch/postfix).
Avant de procéder à l’installation de postfix, il est impératif de désinstal- ler sendmail :
# pkgrm SUNWsndmu # pkgrm SUNWsndmr Les packages nécessaires - sasl, openssl, berkeleydb4, openldap_rt et pcre - doivent être installés : via 2 blastwave[6] : pkg-get install sasl openssl berkeleydb4 openldap_rt pcre
Maintenant on peut installer le package de postfix :
#bunzip CNDpostfix-*.pkg.bz2 #pkgadd -d CNDpostfix-*.pkg Ce paquetage crée tout ce dont Postfix a besoin pour fonctionner, tels que les utilisateurs/groupes, les fichiers et leurs permissions associées.
2.3 Paramétrage et sécurisation
Je n’aborderai pas toute la configuration d’un serveur de messagerie - ceci dépasserait largement le cadre de ce document. Je préfère me focaliser sur sa 2. nécessite l’installation d’utilitaires pkg-get,. . .
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 2.3 Paramétrage et sécurisation 115 sécurisation via l’utilisation d’une authentification chiffrée (TLS).
Le Transport Layer Security ou TLS 3 permet une authentification basées sur les certificats ainsi que des sessions chiffrées.
2.3.1 Fonctionnement de l’implémentation de TLS dans Postfix Le diagramme ci-dessous représente le mode de fonctionnement de TLS dans Postfix. Les boîtes de couleur représentent les démons de Postfix, les autres des éléments stockés.
Fig. 2.1 – Fonctionnement de TLS
– smtpd implémente SMTP over TLS coté serveur – tlsmgr s’occupe du générateur de nombres pseudo-aléatoires (PRNG) utilisés par les moteurs TLS dans les processus smtpd et smtp, ainsi que les fichiers caches des clefs de session TLS. – smtp implémente SMTP over TLS coté client.
2.3.2 Configuration de TLS pour Postfix Le fichier de configuration est main.f. Il faut donc l’éditer et mettre les lignes suivantes : ################ #authentification au serveur SMTP TLS via une session chiffrée ################# 3. appelé aussi SSL
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 116 Serveur de messagerie
smtp_use_tls = yes smtpd_use_tls = yes smtp_tls_note_starttls_offer = yes smtpd_tls_key_file = /etc/postfix/ssl/privkey.pem smtpd_tls_cert_file = /etc/postfix/ssl/cacert.pem smtpd_tls_CAfile = /etc/postfix/ssl/smtpd.pem smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_session_cache_timeout = 3600s tls_random_source = dev:/dev/urandom Les fichiers privkey.pem, cacert.pem et smtpd.pem sont générés avec OpenSSL.
David Pauillac c novembre 2007 - OpenSolaris et la sécurité Chapitre 3 Serveur web et application J2EE
Bien qu’il soit tout à fait possible de déployer une application web J2EE sur un serveur d’application intégrant un serveur web (les serveurs d’applica- tion les plus courants offrent cette fonctionnalité par défaut), il est fortement recommandé de mettre un serveur web dédié en frontal. En effet, nous pouvons alors obtenir une architecture semblable à celle illus- trée par la figure 3.1. L’avantage de cette architecture est de pouvoir implé- menter facilement la répartition de charge sur les différents serveurs d’appli- cation et d’assurer une haute disponibilité du service.
Fig. 3.1 – Exemple d’architecture J2EE
On peut bien évidemment augmenter la disponibilité de cette plate-forme
117117117 118 Serveur web et application J2EE
en transférant les sessions (HTTP/HTTPS, EJB, etc.) sur un SAN, par exemple. Ainsi, même si un serveur doit s’arrêter, la session de l’utilisateur est conservée et peut être récupérée par un autre serveur.
Cependant, nous n’aborderons pas cette solution, complexe et coûteuse à mettre en place. Nous allons juste voir comment monter un cluster de serveur J2EE rapidement et simplement 1.
Nous utiliserons le serveur web Apache, très répandu, qui offre l’avantage de parfaitement s’interfacer avec les serveurs d’application basés sur Tomcat (JOnAS, JBoss,. . . ).
Dans l’exemple illustré par la figure 3.1, les différents services sont hé- bergés par des serveurs physiques distincts. Nous pouvons aussi utiliser le mécanisme de zones d’OpenSolaris, ce que nous ferons d’ailleurs ici. Nous allons donc créer les zones suivantes :
1. cette architecture convient à une large majorité de cas
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 3.1 Le serveur web 119
3.1 Le serveur web
3.1.1 Généralités Le serveur web Apache est le serveur web le plus répandu à ce jour (plus de 54% des serveurs web d’Internet). Sa configuration aisée, ses modules externes ainsi que le support de nombreuses plate-formes sont des atouts importants.
3.1.2 Installation Avant de procéder à l’installation du serveur, il ne faut pas oublier de supprimer tous les packages contenant une version du serveur web : – SUNWaclg – SUNWapch2* – SUNWapch*
Il faut maintenant créer la zone qui va accueillir le serveur web :
Fig. 3.2 – Création des répertoires pour la zone Web
Une fois connecté à la zone webzone, on installe depuis le package le serveur web Apache :
Il ne faut pas oublier les dépendances : – libgcc – expat – OpenSSL – libiconv.
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 120 Serveur web et application J2EE
Fig. 3.3 – Création de la zone Web
3.1.3 Paramétrage et sécurisation
La configuration du serveur Apache se fait depuis les fichiers httpd.conf et ssl.conf. Le tableau 3.1 indique les modules d’Apache à activer. Cette liste peut varier selon les besoins mais il est conseillé de ne pas en activer d’autre.
Avec le module mod_security, chrooter Apache devient très simple : il suffit d’ajouter la ligne suivante dans le fichier httpd.conf : SecChrootDir /chroot/apache
Pour installer ce module, il faut le compiler. Pour cela, nous créons une
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 3.1 Le serveur web 121
Nom du module Description security Permet de renforcer la sécurité d’Apache unique_id Indispensable pour le mod_security SSL Secure Socket Layer proxy_ajp Permet la communication avec un ser- veur d’application proxy_balancer Offre la fonction de répartition de charge entre plusieurs serveurs d’appli- cation proxy proxy_http rewrite Réécriture des URL mime_magic usertrack expires headers env setenvif negociation alias access log_config
Tab. 3.1 – Liste de modules Apache à activer nouvelle zone, clone de la zone webzone où nous installerons un compilateur (gcc) : Les paquetages suivants doivent être installés : – gcc – make – pcre – expat – OpenSSL – libiconv – apache
Afin de lancer la compilation, il faut éditer le fichier Makefile pour renseigner
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 122 Serveur web et application J2EE
le répertoire ServerRoot 2 et commenter tout ce qui concerne la bibliothèque libxml2.
2. information disponible dans le fichier de configuration d’Apache
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 3.1 Le serveur web 123
Fig. 3.4 – Installation du serveur web Apache
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 124 Serveur web et application J2EE
Fig. 3.5 – Apache en action
Fig. 3.6 – Création de la zone de compilation acte I
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 3.1 Le serveur web 125
Fig. 3.7 – Modification du fichier xml
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 126 Serveur web et application J2EE
Fig. 3.8 – Modification du fichier des zones
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 3.1 Le serveur web 127
Fig. 3.9 – On installe la zone de compilation
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 128 Serveur web et application J2EE
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 3.1 Le serveur web 129
Il faut ensuite modifier le PATH comme suit : # PATH=$PATH:/usr/local/bin:/usr/ccs/bin Et ajouter les liens symboliques 3 : # ln -s /usr/bin/sed /usr/local/bin/sed # ln -s /usr/bin/bash /usr/local/bin/bash Il ne reste plus qu’à compiler : # make && make install Depuis la zone globale, on peut récupérer le module et le copier dans la zone web : # cp /zones/webzoneGCC/usr/local/apache2/modules/mod_security2.so /zones/web/usr/local/apache2/modules/ On peut arrêter la zone de compilation # zoneadm -z webzoneGCC halt.
Dans la zone web, on édite le fichier de configuration d’Apache (/usr/local/apache2/conf/httpd.conf) et on ajoute la ligne suivante : LoadModule security2_module modules/mod_security2.so
Maintenant on configure Apache : Les informations fournies par le serveur sont primordiales pour une personne malintentionnée. Il est donc important de donner le minimum d’informa- tion. Pour ce faire, il faut modifier les lignes dans le fichier de configuration httpd.conf comme suit :
Port 80 User apache Group apache ServerAdmin [email protected] UseCanonicalName On ServerSignature Off HostnameLookups Off ServerTokens Prod SecServerSignature "Serveur toto version 1.0" Il faut aussi personnaliser toutes les pages d’erreurs afin que ces dernières ne puissent donner aucune information.
Pour lutter contre les attaques de type Déni de Service, il faut bien définir tous les besoins et les ressources disponibles afin de configurer correctement la partie performance d’Apache : Timeout 300 KeepAlive On MaxKeepAliveRequests 100 3. c’est un peu de la bidouille mais le programme make ne trouve pas ces exé- cutables dans /usr/bin !!
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 130 Serveur web et application J2EE
KeepAliveTimeout 15 MinSpareServers 5 MaxSpareServers 10 StartServers 5 MaxClients 2000 MaxRequestsPerChild 0 L’analyse de l’URL peut donner des informations importantes à un utilisa- teur malicieux. Pour contrer cette fuite d’informations, le module mod_security offre des solutions intéressantes : – SecFilterEngine : active/désactive le moteur de filtre – SecFilterCheckURLEncoding : vérifie si l’encodage de l’URL est valide – SecFilterCheckUnicodeEncoding : vérifie l’encodage Unicode – SecFilter : règle de filtrage
Ainsi on peut ajouter les lignes suivantes dans httpd.conf :
On ajoute ensuite les lignes suivantes dans le fichier de configuration d’Apache :
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 3.1 Le serveur web 131
SSLRandomSeed startup builtin SSLRandomSeed connect builtin
AddType application/x-x509-ca-cert .crt AddType application/x-pkcs7-crl .crl
SSLPassPhraseDialog builtin SSLSessionCache none SSLMutex default
SSLCertificateFile conf/ssl.crt/server.crt SSLCertificateKeyFile conf/ssl.key/server.key SSLCACertificatePath conf/ssl.crt SSLCACertificateFile conf/ssl.crt/ca-bundle.crt
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 CustomLog logs/ssl_request_log \ "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 132 Serveur web et application J2EE
Si le serveur que l’on configure doit rediriger toutes les requêtes vers HTTPS, on ajoute dans le fichier http.conf :
ProxyPass / balancer://lb/
3.2 Le serveur d’application
3.2.1 Généralités Définition 10 Un serveur d’application est un serveur sur lequel sont instal- lées des applications utilisées par les usagers. Ces applications sont chargées (on dit aussi déployées) sur le serveur d’application et accédées à distance par le réseau. [Source wikipedia]
Nous utiliserons le serveur d’application libre Tomcat développé par "The Apache Foundation". Issu du projet Jakarta, il implémente les spécifications de Sun Microsystem sur les servlets et les JSP (Java Servlet Pages). Il inclut aussi un serveur HTTP interne. Il est à la base de nombreux serveurs d’ap- plication.
3.2.2 Installation Celà devient une habitude, il faut créer la zone qui va accueillir le serveur d’application ; en fait nous allons en créer deux afin de simuler un cluster de serveurs d’application :
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 3.2 Le serveur d’application 133
Ensuite, pour chacune des zones, on se connecte et on installe le serveur d’application Tomcat : L’installation de Tomcat est des plus simples on décompresse l’archive conte- nant les binaires et. . . c’est tout ! Enfin presque, il faut définir la variable d’environnement CATALINA_HOME qui contiendra le chemin d’installation de Tomcat. # gunzip apache-tomcat-6.0.14.tar.gz | tar xvf CATALINA_HOME=/usr/local/apache-tomcat PATH=$PATH:$CATALINA_HOME/bin
3.2.3 Paramétrage et sécurisation La configuration d’un serveur d’application se fait via le fichier server.xml. Avant tout chose il faut configurer le serveur pour désactiver la partie web et configurer le connecteur ajp : ...
...
...
David Pauillac c novembre 2007 - OpenSolaris et la sécurité 134 Serveur web et application J2EE debug="0" protocol="AJP/1.3" serverAdresse="192.168.1.22" /> David Pauillac c novembre 2007 - OpenSolaris et la sécurité Chapitre 4 Annuaire LDAP 4.1 Généralités Selon le dictionnaire, un annuaire est un ouvrage publié chaque année, donnant la liste des membres d’une profession, des abonnés à un service, etc. Ainsi un annuaire est un recueil de données dont le but est de pouvoir re- trouver facilement des ressources à l’aide d’un certain nombre de critères. Par extension, un annuaire électronique est une base de données spéciali- sée permettant de stocker des informations de manière hiérarchique et offrant des mécanismes simples pour rechercher l’information, la trier et l’organiser. L’utilisation d’annuaire ne se limite pas à la recherche de personnes ou de ressources. En effet, un annuaire peut servir à – constituer un carnet d’adresse – authentifier des utilisateurs (grâce à un mot de passe) – définir les droits de chaque utilisateur – recenser des informations sur un parc matériel – décrire les applications disponibles. 4.1.1 Protocole utilisé Définition 11 LDAP : Lightweight Directory Access Protocol. Ce protocole est basé sur X500 et Directory Service (RFC1777). Le protocole LDAP a été conçu en partant du principe que les données seront le plus souvent lues, très peu modifiées. Ainsi il n’y a ni transaction ni rollback. C’est une structure hiérarchique qui a été retenue. Cette structure, sous forme d’arbre, est appelée Directory Information Tree (DIT). 135135135 136 Annuaire LDAP Fig. 4.1 – Structures LDAP Définition 12 LDIF : LDAP Data Interchange Format. Représente les en- trées LDAP au format texte, compréhensible par un être humain. Ceci permet de modifier des entrées LDAP (la commande ldmcat extrait la base de don- nées au format LDIF, la commande ldif2ldbm permet de convertir le LDIF en base de données ldbm. Exemple de LDIF : dn: uid=dpauillac,ou=User,dc=ustv,dc=fr uid: dpauillac cn: David Pauillac objectclass: account objectclass: posixAccount objectclass: top loginshell: /bin/bash uidnumber: 500 gidnumber: 120 homedirectory: /mnt/home/dpauillac userpassword: {crypt}KDnOoUYN7Neac 4.1.2 Application OpenLDAP est une implémentation libre du protocole LDAP développée par The OpenLDAP Project. Elle est publiée sous sa propre licence : OpenL- DAP Public License. Bien qu’officiellement distribuée uniquement sous forme de code source, on trouve des versions compilées pour GNU/Linux, BSD, David Pauillac c novembre 2007 - OpenSolaris et la sécurité 4.2 Installation 137 AIX, HP-UX, Mac OS X, Solaris, et Microsoft Windows (2000, XP). OpenLDAP est constitué des éléments suivants : – slapd (Stand-alone LDAP Daemon): démon LDAP autonome. Il écoute les connexions LDAP sur n’importe quel port (389 par défaut) et répond aux opérations LDAP qu’il reçoit via ces connexions – slurpd (Stand-alone LDAP Update Replication Daemon): démon de mise à jour autonome. Il est utilisé pour propager les changements effectués dans une base de donnée slapd aux autres bases. Si slapd est configuré pour produire des logs de réplication, slurpd lit ces logs et envoie les changements aux instances slapd esclaves 1 (dépendantes de l’instance principale, dite maîtresse) via le protocole LDAP.Comme slapd, slurpd est appelé au moment du boot – bibliothèques et utilitaires. Fig. 4.2 – Architecture de réplication d’OpenLDAP Pour la configuration, [5] est une source d’information indispensable. 4.2 Installation 4.2.1 Création de la zone dédiée Avant de commencer l’installation, il faut créer la zone ldapzone. Une fois la zone créée, on peut installer le package openldap disponible sur 1. voir 4.2 David Pauillac c novembre 2007 - OpenSolaris et la sécurité 138 Annuaire LDAP le site Sun Freeware avec la commande pkgadd. Voici un exemple du fichier de configuration d’OpenLDAP, slapd.conf : # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/slapd.at.conf include /etc/openldap/slapd.oc.conf schemacheck off pidfile /var/run/slapd.pid argsfile /var/run/slapd.args defaultaccess read access to attr=userpassword by self write by * read access to * by self write by dn=".+" read by * read ######################################################### # ldbm database definitions ######################################################### database ldbm suffix "dc=master2SSI, dc=ustv" rootdn "cn=professeur, dc=master2SSI, dc=ustv" rootpw {crypt}lAn4J@KmNp9 replica host=backup.master2SSI.ustv:389 binddn="cn=professeur,dc=master2SSI,dc=ustv" bindmethod=simple credentials=secret replogfile /var/lib/openldap/replication.log # cleartext passwords, especially for the rootdn, should # be avoid. See slapd.conf(5) for details. directory /var/lib/openldap/ David Pauillac c novembre 2007 - OpenSolaris et la sécurité 4.3 Paramétrage et sécurisation 139 4.2.2 Chrooter OpenLDAP On crée l’utilisateur ldap et son groupe associé. On lui interdit toute connexion (shell=/sbin/nologin). groupadd ldap useradd -s /sbin/nologin -d /var/lib/ldap -g ldap ldap On crée ensuite un répertoire pour le fichier pid : mkdir -p /var/run/slapd Il ne faut surtout pas oublier de modifier le fichier slapd.conf : pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args Il ne reste plus qu’à modifier les droits sur les répertoires utilisées par slpad : # Sur le répertoire de configuration chown -R ldap:ldap /etc/ldap # Sur le répertoire de stockage chown -R ldap:ldap /var/lib/ldap # Sur le répertoire d’exécution chown ldap:ldap /var/run/slapd 4.3 Paramétrage et sécurisation 4.3.1 Sécuriser la partie réseau 4.3.1.1 Restriction d’accès via le couple adresse/port Par défaut, slapd écoute sur toutes les adresses IPv4 et IPv6. Il peut être intéressant d’avoir un service écoutant uniquement sur un couple adresse/port sélectionné. On peut par exemple désactiver les accès distants (pour tester entre autre) : slapd -h ldap://127.0.0.1 Il est tout de même recommandé de laisser le pare-feu jouer le rôle de contrôle au niveau du réseau. 4.3.1.2 TCP-Wrappers OpenSolaris supporte TCP Wrappers. Ce dernier fournit un contrôle d’ac- cès au système basé sur des règles TCP/IP? Par exemple : slapd: 192.168.1.0/255.255.255.0 127.0.0.1 : ALLOW slapd: ALL : DENY autorisera seulement les connexions depuis le réseau privé 192.168.1.0 et David Pauillac c novembre 2007 - OpenSolaris et la sécurité 140 Annuaire LDAP localhost-127.0.0.1 pour accéder au service. 4.3.2 Intégrité et confidentialié Le protocole LDAP a la fâcheuse tendance a faire transiter des informa- tions sensibles (mot de passe par exemple) en clair sur le réseau. Pour éviter cela, on peut utiliser le protocole LDAP Sécurisé ou LDAPS. Ce dernier est basé sur TLS (Transport Layer Security) et permet d’assurer l’intégrité et la confidentialité des données. Pour configurer LDAPS, on génère tout d’abord les clefs de chiffrement : cd /usr/local/etc/openldap ln -s /usr/local/ssl/bin/openssl . ln -s /usr/local/ssl/misc/CA.pl . PATH=$PATH:‘pwd‘ CA.pl -newca CA.pl -newreq CA.pl -signreq mv newreq.pem ldapkey.pem chmod 0600 ldapkey.pem mv newcert.pem ldapcert.pem Ensuite on modifie le fichier slapd.conf : TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCertificateFile /usr/local/etc/openldap/ldapcert.pem TLSCertificateKeyFile /usr/local/etc/openldap/ldapkey.pem TLSCACertificateFile /usr/local/etc/openldap/demoCA/cacert.pem On lance ensuite le serveur ldap avec la commande suivante : slapd -h "ldap:/// ldaps:///" On peut forcer l’utilisation de ldaps avec la commande suivante : slapd -h "ldaps:///" 4.3.2.1 Security Strength Factors - SSF OpenLDAP utilise les SSF pour indiquer le niveau de protection du ser- veur. Un SSF à 0 indique qu’il n’y a aucune protection en place. Un SSF à 1 indique qu’une protection de l’intégrité est en place. Un SSF supérieur David Pauillac c novembre 2007 - OpenSolaris et la sécurité 4.3 Paramétrage et sécurisation 141 à 1, alors la valeur correspond (plus ou moins) à la longueur de la clef de chiffrement utilisée. Par exemple, pour le DES, la valeur sera 56, 3DES 112 et AES fournira les valeurs 128, 192 ou encore 256. On peut aussi augmenter le niveau de sécurité, par exemple : security ssf=1 update_ssf=256 signifie que pour toute opération, la protection de l’intégrité est requis et pour les opérations de mise à jour la protection de chiffrement AES 256 bits. 4.3.3 Méthodes d’authentification Par défaut, LDAP offre trois modes d’authentification : – anonyme ne requiert ni login ni mot de passe. Activé par défaut, pour le désactiver, on modifie le fichier de configuration et la valeur de disallow bind_anon – non authentifié, requiert un login mais pas de mot de passe. Peut être activé via le fichier de configuration à l’aide du paramètre allow bind_anon_cred – utilisateur/mot de passe. Pour l’activer on modifie la valeur de disallow bind_simple_unprotected. On peut aussi modifier celle de disallow bind_simple. Remarque 12 Les ports à ouvrir depuis le pare-feu de la zone globale sont : – 389 pour le LDAP – 636 pour le LDAPS David Pauillac c novembre 2007 - OpenSolaris et la sécurité 142 Annuaire LDAP David Pauillac c novembre 2007 - OpenSolaris et la sécurité Chapitre 5 Serveur de fichiers 5.1 Généralités Le partage de fichiers consiste à rendre disponible à travers le réseau le contenu d’un ou plusieurs répertoires. Le partage de fichiers peut poser des problèmes de sécurité, car, par définition, il donne accès aux autres utilisa- teurs au contenu d’une partie du disque dur. Remarque 13 Il est primordial de ne partager que des répertoires dont la révélation du contenu (voire la destruction) n’aura aucune conséquence im- portante voire capitale. Plusieurs éditeurs de logiciels ont développé des protocoles afin de mettre en place le partage de fichier via le réseau 1 : – NFS (Network File System - port tcp/2049) développé par Sun Micro- system essentiellement pour les machines Unix. Á partir de la version 4, le protocole inclut des mécanismes de chiffrement afin de renforcer la sécurité. – SMB (pour Server Message Block - port 139 ou 445) développé Micro- soft pour Windows. C’est ce dernier qui va nous intéresser. 5.1.1 Protocole utilisé En plus d’assurer le partage de fichier à travers le réseau, le protocole SMB est utilisé aussi pour les authentifications Microsoft - dans le cadre de 1. Liste non exhaustive. . . 143143143 144 Serveur de fichiers domaine par exemple 2. Les clients et serveurs SMB sous GNU/Linux et Unix en général, utilisent SAMBA pour traiter les échanges avec ce protocole. Ainsi il est possible d’uti- liser un serveur Unix pour gérer le partage de fichiers des stations Windows ou même en tant que contrôleur de domaine primaire ou secondaire. Fig. 5.1 – Principes de connexion du protocole SMB SMB possède deux modes d’authentification : le mode "share", dans le- quel il associe un mot de passe à une ressource (espace disque, imprimantes ...), et le mode "user", où il associe un mot de passe à un utilisateur. Cet utilisateur peut être aussi propriétaire d’une ressource. En mode " David Pauillac c novembre 2007 - OpenSolaris et la sécurité 5.1 Généralités 145 d’utilisateur. ATTENTION : les clients Microsoft Windows sont sujets à des problèmes de compatibilité avec les serveurs implémentant ce mode de sécu- rité. SMB utilise aussi deux modes pour l’envoi des mots de passe : chiffré ou non. C’est ce mode de fonctionne qui est la faiblesse de ce protocole : en effet le serveur donne l’information au client s’il supporte le chiffrement ou non. Si un individu malintentionné parvient à détecter un établissement de session SMB avant cet échange, il peut très bien détourner le flux et demander au client d’envoyer son mot de passe en clair et le recevoir. La sécurité au niveau du partage peut être implémentée d’une seule ma- nière alors que la sécurité au niveau de l’utilisateur peut elle être mise en oeuvre de trois manières différentes : 1. Mode de sécurité domaine : le serveur Samba force toutes les requêtes d’authentification à passer par les contrôleurs de domaine. Le serveur Samba se voit devenir un serveur membre du domaine en utilisant la directive suivante dans smb.conf : [GLOBAL] ... security = domain workgroup = GROUP ... 2. Mode de sécurité Active Directory : il est possible de faire partie du domaine en tant que membre natif d’Active Directory. Même si une politique de sécurité limite l’utilisation de protocoles d’authentification compatibles avec NT, le serveur Samba peut faire partie d’un ADS à l’aide de Kerberos. Samba en mode membre d’Active Directory peut accepter des tickets Kerberos. Pour cela, il faut modifier le fichier de configuration comme suit : [GLOBAL] ... security = ADS realm = TOTO.FR password server = kerberos.toto.fr ... 3. Mode de sécurité serveur : utilisé lorsque Samba n’était pas à même d’agir comme un serveur membre d’un domaine. NE PAS UTILISER. David Pauillac c novembre 2007 - OpenSolaris et la sécurité 146 Serveur de fichiers 5.1.2 Application Samba[12] est une suite logicielle libre qui, depuis 1992, permet d’émuler les protocoles SMB et CIFS pour les systèmes d’exploitations unix, linux et autres (VMS par exemple). Samba est disponible sous licence GNU General Public License. Le projet Samba fait partie de la Software Freedom Conservancy. Samba est scindé en deux programmes clefs : smbd et nmbd. Ils implé- mentent les quatre services de base de CIFS (nouveau nom de SMB) : – Services fichiers et imprimantes. Ces services sont fournis par smbd – Authentification et Authorisation. Gérés aussi par smbd, les deux modes d’authentification de SMB sont implémentés par le deamon Samba. – Résolution de noms (Netbios). Il peut prendre deux formes : broadcast ou point-à-point. Il est fourni par nmbd. L’implémentation de Microsoft de ce service est WINS. – Service d’annonce (navigation). Samba offre d’autres outils dont les plus courants sont : – smbclient ; la partie cliente de Samba, dispose d’une interface semblable aux utilitaires ftp. Il peut être utilisé depuis un système Unix pour se connecter et accéder aux partages SMB, transférer des fichiers et en imprimer – nmblookup ; client du service de nom NETBIOS. Il peut etre utilisé pour retrouver des noms Netbios sur le réseau, de la même manière que nslookup le fait avec les adresses IP – swat (Samba Web Administration Tool). Permet la configuration de Samba à distance via un navigateur web. Samba dispose aussi de son propre système de fichiers, smbfs mais ne fonctionne que sur les systèmes GNU/Linux. 5.2 Installation Comme c’est devenue une habitude, on crée la zone smbzone. David Pauillac c novembre 2007 - OpenSolaris et la sécurité 5.3 Paramétrage et sécurisation 147 Fig. 5.2 – Création des répertoires pour la zone de Samba Ensuite, on installe Samba depuis le package (toujours disponible depuis sunfreeware) : # pkgadd -d samba-3.0.25a-sol10-x86-local Et les packages nécessaires : # pkgadd -d libgcc-3.4.6-sol10-x86-local # pkgadd -d libiconv-1.11-sol10-x86-local # pkgadd -d popt-1.7-sol10-intel-local # pkgadd -d ncurses-5.6-sol10-x86-local # pkgadd -d readline-5.2-sol10-x86-local La configuration se fait via le fichier smb.conf dont un exemple simple suit : [global] workgroup = MASTER2SSI netbios name = DAV [share1] path = /tmp [share2] path = /share comment = Mon premier partage Samba 5.3 Paramétrage et sécurisation On va mettre les services Samba dans une cage (cf. ). On modifie ensuite le fichier passwd de la cage pour supprimer tous les comptes utilisateurs systèmes. David Pauillac c novembre 2007 - OpenSolaris et la sécurité 148 Serveur de fichiers Fig. 5.3 – Création de la zone de Samba David Pauillac c novembre 2007 - OpenSolaris et la sécurité TOME III OPENSOLARIS POUR UNE STATION DE TRAVAIL 149149149 150 David Pauillac c novembre 2007 - OpenSolaris et la sécurité Première partie Déployer OpenSolaris 151151151 Chapitre Premier Configurer 153153153 154 Configurer David Pauillac c novembre 2007 - OpenSolaris et la sécurité Chapitre 2 Déployer Au même titre qu’il existe Norton GHOST pour Windows, le monde du libre dispose aussi d’un logiciel de création d’image disque, G4U (Ghost for Unix) disponible sur le site officiel (http://www.feyrer.de/g4u/). Du fait que G4U lise les systèmes de fichiers bit à bit, en incluant le MBR, le boot record, la table des partitions et les partitions elles-mêmes, tous les systèmes d’exploitation et les systèmes de fichiers sont supportés. Il peut être utilisé depuis un CD-ROM bootable. Pour créer une image : Booter sur le CD-ROM, puis configurer le réseau : # ifconfig -a //permet de récupérer le nom de l’interface réseau # ifconfig xx0 @IP netmask 255.255.255.0// configuration de l’adresse IP # route add default @IP // configuration de la passerelle. Si nous admettons qu’un deuxième disque soit installé pour stocker l’image disque (we), avec 3 partitions (1 pour /boot, 1 pour /, 1 pour la swap) la procédure est la suivante : # copypart wd0a we0a // copie de la partition /boot # copypart wd0b we0b // copie de la partition /home # copypart wd1a we0c // copie de la partition swap Pour réinstaller l’image, les commandes sont identiques, seuls les paramètres sont inversés : # copypart we0a wd0a // copie de la partition /boot # copypart we0b wd0b // copie de la partition /home # copypart we0c wd1a // copie de la partition swap Il est aussi possible d’utiliser un serveur ftp pour n’avoir qu’une seule image, la commande est alors : 155155155 156 Déployer # uploadpart ftp.server.ctirh.dpmm.marine.def boot.gz wd0a // pour la création de l’image # slurppart ftp.server.ctirh.dpmm.marine.def boot.gz wd0a Remarque 14 Les commandes uploaddisk, slurpdisk et copydisk permettent de travailler sur des disques entiers. David Pauillac c novembre 2007 - OpenSolaris et la sécurité Seconde partie La labellisation 157157157 Chapitre Premier Les principes 159159159 160 Les principes David Pauillac c novembre 2007 - OpenSolaris et la sécurité Chapitre 2 La mise en place 161161161 162 La mise en place David Pauillac c novembre 2007 - OpenSolaris et la sécurité Chapitre 3 L’administration 163163163 164 L’administration David Pauillac c novembre 2007 - OpenSolaris et la sécurité Annexes 165165165 Annexe Premier Exemple de script ndd #!/sbin/sh # # # INTRODUCTION # # Ce script modifie certains paramètres réseau afin de prévenir # quelques attaques réseau. L’installation de ce script changera # le démarrage du système. Pour plus d’information sur les paramétrages # de ce script, voir l’article "Solaris Operating Environment # Network Settings for Security - update for 8" disponible à # l’adresse : # # http://www.sun.com/blueprints/1200/network-updt1.pdf # # Le script ayant servi de base à celui-ci est disponible ici : # # http://www.sun.com/blueprints/tools/ # # Initialement écrit pour les versions 2.5.1, 2.6, 7 et 8 de Solaris, # il a été modifié et testé sur OpenSolaris et de ce fait n’est plus # compatible avec les versions précédentes de Solaris. # # ATTENTION # # Ce script produit des changements sur le comportement réseau du # système. # Les paramètres de ce script sont considérés comme sûrs d’un point # de vue de la sécurité. Cependant, certains pourraient ne pas # fonctionner correctement dans votre environnement. Les commentaires # de chaque paramètre expliquent l’effet que ce dernier aura sur le # système. 167167167 168 Exemple de script ndd # # INSTALLATION # # # cp