| Guide d'administration de Solaris Security Toolkit 4.1 |     |
| Guide d'administration de Solaris Security Toolkit 4.1 | |
| C H A P I T R E 2 |
|
Sécurisation de systèmes : application d'une méthodologie |
Ce chapitre décrit une méthodologie pour la sécurisation de systèmes. Il propose une méthode à appliquer avant de sécuriser des systèmes à l'aide du logiciel Solaris Security Toolkit.
Ce chapitre traite des points suivants :
Une bonne planification est essentielle à la réussite de la sécurisation de systèmes à l'aide du logiciel Solaris Security Toolkit. La phase de planification construit un profil Solaris Security Toolkit pour le système, basé sur les stratégies et les normes de sécurité de l'entreprise, ainsi que sur les conditions de fonctionnement et d'application du système. Cette phase comprend les tâches suivantes :
Même si elles ne sont pas décrites dans cet ouvrage, il est bon de faire certaines considérations sur la compréhension des risques, la maîtrise de l'infrastructure et de ses besoins en matière de sécurité, l'imputabilité, le logging et l'audit de l'usage.
Cette section présente certains facteurs qui doivent être pris en compte et parfaitement compris avant toute tentative de sécurisation d'un système. Evaluez soigneusement les risques et les avantages afin de déterminer quelles sont les actions les plus appropriées à votre entreprise.
Pour le durcissement de systèmes, vous devez prendre certaines précautions afin d'assurer le fonctionnement du système après l'implémentation du logiciel Solaris Security Toolkit. De plus, il est important d'optimiser la procédure pour limiter au minimum les temps d'arrêt.
1. Description des besoins des services et des applications sur le système.
Vous devez identifier les services et les applications exécutés sur un système avant d'exécuter le logiciel Solaris Security Toolkit. Toutes dépendances associées aux services et aux applications doivent être énumérées afin que la configuration du logiciel Solaris Security Toolkit puisse être ajustée. L'absence d'énumération pourrait causer la désactivation des services nécessaires ou empêcher leur démarrage. Alors que la plupart des modifications apportées par le logiciel Solaris Security Toolkit peuvent être annulées, le développement d'un profil correct avant l'installation limite les temps morts lors de l'implémentation du logiciel Solaris Security Toolkit.
2. Prise en compte du fait que le système doit être déconnecté et réinitialisé.
Pour que les modifications apportées par le logiciel Solaris Security Toolkit prennent effet, le système doit être réinitialisé. Selon l'importance vitale du système, les services qu'il fournit et la disponibilité d'une fenêtre de maintenance, l'implémentation du logiciel peut poser plus ou moins de problèmes à une entreprise. Pour prendre une décision, il faut d'abord évaluer attentivement le coût d'un arrêt de l'activité par rapport aux risques encourus si la sécurité n'est pas augmentée.
3. Il peut être nécessaire de réinitialiser plusieurs fois un système pour vérifier son fonctionnement.
Dans la mesure du possible, effectuez toutes les modifications sur des systèmes hors production avant d'implémenter les systèmes dans une configuration stratégique. Ceci n'est pas toujours possible ; par exemple, en l'absence de matériel ou de logiciel suffisant pour répliquer l'environnement cible. Des tests doivent être accomplis avant et après l'installation du logiciel Solaris Security Toolkit. Des dépendances non identifiées nécessitant un dépannage après le durcissement du système pourraient être présentes. Dans la plupart des cas, ces problèmes peuvent être résolus assez rapidement en utilisant les techniques décrites dans ce chapitre. En cas de problèmes de fonctionnement après l'installation du logiciel Solaris Security Toolkit, il peut être nécessaire de réinitialiser plusieurs fois la plate-forme, soit pour annuler les effets du logiciel Solaris Security Toolkit, soit pour ajouter d'autres modifications à la configuration de sécurité du système afin de supporter et d'activer les fonctionnalités manquantes.
4. La sécurisation d'une plate-forme ne se limite pas au durcissement et à la réduction.
Si vous envisagez la mise à niveau de la configuration de votre système pour améliorer sa sécurité, il est essentiel de comprendre que le durcissement et la réduction d'une plate-forme ne représente qu'une fraction des tâches nécessaires à la sécurisation d'un système, de services et de données. Ce document ne traite pas des mesures et contrôles additionnels ; il est toutefois conseillé de considérer des questions telles que la gestion des comptes, la gestion des privilèges, l'intégrité des systèmes de fichiers et des données, les contrôles d'accès basés sur les hôtes, la détection des intrusions, l'exploration et l'analyse de la vulnérabilité et la sécurité des applications.
5. Le système pourrait avoir déjà été exploité ou avoir des vulnérabilités exploitables.
La plate-forme en cours de durcissement pourrait déjà avoir fait l'objet d'une attaque. Le logiciel Solaris Security Toolkit a probablement été implémenté trop tard pour assurer une protection contre les vulnérabilités exploitables. Dans ce cas, réinstallez le système puis installez et utilisez le logiciel Solaris Security Toolkit pour le sécuriser.
Le premier pas pour la sécurisation d'un système est la compréhension des principales stratégies de sécurité, des normes et des documents de référence adoptés par votre entreprise en matière de sécurité de plate-forme. Déterminez le profil de Solaris Security Toolkit à partir de ces documents, qui décrivent les besoins et les mesures à mettre en oeuvre pour tous les systèmes de votre entreprise. Si votre entreprise ne dispose pas de documentation, sa préparation augmentera votre capacité à personnaliser le logiciel Solaris Security Toolkit (SST).
|
Remarque - Lorsque vous recherchez ces documents, n'oubliez pas que vous pouvez trouver du matériel dans les exercices pratiques ou autre documentation. |
Pour de plus amples informations sur les stratégies en matière de sécurité, reportez-vous à l'article Sun BluePrints OnLine « Developing a Security Policy ». Ce document vous permettra de mieux comprendre le rôle des stratégies de sécurité à l'échelle de l'entreprise.
Les deux exemples qui suivent illustrent comment les stratégies de sécurité peuvent avoir des conséquences directes sur la configuration du profil de Solaris Security Toolkit.
Stratégie - Tous les utilisateurs doivent obligatoirement changer leurs mots de passe tous les 30 jours.
Impact du profil - Le logiciel Solaris Security Toolkit peut être configuré pour permettre le vieillissement du mot de passe. Par défaut, le logiciel Solaris Security Toolkit accepte les mots de passe pendant une période maximale de 8 semaines (56 jours). Pour se conformer à la stratégie, il faut changer le profil du logiciel Solaris Security Toolkit. Reportez-vous au manuel le Solaris Security Toolkit 4.1 Reference Manual.
Même si, par défaut, le logiciel Solaris Security Toolkit permet le vieillissement du mot de passe lorsqu'il est exécuté sur un système, cette modification n'affecte pas les utilisateurs existants. Pour permettre le vieillissement du mot de passe des utilisateurs existants, utilisez la commande passwd(1) sur chaque compte utilisateur.
Cette tâche permet d'assurer que les services restent fonctionnels après le durcissement du système. Cette tâche comprend les étapes suivantes :
Inventaire des applications, services et fonctions opérationnelles ou de gestion. Cet inventaire est nécessaire pour déterminer quel logiciel est en cours d'utilisation sur un système. Les systèmes sont souvent dotés de logiciels non utilisés et de logiciels qui ne prennent pas en charge les fonctions de l'entreprise.
Les logiciels installés sur les systèmes doivent autant que possible être réduits au minimum. En effet, les logiciels non utilisés pour la prise en charge d'une fonction de l'entreprise ne doivent pas être installés. Les applications inutiles augmentent d'autant les failles du système et donc ses vulnérabilités exploitables. Par ailleurs, davantage de logiciels sur un système équivaut généralement à davantage de patchs à appliquer. Pour de plus amples informations sur la réduction du SE Solaris, reportez-vous à l'article Sun BluePrints OnLine « Minimizing the Solaris Operating Environment for Security ».
Lors de l'inventaire des logiciels, pensez à inclure les composants d'infrastructure, tels que les logiciels de gestion, de contrôle et de sauvegarde, en plus des applications résidant sur le système.
Après avoir terminé un inventaire des applications et des services, déterminez si des composants quelconques ont des dépendances qui pourraient avoir une incidence sur le durcissement. De nombreuses applications tierce partie n'utilisent pas directement les services fournis par le SE Solaris. Vous trouverez, dans les sections qui suivent, des informations utiles sur ces applications.
Il est important de comprendre quelles bibliothèques sont nécessaires pour la prise en charge d'une application. Ceci est surtout utile en cas de débogage, mais l'est également pour la préparation d'un système avant son durcissement. Si vous ne connaissez pas l'état d'un système, recueillez autant d'informations que possible de manière à bien comprendre certains faits, tels que les dépendances logicielles.
Pour déterminer quelles bibliothèques sont utilisées par une application, vous avez le choix entre trois méthodes, selon la version du SE Solaris installée :
Prenons un exemple : détermination des bibliothèques nécessaires au support du logiciel d'un serveur DNS.
Pour la collecte d'informations sur un objet système de fichiers, utilisez la commande /usr/bin/ldd.
Pour la collecte d'informations depuis un processus en cours, utilisez la commande /usr/proc/bin/pldd (disponible sur les SE Solaris versions 8 et 9).
La commande pldd montre les bibliothèques partagées qui sont chargées de manière dynamique par l'application, en plus des bibliothèques par rapport auxquelles est reliée l'application. Cette information peut également être obtenue en utilisant la commande truss suivante.
Ce type de sortie contient l'identificateur de processus, l'appel système (dans ce cas open) et ses arguments, ainsi que la valeur renvoyée par l'appel système. En utilisant la valeur renvoyée, il est clair que l'appel système réussit à trouver et ouvrir la librairie partagée.
Après avoir pris connaissance des bibliothèques partagées, utilisez la commande suivante pour savoir à quels packages du SE Solaris elles appartiennent.
# grep `/usr/lib/dns/cylink.so.1' /var/sadm/install/contents /usr/lib/dns/cylink.so.1 f none 0755 root bin 63532 24346 \ 1018126408 SUNWcsl |
La sortie de la commande indique que la bibliothèque partagée en question appartient au package SUNWcsl (Core, Shared Libs). Cette procédure est particulièrement utile lors de la réduction d'une plate-forme, car elle permet d'identifier les packages requis pour la prise en charge d'une application ou d'un service.
Les fichiers de configuration peuvent également être utilisés pour la collecte d'informations. Cette méthode a des conséquences plus directes sur la manière dont un système est durci du fait que les fichiers de configuration peuvent être renommés ou supprimés pour désactiver des services. Pour plus d'informations, reportez-vous au manuel le Solaris Security Toolkit 4.1 Reference Manual.
Pour savoir si un fichier de configuration est en cours d'utilisation, utilisez la commande truss.
Dans cet exemple, le service DNS utilise des fichiers de configuration, tels que/etc/named.conf. Comme dans l'exemple précédent, si la valeur renvoyée pour un service indique une erreur, il est probable qu'il y ait un problème. Une documentation attentive des résultats avant et après le durcissement peut contribuer à l'accélération de l'ensemble du processus de validation.
Cette catégorie comprend des structures ou des métaservices sur lesquels sont construites des applications plus grosses et plus complexes. Les structures types appartenant à cette catégorie sont les services d'attribution de noms (par exemple, NIS, NIS+ et LDAP), les services d'authentification (par exemple, Kerberos et LDAP) et des services tels que le portmapper utilisé par les RPC.
On ne sait pas toujours avec précision quand une application dépend de ces types de services. Lorsque des ajustements particuliers sont nécessaires pour configurer une application, par exemple lorsqu'il faut l'ajouter à un domaine Kerberos, on connaît parfaitement la dépendance. Dans certains cas, les dépendances des applications ne nécessitent aucune tâche supplémentaire ce qui fait que la dépendance actuelle peut ne pas être documentée par le vendeur.
Le RPC portmapper en est un exemple type. Par défaut, le logiciel Solaris Security Toolkit désactive le RPC portmapper. Cette opération peut donner lieu à des comportements inattendus dans d'autres services reposant sur ce service. D'après les expériences passées, l'abandon, l'interruption ou l'échec des services dépend de la qualité d'écriture du code de l'application pour gérer les exceptions. Pour savoir si une application utilise le RPC portmapper, utilisez la commande rpcinfo. Par exemple :
Les informations figurant dans la colonne du service proviennent du fichier /etc/rpc et/ou d'un service d'attribution de noms configuré, tel que LDAP.
Si ce fichier ne possède pas d'entrée pour un service, comme c'est souvent le cas pour les produits tiers, le champ du service peut être vide. L'identification des applications enregistrées par d'autres applications devient donc encore plus difficile.
Par exemple, prenons la commande rusers. Cette commande repose sur le service RPC portmapper. Si le RPC portmapper n'est pas en cours d'exécution, il semble que la commande rusers s'interrompt. Après un délai d'attente, le programme renvoie le message d'erreur suivant :
Ce problème survient parce que le programme est dans l'impossibilité de communiquer avec le service. Toutefois, après le démarrage du service RPC portmapper depuis /etc/init.d/rpc, le programme renvoie immédiatement son résultat.
Comme autre exemple, prenons le cas où le service RPC portmapper est en cours d'exécution alors que le service rusers n'est pas configuré pour fonctionner. Dans ce cas, la réponse générée est complètement différente et relativement facile à valider.
Vu que la commande rpcinfo ne possède pas de registre pour le service rusers, il est sage de supposer que le service n'est pas configuré pour être exécuté. Cette hypothèse est validée en regardant l'entrée du service dans le fichier /etc/inet/inetd.conf.
# grep rusers /etc/inet/inetd.conf # rusersd/2-3 tli rpc/datagram_v,circuit_v wait root /usr/lib/netsvc/rusers/rpc.rusersd rpc.rusersd |
La marque de commentaire (#) au début de la ligne du service indique que le service rusers est désactivé. Pour activer le service, éliminez le commentaire de la ligne et envoyez un signal SIGHUP au processus /usr/sbin/inetd, comme suit.
Pour déterminer si une application utilise RPC, il est également possible d'utiliser la commande ldd décrite ci-avant.
L'entrée pour librpcsvc.so.1 indique, avec le nom de fichier, que ce service repose sur le RPC portmapper.
En plus du RPC portmapper, les applications peuvent également reposer sur d'autres services OS courants, tels que FTP, SNMP ou NFS. Vous pouvez utiliser des techniques similaires pour déboguer ces services et déterminer s'ils sont effectivement nécessaires pour la prise en charge d'une fonction donnée de l'entreprise. L'une des méthodes consiste à utiliser la commande netstat comme suit.
Cette commande renvoie une liste de services qui sont en cours d'utilisation ou ont récemment été utilisés, par exemple :
Dans cet exemple, de nombreux services sont utilisés, mais on ne sait pas quels ports appartiennent à quels services ou quelles applications. Pour le savoir, on peut inspecter les processus à l'aide de la commande pfiles (disponible sur les SE Solaris versions 8 et 9).
# for pid in `ps -aeo pid | grep -v PID`; do > pfiles ${pid} | egrep "^${pid}:|sockname:" > done |
Ces dépendances peuvent être déterminées plus efficacement en utilisant la commande lsof (pour obtenir la liste des fichiers ouverts). Cette commande permet de savoir quels processus utilisent quels fichiers et quels ports. Par exemple, pour savoir quels processus de l'exemple précédent utilisent le port 35047, lancez la commande suivante.
La sortie delsof indique que le port 35047 est utilisé pour la communication entre les processus dtexec et ttsession.
L'utilisation du programme lsof peut vous permettre de déterminer plus rapidement les dépendances entre systèmes ou entre applications nécessitant l'emploi d'un système de fichiers ou d'un réseau. Presque tout ce qui est signalé dans cette section peut être capturé à l'aide d'options du programmelsof.
Vous pouvez télécharger le programme lsof depuis l'adresse :
ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/
Une fois la phase de planification et de préparation terminée, développez et implémentez un profil de sécurité. Un profil de sécurité consiste en un pilote de durcissement comme, par exemple, nom-hardening.driver, et tous les pilotes, scripts et fichiers nécessaires pour l'implémentation des stratégies de sécurité spécifiques à votre site.
Personnalisez l'un des profils de sécurité fournis avec le logiciel Solaris Security Toolkit ou développez-en un nouveau. Les stratégies, les normes et les besoins en applications diffèrent, même légèrement, d'une entreprise à l'autre.
Pour personnaliser le logiciel Solaris Security Toolkit, ajustez ses actions à l'aide de scripts finish, de scripts audit, de variables d'environnement, de fonctions de structure et de modèles de fichiers.
Vous trouverez de plus amples informations dans les chapitres suivants :
Si nécessaire, consultez les chapitres relatifs aux scripts, aux fonctions de structure, aux variables d'environnement et aux fichiers du Solaris Security Toolkit 4.1 Reference Manual. Parmi les variables d'environnement, vous pouvez vouloir personnaliser JASS_FILES et JASS_SCRIPTS.
Pour l'application de normes communes à la majorité des plates-formes, tout en préservant des différentes spécifiques à chaque plate-forme, utilisez une technique connue comme profils de sécurité imbriqués ou hiérarchiques. Pour plus d'informations, reportez-vous au manuel le Solaris Security Toolkit 4.1 Reference Manual. Comparez le profil de sécurité résultant des stratégies, normes et besoins de votre entreprise pour éviter que des modifications ne soient apportées par inadvertance ou par erreur.
La procédure d'installation du logiciel Solaris Security Toolkit est la même que le système soit déployé ou nouveau. Pour des instructions détaillées, consultez le Chapitre 3.
Pour les systèmes déployés, certains cas particuliers peuvent rendre l'installation plus simple et plus rapide. Ces cas ne sont pas centrés sur le processus de durcissement, mais sur les tâches qui précèdent et suivent l'installation.
Avant le durcissement d'un système déployé, vous devez étudier et planifier deux tâches importantes--sauvegarde et vérification. Ces tâches facilitent la détermination de l'état du système déployé et la résolution des problèmes de configuration pouvant se poser avant le durcissement du système.
Cette tâche est centrée sur la planification prévisionnelle. En cas de problème, il est indispensable que la configuration et les données du système soient archivées sous une forme ou une autre. Vous devez sauvegarder le système, vous assurer que la copie de sauvegarde peut être lue et confirmer que son contenu peut être récupéré. Cette opération doit être accomplie avant toute modification significative de la configuration d'un système.
La vérification est une tâche presque aussi importante que la sauvegarde. La vérification permet d'assurer la stabilité et le fonctionnement du système avant l'implémentation de modifications de configuration, telles que les modifications introduites par le processus de durcissement. Ce processus de vérification comporte une réinitialisation suivie de tests positifs des applications ou services. Bien qu'il soit préférable d'avoir un programme de test et d'acceptation bien défini, la documentation peut ne pas être toujours disponible. Dans ce cas, testez raisonnablement le système en fonction de son type d'utilisation. Cette tâche a pour objectif d'assurer que la configuration utilisée correspond bien à la configuration enregistrée.
Analysez tous les messages d'erreur ou d'avertissement qui s'affiche à l'initialisation du système ou au démarrage d'une application. Si vous n'arrivez pas à corriger les erreurs, consignez-les de manière à éviter qu'elle ne soient considérées comme des problèmes potentiels au cours du processus de durcissement. Lorsque vous examinez les fichiers journaux, n'oubliez pas d'inclure les journaux de système, service et application tels que :
Cette tâche est terminée quand vous redémarrez le système sans rencontrer de messages d'erreur ou d'avertissement ni d'erreurs ou d'anomalies inconnues (toutes les erreurs ou anomalies connues sont documentées). Le système doit redémarrer dans un état connu et stable. Au cours d'une vérification, si vous découvrez que les configurations en cours d'utilisation et stockées ne sont pas les mêmes, réévaluez les stratégies et processus de contrôle des changements de votre entreprise pour identifier le problème à l'origine de cette situation.
Les tâches suivant l'installation sont un prolongement des tâches préalables à l'installation. Leur objectif est d'assurer que le processus de durcissement n'a pas causé de nouvelles défaillances dans le système ou les applications. Cette tâche consiste avant tout à examiner les fichiers journaux du système et des applications. Les fichiers journaux créés après le durcissement et la réinitialisation doivent être similaires à ceux qui avaient été collectés avant le durcissement du système. Ils peuvent parfois contenir moins de messages parce que les services démarrés sont moins nombreux. Mais il est fondamental qu'il ne contiennent pas de nouveaux messages d'erreur ou d'avertissement.
Après avoir examiné les fichiers journaux, testez les fonctionnalités, parce que certaines applications pourraient rencontrer des problèmes sans consigner de messages dans le fichier journal. Consultez la section suivante pour des informations détaillées sur la vérification.
La dernière tâche de ce processus consiste à vérifier que les applications et services offerts par le système fonctionnent tous correctement. Cette tâche vérifie également que le profil de sécurité a été correctement implémenté en conformité avec les stratégies de l'entreprise en matière de sécurité. Effectuez cette tâche avec soin et immédiatement après la réinitialisation de la plate-forme durcie, afin d'assurer la détection des anomalies ou problèmes éventuels et leur correction immédiate. Cette procédure comporte deux tâches : vérification de l'installation du profil de sécurité et vérification du fonctionnement des applications et des services.
Pour vérifier que le logiciel Solaris Security Toolkit a installé correctement le profil de sécurité et sans erreurs, examinez le fichier journal de l'installation. Ce fichier est installé dans JASS_REPOSITORY/jass-install-log.txt.
Après avoir vérifié que le profil a été installé, évaluez la configuration de sécurité du système. Effectuez un examen manuel ou utilisez un outil pour automatiser le processus.
Pour vérifier les applications et les services du processus, lancer un plan de test et d'acceptation. Il teste les différents composants d'un système ou d'une application et s'assure de leur disponibilité et de leur bon état de marche. En l'absence d'un tel plan, testez raisonnablement le système en vous basant sur la manière dont il est utilisé. L'objectif est de s'assurer que le durcissement n'a pas altéré le fonctionnement des applications ou services.
Si vous découvrez qu'une application ou un service ne fonctionne pas correctement après le durcissement du système, recherchez la cause du problème en examinant les fichiers journaux de cette application. Le plus souvent, vous pouvez utiliser la commande truss pour localiser le problème. Un fois le problème localisé, vous pouvez le cibler et remonter à la modification apportée par le logiciel Solaris Security Toolkit.
Une erreur commune à de nombreuse entreprises est de considérer la sécurité qu'au moment de l'installation, et d'y revenir rarement voire jamais. La maintenance de la sécurité est un processus permanent. La sécurité d'un système doit être vérifiée périodiquement.
La maintenance d'un système sécurisé requiert le maximum d'attention étant donné que la configuration de sécurité par défaut de tout système tend à s'ouvrir de plus en plus avec le temps. Par exemple, les failles du systèmes deviennent connues. Les indications ci-après vous serviront de guide pour la maintenance de la sécurité.
Le logiciel Solaris Security Toolkit peut vous assister lors de l'application de patchs, parce qu'il supports les exécution répétées sur un système de sorte que vous pouvez sécuriser le système après l'application de patchs. Exécutez le logiciel après l'installation de chaque patch, en utilisant les pilotes appropriés, pour toujours assurer la cohérence de votre configuration avec vos stratégies en matière de sécurité. Effectuez également un examen manuel du système, parce que la version de Solaris Security Toolkit utilisée pourrait ne pas prendre en charge les nouvelles fonctionnalités ajoutées par les patchs installés.
Le logiciel Solaris Security Toolkit incorpore des profils de sécurité par défaut que vous pouvez utiliser comme point de départ.
| Guide d'administration de Solaris Security Toolkit 4.1 | 817-7652-10 | |
Copyright © 2004, Sun Microsystems, Inc. Tous droits réservés.