[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ suivant ]
Vous devriez effectuer des mises à jour de sécurité fréquemment. La grande
majorité des exploits résulte de failles connues qui n'ont pas été corrigées à
temps, comme l'explique ce papier par Bill
Arbaugh (presenté lors du Symposium 2001 IEEE sur la sécurité et la
confidentialité). Les mises à jour sont décrites dans Faire une mise à jour de sécurité, Section
4.2.
Debian dispose d'un outil spécifique pour déterminer si un système a besoin d'être mis à jour (voir Tiger ci-dessous), mais beaucoup d'utilisateurs veulement simplement vérifier si des mises à jour de sécurité sont disponibles pour leur système.
Si vous avez configuré votre système comme décrit dans Faire une mise à jour de sécurité, Section 4.2, vous avez simplement à faire :
# apt-get update
# apt-get upgrade -s
[ ... passer en revue les paquets à mettre à jour ... ]
# apt-get upgrade
# checkrestart
[ ... redémarrer les services qui doivent être redémarrés ... ]
Et redémarrez les services dont les bibliothèques ont été mises à jour s'il y en a. Note : lisez Faire une mise à jour de sécurité, Section 4.2 pour plus d'informations sur les mises à jour de bibliothèques (et de noyau).
La première ligne téléchargera la liste des paquets disponibles depuis vos sources de paquets configurées. L'option -s effectuera une simulation d'exécution, c'est-à-dire, qu'elle ne va pas télécharger ou installer de paquets, mais qu'elle va plutôt vous dire quels paquets seraient téléchargés et/ou installés. À partir de cette sortie, vous pouvez en déduire quels paquets ont été corrigés dans debian et sont disponibles comme mise à jour de sécurité. Par exemple :
# apt-get upgrade -s
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
Calcul de la mise à jour... Fait
Les paquets suivants seront mis à jour :
cvs libcupsys2
2 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.
Inst cvs (1.11.1p1debian-8.1 Debian-Security:3.0/stable)
Inst libcupsys2 (1.1.14-4.4 Debian-Security:3.0/stable)
Conf cvs (1.11.1p1debian-8.1 Debian-Security:3.0/stable)
Conf libcupsys2 (1.1.14-4.4 Debian-Security:3.0/stable)
Dans cet exemple, vous pouvez voir que le système a besoin d'être mis à jour
avec des nouveaux paquets cvs et cupsys qui sont récupérés depuis l'archive de
mises à jour de sécurité de woody. Si vous voulez comprendre pourquoi
de tels paquets sont nécessaires, vous devriez aller à http://security.debian.org et
vérifier quelles Alerts de sécurité Debian (DSA) récentes ont été publiées
concernant ces paquets. Dans ce cas, les DSA concernées sont DSA-233 (pour
cvs) et DSA-232 (pour
cupsys).
Remarquez que vous devrez redémarrer votre système s'il y a eu une mise à jour du noyau.
Une autre méthode pour des mises à jour de sécurité automatique est
l'utilisation de cron-apt. Ce paquet fournit un outil pour mettre
à jour le système à intervalles réguliers (en utilisant une tâche cron). Par
défaut, il va simplement mettre à jour la liste des paquets et télécharger les
nouveaux paquets. Il peut également être configuré pour envoyer un courriel à
l'administrateur système.
Notez que vous pouvez vouloir vérifier la version de distribution comme décrit dans Alternative à la vérification des versions de distribution, Section 7.4.4, si vous avez l'intention de mettre à jour automatiquement votre système (même si vous ne faites que télécharger les paquets). Sinon, vous ne pouvez pas être certain que les paquets téléchargés proviennent réellement d'une source de confiance.
Si vous recherchez un outil pour vérifier rapidement et fournir un compte rendu
sur les failles de sécurité d'un système, essayez le paquet tiger.
Ce paquet est un ensemble de scripts shell Bourne, de programmes C et de
fichiers de données utilisés pour effectuer des audits de sécurité. Le paquet
Debian GNU/Linux dispose d'améliorations supplémentaires orientés vers la
distribution Debian, en fournissant plus de fonctionnalités que les scripts
Tiger fourni par TAMU (ou même TARA, une version de tiger distribuée par ARSC).
Voir le fichier README.Debian et la page de manuel
tiger(8) pour plus d'informations.
L'une de ces améliorations est le script deb_checkadvisories. Ce script prend une liste de DSA et la vérifie par rapport à la base de paquets installés, en indiquant tout paquets qui serait vulnérables selon l'équipe de sécurité Debian. Cela est une approche légèrement différente et plus générale que celle implémentée par le script Tiger check_signatures qui vérifie les MD5sums de programmes vulnérables connus.
Comme Debian ne fournit pas actuellement une liste de MD5sums des programmes vulnérables connus (utilisée par certains autres systèmes d'exploitation comme Sun Solaris), l'approche vérifier-par-rapport-aux-DSA est utilisée. L'approche DSA et l'approche MD5sums souffrent toutes deux du problème que les signatures doivent être mises à jour régulièrement.
Cela est actuellement résolu en créant de nouvelles version du paquet Tiger,
mais le responsable du paquet pourrait ne pas faire une nouvelle version à
chaque fois qu'une DSA est annoncée. Un ajout agréable, qui n'est pas encore
implémenté, serait de faire cela de façon proactive. C'est-à-dire, de
télécharger les DSA du web, de faire la liste et d'exécuter la vérification.
Les DSA sont actuellement mises à jour depuis la mise à jour CVS locale du
responsable des sources WML utilisés pour construire http://security.debian.org (le
serveur web).
Un programme pour analyser les DSA publiées, soit reçues par courriel ou
disponible sur security.debian.org et qui générerait le fichier utilisé par
deb_checkadvisories pour confirmer les failles serait apprécié.
Envoyez un rapport de bogue pour tiger.
La vérification mentionnée est exécuté par la configuration de programme
standard une fois installé (voir /etc/tiger/cronrc) :
# Vérifie les mesures de sécurité Debian chaque jour à 1h00
#
1 * * deb_checkmd5sums deb_nopackfiles deb_checkadvisories
#
Il y a une vérification supplémentaire que vous pourriez vouloir ajouter, qui
ne fait pas partie des scripts standard cron scripts. Cette
vérification est le script check_patches, qui fonctionne de la
façon suivante :
exécuter apt-get update
vérifier si de nouveaux paquets sont disponibles
Si vous utilisez un système stable et que vous ajoutez la ligne de
source apt pour security.debian.org à votre fichier
/etc/apt/sources.list (comme décrit dans Faire une mise à jour de sécurité, Section
4.2), ce script sera capable de vous dire s'il y a de nouveaux paquets que
vous devez installer. Comme les seuls paquets modifiés dans cette
configuration sont les mises à jour de sécurité, vous pourriez avoir exactement
ce que vous désirez.
Bien sûr, ceci ne fonctionnera par si vous utilisez testing ou sid/unstable, car actuellement, les nouveaux paquets sont probablement beaucoup plus que des mises à jour de sécurité.
Vous pouvez ajouter ce script aux vérifications effectuées par la tâche
cron (dans le fichier de configuration ci-dessus) et
tigercron vous enverra par courrier (à l'expéditeur désigné par
Tiger_Mail_RCPT dans le fichier /etc/tiger/tigerrc)
la liste des nouveaux paquets :
# Vérifie les mesures de sécurité Debian chaque jour à 1h00
#
1 * * deb_checkmd5sums deb_nopackfiles check_patches
#
Vous pourriez également regarder du côté de secpack qui est un
programme non officiel pour effectuer des mises à jour de sécurité depuis
security.debian.org avec des vérifications de signatures écrit par Fruhwirth
Clemens.
À moins que vous ne vouliez dédier du temps à corriger les paquets vous-même quand une faille survient, vous ne devriez pas utiliser la branche unstable de Debian pour des systèmes de production. La raison principale à cela est qu'il n'y a pas de mises à jour de sécurité pour unstable (voir Comment est assurée la sécurité pour les versions testing et unstable ?, Section 11.3.7).
Le fait est que certains problèmes de sécurité peuvent apparaître dans unstable et pas dans la distribution stable. Cela est dû aux nouvelles fonctionnalités ajoutées constamment aux applications fournies, ainsi qu'aux nouvelles applications incluses qui peuvent ne pas encore avoir été testées en profondeur.
Pour effectuer des mises à jour de sécurité dans la branche unstable, il se peut que vous deviez faire des mises à jour complètes vers de nouvelles versions (ce qui peut mettre à jour beaucoup plus que les paquets touchés). Bien qu'il y ait des exceptions, les correctifs de sécurité sont habituellement rétro-portés dans la branche stable. L'idée principale étant qu'entre les mises à jour, aucun nouveau code ne doit être ajouté, seulement des correctifs pour des problèmes importants.
Si vous utilisez la branche testing, il y a plusieurs problèmes que vous devez prendre en compte concernant la disponibilité des mises à jour de sécurité :
Quand un correctif de sécurité est préparé, l'équipe de sécurité rétroporte le correctif pour stable (car stable est habituellement en retard de quelques versions mineures ou majeures). Le responsable du paquet est responsable pour préparer les paquets pour unstable, habituellement basé sur une nouvelle version amont. Parfois, les modifications se produisent en même temps et parfois l'une des distributions reçoit le correctif de sécurité avant. Les paquets de la distribution stable sont testés plus en profondeur que ceux d'unstable car ces derniers peuvent fournir la dernière version amont (qui peut inclure de nouveaux bogues inconnus).
Les mises à jour de sécurité sont disponibles pour la branche unstable quand le responsable du paquet crée une nouvelle version du paquet et pour stable quand l'équipe de sécurité effectue un envoi et publie une DSA. Veuillez noter que ni l'un, ni l'autre ne modifie testing.
Si aucun (nouveau) bogue n'est détecté dans la version unstable de paquet, il est déplacé dans testing après plusieurs jours. Le délai est habituellement de dix jours, bien que cela dépende de la priorité de l'envoi des changements et si l'entrée du paquet dans testing est bloquée par ses relations de dépendances. Notez que si l'entrée du paquet dans testing est bloquée, la priorité d'envoi ne changera pas le temps que cela lui prendra pour y entrer.
Ce comportement peut changer selon l'état de publication de la distribution. Quand une nouvelle version est presque imminente, l'équipe de sécurité ou les responsables de paquet peuvent fournir des mises à jour directement dans testing
Tout d'abord, les mises à jour automatiques ne sont pas complètement recommandées car les administrateurs devraient vérifier les DSA et comprendre l'impact de toute mise à jour de sécurité donnée.
Si vous voulez mettre à jour votre système automatiquement, vous devriez :
Configurer apt pour que les paquets que vous ne voulez pas mettre
à jour restent à leur version actuelle, soit avec la fonctionnalité
d'étiquetage (pinning) d'apt, soit en les marquant comme
hold (à garder) avec dpkg ou dselect.
Pour conserver les paquets à une version donnée, vous devez éditer
/etc/apt/preferences (voir apt_preferences(5)) et
ajouter :
Package: *
Pin: release a=stable
Pin-Priority: 100
FIXME: vérifier si cette configuration est correcte.
Utiliser soit cron-apt comme décrit dans Vérifiez
automatiquement les mises à jour avec cron-apt, Section 9.1.2 et activez-le
pour installer les paquets récupérés, soit ajouter une entrée cron
vous-même pour que la mise à jour soit exécutée tous les jours, par
exemple :
apt-get update && apt-get -y upgrade
L'option -y fera qu'apt supposera une réponse
« yes » pour toutes les questions qui pourraient être posées lors de
la mise à jour. Dans certains cas, vous pouvez vouloir utiliser l'option
--trivial-only à la place de --assume-yes (qui est
équivalent à -y).[50]
Configurer cron pour que debconf ne demande aucune
entrée pendant les mises à jour, ainsi, elles sont faites non
interactivement.[51]
Vérifier les résultats de l'exécution de cron qui seront envoyées
au superutilisateur (sauf si la variable d'environnement MAILTO
est changée dans le script).
Une alternative plus sure peut être d'utiliser l'option -d (ou
--download-only) qui téléchargera les paquets nécessaires, mais ne
les installera pas. Puis, si l'exécution de cron affiche que le
système doit être mis à jour, cela peut être fait manuellement.
Pour accomplir ces tâches, le système doit être configuré correctement pour télécharger les mises à jour de sécurité comme décrit dans Faire une mise à jour de sécurité, Section 4.2.
Cependant, cela n'est pas recommandé pour unstable sans analyse attentive, car vous pourriez placer votre système dans un état inutilisable si un bogue sérieux s'introduit dans un paquet important et est installé sur votre système. Testing est un peu mieux sécurisé concernant ce problème car les bogues sérieux ont une meilleure chance d'être détecté avant que le paquet ne soir placé dans la branche testing (cependant, vous pouvez n'avoir aucune mise à jour de sécurité disponible de quelque façon).
Si vous avez une distribution mixte, c'est-à-dire, une installation de
stable avec des paquets mis à jour de testing ou
d'unstable, vous pouvez jouez avec les préférences d'étiquetage ainsi
qu'avec l'option --target-release d'apt-get pour ne
mettre à jour que les paquets que vous avez mis à jour. [52]
En vous basant sur les informations de base que vous avez générées après l'installation (i.e. l'instantané décrit dans Prendre un instantané (snapshot) du système, Section 4.18), vous devriez pouvoir effectuez un test d'intégrité de temps en temps. Un test d'intégrité pourra détecter des modifications du système de fichiers réalisées par un intrus ou dues à une erreur de l'administrateur système.
Les tests d'intégrité devraient, si possible, être réalisés non connectés.[53] C'est-à-dire, sans utiliser le système d'exploitation du système à contrôler, pour éviter un sentiment de sécurité erroné (i.e. des faux négatifs) produit par, par exemple, des rootkits installés. La base de données d'intégrité par rapport à laquelle le système est vérifiée devrait également être utilisée depuis un support en lecture seule.
Vous pouvez envisager de faire des vérifications d'intégrité en ligne en utilisant l'un des outils d'intégrité de système de fichiers disponibles (décrits dans Vérifier l'intégrité des systèmes de fichiers, Section 4.16.3) s'il n'est pas possible de déconnecter le système. Cependant, des précautions devraient être prises pour utiliser une base de données d'intégrité en lecture seule et également pour assurer que les outils de vérification d'intégrité (et le noyau du système d'exploitation) n'ont pas été falsifiés.
Certains des outils mentionnés dans la sections des outils d'intégrité, comme
aide, integrit ou samhain, sont déjà
préparés pour faire des vérifications périodiques (en utilisant la crontab dans
les deux premiers cas et en utilisant un démon indépendant pour
samhain) et ils peuvent avertir l'administrateur par différents
moyens (habituellement par courriel, mais samhain peut également
envoyer des pages, des alertes SNMP ou des alertes syslog) quand le système de
fichiers est modifié.
Bien sûr, si vous exécutez une mise à jour de sécurité du système, l'instantané pris pour le système devrait être régénéré pour prendre en compte les modifications réalisées par la mise à jour de sécurité.
Debian inclut certains outils pour la détection d'intrusion qui sont utiles pour défendre votre système local ou pour défendre d'autres systèmes dans le même réseau. Ce type de défense est important si le système est très critique ou si vous êtes vraiment paranoïaque. Les approches les plus communes dans la détection d'intrusion sont la détection d'anomalie statistique et la détection de correspondance de modèle.
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.
Quand une attaque particulière est détectée, la plupart des outils de détection
d'intrusion vont soit loguer l'événement avec syslogd, soit
envoyer des courriers à l'utilisateur root (le destinataire du courrier est
habituellement configurable). Un administrateur doit configurer convenablement
les outils afin que de fausses alertes ne soient pas envoyées. Les alertes
peuvent également indiquer 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 règle de sécurité correcte a été mise en
place vis-à-vis des alertes et que les mécanismes techniques pour l'implémenter
sont en place.
Une source d'information intéressante est la checklist
de détection d'intrusion du CERT.
Les outils de détection d'intrusions provenant du réseau scrutent le trafic sur un segment de réseau et utilisent cette information comme source de données. Spécifiquement, les paquets du réseau sont examinés et ils sont vérifiés pour voir s'ils correspondent à une certaine signature.
Snort est un renifleur flexible de paquets ou un logueur qui
détecte les attaques selon un dictionnaire de signature d'attaques. Il détecte
une variété d'attaques et de sondes, tels que des débordements de capacité, les
scans dissimulés de ports, les attaques CGI, les sondes SMB, et bien d'autres.
Snort dispose également d'une capacité d'alerte en temps réel.
Vous pouvez utiliser snort pour un certain nombre d'hôtes de votre
réseau ainsi que pour votre propre hôte. C'est un outil qui peut être installé
sur n'importe quel routeur pour garder un œil sur le réseau.
Installez-le simplement avec apt-get install snort, suivez les
questions et regardez les logs. Pour un cadre de travail de sécurité un peu
plus large, veuillez voir Prelude.
Le paquet snort de Debian est installé avec de nombreuses
vérifications de sécurité activées par défaut. 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 demander des
vérifications supplémentaires spécifiques à ces services.
Note : Les paquets snort disponibles pour Woody sont
plutôt obsolètes et peuvent même être bogués,
vous pouvez récupérer des paquets Snort rétroportés (et signés) fournis par le
responsable à http://people.debian.org/~ssmeenk/snort-stable-i386/.
Il y a d'autres outils plus simples qui peuvent être utilisés pour détecter les
attaques réseaux. portsentry est un autre paquet intéressant qui
peut vous informer lorsqu'un scan de votre réseau est effectué sur votre site.
D'autres outils comme ippl ou iplogger peuvent aussi
détecter certaines 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 paquet Debian
idswakeup, un générateur de fausses alertes et qui inclut un grand
nombre de signature d'attaques communes.
La détection d'intrusion fondée sur l'hôte implique de charger des logiciels sur le système à étudier qui utilise les fichiers de journaux et/ou les programmes d'audit du système comme source de données. Il scrute les processus suspects, scrute les accès d'hôtes et peut même scruter les changements aux fichiers critiques du système.
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érifications sur des problèmes communs liés aux failles de
sécurité, il vérifie la force des mots de passe, les problèmes du système de
fichiers, les processus de communications et d'autres façons par lesquelles
root peut être compromis. Ce paquet inclut de nouvelles vérifications de
sécurité spécifiques à Debian comprenant : les vérifications de MD5sums
des fichiers installés, les emplacements de fichiers n'appartenant pas aux
paquets et l'analyse des processus locaux à l'écoute. L'installation par
défaut configure tiger pour être exécuté chaquet jour, générant un
compte-rendu qui est envoyé au super-utilisateur à propos des compromis
possibles du système.
Des outils d'analyse de journaux comme logcheck peuvent également
être utilisés pour détecter des tentatives d'intrusions. Voir Utiliser et personnaliser
logcheck, Section 4.12.1.
De plus, des paquets scrutant l'intégrité du système de fichiers (voir Vérifier l'intégrité des systèmes de fichiers, Section 4.16.3) peuvent être utiles dans la détection d'anomalies dans un environnement sécurisé. Il est très probable qu'une intrusion effective modifiera certains fichiers du système de fichiers locaux pour court-circuiter les règles de sécurité locales, installer un cheval de Troie ou créer des utilisateurs. De tels événements peuvent être détectés avec les vérificateurs d'intégrité du système de fichiers.
Les LKM (Loadable Kernel Modules ou modules de noyau chargeables) sont des fichiers contenant des composants de noyau chargeables dynamiquement utilisés pour étendre les fonctionnalités de noyau. Le principal avantage d'utiliser des modules est la possibilité d'ajouter des périphériques additionnels comme une carte réseau ou une carte son sans avoir à recompiler le noyau entièrement. Cependant certains pirates peuvent utiliser les LKMs pour les rootkits (knark et adore) afin d'installer des portes dérobées sur des systèmes GNU/Linux.
Les portes dérobées des LKM peuvent être plus sophistiquées et moins
détectables que des rootkits traditionnels. Ils peuvent cacher des processus,
des fichiers, des répertoires et même des connexions sans modifier les codes
sources des binaires. Par exemple, un LKM peut forcer le noyau à cacher des
processus spécifiques dans procps pour que même une bonne copie du
binaire ps ne puisse lister des informations exactes à propose des
processus actuels du système.
Il existe deux approches pour défendre votre système contre les rootkits LKM, une défense proactive et une défense réactive. La détection peut être simple et sans douleur ou difficile et usante selon la mesure que vous choisissez.
L'avantage de ce type de défense est qu'elle prévient des dommages que pourrait
entraîner un rootkit au système. Une telle stratégie est de "les attraper
en premier", c'est-à-dire, de charger un LKM bien défini afin de protéger
le système d'autres LKM infectés. Une deuxième stratégie consiste à retirer la
fonctionnalité de chargement des modules du noyau lui-même. Notez, cependant,
qu'il existe des rootkits qui peuvent fonctionner même dans ce cas, il en
existe certains qui altèrent directement /dev/kmem (la mémoire du
noyau) pour se rendre indétectables.
Debian GNU/Linux fournit quelques paquets qui peuvent être utilisés pour mettre en place une défense proactive :
lcap - Une interface utilisateur agréable pour retirer les
fonctionnalités (contrôle d'accès basé sur le noyau) dans le noyau,
rendant le système plus sécurisé. Par exemple, exécuter lcap
CAP_SYS_MODULE [54]
enlèvera des fonctionnalités de chargement des modules (même pour l'utilisateur
root).[55] Pour plus
d'informations sur ces fonctionnalités, vous pouvez vérifier la section de Jon
Corbet Kernel
development sur LWN (décembre 1999).
Si vous n'avez pas l'utilité de toutes ces fonctionnalités de noyau sur votre
système GNU/Linux, vous pouvez vouloir désactiver le support des modules
chargeables lors de la configuration du noyau. Pour désactiver le support des
modules chargeables, positionnez simplement CONFIG_MODULES=n lors de l'étape de
configuration de construction de votre noyau ou dans le fichier
.config. Cela prévient des rootkits LKM mais vous ne pourrez plus
utiliser les modules avec votre noyau GNU/Linux. Faites attention que la
désactivation des modules peut surcharger le noyau, rendant le support du
chargement nécessaire.
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 d'un fichier du disque,
System.map. Bien sûr, une défense réactive n'avertira
l'administrateur qu'après la compromission du système.
La détection des rootkits dans Debian peut être accomplie avec le paquet
chkrootkit. Le programme Chkrootkit cherche des signes de
présence de plusieurs rootkits connus sur le système local, mais ce n'est pas
un test définitif.
Vous pouvez aussi utiliser KSTAT (Kernel Security Therapy
Anti Trolls) du groupe S0ftproject. KSTAT vérifie la zone mémoire du kernel
(/dev/kmem) pour des informations au sujet de l'hôte cible pour
aider l'administrateur système à trouver et supprimer des LKM .
C'est probablement la section la plus instable et la plus amusante, car j'espère que quelques unes des idées « bah, ça semble dingue » pourraient être réalisées. Vous trouverez ci-dessous certaines idées pour améliorer la sécurité — suivant votre point de vue vous les qualifierez de géniales, paranoïaques, folles ou inspirées.
S'amuser avec PAM (Pluggable Authentication Modules) Comme il est dit dans l'article PAM du phrack 56, la chose bien avec PAM est qu'« On est limité seulement par son imagination ». C'est vrai. Imaginez une connexion root seulement possible avec empreinte digitale ou un scan de l'œil ou une cryptocarte (pourquoi ai-je fait une conjonction de OU et pas de ET ici ?).
Journalisation fasciste. Je voudrais dire que tout ce dont nous avons discuté plus haut est de la « journalisation douce ». Si vous voulez effectuer une vraie journalisation, procurez-vous une imprimante avec du papier listing et journalisez tout en l'imprimant. Ca semble amusant, mais c'est fiable et ne peut être supprimé, ni altéré.
Distribution CD. Cette idée est très simple à réaliser et offre une assez bonne sécurité. Créez une distribution Debian durcie, avec les bonnes règles pare-feu, faites-en une image ISO amorçable et gravez-la sur un cédérom. Vous avez maintenant une bonne distribution en lecture-seule avec environ 600 Mo d'espace pour les services. Assurez-vous juste que toutes les données qui devraient être écrites, soient écrites via le réseau. Il est impossible pour des intrus d'obtenir un accès en lecture/écriture sur ce système et tout changement qu'un intrus ferait peut être désactiver avec un redémarrage du système.
Désactiver la capacité module. Comme décrit auparavant, quand vous désactivez l'usage des modules noyau à la compilation, beaucoup de portes dérobées basées sur le noyau sont impossibles à implémenter car la plupart d'entre elles sont basées sur l'installation de modules noyau modifiés.
Journalisation par câble série (contribution de Gaby schilders). Tant que les serveurs ont toujours des ports série, imaginez-vous ayant une machine dédiée à la journalisation pour un certain nombre de serveurs. Le système de journalisation serait déconnecté du net et connecté aux serveurs via un multiplexeur de ports série (cyclades ou similaire). Maintenant faites journaliser vos serveurs par leurs ports série en écriture seule. La machine de journalisation n'accepterait que du texte en clair en entrée sur ses ports séries et n'écrirait que sur un fichier journal. Branchez un graveur de cédérom/dévédérom et transférez-y les fichiers journaux quand le fichier journal atteint la capacité du média. Maintenant si seulement ils faisaient des graveurs avec des auto-changeurs... Pas aussi "copie-en-dur" que la journalisation directe vers l'imprimante, mais cette méthode peut gérer de larges volumes et les cédéroms prennent moins d'espace de stockage.
Changez les attributs de tous les fichiers avec chattr (tiré du
Tips-HOWTO écrit par Jim Dennis). Tout de suite après que vous ayez installé
et configuré initialement votre système, utilisez le programme
chattr avec l'attribut +i pour rendre les fichiers
non-modifiables (le fichier ne peut être supprimé, renommé, lié ou réécrit).
Envisagez de positionner cet attribut sur tous les fichiers de
/bin, /sbin/, /usr/bin,
/usr/sbin, /usr/lib et tous les fichiers noyau de la
racine. Vous pouvez également faire une copie de tous les fichiers de
/etc/, en utilisant tar et marquez l'archive comme
immuable.
Cette stratégie vous aider à limiter les dégâts que vous pouvez faire quand
vous êtes connecté en root. Vous n'écraserez pas de 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'abri).
Cela rend aussi un large éventail d'exploits de sécurité et de denis de service soit impossibles soit plus difficiles (car beaucoup d'entre eux comptent sur l'écrasement d'un fichier à travers les actions d'un programme SETUID qui ne fournit pas une commande shell arbitraire).
Le seul inconvénient de cette stratégie survient lorsque vous compilez et
installez divers 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 de faire un chattr -i, les fichiers qui vont être
réécrits (et les répertoires auxquels vous voulez ajouter des fichiers) - la
commande make échoue, utilisez juste la commande chattr et
relancez-le. Vous pouvez aussi profiter de l'occasion pour déplacer vos vieux
binaires et bibliothèques dans un répertoire .old/ ou dans une archive tar par
exemple.
Notez que cette stratégie vous empêche aussi de mettre à jour vos paquets
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 drapeau immuable
sur tous les binaires juste avant de faire un apt-get update.
Jouez avec le cablage UTP de façon à couper 2 ou 4 brins et rendez le cable à sens unique. Puis utilisez des paquets UDP pour envoyer des informations à la machine destinatrice qui peut agir en tant que serveur de journalisation sécurisé ou système de stockage de carte de crédit.
Un pot de miel est un système conçu pour apprendre aux administrateurs système comment des attaquants sondent et exploitent un système. Il s'agit d'une configuration système qui a pour but d'être sondée, attaquée et potentiellement exploitée. En apprenant les outils et méthodes utilisées par l'attaquant, un administrateur système peut apprendre à mieux protéger ses propres systèmes et son réseau.
Un système Debian GNU/Linux peut facilement être configuré comme un pot de miel, si vous y consacrez le temps de l'implémenter et de le surveiller. Vous pouvez facilement mettre en place le serveur de pot de miel factice ainsi que le pare-feu[56] qui contrôle le pot de miel et un certain type de détecteur d'intrusion réseau, placez-le sur l'Internet et attendez. Prenez soin de vous assurer d'être averti à temps (voir L'importance des logs et des alertes, Section 4.12) si le système est victime d'un exploit pour que vous puissiez prendre des mesures appropriées et terminer le compromis une fois que vous en avez assez vu. Voici quelques uns des paquets et problèmes à considérer lors de la configuration de votre pot de miel :
la technologie pare-feu dont vous aurez besoin (fourni par les noyaux Linux).
syslog-ng pour envoyer les logs du pot de miel vers un serveur
syslog distant.
snort pour configurer la capture de tout le trafic réseau arrivant
sur le pot de miel et détecter les attaques.
osh, un shell restreint à sécurité amélioré et SETUID root avec
journalisation (voir l'article de Lance Spitzner ci-dessous).
bien sûr, tous les serveurs que vous utiliserez pour votre serveur mot de miel factice. Selon le type d'attaquant que vous voulez analyser, vous renforcerez ou non le pot de miel et vous le conserverez ou non à jour avec les mises à jour de sécurité.
des vérificateurs d'intégrité (voir Vérifier l'intégrité des systèmes de fichiers,
Section 4.16.3) et la boîte à outils du légiste (The Coroner's Toolkit
(tct)) pour faire des audits post-attaques.
honeyd et farpd pour mettre en place un pot de miel
qui écoutera les connexions vers des adresses IP non utilisées et les fera
suivre vers des scripts simulant des services actifs. Regardez également
iisemulator.
tinyhoneypot pour mettre en place un serveur pot de miel simple
avec des services factices.
Si vous ne pouvez pas utiliser des systèmes de réserve pour construire les pots
de miel et les systèmes réseau pour le protéger et le contrôler, vous pouvez
utiliser la technologie de virtualisation disponible dans xen ou
uml (User-Mode-Linux). Si vous choisissez cette route, vous
devrez modifier votre noyau soit avec kernel-patch-xen, soit avec
kernel-patch-uml.
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"). De même, le Honeynet Project fournit des
informations de valeurs sur comment configurer un pot de miel et comment
auditer les résultats d'une attaque.
[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ suivant ]
Manuel de sécurisation de Debian
Version: 3.4, Sun, 06 Nov 2005 22:34:04 +0100jfs@debian.orgdebian-l10n-french@lists.debian.org