Installation et sécurisation d'une station Debian 3.0 stable
Installation et sécurisation d'une station Debian 3.0 stable15/05/2004 5. SECURISATION APPROFONDIE 5.1. Installation du patch OpenWall 5.2. Installation du wrapper libsafe 5.3. Conserver une empreinte de vérification d'intégrité du système 5.4. Gestion des quotas 5.5. Sécurisation PAM : Gestion des limites 5.6. Disquette de secours avec Tomsrtbt 5.7. Installation de Prelude-Lml pour une remontee de log securisée vers un serveur centralisé 5.7.1. Configuration initiale 5.8. Sécurisation approfondie avec GrSecurity 5.8.1. Patch du noyau : Compilation et installation 5.8.2. Configuration du système 5.8.3. Installation et configuration de Gradm et des ACLs
NDR : Vous devez savoir ce que vous faites dans les parties présentées ici.
Le patch est téléchargeable sur http://www.openwall.com/linux/
Deux fichiers ne passent pas avec notre noyau 2.2.20 :
=> Mais les modifications manuelles sont triviales. On prépare la compilation du nouveau noyau :
Si vous lancez make menuconfig à ce moment, vous trouverez un nouveau menu
nomme 'Security options'. Deux options demeurent non-activées après le passage
du patch :
'Restricted /proc'
'Destroy shared memory segments not in use'
=> Vous pouvez activer 'Restricted /proc' mais il vous faudra une
configuration supplémentaire des comptes administrateurs avec un outil
comme sudo pour éviter que les admins ne passent root à tout bout de champ: On compile :
On installe :
Installez les modules :
On modifie /etc/lilo.conf pour ajouter :
Et on lance 'lilo'. On reboote et on passe sur le noyau avec OpenWall. Si tout s'est bien passe, vous pouvez changer le noyau charge par défaut par lilo en supprimant restricted de l'ancien noyau.
L'archive est disponible sur : http://www.research.avayalabs.com/project/libsafe/
Testez la librairie :
Installez la libsafe dans /etc/ld.so.preload si le fichier n'existe pas :
Rebootez le système (?!).
Installez le package Debian :
dselect => installation de 'aide' => La préconfiguration ne fonctionne pas, car elle tente d'exécuter un script dans /tmp => 'Initalize aide database ?' -> No
Préparez le terrain :
Editez /etc/aide/aide.conf et modifiez le de telle sorte que :
Initialisez la base de données : aide --init -V200 NDR : Est-il trivial de vous reccomander de ne pas faire de modifications pendant l'initialisation ? Première sauvegarde de la base de données (la suite est donnée à titre d'exemple) : Insérez une disquette puis 'mke2fs /dev/fd0'
Sortez la disquette et protégez la en écriture. Vérifier le système avec le support de sauvegarde : Insérez la disquette
Mise à jour de la base de données sauvegardée :
NDR : Ce qui précède est donné à titre d'exemple, Il serait plus approprié en
cas de doute de booter le système sur un support amovible sur protégé en
écriture et d'effectuer la verification d'intégrité à partir de ce
support. MAN : aide, aide.conf
NDR : Vous devez commencer a connaitre le système donc je n'explique plus les
details déjà presentes plusieurs fois... Recompilation du noyau et installation du package : Compilez un nouveau noyau en activant 'Filesystems -> Quota support'. Rebootez, sauvez la configuration etc... Installez le package 'quota'.
Configuration des partitions : Modifiez le fichier /etc/fstab pour ajouter les flags relatifs aux quotas :
Ajoutez les fichiers de quotas :
Remontez les partitions :
Suppression d'un service inutile pour nous :
Une première verification :
Edition des quotas pour les groupes : Lancez 'edquota -g users' et editez les quotas pour le groupe users :
Lancez 'edquota -g adm' et editez les quotas pour le groupe adm :
NDR : Utilisez 'df -[h|i]' de facon à obtenir les informations sur
l'ensemble du disque pour le choix des quotas précédents. Créez un utilisateur fictif qui servira de modèle de mise en place de quotas :
Mettez en place les quotas pour le modèle d'utilisateur : Lancez 'edquota -u quotauser' et éditez les quotas :
Vous pouvez vérifier les quotas mis en place avec : 'quota -vu quotauser' Pour un nouvel utilisateur {username}, vous pouvez associer ce modèle de quotas avec 'edquota -p quotauser {username}'. Modifiez '/etc/adduser.conf' pour inclure ce modàle dans la définition des quotas :
Activation - Désactivation - Etat des quotas (quelques exemples) : Activation : /etc/init.d/quota start Désactivation : /etc/init.d/quota stop Etat (Active ou Desactive ? ) : quotaon -pa Statistiques : repquotas -ugva NDR : Le fichier d'initialisation des quotas au boot est placé dans /etc/rcS.d et sera donc active à chaque redémarrage de la station. MAN : quotacheck, quotaon, quotaoff, quotastats, repquota, edquota, quota
Limites aux sessions : Vérifiez avec 'grep pam_limits.so /etc/pam.d/ssh' que la librairie est activee (c'est le cas par défaut). Constatez avec 'grep pam_limits.so /etc/pam.d/login' que la librairie n'est pas activée par défaut : => Activez la en décommentant la ligne. => Faites de même pour /etc/pam.d/su Editez /etc/security/limits.conf en ajoutant les parametres suivants (exemple pour le groupe administrateurs) :
NDR : Pour afficher les limites d'un utilisateurs, entrez 'ulimit -a' MAN : bash, ulimit
La distribution tomsrtbt est téléchargeable sur http://www.toms.net/rb/
Insérez une disquette vierge.
Vous avez désormais une disquette de secours. En rebootant sur la disquette, deux choix vous sont proposés :
Et puis en fait, le mieux est que vous lisiez la FAQ...
L'installation de Prelude-Lml est désormais présentée dans une autre
documentation. Ne figurent ici que les aspects de configuration du moniteur
Prelude qui sont spécifique à l'installation de notre station sécurisée. La nouvelle documentation est intitulée "Centralized and secured remote logging solution with Prelude-Lml on Debian : How to securely install and set up the Prelude-Lml engine". Elle est disponible sur http://www.entreelibre.com/scastro/prelude/ .
Nous abordons ici la remontée de certains des logs 'sécurité' générés par
la configuration présentée dans cette documentation. NDR : Par la suite, nous emploierons le terme 'sonde' à la place de 'sensor'. NDR : Cette configuration est minimale, je vous conseille, de lire les documentations disponibles sur prelude et de procéder à votre propre paramétrage. Il est par exemple possible, entre autres, de recompiler la libsafe pour qu'elle puisse se comporter en sonde prelude. Modifiez '/home/prelude/etc/prelude-sensors/sensors-default.conf' : > node-name = Test Secured Debian; > node-location = Salle serveur; Modifiez '/home/prelude/etc/prelude-lml/plugins.rules' :
Modifiez '/home/prelude/etc/prelude-lml/prelude-lml.conf' : Nos fichier à surveiller sont (voir '4.8. Installation et premiers pas avec Modular-Syslog') : /var/log/fw_deny.log, /var/log/fw_accept.log et /var/log/sécurité.log :
Nous allons charger notre propre série de règles :
Créez '/home/prelude/etc/prelude-lml/ruleset/debian-secinst.rules' :
Créez '/home/prelude/etc/prelude-lml/ruleset/ipchains.rules' a partir de
'ANNEXE 5 - Fichier de règles pour un support Ipchains avec Prelude-lml'
si vous utilisez un firewall IpChains. Attribuez les permissions correctes aux fichiers crées :
!!! ATTENTION
Notez qu'avec cette version de Prelude, il n'est apparemment plus possible
de donner des droits restreints aux fichiers de logs que vous monitorez.
Par défaut, vos fichiers de logs (dans /var/log) sécurité.log et fw_[deny|
accept].log doivent être en 640 et appartenir a root:adm (si vous avez
suivi cette procédure).
Il se trouve que si vous ne configurez pas ces fichiers en 644 au minimum
avec cette installation, le moniteur prelude ne sera pas capable de les
consulter après avoir perdu ses privilèges super-utilisateur.
ATTENTION !!!
Et redemarrez la sonde prelude-lml :
GrSecurity est constitue d'un patch pour le noyau Linux et d'un utilitaire
destine à être utilisé en espace utilisateur. Le patch accroît la sécurité du
système en apportant des restrictions aux systèmes de fichiers /proc et /tmp,
aux actions réalisables par des processus 'chrootes', en créant un espace de
stockage d'ACLs (Access Control Lists) permettant d'implémenter un système
base sur le modèle MAC (Mandatory Access Control) pour tous les utilisateurs
et y compris pour le super-utilisateur (la liste n'est pas exhaustive :) ).
La suite GrSecurity inclut également Pax : une protection du noyau permettant
l'implémentation de pages mémoire non exécutables et un espace d'adressage
aléatoire. Nous allons tout d'abord commencer par patcher le noyau du système puis nous aborderons l'intégration des listes de contrôle d'accès. Notez que vous devez choisir entre cette procédure et celle présentée en '5.1. Installation du patch OpenWall'. Le patch noyau GrSecurity et l'outil d'administration GrAdm sont tous deux disponibles sur www.grsecurity.net et l'utilitaire chpax est disponible sur pageexec.virtualave.net . Je ne peux que vous indiquer de lire consciencieusement la documentation présente sur le site avant de procéder aux manipulations décrites ci-après... Avant de commencer, sachez enfin que cette documentation s'applique pour un noyay 2.4.22 (noyau non disponible dans la branche stable des packages Debian) donc à vous de choisir...
Récupérez le patch du noyau ainsi que chpax, vérifiez les MD5 et stockez les
dans /home/system/download/. Récupérez les sources du noyau 2.4.22, vérifiez le md5 puis :
Patchez les sources du noyau :
Editez le flag EXTRAVERSION du fichier linux-2.4.22/Makefile pour ajouter un
commentaire du type '-grsec'. Si vous utilisiez le noyau 2.4.18 de Debian, récuperez le fichier de config que vous avez du sauvegarder dans /boot et placez le dans /usr/src/linux-2.4 .22/.config puis 'make oldconfig' - sinon 'make menuconfig' et configurez votre nouveau noyau. Choisissez les options GrSecurity que vous voulez activer - celles qui ont été utilisees lors de la rédaction de cette documentation sont présentées dans 'ANNEXE 11 - Parametres de configuration d'un noyau GrSecurity' - puis compilez et installez votre nouveau noyau en suivant la procédure présentée dans 'II. COMPILATION DU NOYAU'. Notes sur le choix des options : Si vous activez l'option 'Deny writing to /dev/kmem, /dev/mem, and /dev/port' dans le menu 'Address Space Protection' et que votre système est un guest VmWare (tm), il ne bootera plus... J'utilise le gid 4 pour l'option 'CONFIG_GRKERNSEC_PROC_GID', ce qui permet aux membres du groupe 'adm' d'obtenir des permissions que je juge appropriées pour les administrateurs non-root du serveur. J'active l'option 'CONFIG_GRKERNSEC_CHROOT_SYSCTL' car je préfère créer un script d'initialisation chargé de positionner les bonnes valeurs lors du boot. Si vous préférez sécuriser "encore plus" votre installation, désactivez cette option, mais faites attention que les gids que vous utiliserez dans les options 'CONFIG_GRKERNSEC_AUDIT_GID' , 'CONFIG_ GRKERNSEC_TPE_GID', 'CONFIG_GRKERNSEC_SOCKET_ALL_GID', 'CONFIG_GRKERNSEC _SOCKET_CLIENT_GID' et 'CONFIG_GRKERNSEC_SOCKET_SERVER_GID' ne soient pas déjà utilisés sur votre système. Une fois votre nouveau noyau installe, rebootez le système.
Créez les groupes suivants :
Créez le fichier /etc/sysctl.conf.grsecurity à partir du fichier présent en
'ANNEXE 12 - Configuration Sysctl de GrSecurity' et parametrez ce fichier
selon vos besoins en mettant à jour les gid avec les groupes que vous venez
de créer. !!! Attention !!! La suite peut rendre votre système instable. Testez cette configuration avec la commande :
Si tout se passe bien et que le comportement du serveur répond à vos
attentes, positionnez la variable 'grsec_lock' de sysctl.conf.grsecurity à
'1' puis créez le fichier '/home/system/security/apply_grsec.sh' :
Configurez le système pour que ce script soit appellé au boot :
où {XX} correspond à votre priorité de lancement par rapport aux autres
scripts exécutés lors du boot du système. Modifiez votre fichier de configuration syslog pour stocker les alertes dans le fichier de log sécurité grâce aux entrées suivantes :
La configuration initiale est terminée... Voici la politique que j'applique
personnellement (elle est fonction de l'usage final du serveur) :
Tous les operateurs du système sont dans grsec_sock_srv;
Les serveurs Apache et Websphere sont dans grsec_audit et dans grsec_tpe;
Si Apache n'a pas besoin d'établir de connexions distantes (Attention,
c'est le cas pour le module WAS), je place Apache dans grsec_sock_cl;
Les éventuels utilisateurs guests sont placés dans grsec_sockall et dans
grsec_tpe.
Une dernière note relative à l'interaction de notre noyau avec une
installation Websphere telle que présentée dans 'V. INSTALLATION ET
SECURISATION D'UN SERVEUR D'APPLICATION WEBSPHERE' : Si vous avez suivi la
procédure d'installation de ce document le serveur d'application ne pourra
plus démarrer et vous obtiendrez un message d'erreur du type :
Vous pouvez corriger ce probleme via :
Et vérifiez que vous obtenez ceci avec chpax -v :
Pour finir, le positionnement de l'utilisateur WAS dans le groupe d'audit
génère une quantité quelque peu importante de logs lors des stop/start du
serveur d'applications, ceux-ci sont cependant facilement traçables par le
critère "parent (stopServer.sh:17515)" par exemple.
Avant de commencer, sachez que cette installation va fortement diminuer les
droits de l'utilisateur root. Pour effectuer des tâches d'administration
telles que la mise à jour des packages ou un reboot du serveur, vous devrez
utiliser la commande 'gradm -a' de facon à passer en mode administration. Lors de l'installation de Gradm, vous aurez à saisir un mot de passe pour la commande Gradm (passage en mode administration ou désactivation des ACLs), il paraît donc judicieux de saisir un mot de passe complexe ?! Récupérez l'archive gradm-1.9.12.tar.gz sur le site de GrSecurity et stockez la dans /home/system/download puis vérifiez le MD5. On installe :
Une configuration initiale est désormais positionnée dans /etc/grsec/acl et
sera utilisée si vous activez la sécurité - ce que vous ne faites pas bien
évidemment ! Nous récupérons les acls fournies pour debian et les utilisons :
Conformement à cette documentation, nous n'avons pas besoin des acls
suivantes (certaines sont disponibles en annexe) donc :
Créez un répertoire /etc/grsec/debian-secinst, ajoutez y les fichiers
présentés en 'ANNEXE 13 - ACLs GrSecurity pour Debian-secinst' puis :
Note : Ne prenez que les fichiers d'ACL dont vous avez besoin pour votre
propre système et configurez les selon vos besoins ! Modifiez le fichier /etc/grsec/acl avec le patch présent en 'ANNEXE 13' :
Si vous avez installé un serveur Web, n'oubliez pas d'éditer le fichier
/etc/grsec/debian_secinst/Dmn_apache pour définir les ports sur lesquels le
serveur Apache est autorisé à se positionner en écoute. Si vous avez modifie les ports d'écoute du démon SSH, faites de même avec le fichier /etc/grsec/debian_secure_acls/sshd. Si vous avez configuré d'autre device de logging pour le syslogd (comme par exemple en suivant les explications de '5.7. Installation de Prelude-Lml.'), editez /etc/grsec/debian_secure_acls/syslogd pour les configurer. Vous pouvez maintenant croiser les doigts et activer les acls avec la commande 'gradm -E'. Si tout se passe bien, vous pouvez maintenant modifier le script /home/system/security/apply_grsec.sh pour ajouter la commande 'gradm -E' de facon à ce que les ACLs soient mises en place au boot du système.
Copyright (c) 2003 Simon Castro, scastro [ at ] entreelibre.com.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. You must have received a copy of the license with this document and it should be présent in the fdl.txt file. If you did not receive this file or if you don't think this fdl.txt license is correct, have a look on the official http://www.fsf.org/licenses/fdl.txt licence file. |