%includes;
]>
&header;
Introduction
Cette page web a été conçue afin d'accompagner les utilisateurs, nouveaux venus ou expérimentés,
dans le domaine de la sécurité du système d'exploitation FreeBSD. L'équipe de
développement en charge de FreeBSD considère la sécurité comme une priorité et travaille sans
cesse afin de rendre le système aussi sûr que possible.
Vous trouverez ici des informations complémentaires et des liens vers d'autres ressources
qui vous aideront à configurer votre système afin d'éviter les attaques extérieures,
à savoir qui contacter si vous trouvez une éventuelle faille dans la sécurité du système, etc.
Les programmeurs systèmes seront heureux de trouver une section traitant des techniques à
employer pour éviter avant toute chose de créer soi-même des failles.
Table des Matières
L'Officier de Sécurité FreeBSD
Afin de mieux coordonner les échanges d'informations entre les personnes
concernées par la sécurité, FreeBSD dispose d'un "central" pour les informations relatives à la sécurité :
L'Officier de Sécurité FreeBSD.
Cet Officier de Sécurité est en fait une équipe dont la tâche principale
est d'envoyer des avis de sécurité lorsque des failles sont
connues et d'agir en réponse aux rapports de possibles problèmes de sécurité sur FreeBSD.
Si vous désirez contacter une personne de l'équipe FreeBSD au sujet d'un
éventuel bogue de sécurité, envoyez un message à l'Officier de Sécurité
contenant la description de ce que vous avez découvert et le type de vulnérabilité
que cela représente. Les Officiers de Sécurité sont aussi en relation
avec les équipes du CERT et du FIRST de part le monde, faisant part
ainsi de toutes les éventuelles vulnérabilités de FreeBSD ou des
utilitaires qui l'accompagnent. Les Officiers de Sécurité participe
également aux activités de ces organisations.
Si vous désirez contacter l'Officier de Sécurité sur un sujet
particulièrement sensible, n'hésitez pas à utiliser leurs clés PGP
pour crypter votre message avant de l'envoyer.
Derniers avis de sécurité sous FreeBSD
Les Officiers de Sécurité FreeBSD donnent des avis de sécurité pour les
versions de FreeBSD suivantes :
- La distribution officielle la plus récente de FreeBSD.
- FreeBSD-stable, quand au moins 2 distributions l'utilisent.
- La FreeBSD-stable précédente quand une "nouvelle stable" n'a pas
encore 2 distributions à son actif.
A ce jour, les avis de sécurité sont disponibles pour :
- FreeBSD 3.5.1-STABLE (vulnérabilités exploitables à distance uniquement)
- FreeBSD 4.3-RELEASE
- FreeBSD 4.4-RELEASE
- FreeBSD 4.4-STABLE
Les versions plus anciennes ne sont plus maintenues et les utilisateurs sont vivement
encouragés à mettre leur système à jour.
Comme tout développement, les modifications de sécurité sont d'abord faites sur
la branche FreeBSD-current.
Apres quelques jours de tests, la correction est incluse dans
la (ou les) branches FreeBSD-stable supportée(s) et un avis de sécurité est alors
envoyé.
Quelques statistiques sur les avis de sécurité émis en l'an 2000 :
- Un total de 81 avis ont été émis, concernant à la fois le système
de base (i.e. l'installation par défaut de FreeBSD) et les applications
tierces optionnelles de la collection des ports.
- 24 avis (de sévérités diverses) ont été émis pour le système
de base, les 57 restant concernant les applications tierces optionnelles
de la collection des ports.
- 19 vulnérabilités (8 pour le système de base et 11 pour les ports) ont été découverts
en interne par des membres l'équipe FreeBSD grâce à un audit du
code source.
- 9 avis ont décrits des vulnérabilités concernant uniquement FreeBSD (6
pour le système de base et 3 pour les ports), les 72 restant
étaient des problèmes qui concernaient au moins un autre système d'exploitation (souvent
parce que le code source était commun).
Les avis sont envoyés aux listes de diffusion suivantes :
- FreeBSD-security-notifications@FreeBSD.org
- FreeBSD-security@FreeBSD.org
- FreeBSD-announce@FreeBSD.org
Les avis sont toujours signés avec la
clé PGP
de l'Officier de Sécurité et sont archivées, avec leurs patches associés,
dans notre dépôt FTP CERT
. A ce jour, les avis suivants sont disponibles (veuillez noter que cette liste
n'est pas forcément à jour - pour les tous derniers avis veuillez consulter le
site FTP) :
FreeBSD 4.3-RELEASE.
Les listes de diffusion orientées sécurité de FreeBSD
Si vous administrez ou utilisez d'une manière ou d'une autres des systèmes FreeBSD, vous
devriez vous inscrire à au moins une des listes suivantes :
freebsd-security Discussions sur la sécurité en général
freebsd-security-notifications Avis de sécurité (liste modérée)
Ecrivez à
majordomo@FreeBSD.ORG avec
subscribe <nom_de_la_liste> [<adresse facultative>]
dans le corps du message pour vous inscrire.
Par exemple :
% echo "subscribe freebsd-security" | mail majordomo@FreeBSD.org
Et pour vous désinscrire :
% echo "unsubscribe freebsd-security" | mail majordomo@FreeBSD.org
Eléments de programmation sécurisée
- Ne jamais faire confiance à quelque entrée que ce soit, i.e. arguments de ligne de commande,
variables d'environnement, fichiers de configuration, paquets TCP/UDP/ICMP entrants,
recherche de nom d'hôte, arguments de fonctions, etc. Si la longueur ou le contenu de
la date reçue est sujet à un contrôle extérieure, le programme ou la
fonction devrait la vérifier avant de l'utiliser. Il faut être tout particulièrement
attentif aux choses suivantes :
- Les appels à strcpy() et sprintf() avec des données non bornées. Utilisez strncpy et
snprintf() quand la longueur des données est connue (ou trouvez une manière de vérifier
les bornes si la longueur des données est inconnue). En fait, n'utilisez jamais
gets() ou sprintf(), point. Si vous le faites, nous enverrons des gnomes maléfiques
à votre poursuite.
- Si vous devez vérifier les entrées utilisateur pour voir si elles ne
contiennent pas de caractères interdits, ne recherchez PAS ces caractères. Vérifiez
plutôt si les données ne contiennent QUE les caractères
autorisés. L'idée générale est : interdisez tout ce qui n'
est pas explicitement autorisé.
- Lisez les pages de manuel de strncpy() et strncat(). Soyez certain de
bien comprendre leur fonctionnement !!! strncpy n'ajoutera pas
forcément un \0 à la fin, tandis que strncat() le fera.
- Pas d'utilisation abusive de strvis() et getenv(). Avec strvis() il est facile de
renvoyer une mauvaise chaîne, et getenv() peut renvoyer une chaîne bien plus longue
que celle attendue. Ces deux fonctions sont une des portes d'entrée
de nombreuses attaques, provoquant l'écrasement de la pile
ou de variables en mettant des valeurs invalides dans les variables d'environnement. Si
votre programme lit des variables d'environnement, soyez paranoïaque. Soyez très paranoïaque !
- A chaque appel de open() ou stat() - demandez vous : "Et si c'est
un lien symbolique ?"
- Utilisez mkstemp() plutôt que mktemp(), tempnam(), etc.
Vérifiez avec attention ce que vous faites dans le répertoire /tmp, en gardant à
l'esprit que seulement très peu de choses sont des opérations atomiques dans /tmp :
- La création d'un répertoire. Cela peut réussir ou échouer.
- Ouverture d'un fichier O_CREAT | O_EXCL
Si vous utilisez mkstemp(), les cas précédents seront traités correctement pour vous. Vous
devriez donc utiliser systématiquement mkstemp() pour vos fichiers temporaires afin de garantir
un déroulement sans encombre de votre programme.
- Si un attaquant extérieur peut forcer des paquets à provenir d'un autre système
quelconque alors cet attaquant à un contrôle complet sur les données que vous recevez
et donc AUCUN paquet ne peut être considéré comme sûr.
- Ne jamais considérer un fichier de configuration comme correctement écrit ou
comme généré par l'utilitaire adéquat. Ne jamais considérer que les entrées utilisateur
tels que les noms de terminaux ou de langues ne contiennent pas de '/' ou de '../../../' s'il
y a une chance qu'elles soient utilisées dans un nom de chemin. Ne faire confiance à
AUCUN chemin fourni par l'utilisateur si vous utilisez le setuid root.
- Cherchez d'éventuels trous ou faiblesses dans la façon dont les données sont stockées. Tous les
fichiers temporaires doivent avoir la permission 600 pour être protégés des yeux trop curieux.
- N'utilisez pas que grep pour rechercher les suspects usuels dans les programmes qui tournent
avec des privilèges élevés. Rechercher ligne par ligne du code succeptible de causer des
débordements car il y a bien d'autres moyens de causer des débordements mémoire qu'en
utilisant strcpy() et consorts.
- Ce n'est pas parce que vous diminuez les privilèges à un endroit précis qu'une
attaque est impossible. L'attaquant peut placer dans la pile le code nécessaire
pour regagner les privilèges avant d'exécuter /bin/sh.
- Gérer vos uid. Diminuez les privilèges dès que possible, et
diminuez-les vraiment. Basculer entre euid et uid n'est PAS suffisant.
Utilisez setuid() quand vous le pouvez.
- N'afficher jamais le contenu d'un fichier de configuration en cas d'erreur. Donner plutôt
un numéro de ligne, à la rigueur une position. Cela reste vrai pour toutes les librairies et
pour n'importe quel programme suid/sgid.
- Conseils pour ceux relisant du code pour une amélioration de la sécurité :
- Si vous n'êtes pas certain de vos modifications de sécurité, envoyez les à un relecteur
avec lequel vous vous serez déjà arrangé à l'avance.
Ne validez pas du code dont vous n'êtes pas sûr, car affaiblir du code
sous prétexte de le renforcer peut s'avérer assez embarassant.
- Ceux qui n'ont pas les privilèges d'écritures CVS devraient s'assurer qu'un relecteur
ayant de tels privilèges sera l'un des derniers à relire les changements. Cette personne
révisera et incorporera la version finale de vos changements
dans l'arbre des sources.
- Quand vous enverrez vos modifications pour les faire vérifier, utilisez toujours context ou
unidiff, ainsi les diffs seront facilement passés à patch(1). N'envoyez pas
que les fichiers entiers. Les fichiers diffs sont beaucoup plus simples à lire et à appliquer aux
sources locales (surtout dans le cas de modifications multiples et
simultanées). Tout changement devrait être relatif à la branche -current
du dévelopement.
- Testez directement vos modifications (e.g. recompilez et essayez les sources
modifiées) avant des les envoyez à un relecteur. Personne n'aime recevoir des
fichiers qui ne marchent pas et cela montre seulement que la personne n'a pas fait
très attention à ce qu'elle faisait
(ce n'est pas très bon pour
établir une relation de confiance). Si vous désirez un compte sur une machine possédant
une version spécifique du logiciel - il vous suffit d'en faire la demande. Le projet
dispose de moyens spécifiquement dédiés à de telles requêtes.
- Note aux commiters : n'oubliez pas de réinsérer les patches de la hiérarchie
-current dans la -stable, comme il se doit.
- Ne réécrivez pas le code juste parce que le style ne vous convient pas - cela
complique inutilement le travail du relecteur. Faites le uniquement pour
de très bonnes raisons.
- Faites attention aux programmes faisant une utilisation complexe des gestionnaires
de signaux. Beaucoup de procédures de différentes bibliothèques ne sont pas suffisament
réentrantes pour rendre cet usage sûr.
- Accordez une attention toute particulière aux appels à realloc() - cette fonction
est très souvent mal utilisée.
- Lors de l'utilisation de tampons à taille fixe, utilisez sizeof() pour éviter
les pertes lorsque la taille d'un buffer est changée sans que le code qui l'utilise
ne le soit. Un exemple:
char buf[1024];
struct foo { ... };
...
MAUVAIS :
xxx(buf, 1024)
xxx(yyy, sizeof(struct foo))
BON :
xxx(buf, sizeof(buf))
xxx(yyy, sizeof(yyy))
Faites tout de même attention aux sizeof de pointeurs quand vous voulez
en fait la taille des données pointées !
- A chaque occurence de "char foo[###]", vérifiez chaque utilisation de foo et
assurez-vous qu'elles ne peuvent causer de débordements. Si vous ne pouvez pas éviter le
débordement (cela s'est déjà vu), faites un malloc du tampon pour éviter tout
écrasement dans la pile.
- Fermer les descripteurs de fichiers dès que possible - cela rendra plus
probable l'annulation du tampon stdio. Dans vos bibliothèques, réglez
chaque descripteur de fichier que vous ouvrez à close-on-exec.
Il existe un outil d'audit très utile avec le port its4, situé dans
/usr/ports/security/its4/. C'est un programme d'audit automatisé pour le langage C qui
signale les problèmes potentiels dans le code. C'est un outil utile
pour une première analyse mais qui ne doit pas être considéré comme suffisant.
Un audit complet doit toujours inclure un examen par une personne en chair et en os
de tout le code.
Pour plus d'informations sur les techniques de programmation sécurisée, consulter
le centre de ressources
How to Write Secure Code.
Trucs et astuces de sécurité sous FreeBSD
Plusieurs étapes sont nécessaires pour sécuriser un système FreeBSD, ou
d'ailleurs n'importe quel système UNIX :
- Désactiver tout logiciel potentiellement dangereux
Beaucoup de logiciels nécessitent d'être exécutés avec des privilèges spécifiques pour
accéder à certaines resources, par l'intermédiaire du bit set-uid. Par
exemple un logiciel UUCP ou PPP qui utilise le port série ou
sendmail qui doit écrire dans le spool de mail et bind qui accède à un
port réseau prvilégié. Quand vous n'utilisez pas UUCP, il est de peu d'utilité de
laisser le logiciel correspondant et il est donc sage de le désactiver. Bien sûr,
cela demande une connaissance certaine de l'environnement pour savoir ce qu'on peut désactiver ou non
et des besoins pour savoir quelles fonctionnalités seront nécessaires ou pas
dans le futur.
Certains utilitaires comme swapinfo, qui ne sont que rarement utilisés,
peuvent présenter un risque potentiel. Si on enlève le bit
set-uid de l'éxécutable (avec la commande "chmod ug-s nom_du_fichier") on
pourra toujours utiliser swapinfo, mais seulement en tant que root. Mais ce
n'est pas nécessairement une bonne idée, car en enlevant tous les bits suid,
vous serez obligé de passer toute la journée sous root, ce qui est sans doute pire.
Il ne s'agit pas d'enlever que les programmes inutilisés mais aussi les services que
vous refusez ou dont vous n'avez pas besoin. Vous y remédierez en éditant les
fichiers /etc/inetd.conf et /etc/rc.conf en prenant soin de
désactiver tous les services non désirés.
- Corriger les programmes présentant des bugs de sécurité (ou comment être toujours en
avance sur les crackers)
Inscrivez vous aux différentes listes de diffusion sur la
sécurité afin d'être toujours au courant des trous de sécurité et
des corrections. Appliquez les patches dès que possible.
- Sauvegardes - réparer son système en cas de brêche de sécurité.
Gardez toujours à portée de main vos sauvegardes et une version propre de l'OS (sur
CD-ROM par exemple).
Assurez vous que vos sauvegardes ne contiennent pas de données corrompues ou
modifiées par l'attaquant.
- Installer des logiciels surveillant l'état du système
Les programmes comme tcp wrappers et tripwire (tous les deux dans packages/ports)
peuvent vous aider à surveiller l'activité de votre système. Ce type de logiciel vous
permettra de détecter plus facilement les intrusions. Lisez également les résultats des
scripts /etc/security qui sont lancés quotidiennement et envoyés à root.
- Former et informer les utilisateurs
Les utilisateurs doivent savoir ce qu'ils font. Ils ne doivent jamais donner
leur mot de passe et choisir un mot de passe difficile à deviner.
Faites leur comprendre que la sécurité du système/réseau est aussi
entre leurs mains.
Un Guide sur la Sécurité sous FreeBSD est également disponible, et présente
des conseils avancés pour améliorer la sécurité de votre système. Vous le
trouverez à
http://www.FreeBSD.org/~jkb/howto.html.
La securité est un processus actif. N'hésitez pas à suivre
les derniers développements en la matière.
Que faire face à un compromis en matière de sécurité
- Déterminer le niveau de la faille
Quels privilèges l'attaquant a-t-il gagné ? A-t-il obtenu un accès
root ou simplement utilisateur ?
- Déterminer si l'état du système (noyau ou domaine utilisateur) a été
modifié
Quels logiciels ont été modifiés ? Un nouveau noyau a-t-il été installé ?
Certains binaires systèmes (telnetd, login, etc) ont-t-ils été modifiés ?
En cas de doute sérieux, pensez à éventuellement réinstaller
l'intégralité de l'OS à partir d'une source sûre.
- Déterminer les circonstances de l'attaque
L'attaque a-t-elle été faite via un bug connu ? Si c'est le cas,
installez le(s) patch(es) correspondant(s). L'effraction a-t-elle eu
lieu à cause d'une erreur de configuration ? L'effraction est-elle
due à un bug non répertorié ? Dans ce dernier cas, contactez au plus vite
l'Officier de Sécurité
FreeBSD.
- Réparer la faille
Installez de nouveaux logiciels ou le(s) patch(es) nécessaire(s) pour
remédier au problème. Désactivez tous les comptes compromis.
- Autres resources
CERT offre également de
nombreuses informations
sur la marche à suivre en cas de compromission du système.
Autres informations liées à la sécurité
&footer