mercredi 19 mai 2010

route del default (ou: "et si on réglait définitivement les problèmes de sécurité du LAN" )

La sécurité informatique est un domaine de recherche qui couvre un large spectre de menaces. Certains se spécialisent en reverse engineering, d'autres en spécialistes d'intrusions, en ingénierie sociale, en cryptographie, en protection des réseaux et bien d'autres activités encore.

Le LAN, comme dont je fais référence dans cet article est un réseau d'entreprise, connecté à internet. Ces LANs sont bien évidemment 'at risk'. Les firewalls aujourd'hui fonctionnent relativement bien et les attaques frontales ne sont plus très efficace. Par contre, on observe un énorme regain d'intérêt sur les attaques visant le poste client. Un attaquant cherchera a pousser un poste client à aller chercher lui-même sur internet une charge offensive qui lui permettra de prendre le contrôle de la machine afin soit de rebondir, soit d'extraire des données.

Pour un administrateur SSI (Sécurité des Systèmes d'Informations), la tâche consistant à sécuriser son LAN et éviter ce genre d'attaques revient à une mission impossible pour deux raisons majeures.
La première est évidente: les utilisateurs sont des simples utilisateurs, non conscients des impacts sécuritaire. Lorsqu'un mail d'un "ami" leur arrive et leur demande de cliquer pour voir une video "marrante", ils cliquent, installent un "codec" au besoin, cliquent encore trois ou quatre fois sur des fenêtres de confirmation et se sont fait pirater.
La seconde raison concerne le patch management. En effet, il semble devenu acquis qu'il est impossible de maintenir un parc conséquent à jour. Des virus comme Conficker parviennent à infecter des larges organisations alors même que le virus soit apparu suite au correctif! Ce document et les liens afférents confirme que la cible du "up-to-date" ne sera jamais atteinte.

Ceci étant posé, comment réussir à augmenter le niveau de sécurité ou diminuer l'impact des failles du LAN?

Pour cela, pas de meilleure lecture que les ancêtres ;). En effet, je lisais dans un bouquin (dont je n'ai pas la référence ici) la manière dont une université avait donné accès à internet à un réseau sensible. En ces temps reculés, le masquage n'existait pas. De plus, l'université ne voulait pas router ces IP dû au caractère confidentiel des données sur les machines en question.
L'administrateur a installé une machine avec deux cartes réseaux (une côte LAN une côté internet), qui n'était pas configurée en routeur. Les utilisateurs se connectaient en telnet dessus, puis exportaient en X-DISPLAY le navigateur web sur leur poste local.

Je trouve cette idée excellente et riche d'enseignements, au point même que je pense qu'il faudrait y revenir, ce qui est réalisable en deux étapes.

Première étape: Lister les services dont ont besoin les utilisateurs, qui sont généralement les trois suivants
1- Mail
2- Web
3- flux métiers (par exemple un accès à un serveur TSE ou un accès à une base de données)

Deuxième étape: couper la route par défauti des machines du LAN, d'ou le titre du post de ce blog. En listant ces services, on constate que l'on se passe très bien de passerelle par défaut, voire même de DNS. Le serveur SMTP/POP/IMAP est joint sur le réseau local ou à 1 hop maximum. Les flux réseaux également. Pour le web, il ne faut pas utiliser de proxy. En effet, un virus pourrait récupérer ce paramétrage et sortir sur internet. Il faut utiliser un export DISPLAY afin que seul l'affichage sur le poste local soit effectué. C'est là tout le principe de la méthode. Certains points sont en suspens; notemment l'utilisation d'un web très dynamique (flash, etc..) ou l'envoi de pièces jointes. Généralement ces deux points sont interdits par des politiques d'entreprise (et contournées :) ), avec un export DISPLAY, la politique d'entreprise est d'autant plus respectée que la configuration du navigateur reste sous la maîtrise de l'administrateur.

A peu près toute activité virulente ou offensive risque est donc stoppée dans l'oeuf. Toutes mes récentes lectures de blog de sécurité ou autre qui impliquent une attaque du LAN repose sur ces deux assomptions: A- La machine attaquée pourra résoudre un nom DNS. B- La machine attaquée pourra sortir sur internet. (S'ensuit des débats sans fin préconisant l'utilisation de HTTPS pour éviter les sondes IDS/IPS.)
Je n'ai pas encore vu de botnets ou d'attaques basées sur des communications entièrement asynchrones comme l'email [Cela ne veut pas dire que cela n'existe pas, je fais confiance à l'imagination débordante des pirates :) ].

Avec ma méthode, la gestion de la sécurité revient sur un périmètre gérable et maîtrisable par l'administrateur sécurité ce qui est un énorme gain. Il peut suivre un serveur de mail (ou un pool de), un serveur de sessions X, et une politique de route statique. A la limite, les machines du LAN peuvent ne plus être mises à jour puisque toute faille restera confinée.

En conclusion, essayez d'imaginer votre réseau local sans route par défaut et l'impact que cela donne sur la gestion de la sécurité. Supprimer la route par défaut semble techniquement réalisable, pourquoi s'en priver?

mercredi 12 mai 2010

RMLL 2010

Je présente une conférence aux RMLL 2010 (Rencontres Mondiales du Logiciel Libre) sur le thème de la sécurité informatique intitulée "Le chiffrement de disque sous linux, vrai ou faux sentiment de sécurité?".

Je fournis sur ce blog l'abstract de cette conférence:

Cet article vise à démontrer que le chiffrement de disque sous linux, réalisé via l’utilisation du module noyau dm-crypt et du programme cryptsetup, fait l’objet d’une faille conceptuelle. En effet, le programme déchiffrant le disque réside sur une partition en clair. Il s’ensuit qu’un attaquant peut le modifier à sa guise pour obtenir le mot de passe des partitions chiffrées, ou pour placer un programme malveillant suite au déchiffrement des partitions.

Pour répondre à cette faille, le trusted computing est nécessaire, plus particulièrement la puce TPM et ses mesures des métriques du démarrage. Ainsi, les outils utilisant cette puce (TrustedGrub, trousers et tpm-tools) permettent de présenter une méthode novatrice pour obtenir un boot sécurisé d’une machine. Cette méthode assure que le système démarré est bien un système sain et non un système modifié par un attaquant.

La conférence à lieu le 7 juillet 2010, à 15h aux RMLL.