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.
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.
L’objectif de ce script est de permettre une recherche en ligne depuis un bind clavier.
La simple pression d’un Windows + W vous envoie directement rechercher sur Wikipedia ?
Enfin une utilisation pratique de cette touche bien inutile 🙂
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.
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).
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.
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.
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.
L’objectif de ce tutoriel est de mettre en place un système WebDav avec une authentification prise en charge par mySQL (et non par un fichier de mots de passe apache).
Pour cela, le module authentification mySQL est nécessaire pour Apache2 (Le module WebDav est déjà inclu dans apache2).
L’objectif de ce rapport est d’étudier le fonctionnement et la mise en place d’un DNS dynamique (relation entre un serveur DHCP et DNS).
Nous allons essayer de faire une comparaison de deux modèles de confiance très répandu de nos jours :
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.
Pour commencer, il est intéressant de définir différents principes de cryptographie utilisés par ces deux technologies.
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]](https://www.kns7.org/docs/dest/adminUNIX/rapport/ssl_vs_pgp/images/note.png) |
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
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
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.
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
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.
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 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.
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).
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.
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:
Les numéros de ports prédéfinis par l’IANA sont disponibles dans le fichier /etc/services.
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:
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
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.
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.
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.
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]
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 »).
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 ?
Le processus de chiffrement par PGP passe par plusieurs étapes que nous allons détailler ci-dessous.
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…).
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.
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
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.
Pour accéder au message du côté du destinataire, on reprend les étapes dans le sens inverse.
Voyons ces étapes en détail.
Le message reçu est chiffré, il faut alors commencer par déchiffrer 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é.
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.
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
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).
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.
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.
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).
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).
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).
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.
[zimmerman_pgp] Pourquoi j’ai écrit PGP. http://biblioweb.samizdat.net/article.php3?id_article=4
Cryptograhie Symétrique. http://fr.wikipedia.org/wiki/Cryptographie_asym%C3%A9trique
Cryptograhie Asymétrique. http://fr.wikipedia.org/wiki/Cryptographie_asym%C3%A9trique
[certa_sessionssl] Faille de Sécurité des Sessions SSL. http://www.certa.ssi.gouv.fr/site/CERTA-2000-AVI-006/CERTA-2000-AVI-006.html
Fonctionnement de SSL. http://www.bashprofile.net/article.php3?id_article=384
Transport Secure Layer. http://fr.wikipedia.org/wiki/SSL
