Debian inclus certains outils pour la détection d'intrusion qui sont utiles pour défendre votre système local (si vous êtes paranoïaque ou si votre système est rééllement critique) ou pour défendre d'autres systèmes dans le même réseau.
Soyez toujours aux aguets de manière à réellement améliorer la sécurité du système avec n'importe lequel de ces outils, vous devez avoir un mécanisme alerte+réaction. Donc, n'utilisez pas de système de détection d'intrusion si vous n'avertissez personne (ne perdez pas de temps à configurer des choses que vous n'utiliserez pas par la suite).
La plupart des outils de détection d'intrusion vont soit loguer dans syslog soit envoyer des courriers à l'utilisateur root (la plupart d'entre eux peuvent être configurés afin d'envoyer un courrier au lieu qu'un autre utilisateur le fasse) concernant le détail de l'attaque qui a été détecté. Un administrateur doit les configurer convenablement afin que de fausses alertes ne soient pas envoyées. Les alertes peuvent indiquées une attaque en cours et ne seraient pas très utiles un jour plus tard, puisque l'attaque pourrait déjà alors avoir été couronnée de succès. Assurez-vous donc qu'une police correcte a été mise en place vis à vis des alertes et que le mécanisme mécanique pour les implémenter est en place.
Une source d'information intéressante est CERT's
Intrusion Detection Checklist
snort
est un renifleur flexible de paquet ou un logueur qui
détecte les attaques selon un dictionnaire de signature. Il détecte une
variété d'attaque et de vérifications, tels que des débordements de capacité,
les scans dissimulés de ports, les attaques CGI, les vérifications SMB, et bien
d'autres. Snort a une capacité d'alerte en temps réel. C'est un outil qui
peut être installé sur n'importe quel routeur pour garder un oeil sur le
réseau. Installez le simplement via apt-get install snort, suivez
les questions et regardez les logs.
Snort dans Debian est activé avec de nombreuses vérifications de sécurité que vous pourriez vouloir; toutefois, vous devriez prendre le temps de personnaliser l'installation pour prendre en compte les services que vous utilisez sur votre système. Vous pouvez très bien aussi recevoir des vérifications supplémentaires à propos de ces services.
Vous pouvez utiliser snort
à la fois pour établir une détection
d'intrusion sur le réseau pour un certains nombre d'hôte mais aussi pour
détecter les attaques réseaux contre votre propre hôte.
Il y a d'autres outils qui peuvent être utilisés pour détecter les attaques
réseaux (bien que plus simplistes). Portsentry
est un autre
paquetage intéressant qui peut vous informer lorsqu'un scan de votre réseau est
effectué sur votre site. D'autres outils tel queippl
ou
iplogger
peuvent aussi détecter des attaques IP (TCP et ICMP),
même s'ils ne fournissent pas de techniques avancées pour détecter les attaques
réseaux (comme le ferait snort).
Vous pouvez testez chacun de ces outils avec le programme
idswakeup
program, un faux générateur d'alerte pour alarmer les
NIDSs avec un grand nombre de signature d'attaque commune disponible chez
Debian.
Tiger
est un ancien outil de détection d'intrusion qui a été porté
sous Debian depuis la distribution woody. Tiger fournit un ensemble de
vérification sur des problèmes communs liés aux failles de sécurité, il vérifie
la taille des mots de passe, les problèmes du système de fichier, les process
de communications... La version Debian inclue de nouvelles vérifications de
sécurité Spécificité-Debian: somme MD5 des binaires fournis, et vérification
des paquets installés et vulnérables. L'installation par défaut fait que
tiger
se lance chaque jour et génère un rapport qui est envoyé au
super-utilisateur. Les rapports ainsi générés fournissent l'information sur
les compromissions réussies sur le système.
Il y a aussi un grand nombre de logiciel d'audit de log, sur-site, comme
logcheck
. Ces outils peuvent être très utiles s'ils sont
correctement personnalisés pour alerter l'administrateur à propos d'évènements
inhabituels se produisant sur le système de fichier local.
Logcheck
peut être grandement personnalisé, il peut donc envoyer
des mails pour des évènements récupérés par les logs qui sont dignes
d'attention. L'installation par défaut inclus des profiles pour des évènements
ignorés et des violations de police pour trois types d'installation (station de
travail, serveur et paranoïa). Le paquetage Debian inclue un fichier de
configuration /etc/logcheck/logcheck.conf
, complété par le
programme, indiquant à qui sont envoyé les vérifications. Il fournit aussi une
ouverture pour des paquetages qui fournissent des services pour implémenter de
nouvelles polices dans les répertoires suivant:
/etc/logcheck/hacking.d/_packagename_
,
/etc/logcheck/violations.d/_packagename_
,
/etc/logcheck/violations.ignore.d/_packagename_
,
/etc/logcheck/ignore.d.paranoid/_packagename_
,
/etc/logcheck/ignore.d.server/_packagename_
, and
/etc/logcheck/ignore.d.workstation/_packagename_
. Cependant,peu
de paquetage font actuellement cela. Si vous possédez une police qui peut être
utile aux autres utilisateurs, envoyez la comme rapport de bug pour le
paquetage adéquat. Pour plus d'information voir
/usr/share/doc/logcheck/README.Debian
Vous pourrez aussi trouver un ensemble de vérificateurs d'intégrité (voir Vérifier l'intégrité des systèmes de fichiers, Section 4.12.3) qui peuvent être très utiles pour instaurer une vérification d'anomalies dans un environnement sécurisé. Une intrusion effective sur un système, à coup sûr, modifie les fichiers dans le système de fichier local pour contourner les polices de sécurité locales, installer des trojans, créer des utilisateurs... ces événements peuvent être détectés grâce à ces outils.
FIXME: Cette section a besoin de couvrir la manière d'installer ces rustines spécifiques sur Debian en utilisant les paquets kernel-2.x.x-patch-XXX.
Il existe quelques rustines pour le noyau qui améliorent expressivement la sécurité du système. En voici quelques un :
http://www.openwall.com/linux/
http://www.lids.org
http://acl.bestbits.at/
http://trustees.sourceforge.net/
http://www.kerneli.org
http://www.immunix.org/subdomain.html
http://ramses.smeyers.be/useripacct
.
http://www.freeswan.org
LKM (Loadable Kernel Modules) sont des fichiers contenant les composants chargeables dynamiquement dans le noyau. Ils sont dynamiquement chargeables dans le noyau afin de faire tourner certaines tâches. Sur GNU/Linux, ils sont utilisés pour étendre les fonctionnalités du noyau. Plusieurs avantages dans l'utilisation des LKMs, comme nous l'avons précédemment vu, ils peuvent être chargés dynamiquement sans recompiler le noyau entièrement, peuvent être utilisés pour spécifier des pilotes de périphériques (ou systèmes de fichiers) et d'autres pilotes de matériels tels que les cartes sons, les cartes réseaux. Mais certains pirates peuvent utilisés les LKMs pour les rootkits (knark et adore) afin d'installer des portes dérobées sur des systèmes GNU/Linux.
Les rootkits LKM peuvent cacher des processus, des fichiers, répertoires et
même des connexions sans modifier les codes sources des binaires. Par exemple,
ps
peut avoir des informations sur des processus depuis
/proc
, un LKM malveillant peut miner le noyau pour cacher des
processus spécifiques de procfs, ainsi même une bonne copie du binaire
ps
ne peut lister tous les processus correctement.
La détection peut-être simple et sans douleur ou difficile et usante selon la mesure que vous choisissez. Il existe deux mesures de défense concernant la sécurité LKM, la proactive et la réactive.
L'avantage de cette défense est qu'elle prévient des dommages que pourrait entraîner un rootkit au système. La défense proactive la plus utilisé est "attrapons-les en premier", ceci permet de charger un LKM bien défini afin de protéger le système d'un LKM infecté. Une autre mesure consiste à retirer ces options dans le noyau, rendant ainsi le système plus sécurisé. Par exemple, vous pouvez retirer la possibilité de charger et décharger les modules du noyau.
Sur les systèmes Debian, vous pouvez trouver certains paquets qui sont des outils proactifs :
kernel-patch-2.4-lsm
- LSM est le projet Linux Security Modules.
lcap
- Retire les "privilèges" dans le noyau, rendant le
système plus sécurisé.
Si vous n'avez pas l'utilité de toutes ces caractéristiques sur votre système GNU/Linux, vous pourriez désactiver le support des modules lors de la configuration du noyau. Cela prévient des rootkits LKM mais vous ne pourrez plus utiliser les modules sur votre GNU/Linux. Faites attention que la désactivation des modules peut surcharger le noyau, parfois cela n'est pas nécessaire.
Pour désactiver le support des modules chargeables, mettre juste
CONFIG_MODULES=n dans .config
.
L'avantage d'une défense réactive est qu'elle représente une faible surcharge au niveau des ressources systèmes. Elle fonctionne en comparant la table des appels systèmes avec une copie sûre enregistrée sur disque (System.map). Le désavantage le plus évident est qu'elle renseigne l'administrateur seulement quand le système a déjà été compromis.
La détection des rootkits dans la Debian peut être accomplie avec
chkrootkit
. Ce programme cherche des signes de présence de
rootkits sur le système local et dit si l'ordinateur cible est infecté par un
rootkit.
Vous pouvez aussi utiliser SKAT
. SKAT vérifie la zone
mémoire du kernel (/dev/kmem
) pour des informations au sujet de
l'hôte cible, ces informations incluent l'installation de modules noyau
chargeables.
FIXME: Ajouter des infos sur comment compiler le noyau sans le support des LKM?
C'est probablement la section la plus instable et amusante, car j'espère que quelques unes des idées "bah. ça semble dingue" pourraient être réalisées. Plus loin vous trouverez certaines idées — Suivant votre point de vue vous les qualifierez de géniales, paranoïaques, folles ou sûres — pour augmenter votre sécurité rapidement mais vous n'en sortirez pas indemne.
/bin
, /sbin/
, /usr/bin
,
/usr/sbin
et /usr/lib
(et quelques un des autres
suspects habituels) et faites un usage généreux de la commande chattr
+i
. Ajoutez aussi cela au fichiers noyau dans la racine. Maintenant
mkdir /etc/.dist/
copiez tout /etc/
(je fais cela en
deux étapes en utilisant /tmp/etcdist.tar pour éviter la récursion) dans ce
répertoire. (En option vous pouvez juste créer /etc/.dist.tar.gz) -- et
marquer cela comme immuable.
La raison de tout ceci est de limiter les dégâts que vous pouvez faire quand
vous êtes connecté en root. Vous n'écraserez pas des fichiers avec un
opérateur de redirection égaré, et vous ne rendrez pas votre système
inutilisable avec un espace mal placé dans une commande rm -fr
(vous pourriez encore faire pas mal de dégâts à vos données — mais vos
librairies et binaires seront plus à l'abris).
Cela rend aussi un large éventail d'exploits de sécurité et de deni de service soit impossible soit plus difficile (car beaucoup d'entre eux comptent sur l'écrasement d'un fichier à travers les actions d'un programme SUID qui ne fournit pas une commande shell arbitraire).
Le seul inconvénient de cela est présent lorsque vous compilez et exécutez
votre make install
sur différentes sortes de binaires systèmes.
D'un autre côté cela empêche aussi le make install
d'écraser les
fichiers. Quand vous oubliez de lire le Makefile et chattr -i les fichiers qui
vont être récrits (et les répertoires auxquels vous voulez ajouter des
fichiers) - le make échoue, utilisez juste la commande chattr et relancez le.
Vous pouvez aussi profiter de l'occasion pour déplacer vos vieux binaires,
librairies ou quoique ce soit d'autre dans un répertoire .old/ ou les renommer
ou les sauvegarder avec tar...
Notez que cela vous empêche aussi de mettre à jour vos paquetages systèmes.
Car les fichiers qu'ils fournissent ne peuvent être récrits, vous pourriez donc
souhaiter avoir un mécanisme pour désactiver le sémaphore immuable sur tous les
binaires juste avant de faire un apt-get update
.
FIXME. Nécessite plus de contenu spécifique à la Debian.
Si vous le souhaitez (et pouvez aussi l'implémenter et y consacrer du temps) vous pous pouvez aussi configurer un pot de miel complet en utilisant un système Debian GNU/Linux. Vous avez tous les outils requis pour configurer un "réseau de miel" (i.e. le réseau, le pot de miel est juste le serveur factice): le firewall, le détecteur d'intrusion réseau et le faux serveur. Faites attention cependant, vous devez être plutôt sûr d'être alerté à temps (voir L'importance des logs et des alertes, Section 4.8) pour que vous puissiez prendre les mesures appropriées et terminer le compromis aussitôt que vous pensez que vous en avez vu assez.
syslog-ng
pour envoyer les logs du pot de miel vers un serveur
syslog distant.
snort
pour configurer la capture de tout le traffic réseau
arrivant sur le pot de miel et détecter les attaques.
osh
qui pourrait être utilisé pour mettre en place un shell
restreint avec journalisation (voir l'article de Lance Spitzner plus bas).
dtk
si vous voulez aussi
utiliser le honeynet comme un service de détection d'intrusion.
tct
)) pour faire des audits
post-attaques.
Vous pouvez en lire plus sur la construction des pots de miel dans l'excellent
article de Lance Spizner To
Build a Honeypot
(de la série des "connaissez votre
ennemi"), ou le Building
your own honeypot
de David Raikow. De même, le Honeynet Project
est dédié à la
construction de pots de miel et à l'audit des attaques menées contre eux, il y
a là des informations de valeurs sur comment configurer un pot de miel et
comment auditer les résultats d'une attaque (voyez le concours).
Securing Debian Manual
2.8 14 febrero 2004Mon, 18 Nov 2002 23:13:42 +0100jfs@computer.org