Catégorie : Sécurité

Gérer les règles iptables d’un parc de serveurs : Netfilter Manager

Antoine 4 commentaires

Cet article va pouvoir expliquer une partie de l’absence d’activité sur ce blog dernièrement. Avant de rentrer dans le vif du sujet, je tiens à prévenir du fait que je ne suis pas, à la base, un développeur et donc que je débute dans le domaine de développement applicatif et du développement Open Source. Soyez-donc indulgent si je fais des erreurs « de base ».

Problématique

Le besoin initial de cette application est la gestion des règles iptables d’un parc de machines. En tant qu’administrateurs système, nous ne retrouvons régulièrement à gérer des scripts iptables sur divers serveurs. Lorsqu’on gère 5-10 serveurs, la gestion à la main reste acceptable. Cependant, dès que l’on commence à gérer plus de serveurs, ca commence à devenir réellement long et fastidieux. Et qui dit fastidieux dit fort potentiel d’erreurs.

J’ai donc entrepris de créer une application qui permettrait de gérer tout ca de manière un peu plus automatisée. L’application Netfilter Manager est donc née. Le nom est pas tout à fait extraordinaire mais ca représente à peu près ce que ca fait.

Présentation

Netfilter Manager utilise donc une interface en ligne de commande afin de pouvoir gérer un lot d’hôtes et les règles associées. Cette CLI est inspirée quelque peu de la CLI Cisco pour ceux qui ont déjà eu la chance l’occasion de l’utiliser. La licence de l’application est GPLv3. J’avoue ne pas être un expert dans le domaine des licences de logiciel mais c’est une des plus répandues et le peu que j’en connais me convient.

Chaque hôte dispose d’un nom et d’une adresse IP. A la place de l’adresse IP, on peut bien sûr utiliser un nom DNS que le serveur de gestion saura résoudre. L’application ne supporte que pour l’instant Iptables, il n’est donc pas encore possible de sélectionner un type d’hôte mais c’est une fonctionnalité envisageable.

Les règles sont ajoutées hôte par hôte et peuvent être organisées par ligne. Par défaut, les règles que vous ajoutées sont ajoutés à la suite des règles existantes. Il est possible de gérer plus finement l’ordonnancement des règles en utilisant la gestion par ligne. Chaque ligne peut comporter plusieurs règles et les règles seront appliquées dans l’ordre croissant des lignes. Ce comportement est très similaire au mode de fonctionnement des access-list Cisco.

Voici un petit exemple d’utilisation :

Il est également possible de créer des lots de règles grâce à un moteur de template dont l’utilisation est expliquée dans le README. Vous trouverez un exemple de template dans le fichier cobalt.tpl présent dans le répertoire templates.

Une fois que vous avez créé toutes les règles de firewall, vous allez pouvoir les « pousser » vers vos serveurs. Un script contenant les règles est généré en prenant les règles que vous avez spécifié et en ajoutant au début le contenu du fichier start.tpl. Par défaut, ce fichier contient des règles permettant de supprimer les règles iptables actuellement utilisées.

Pour en savoir plus sur l’utilisation de l’application, la commande help devrait pour vous aider. Sinon je vous conseille de lire le README (en anglais pour l’instant). J’espère que les explications sont claires et vous permettront de réussir à utiliser l’application. Si ce n’est pas le cas, vous pouvez me le faire savoir soit par ce blog soit par le bugtracker de github.

Bonus

En petit bonus, j’ai ajouté la possibilité de créer des règles en utilisant la syntaxe Cisco. Pour l’instant, seuls les règles IP sont supportées mais les règles TCP/UDP devraient également être supportées par la suite. Dans le mode ajout, il faut utiliser la commande access-list. Un page d’aide a été spécifiquement ajouté, vous pouvez y accéder en tapant access-list help. Je ne suis pas sûr que ce soit d’une utilité débordante mais ca m’a bien amusé de le coder.

Code

Tout le code de l’application est disponible sur github. Vous pouvez télécharger la version courante de l’application en cliquant sur ce lien.

Si vous souhaitez contribuer, vous êtes les bienvenus. Tout se passe via le git proposé par github. L’application est faite en Python et j’ai essayé de rendre le code le plus lisible possible. Si vous souhaitez effectuer des remontées de bugs ou me donner votre avis, vous pouvez le faire sur ce blog ou sur github.

Génération de certifications OpenVPN par lots avec pkitool

Antoine

Ce blog n’est pas particulièrement actif ces derniers temps comme vous pouvez le remarquer. Surement une petite baisse de motivation de ma part mais également les vacances. Aujourd’hui ce sera donc un petit article simple mais efficace.

En Avril, j’avais écrit un petit billet sur la génération de certificats OpenVPN par lots ce qui est bien pratique lorsqu’on doit en générer une quantité importante. J’ai à nouveau rencontré cette problématique mais dans un contexte légèrement différent. Sous Ubuntu Server 10.04, le jeu d’outils Easy-RSA d’OpenVPN n’utilisent plus OpenSSL directement mais utilisent pkitool qui ne semble être qu’un intermédiaire de simplification.

Du coup, le script donné précédemment n’est plus valable. Il a donc fallu trouver une parade assez simple mais non moins fonctionnelle. La solution adaptée à pkitool ne tient plus qu’en un seul script qui est le suivant.

#! /bin/bash
# Make a certificate/private key pair using a locally generated
# root certificate.
export EASY_RSA= »`pwd` »
export OPENSSL= »openssl »
export PKCS11TOOL= »pkcs11-tool »
export GREP= »grep »
export KEY_CONFIG=`$EASY_RSA/whichopensslcnf $EASY_RSA`
export KEY_DIR= »$EASY_RSA/keys »
export PKCS11_PIN= »dummy »
export KEY_SIZE=1024
export CA_EXPIRE=3650
export KEY_EXPIRE=3650
export KEY_COUNTRY= »FR »
export KEY_PROVINCE= »FR »
export KEY_CITY= »Paris »
export KEY_ORG= »Antoine-Corp »
export KEY_EMAIL= »me@myhost.mydomain »
export KEY_CNAME=$1
export EASY_RSA= »${EASY_RSA:-.} »
« $EASY_RSA/pkitool » $*

Le tour est joué ! Vu que WordPress (ou plutôt de ces modules/thèmes) remplace les quotes par des guillemets impossibles à copier/coller dans un shell, je vous mets à disposition une version en texte brut jusqu’à ce que j’ai réussi à résoudre ce problème assez agaçant.

Au final, ce script devrait vous être utile pour générer rapidement des certifications OpenVPN à la pelle et ainsi vous simplifier la vie.

La sécurité de la virtualisation : suite et fin

Antoine 5 commentaires

Cet article complète le précédent sur le sujet de la sécurité de la virtualisation en abordant l’aspect réseau de stockage et essaye de présenter les risques réels de sécurité des plateformes de virtualisation. Il s’agira également du dernier billet sur ce sujet bien que je compte revenir sur ce sujet par la suite.

La sécurisation du stockage

La virtualisation n’ajoute pas de risque particulier à partir du moment où l’on suppose que l’attaquant dispose d’un accès physique aux données. Ce type d’exploit est donc uniquement inhérent au stockage sur disque.

Les réseaux de stockage en Fibrechannel n’ajoutent également pas de risque particulier. Seul les hyperviseurs ont accès aux supports de stockage distribués par le réseau de stockage. De plus, il est possible de gérer finement les accès aux différents supports de disque par les biais des techniques de « zoning ». Le zoning est une technique équivalente aux « Private VLAN » de Cisco dans le cas des réseaux Ethernet.

Contrairement à ce qui a été présenté Samedi dernier, la connexion des équipements Fibrechannel au réseau Ethernet n’ouvre pas de faille supplémentaire. Il n’est pas possible d’utiliser cette interface pour accéder aux données transitant sur le réseau de stockage. L’interface Ethernet permet uniquement d’accéder aux informations de configuration du commutateur.

Supposons qu’il soit possible d’accéder aux données transitant sur le réseau Fibrechannel par le biais de cette interface Ethernet. Toute tentative de spoofing d’adresse MAC serait parfaitement inutile car les réseaux Fibrechannel n’utilisent pas d’adresses MAC mais des WWN qui n’ont rien à voir. Les protocoles de communication sont différents et ne sont pas compatibles.

Cette problématique est cependant intéressante dans le cas des réseaux iSCSI qui n’ont même pas été mentionnés. Il n’est absolument pas souhaitable que les LAN iSCSI soient routables vers d’autres réseaux. Il est même recommandé d’avoir des équipements uniquement dédiés aux fonctionnalités iSCSI dans la mesure du possible.

Récapitulons…

Les potentielles interfaces d’attaque vers les hyperviseurs sont très peu nombreuses. Dans le cas de la virtualisation totale et de la virtualisation matérielle assistée, ces interfaces sont même inexistantes. Dans le cas des interfaces de paravirtualisation, leur utilisation est standardisée par le biais d’API mais la découverte de failles reste envisageable bien qu’aucune n’ait été trouvée à ce jour.

Les mécanismes de DoS sont régulés voire supprimés par les mécanismes classiques d’ordonnancement présents dans toutes les solutions de virtualisation.

Quels sont les risques ?

Les risques réels de sécurité inhérents aux plateformes de virtualisation se situent, d’une part, au niveau des interface de gestion. Les interfaces de gestion ne sont pas propres à la virtualisation mais leur utilisation dans ce cas particulier est généralisé.

L’accès aux interfaces de gestion doivent être sécurisés par les mécanismes réseau traditionnels ainsi que par le biais de méthodes d’authentification. Dans le cas d’une compromission de ces interfaces, les données et l’accès aux machines virtuelles reste indemne. Les interfaces ne disposent généralement pas d’accès particulier aux données, elles disposent uniquement d’une vue globale permettant la configuration des supports de stockage. En ce qui concerne l’accès aux VM, il reste protégé par les protections classiques telles que le couple login et mot de passe. Le passage dans des modes plus privilégiés attireraient inévitablement l’attention car cela nécessiterait des redémarrages non planifiés.

Conclusion

Traditionnellement, on considère qu’une technologie est sécurisée jusqu’à preuve du contraire. Il n’est pas utile de céder au sensationnalisme en décriant des potentielles failles qui n’ont pas été découvertes et qui n’ont jamais été exploitées (dans le cas de Xen).

Si nous suivons cette supposition traditionnelle, nous pouvons affirmer que la virtualisation est une technologie sécurisée. Comme toute technologie informatique, il est nécessaire d’être vigilant lors de son implémentation en suivant quelques règles de bon sens.

Pour revenir au sujet de la présentation effectué lors de la nuit du hack, j’ai été largement déçu par cette présentation aux conclusions au mieux hâtives et des nombreuses autres imprécisions que je n’ai pas évoqué ici.

La sécurité de la virtualisation

Antoine 4 commentaires

Ce weekend avait lieu la Nuit du Hack 2010. Il s’agit d’un événement orienté vers tous les types de hacking. De nombreuses conférences étaient proposées au public venu pour l’occasion avec notamment une présentation du hacking de l’iPhone et de la PS3.

Une présentation a particulièrement attiré mon attention mais pas pour de bonnes raisons. En fin de soirée avait lieu une conférence intitulé « Virtualisation et sécurité ». J’attendais donc avec impatience cette conférence. Autant dire que cela a été une grande déception. Le sujet était traité d’un point de vue beaucoup trop global mais, surtout, les informations soutenues étaient plus que discutables.

Je vais donc profiter de cette espace pour tenter d’éclaircir certains points par rapport à la sécurité de la virtualisation.

Classification

Avant de plonger dans l’étude à proprement dit de la sécurité dans la virtualisation, il est intéressant de se replonger dans la classification des solutions. Lors de la présentation, il avait été différencié les types de virtualisation suivants : « full virtualisation », « paravirtualisation » et « hyperviseurs ».

Un hyperviseur n’est pas un type de virtualisation mais une application qui peut effectuer de la virtualisation. Il est possible de les classifier selon deux catégories bien que cette division ne me plaise pas particulièrement.

La sécurisation de l’hyperviseur : DoS & DDoS

Lors de la présentation, le DoS (Denial of Service) et le DDoS (Distributed Denial of Service) ont été désignés comme des solutions simples et efficaces de neutraliser une plateforme de virtualisation.

Dans le cas de Xen, il est pratiquement impossible de communiquer avec l’hyperviseur. Il ne faut bien sur par confondre hyperviseur et domaine 0 (ou console de gestion dans le cas de VMWare). L’attaque DoS est donc difficile à imaginer dès le départ. L’interface de communication avec l’hyperviseur dont nous disposons est l’API des hypercalls, remplaçants des appels systèmes classiques dans le cas de la paravirtualisation.

L’utilisation des ces hypercalls est limitée par les algorithmes d’ordonnancement système ce qui empêche une utilisation abusive. Il s’agit du même mécanisme que celui utilisé pour le partage des ressources physiques. Le DoS semble donc impossible par ce biais.

Les outils d’administration sont également un potentiel point d’entrée supplémentaire. Ces outils ne sont accessibles qu’à partir du domaine 0 qui peut difficilement être considéré en tant que VM comme les autres. Un attaque DoS sur le domaine 0 rendrait les mêmes résultats qu’une attaque DoS sur les autres machines virtuelles étant donné les mécanismes d’ordonnancement.

La communication avec l’hyperviseur n’étant possible que par ces interfaces, il parait impossible d’y effectuer une attaque DoS capable d’atteindre toutes les machines virtuelles de la plateforme.

La sécurisation de l’hyperviseur : cloisonnement

Le cloisonnement des machines virtuelles est bien sûr une caractéristique élémentaire d’une plateforme de virtualisation. Contrairement à ce qui a été dit, l’hyperviseur n’a pas « la main » sur les machines virtuelles. Il a simplement la possibilité de les éteindre, de les démarrer ou de les mettre en pause. Ni plus, ni moins.

Le cloisonnement est géré par la restriction des accès mémoire. Les hyperviseurs ont été spécifiquement prévus afin d’éviter un débordement des accès vers la mémoire. Le seul vecteur d’exploitation de ce type de faille est les hypercalls dans le cas de Xen. A ce jour aucune faille connu permet d’accéder à des zones mémoires non autorisées.

De plus dans le cas de la virtualisation totale et de la virtualisation matérielle assistée, les machines virtuelles ne disposent même pas d’interface spécifique avec l’hyperviseur ce qui rend pratiquement impraticable de ce type de vulnérabilité.

Les risques d’erreur de cloisonnement ne sont pas inexistants bien entendu cependant il ne faut pas perdre de vue qu’il s’agit de l’objectif même de la conception de l’hyperviseur et que les machines virtuelles disposent de très peu ou aucune interface de communication avec l’hyperviseur afin de l’induire en erreur.

Dans le prochain (et dernier épisode), nous étudierons les autres points abordés lors de la présentation et les risques réels associés à la virtualisation. Loin de moi l’idée de prêcher la sécurisation totale de la virtualisation, je pense cependant qu’il est très facile et réducteur d’agiter des menaces sans fondement pratique.

Livre sur la cryptographie : Cryptographie en pratique

Antoine 2 commentaires

En tant qu’administrateurs réseau ou systèmes, nous utilisons quotidiennement un élément sur lequel repose la majeure de partie de la sécurité de nos infrastructures : la cryptographie. Nous la retrouvons pour chiffrer les données que nous ne souhaitons pas voir interceptées ou bien pour effectuer de la déduplication de données (au hasard). La cryptographie est un élément central dans l’informatique depuis de très nombreuses années.

Souhaitant mieux comprendre ce domaine, je suis parti à la quête d’un livre. De nombreux livres en cryptographie ne sont clairement pas tournés vers les informaticiens mais vers le mathématiciens. Un tel niveau de compréhension n’est pas forcément nécessaire. « Cryptographie en pratique » est un ouvrage adapté à notre situation. Un niveau lycée en mathématiques est demandé pour les explications les plus compliquées ainsi qu’un peu de patience et de relecture pour certains passages.

Ce livre a pour but d’effectuer un tour d’horizon des différentes techniques de chiffrement utilisées aujourd’hui et leurs applications dans le monde réel. Ainsi, vous pourrez comprendre ce qu’est un MAC ou bien comment fonctionne AES. Les auteurs, Bruce Schenier et Nils Ferguson, sont de réelles pointures dans la matière et distillent les retours d’expérience à travers cet ouvrage.

Une partie du contenu de ce livre ne doit plus être tout à fait à jour car il date de 2002 mais une grande partie est clairement atemporel.

Au final, ce livre a été un plaisir à lire et m’a permis de mieux comprendre le fonctionnement et les enjeux de la cryptographie. Je vous le recommande très chaleureusement.

Génération de certificats OpenVPN par lots

Antoine 4 commentaires

J’ai déjà eu l’occasion de parler d’OpenVPN plusieurs fois sur ce blog car je pense qu’il s’agit d’une application très intéressante. J’avais déjà traité l’installation d’OpenVPN sur OpenSolaris et le client MacOS Viscosity. Une problématique régulièrement rencontrée est la génération de certificats SSL pour OpenVPN afin de créer des accès utilisateur à un serveur.

La méthode la plus simple consiste à utiliser les outils easy-rsa en ligne de commande. Ces outils simplifient réellement la tâche par rapport à l’utilisation directe d’OpenSSL. Le problème avec l’utilisation de ces outils est la nécessité d’interagir avec le terminal. Cet outil va vous demander bon nombre de renseignements tels que le pays, la ville, l’adresse email, etc. Cette interaction rend compliquée la création par lots de certificats.

Une méthode plus compliquée, mais plus efficace, consiste à adapter les scripts easy-rsa afin de rendre leur utilisation plus linéaire et non interactive afin qu’un script puisse les exécuter. De plus, j’ai souhaité donner la possibilité de spécifier la durée de validité du certificat au cas par cas, ce qui n’est pas possible par défaut.

Le premier script, build-key-batch, permet de créer une clé en spécifiant une durée de validité. Il n’y a qu’une toute petite modification qui permet de récupérer la durée de validité passée en argument.

#!/bin/sh

if test $# -ne 2; then
     echo « usage: build-key-batch <name> <duree> »;
     exit 1
fi

if test $KEY_DIR; then
     cd $KEY_DIR && \
     openssl req -days $2 -nodes -new -keyout $1.key -out $1.csr -batch -config $KEY_CONFIG && \
     openssl ca -days $2 -out $1.crt -in $1.csr -batch -config $KEY_CONFIG && \
     chmod 0600 $1.key
else
     echo you must define KEY_DIR
fi

Par défaut, easy-rsa nécessite d’exécuter le fichier vars dont le rôle est d’exporter un certain nombre de variables d’environnement utilisées par les scripts de génération de clé. Cela ne me convenait pas car je souhaitais exécuter un seul fichier contenant toutes les informations dont je pouvais avoir besoin. J’ai donc créé un script nommé build-batch qui contient toutes les options.

#!/bin/sh
if test $# -ne 2; then
     echo « usage: batch-build <name> <duree> »;
     exit 1
else
     # Definition des variables
     export D=`pwd`
     export KEY_CONFIG=$D/openssl.cnf
     export KEY_DIR=$D/keys
     export KEY_SIZE=1024
     export KEY_COUNTRY=FR
     export KEY_PROVINCE=XX
     export KEY_CITY=Paris
     export KEY_ORG= »Keeyyyy »
     export KEY_EMAIL= »$1″
     export KEY_CNAME=$1
     ./build-key-batch $1 $2
fi

Ce script nécessite une petite modification du fichier openssl.cnf présent dans le dossier easy-rsa qui est la suivante :

commonName = Common Name (eg, your name or your server\’s hostname)
commonName_max = 64
++ commonName_default = $ENV::KEY_CNAME

Le script a exécuter afin de générer un certificat est donc build-batch suivi de deux arguments qui sont le nom du certificat et la durée de validité. Vous pourrez ainsi générer des certificats pour OpenVPN simplement et efficacement sans nécessiter une intervention humaine.

Source : insights