Installation et sécurisation d'une station Debian 3.0 stable

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

< Paxmod   -   .* PAX: .*
> #Paxmod   -   .* PAX: .*

Modifiez '/home/prelude/etc/prelude-lml/prelude-lml.conf' :

Nos fichier à surveiller sont (voir Installation et premiers pas avec Modular-Syslog) : /var/log/fw_deny.log, /var/log/fw_accept.log et /var/log/sécurité.log :

< file = /var/log/auth.log
< file = /var/log/messages
> file = /var/log/sécurité.log
> file = /var/log/fw_accept.log
> file = /var/log/fw_deny.log

Nous allons charger notre propre série de règles :

< ruleset=/home/prelude/etc/prelude-lml/ruleset/simple.rules;
> #ruleset=/home/prelude/etc/prelude-lml/ruleset/simple.rules;
> ruleset=/home/prelude/etc/prelude-lml/ruleset/debian-secinst.rules

Créez '/home/prelude/etc/prelude-lml/ruleset/debian-secinst.rules' :

# Customized prelude-lml rules file from debian-secinst v0.1.7 doc 
# Simon Castro <scastro [at] entreelibre.com>
# These one are from the simple.rules standard file.
regex=PAM_unix\[([0-9]+)\][^(]+\(uid=([0-9]+)\) -> ([^ ]+);\
class.name=Authentication Failure; impact.completion = failed;\
impact.type = other; impact.severity = high;\
impact.description=Process $1 attempted to change UID from $2 to $3; 
regex=entered promiscuous mode; class.name=Promiscuous mode detected;\
impact.completion = succeeded; impact.type = other;\
impact.severity = medium; impact.description=A sniffer is probably\
running on this machine;
# A few of rules only of this file will be used as we don't configure\
prelude-lml to look into auth.log
include = ssh.rules;
# These are personal rules...
regex=left promiscuous mode; class.name=Promiscuous mode end detected;\
impact.completion = succeeded; impact.type = other;\
impact.severity = medium; impact.description=A sniffer is probably\
running on this machine;
# Uncomment one of the two ruleset below
#include = ipchains.rules;
#include = netfilter.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 :

cd /home/prelude/etc/prelude-lml/ruleset/
chown prelude:prelude debian-secinst.rules ipchains.rules
chmod 640 debian-secinst.rules ipchains.rules

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.

Et redémarrez la sonde prelude-lml :

/etc/init.d/preludelogmonitor.sh restart

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 :

mount -o remount,rw /usr
mount -o remount,exec /tmp
cd /usr/src
mv /home/system/download/linux-2.4.22.tar.bz2 .
tar jxvf linux-2.4.22.tar.bz2
chown -R root:root linux-2.4.22
chmod 750 linux-2.4.22
mv linux-2.4.22 kernel-source-2.4.22
ln -s kernel-source-2.4.22 linux-2.4.22

Patchez les sources du noyau :

cd /usr/src
patch -p0 < /home/system/download/grsecurity-1.9.12-2.4.22.patch

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 :

for i in `echo grsec_tpe grsec_sockall grsec_sock_cl grsec_sock_srv grsec\
	_audit`; do groupadd $i; done

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 :

/sbin/sysctl -p /etc/sysctl.conf.grsecurity

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

#!/bin/sh
/sbin/sysctl -p /etc/sysctl.conf.grsecurity

Configurez le système pour que ce script soit appellé au boot :

cd /etc/rc2.d
ln -s /home/system/security/apply_grsec.sh S{XX}apply_grsec

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 :

kern.* %regex -m "PAX" %classic /var/log/sécurité.log
kern.* %regex -m "grsec" %classic /var/log/sécurité.log

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 Installation et sécurisation 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 :

[...] kernel: grsec: From a.b.c.d: Proc handler: being fed garbage 2  bytes\
      sent 208 require
[...] kernel: PAX: From a.b.c.d: terminating task: /usr/local/websphere500/\
      appserver/java/jre/bin/exe/java(java):4773, uid/euid: [...]
[...] kernel:grsec: From a.b.c.d: attempted resource overstep by requesting\
      4096 for RLIMIT_CORE against limit 0 by (java:4773) [...],  parent (start\
      Server.sh:19644) [...]

Vous pouvez corriger ce probleme via :

cd /home/system/applis/chpax-0.5/
./chpax -s /usr/local/websphere500/appserver/java/jre/bin/exe/java

Et vérifiez que vous obtenez ceci avec chpax -v :

* Paging based PAGE_EXEC       : enabled
* Trampolines                  : not emulated
* mprotect()                   : restricted
* mmap() base                  : randomized
* ET_EXEC base                 : not randomized
* Segmentation based PAGE_EXEC : disabled

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 :

cd /home/system/applis/
tar zxvf ../download/gradm-1.9.12.tar.gz
chown -R root:root gradm/
find . -type f -exec chmod 640 {} \;
find . -type d -exec chmod 750 {} \;
make && make install

=> Le mot de passe vous est demande et est stocke dans /etc/grsec/pw.

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 :

cd /etc/grsec/
cp -r /home/system/applis/gradm/debian_secure_acls .
chmod 700 debian_secure_acls/
chmod 600 debian_secure_acls/*
mv acl acl.orig
mv debian_secure_acls/default acl

Conformement à cette documentation, nous n'avons pas besoin des acls suivantes (certaines sont disponibles en annexe) donc :

cd debian_secure_acls/
rm -f apache cron inetd ipop3d klogd mysqld postfix syslogd tcpd xfree86

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 :

cd /etc/grsec
chmod 700 debian-secinst
chmod 600 debian-secinst/*

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

cd /etc/grsec
patch < patch
=> File to patch ? entrez acl puis supprimez le patch

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.