Archives de catégorie : Linux

Proxy Squid + Squidguard et intégration Active Directory

 Objectif

L’objectif de ce tutoriel, est d’installer un proxy Squid avec un filtrage de contenu géré par Squidguard. Le serveur sera intégré à un domaine Active Directory 2008 pour permettre une authentification des utilisateurs par NTLM/Kerberos.
Webalizer sera utilisé pour générer des rapports d’utilisation du proxy.

Continuer la lecture

Installation d’un serveur de fichier (Samba/NFS)

Objectif

L’objectif de ce tutoriel est de mettre en place un serveur de fichiers (sous Ubuntu/Debian) et que des postes client (Linux et Windows) puissent y avoir accès, le tout de manière sécurisée.
Les postes client sous Windows auront accès au partage en passant par Samba et les postes client sous Linux utiliseront le partage NFS.

Continuer la lecture

Gestion des ACL sous Debian

Objectif

L’objectif de ce tutoriel est la mise en place et la gestion des ACL sous Linux. Les ACL (Access Control List, ou Liste de Contrôle d’Accès) permettent d’étendre les droits POSIX (type user:group:others) en décrivant des droits pour des utilisateurs ou groupes supplémentaires.

L’intérêt de ce système se retrouve principalement sur des serveurs, dans des contextes de travail collaboratif.

Dans l’exemple suivant, je me suis basé sur un de mes besoins: Droits sur la HomeDir standards préservés (755) et un accès web en lecture/écriture sur un répertoire des homes.

Il s’agit ici uniquement d’un exemple sur l’utilisation des ACL avec quelques notions de base. Pour aller plus loin, consultez les sources en bas de page.

Continuer la lecture

Utilisation de LVM pour gérer un volume de disques

Objectif

Ce tutoriel peut être utilisé comme la suite du tutoriel sur la  Mise en place d’un RAID-1 Logiciel ou tout simplement avec des disques physiques non monté en RAID.

L’exemple d’installation qui suivra se base sur un volume RAID de 1000.2 Go, dont l’installation a été décrite dans le tutoriel RAID (lien ci-dessus).
Le volume physique utilisé dans tout l’exemple sera /dev/md0 (qui correspond aux RAID1 de 1000.2 Go).

Quelques explications sur LVM

Fonctionnement

LVM (ou Logical Volume Management) permet de créer une sorte de « couche d’abstraction » entre vos disques durs, unités RAID ou encore unité SAN et la gestion de vos points de montage.
Cela permet de gérer de manière plus souple vos allocations d’espace disque pour chaque point de montage.

Le principe de fonctionnement LVM se base sur des PV ou Physical Volumes (volumes physiques) tels que des disques durs, des unités RAID, des espaces distants tels que des SAN, DAS.
Toutes ces unités (PV) sont regroupées dans un VG ou Volume Groups, (groupes de volumes) pour former un espace de stockage plus important.
Dans ce (ou ces) VG, on découpe ensuite des LV ou Logical Volumes (volumes logiques) qui seront formatés puis monté sur différents points de montage.

Continuer la lecture

Mise en place d’un RAID-1 Logiciel

Objectif

L’objectif de ce tutoriel est la mise en place d’un RAID logiciel sous Linux. C’est-à-dire, l’installation et la configuration de l’outil mdadm.
Dans ce tutoriel, nous installerons un RAID-1. L’exemple pris est celui de deux disques durs de 1To en SATA.
L’avantage du SATA sur le IDE, est la possibilité du Hot-Plug, ou branchement à chaud, qui pourrait s’avérer utile dans l’avenir en cas de défaillance d’un des deux disques.

Continuer la lecture

Configuration d’une connection SSH

Objectif

L’objectif de ce tutoriel est de mettre en place une connexion SSH depuis un poste client Windows vers un poste Linux (Serveur), le tout de manière automatisée (utilisation de clef SSH).

L’architecture des exemples sera la suivante:

Sur le serveur A (Linux) sera installé OpenSSH Server, sur le client B (Windows) on utilisera Putty et sur le client C (Linux) le client OpenSSH.

Continuer la lecture

SSL/PGP, Modèles de confiance

Introduction

Nous allons essayer de faire une comparaison de deux modèles de confiance très répandu de nos jours :

  • SSL: Secure Socket Layer
  • PGP: Pretty Good Privacy

Quels sont leurs fonctionnement ? Quels sont leurs buts ? Sont-ils de véritables concurrents, ou bien deux technologies différentes ? Qui est le plus « sûr » ? Nous tenterons de répondre à toutes ces questions dans cette étude.

La première partie sera consacrée à SSL, son fonctionnement, ses applications. La seconde portera sur PGP, son fonctionnement, ses applications. Enfin la troisième tentera de confronter ces deux solutions.

Principes de Cryptographie

Pour commencer, il est intéressant de définir différents principes de cryptographie utilisés par ces deux technologies.

Cryptographie asymétrique

La cryptographie fonctionne sur le principe d’une fonction à sens unique, c’est-à-dire qu’il est facile de la calculer dans un sens mais quasiment impossible de retrouver les données d’entrées de la fonction en ne regardant que le résultat.

[Note] Exemple
Soit l’opération a = bc et b,c deux nombres premiers. Il est très facile de calculer a en connaissant b et c. Par contre, trouver b et c depuis en ne connaissant que a, le résultat, ceci est irréalisable.

Dans le cas de la cryptographie asymétrique, on utilise une brèche secrète permettant d’inverser l’opération et de retrouver les données d’entrée de cette fonction. Cette brèche secrète est la clef privée. Elle doit être tenue secrète.

Admettons qu’Alice souhaite recevoir des informations chiffrée de la part de Bob. Alice va donc générer une valeur de cette fonction à sens unique, ainsi que la brèche secrète. La valeur est dans notre cas la clef publique. Elle sera transmise à Bob. La brèche secrète de cette fonction, la clef privée, sera gardée précieusement secrète par Alice.

Figure 1. Envoi de la clef publique

Envoi de la clef publique

Maintenant, Bob pourra chiffrer le message qu’il souhaite envoyer à Alice, en s’assurant que seul le possesseur de la clef privée sera capable de déchiffrer ce message (donc Alice).

Figure 2. Communication chiffrée entre Bob et Alice

Communication chiffrée entre Bob et Alice

Dans ce fonctionnement, on s’assure de la réception des données par un destinataire précis.

Alice peut également utiliser sa clef privée pour signer un message. Car quand Bob recevra le message d’Alice, il va pouvoir utiliser la clef publique d’Alice pour s’assurer que le message a bien été signé par la clef privée d’Alice. On parle à ce moment là de l’authentification, car on est en mesure de savoir de qui provient le message. Si on étend ce système à toute personne de la conversation (paire clef publique, clef privée), chacun est capable de s’authentifier auprès de son interlocuteur lorsqu’il envoie des messages.

La cryptographie asymétrique est principalement utilisée dans PGP pour l’échange de clef de la cryptographie symétrique, puisqu’il faut un moyen sûr d’échange des clefs dans cette seconde technique expliquée ci-dessous.

Cryptographie symétrique

La cryptograhie symétrique fonctionne sur des clefs privées. On donne notre clef de chiffrement (qui est le plus souvent identique à la clef de déchiffrement) au destinataire des messages.

Si Alice veut échanger des données avec Bob, il faut qu’elle transmette dans un premier temps sa clef privée à Bob (généralement par un canal sécurisé sinon le chiffrement n’a plus d’intérêt dans le sens où la clef privée pourrait être interceptée par Carole). Puis elle pourra chiffrer ses messages avec sa clef pivée et Bob pourra les déchiffrer.

Figure 3. Echange de données par cryptographie symétrique

Echange de données par cryptographie symétrique

De même, Bob est obligé d’envoyer sa clef à Alice pour communiquer de manière sécurisée avec elle.

Cette technique de cryptographie a l’avantage d’être simple et peu gourmande en terme de ressources, mais elle demande certains investissements afin de sécuriser le transfert des clefs au destinataire.

Cryptographie hybride

La cryptographie hybride repose sur les principes de cryptogrpahie asymétrique (cf. Section 2.1, « Cryptographie asymétrique ») et symétrique (cf. Section 2.2, « Cryptographie symétrique »), combinant ainsi les avantages des deux techniques. Elle combine l’avantage des deux solutions, principalement en utilisant la cryptographie asymétrique pour transmettre la clef de session utilisée par la cryptogrpahie symétrique.

SSL: Secure Socket Layer

Historique

SSL a été développé en 1994 par Netscape, Mastercard, Bank of America, MCI et Silicon Graphics. Il existe des versions SSL v2 et SSL v3. Depuis le rachat par l’IETF en 2001 du brevet sur le SSL déposé par Netscape, cette technologie a été rebaptisée TLS (Transport Layer Security). Communément, on parle de SSL pour parler soit de TLS soit de SSL. Nous utiliserons la notation SSL.

Fonctionnement de SSL

SSL fonctionne sur le principe de Socket sécurisées par un système de clefs symétriques RSA (du nom des concepteurs: Rivest – Shamir – Adleman).

Couche Réseau

SSL se trouve dans la pile de protocoles TCP/IP, au niveau de la couche session entre les couches applications et la couche transport. la couche SSL est implémentée par la couche application (on associe SSL aux protocoles de couche supérieure comme HTTP, FTP, IMAP,…). On a donc une encapsulation de ces protocoles applicatifs (non sécurisés) dans cette couche SSL, qui elle-même sera encapsulée en TCP ou UDP.

Ports de communication SSL

Les ports utilisés par SSL ont été définis par l’IANA (Internet Assigned Numbers Authority, Organisation américaine qui gère notamment l’assignation des numéros de ports utilisés par les différents protocoles internet). Voici quelques exemples de Numéros de ports pour les protocoles utilisant SSL:

  • HTTPS: 443
  • IMAPS: 993
  • POP3S: 995

Les numéros de ports prédéfinis par l’IANA sont disponibles dans le fichier /etc/services.

Fonctionnement du Protocole SSL

La communication par SSL débute avec la phase de poignée de main (ou HandShake pour les anglicistes). Cette phase se déroule selon le protocole suivant:

  • Client HelloLe client envoie un message Client Hello au serveur en spécifiant par ordre décroissant de longueur de clef tous les cryptosystèmes qu’il supporte, ainsi qu’un SessionID, qui permettra au serveur d’identifier la session avec ce client précis.
  • Serveur HelloLe serveur répond alors au client par un message Server Hello en spécifiant le cryptosystème qui sera utilisé, ainsi que sa clef publique (généralement certifiée par un CA (Certificate Authoritate).
  • Vérification des informations par le clientLe client vérifie alors trois informations envoyées par le serveur:
    • si le certificat a été signé par une autorité de sertification (par exemple Verisign)
    • Si le nom du certificat correspond bien au nom du serveur
    • Si le certificat n’est pas périmé

    Si un de ces trois points n’est pas satisfaisants, un message est envoyé à l’utilisateur, lui demandant s’il désire continuer.

    Figure 4. Message envoyé au client en cas de problème

    Message envoyé au client en cas de problème

     

  • Génération d’une clef de session par le clientSi ces trois points sont validés, le client va générer une clef de session (utilisation de la cryptographie symétrique cf. Section 2.2, « Cryptographie symétrique ») et la chiffre avec la clef publique précédemment envoyée par le serveur (utilisation de la cryptographie asymétrique cf. Section 2.1, « Cryptographie asymétrique ») pour la renvoyer de manière sécurisée vers le serveur.
  • Communication sécurisée avec le clientA présent, le serveur et le client peuvent communiquer de façon sécurisée (grâce à la clef de session générée par le client), car ils sont les seuls à posséder cette clef. La communication se fait par le principe de cryptographie symétrique (cf. Section 2.2, « Cryptographie symétrique ».

 

3.2.4. Sécurité de la communication

Le SessionID permet d’améliorer la sécurité de la communication, car en cas de rupture de la communication TCP, le client se reconnectera au serveur en utilisant ce numéro de session. Le serveur va alors le vérifier avec les informations de son cache. Si celui-ci correspond, alors il reprendra la session avec le client sans relancer la négociation HandShake.

3.3. Utilisation privilégiée de SSL

SSL est donc un protocole de communication permettant d’ajouter à des protocoles applicatifs tels que HTTP. Les sites web commerçants sont certainement les plus gros utilisateurs de ce protocole.

4. PGP: Pretty Good Privacy

4.1. Historique

PGP a été développé par Philip R. Zimmerman, informaticien américain, en 1991. Cela lui a valu plusieurs problèmes avec la justice. C’est une technique de cryptographie très sûre, permettant de résister aux intrusions de la plus grande institution du monde en terme de surveillance, la NSA.

4.2. Philosophie de PGP

Philip R. Zimmerman a mis au point cette technologie pour permettre au peuple de garantir sa sphère privée dans un univers numérique qui peut remettre en cause sa sureté. En effet, la Constitution américaine ne prévoit pas la protection des conversations privées (ce qui était inutile à l’époque, car toutes les conversations étaient privées). Mais avec l’ère de l’informatique, de plus en plus d’échanges se font par le biais des technologies numériques (email, téléphonie…) et nos conversations passent par des réseaux de communications « en clair » et sont susceptibles d’être interceptés par des personnes plus ou moins bien intentionnées.

C’est par ce constat que le créateur de PGP a souhaité offrir à quiconque un moyen de garder privé et personnel ce qui avait besoin de l’être.

Je vous laisse la possibilité de consulter l’article de Philip R. Zimmerman justifiant la création de PGP que vous trouverez dans la bibliographie ([zimmerman_pgp]

4.3. Fonctionnement de PGP

PGP est un système dit hybride, car il utilise les principes de cryptographie asymétrique (cf. Section 2.1, « Cryptographie asymétrique ») et cryptographie symétrique (cf. Section 2.2, « Cryptographie symétrique »).

4.3.1. Combinaison de ces deux techniques

Dans le cadre de PGP, on utilise la combinaison de ces deux techniques de cryptographie. Comment cela se passe-t-il en pratique dans PGP ?

4.3.1.1. Du côté de l’émetteur du message

Le processus de chiffrement par PGP passe par plusieurs étapes que nous allons détailler ci-dessous.

  • Compression des Données
  • Chiffrement du message
  • Chiffrement de la clef de session dans ce message
  • Envoi du message

 

4.3.1.1.1. Compression des Données

Il y a deux intérêts à compresser les données. D’une part, une fois compressé, les temps de transmission du message sont plus courts. D’autre part, on améliore la sécurité des données, car la compression évite l’analyse du modèle du message (observation des fréquences des lettres, des mots répétés…).

4.3.1.1.2. Chiffrement du message

On génère ensuite une clef de session aléatoire par l’algorithme CAST-128 (également appelé CAST5), inventé en 1996 par Carlisle Adams et Stafford Tavares. C’est un algorithme de chiffrement par bloc. Le message est alors chiffré par cryptographie symétrique (cf. Section 2.2, « Cryptographie symétrique ») avec cette clef de session.

4.3.1.1.3. Chiffrement de la clef de session au sein de ce message

Puis cette clef de session précédemment utilisée est chiffré avec ce message grâce à la clef publique du destinataire. On applique alors le principe de cryptographie asymétrique (cf. Section 2.1, « Cryptographie asymétrique »).

 

Figure 5. Schéma Récapitulatif

Schéma Récapitulatif

Ainsi en utilisant une cryptographie hybride (cf. Section 2.3, « Cryptographie hybride »), on a trouvé un moyen efficace de transférer la clef privée de la cryptographie symétrique et éviter toute tentative d’interception du message puisqu’il faut posséder la clef privée du destinataire pour déchiffrer la clef de session (cf. Section 4.3.1.2.2, « Déchiffrement de la clef de session »), et avoir accès au contenu du message.

4.3.1.2. Du côté du destinataire du message

Pour accéder au message du côté du destinataire, on reprend les étapes dans le sens inverse.

  • Réception du message
  • Déchiffrement de la clef de session
  • Déchiffrement du message avec la clef de session
  • Décompression des données

Voyons ces étapes en détail.

4.3.1.2.1. Récéption du Message

Le message reçu est chiffré, il faut alors commencer par déchiffrer la clef de session.

4.3.1.2.2. Déchiffrement de la clef de session

Le déchiffrement de la clef de session se fait exclusivement avec la clef privée du destinataire, car elle a été au préalable chiffrée avec la clef publique fournie par le destinataire à l’émetteur. On applique ici les principes de la cryptographie asymétrique (cf. Section 2.1, « Cryptographie asymétrique »). Une fois la clef de session récupérée, on peut passer à l’étape suivante, le déchiffrement du message compressé.

4.3.1.2.3. Déchiffrement du message avec la clef de session

Le message compressé ayant été chiffré par la clef de session générée aléatoirement par l’émetteur (et transmise dans le message final), on l’utilise pour déchiffrer le message compressé. C’est le principe de la cryptographie symétrique (cf. Section 2.2, « Cryptographie symétrique »). Une fois déchiffré, il ne reste plus qu’une étape pour accéder au message en clair.

4.3.1.2.4. Décompression du message

Le message déchiffré, il ne reste plus qu’à le décompresser pour avoir accès à l’information en clair.

 

Figure 6. Schéma Récapitulatif

Schéma Récapitulatif

Grâce à la cryptographie hybride (cf. Section 2.3, « Cryptographie hybride »), on a pu assurer l’unicité du destinataire, car lui seul possède la clef privée permettant de récupérer la clef de session (sauf fuite de la clef privée vers une tierce personne).

4.4. Utilisation privilégiée de PGP

PGP est donc utilisé principalement pour signer ou chiffrer des messages ou des données. C’est un moyen sûr et facile d’utilisation pour communiquer de manière sécurisée avec ses proches, ou encore de s’assurer qu’un message (email par exemple) provient bien de la personne que l’on désire.

5. Confrontation des deux solutions

La « confrontation » de ces deux solutions de sécurité se fera par rapport à l’utilisation, leur simplicité à être mises en oeuvre, ainsi que d’un point critique, la sûreté de ces systèmes.

5.1. Utilisation

SSL est utilisé comme couche réseau pour sécuriser des protocoles de communication, le plus souvent à travers la toile(d’où le nom de Secure Socket Layer).

PGP quant à lui est plus destiné à protéger des données, mêmes stockées sur un disque dur, ou envoyées par des moyens de communication non sécurisés (tel que l’envoi d’e-mails par exemple). Il peut également servir de signature de documents pour s’assurer de l’émetteur.

Ces deux solutions ne s’affrontent pas réellement sur le même terrain, et on peut les imaginer complémentaires (pourquoi pas se connecter sur un serveur Webmail par SSL et transférer des emails chiffrés à un ami).

5.2. Simplicité

Les deux solutions sont assez simples à mettre en oeuvre. Dans le cas de SSL, côté client, il n’y a rien à faire, et côté serveur, OpenSSL est très bien documenté sur la toile quant à sa mise en place et la création de certificats.

PGP dispose aussi de logiciels libre d’utilisations (au fonctionnalités moins avancées que les versions payantes) comme par exemple GPG (Gnu Privacy Guard).

5.3. Sûreté

la sûreté de PGP et de SSL ont déjà été éprouvées, et s’avèrent aujourd’hui des produits très sûrs. Le seul invonvénient de SSL c’est qu’il dépend de navigateurs clients révélants certaines failles de sécurisées. Un exemple peut être pris, celle découverte en 2000: les clients web Internet Explorer 4.x, 5.x et Netscape 4.x laissaient une faille de sécurité assez critique, puisqu’ils se référaient uniquement à l’adresse IP du serveur pour séparer les différentes sessions SSL. Une usurpation d’adresse IP par un site malveillant pouvait détourner les informations envoyées dans cette session « sécurisée » (cf. article du CERTA [certa_sessionssl]). Il existe encore de nombreuses failles de sécurité découvertes régulièrement sur le protocole SSL mais provenant principalement du fait qu’il est implémenté sur d’autres couches et applications possédant elles-mêmes des failles. (cf. articles publiés par le CERTA).

6. Conclusion, Ouverture

Aujourd’hui, en France, le chiffrement des données a été rendu publique afin de protéger les conversations personnelles et plus en général la sphère privée de chacun. En ces temps houleux de défense de droits d’auteurs, de surveillance de l’internaute, il est plus qu’urgent de connaître ces connaissances mises à disposition du peuple pour se défendre et garantir la liberté de chacun. Il est important de savoir que dans de nombreux pays (Chine, Etats-Unis notamment), l’utilisation du chiffrement à titre personnel est interdit et puni par la loi.

Bibliographie

[zimmerman_pgp] Philip R. ZIMMERMANPourquoi j’ai écrit PGPhttp://biblioweb.samizdat.net/article.php3?id_article=4

Wikipédia.orgCryptograhie Symétriquehttp://fr.wikipedia.org/wiki/Cryptographie_asym%C3%A9trique

Wikipédia.orgCryptograhie Asymétriquehttp://fr.wikipedia.org/wiki/Cryptographie_asym%C3%A9trique

[certa_sessionssl] CERTA (Centre d’Expertise gouvernemental de Réponse et de Traitement des Attaques informatiques)Faille de Sécurité des Sessions SSLhttp://www.certa.ssi.gouv.fr/site/CERTA-2000-AVI-006/CERTA-2000-AVI-006.html

Marc BEY, BashProfileFonctionnement de SSLhttp://www.bashprofile.net/article.php3?id_article=384

Wikipédia.orgTransport Secure Layerhttp://fr.wikipedia.org/wiki/SSL