Apache Open SSL

Installation & Sécurisation d’un Serveur Web Apache par protocole OpenSSL Sous Plateforme Gnu/Linux (Ubuntu 9.10 Karmic Koala) Réalisée par : Proposée par : M. Anouar Loukili Mme Saida Lazaar M. José Johnny Randriamampionona Mlle Harisoa Mino Rakotoarivelo Sommaire TOC
Titre 1;2;Titre 2;3;Titre 3;4;Titre;1
Sommaire PAGEREF _Toc251573771 1 Liste des figures PAGEREF _Toc251573772 2 A.Introduction PAGEREF _Toc251573773 3 B.Serveur Apache PAGEREF _Toc251573774 4 I.Présentation PAGEREF _Toc251573775 4 II.Apache v.1 vs Apache v.2 PAGEREF _Toc251573776 4 III.Installation du serveur Apache sous UNIX/Ubuntu 9.10 PAGEREF _Toc251573777 5 1.Vérification des ports écoutés PAGEREF _Toc251573778 5 2.Au niveau du navigateur web PAGEREF _Toc251573779 5 3.Création des Hôtes virtuels PAGEREF _Toc251573780 6 4.Sécurisation par mot de passe PAGEREF _Toc251573781 7 5.Sniffing avec wireshark PAGEREF _Toc251573782 7 C.OpenSSL PAGEREF _Toc251573783 10 I.Présentation OpenSSL PAGEREF _Toc251573784 10 II.Installation d’OpenSSL sous UNIX/Ubuntu 9.10 PAGEREF _Toc251573785 10 III.Remarque PAGEREF _Toc251573786 14 D.Conclusion PAGEREF _Toc251573787 15 Webographie PAGEREF _Toc251573788 16 Liste des figures : TOC
Figure
Figure 1 : page d’accueil de wireshark (commande sudo wireshark) PAGEREF _Toc251572618 8 Figure 2 : sélection du filtre HTTP PAGEREF _Toc251572619 8 Figure 3 : résultat au niveau de la première fenêtre, le premier GET PAGEREF _Toc251572620 8 Figure 4 : le résultat PAGEREF _Toc251572621 9 Figure 5 : le résultat au niveau de la 2e fenêtre (login/password en clair) PAGEREF _Toc251572622 9 Figure 6 : le terminal sous Ubuntu 9.10 lors de la création de certificat et des clés PAGEREF _Toc251572623 10 Figure 7 : premier test sans OpenSSL PAGEREF _Toc251572624 11 Figure 8 : le lien https://localhost est redirigé vers https://tsingy.ma PAGEREF _Toc251572625 11 Figure 9 : fenêtre d’ajout de l’exception PAGEREF _Toc251572626 12 Figure 10 : détails concernant le certificat PAGEREF _Toc251572627 12 Figure 11 : certificat plus en détail PAGEREF _Toc251572628 13 Figure 12 : après avoir accepté le certificat, de nouveau le mot de passe et login PAGEREF _Toc251572629 13 Figure 13 : pop-up pour saisir le login/mot de passe PAGEREF _Toc251572630 13 Figure 14 : la page tsingy.ma PAGEREF _Toc251572631 14 Figure 15 : certificat auto signé PAGEREF _Toc251572632 14 Introduction Les premières attaques réseau exploitaient des vulnérabilités liées à l'implémentation des protocoles de la suite TCP/IP. Avec la correction progressive de ces vulnérabilités les attaques se sont décalées vers les couches applicatives et en particulier le web, dans la mesure où la plupart des entreprises ouvrent leur système pare-feu pour le trafic destiné au web. Le protocole HTTP (ou HTTPS) est le standard permettant de véhiculer les pages web par un mécanisme de requêtes et de réponses. Utilisé essentiellement pour transporter des pages web informationnelles (pages web statiques), le web est rapidement devenu un support interactif permettant de fournir des services en ligne. Le terme d'« application web » désigne ainsi toute application dont l'interface est accessible à travers le web à l'aide d'un simple navigateur. Devenu le support d'un certain nombre de technologies (SOAP, JavaScript, XML RPC, etc.), le protocole HTTP possède désormais un rôle stratégique certain dans la sécurité des systèmes d'information. Le présent rapport a pour but de montrer les étapes d’installation d’un serveur Apache sur la plateforme UNIX dans un premier temps, puis s’intéresse par la suite plus en détail à la manière de la sécurisation par protocole OpenSSL introduisant les notions de clés et de certificat. Serveur Apache Présentation Apache HTTP Server, souvent appelé Apache, est un logiciel de serveur HTTP produit par l'Apache Software Foundation. C'est le serveur HTTP le plus populaire du Web. C'est un logiciel libre avec un type spécifique de licence, nommée licence Apache. Apache fonctionne principalement sur les systèmes d'exploitation UNIX (Gnu/Linux, Mac OS X, Solaris, BSD et UNIX) et Windows. La version Windows n'est considérée comme stable que depuis la version 1.2 d'Apache. Apache est utilisé par de nombreux produits, dont WebSphere d'IBM, ainsi que par Oracle Corporation. Il est également supporté d'une façon ou d'une autre par les outils de développement Borland Delphi et Kylix, ainsi que par des CMS comme Drupal. Apache est conçu pour prendre en charge de nombreux modules lui donnant des fonctionnalités supplémentaires : interprétation du langage Perl, PHP, Python et Ruby, serveur proxy, CGI (Common Gateway Interface), Server Side Includes, réécriture d'URL, négociation de contenu, protocoles de communication additionnels, etc. Les possibilités de configuration d'Apache sont une fonctionnalité phare. Le principe repose sur une hiérarchie de fichiers de configuration, qui peuvent être gérés indépendamment. Cette caractéristique est notamment utile aux hébergeurs qui peuvent ainsi servir les sites de plusieurs clients à l'aide d'un seul serveur HTTP. Pour les clients, cette fonctionnalité est rendue visible par le fichier .htaccess. Parmi les logiciels aidant la maintenance d'Apache, les fichiers de log peuvent s'analyser à l'aide de nombreux scripts et logiciels libres tels qu’AWStats, Webalizer ou W3Perl. Plusieurs interfaces graphiques facilitent la configuration du serveur. Apache v.1 vs Apache v.2 Ce rapport se base sur la dernière version d’Apache appelée apache2, néanmoins, il semble nécessaire de connaître ce que cette version a apporté de plus à apache. Nous n’allons pas étaler ici les développements et améliorations faites, mais nous allons plutôt voir les changements au niveau de quelques fichiers de configurations clés. D’après http://ilia.ws/archives/32-Apache-1-vs-Apache-2-Performance.html apache2 est plus stable et conviviale par rapport à son prédécesseur. En ce dernier est 4% moins vite qu’apache2. jjohnny@johnny-netbook:/etc/apache2$ls -l total 80 -rw-r--r-- 1 root root 8097 2009-11-12 22:48 apache2.conf drwxr-xr-x 2 root root 4096 2010-01-06 18:17 conf.d -rw-r--r-- 1 root root 551 2009-11-12 22:48 envvars -rw-r--r-- 1 root root 0 2009-11-06 18:17 httpd.conf -rw-r--r-- 1 root root 31063 2009-11-12 22:48 magic drwxr-xr-x 2 root root 4096 2010-01-06 18:17 mods-available drwxr-xr-x 2 root root 4096 2010-01-06 18:53 mods-enabled -rw-r--r-- 1 root root 513 2009-11-12 22:48 ports.conf drwxr-xr-x 2 root root 4096 2010-01-11 13:21 sites-available drwxr-xr-x 2 root root 4096 2010-01-06 18:37 sites-enabled Le fichier de configuration principale httpd.conf de l’ancienne version est vide dans la dernière version (mais reste maintenu pour assurer la rétrocompatibilité) et est remplacé par apache2.conf qui se chargera par la suite d’appeler tous les autres fichiers de configurations. ports.conf contient la directive listen qui spécifie les adresses et les ports d’écoutes, conf.d est un répertoire qui contient plusieurs petits fichiers qui seront analysés par apache (comme charset qui spécifie l’encodage à utiliser par défaut), mods-available contient la liste des modules d’apache installés ; mods-enabled celle des modules utilisés ; sites-available contient la liste des virtual hosts disponibles tandis que sites-enabled celles qui sont utilisés (ou plutôt utilisables). Et tout ça se trouve dans /etc/apache2 Installation du serveur Apache sous UNIX/Ubuntu 9.10 L’installation d’Apache se fait en ligne de commande avec la commande apt-get install permettant ainsi d’installer la dernière version d’apache sans se soucier des dépendances possibles. jjohnny@johnny-netbook:~$ sudo apt-get install apache2 Vérification des ports écoutés: jjohnny@johnny-netbook:~$ netstat –nlt Active Internet Connections (only servers) ProtoRecv-QSend-QLocal AddressForeign AddressState tcp00127.0.0.1:65600.0.0.0:*LISTEN tcp00127.0.0.1:6310.0.0.0:*LISTEN tcp600:::80:::*LISTEN tcp00::1:631:::*LISTEN la partie surlignée est la ligne qui nous intéresse : le port 80 au niveau de l’hôte local est en écoute : autrement dit le serveur attend qu’un client l’utilise (comme un browser par exemple). Au niveau du navigateur web : On peut afficher les processus en cours pour voir si le serveur est démarré ou non (même s’il l’est par défaut, juste après l’installation), ou en ouvrant un navigateur (n’importe lequel) et mettant l’url http://localhost:80 au niveau de la barre d’adresse. Dans notre cas nous avons : Création des Hôtes virtuels : On essai d’imiter la syntaxe du fichier /etc/apache2/sites-available/default pour créer notre hôte virtuel qu’on va appeler « Tsingy » et l’enregistrer dans le répertoire /etc/apache2/sites-available/: NameVirtualHost *:80 # accessible à partir de n’importe quel IP ,[object Object], Une fois qu’on a créé notre hôte virtuel il faut le référencier dans le fichier hosts se trouvant dans /etc/ autrement dit donner son nom de domaine jjohnny@johnny-netbook:~$ sudo gedit /etc/hosts On ajoute la ligne : 127.0.0.1localhost 127.0.0.1jjohnny-netbook 127.0.0.1tsingy.ma # pour lui dire que le localhost (à distance s’affichera en tant que http://tsingy.ma # The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters ff02::3 ip6-allhosts Chose faite, on part dans /var/www/ pour créer notre site web, pour cela on crée un répertoire du même nom que notre hote virtuel à savoir « Tsingy » comme on la déjà spécifié par la ligne : DocumentRoot /var/www/tsingy où on va mettre toutes nos pages web : jjohnny@johnny-netbook:~$ sudo mkdir /var/www/tsingy Dedans on crée notre page web index.html qui fera office de page d’accueil du site. Puis on active l’hôte virtuel en créant un lien symbolique entre sites-available/ vers sites-enabled/ jjohnny@johnny-netbook:~$ sudo a2ensite tsingy.ma A ce stade la configuration de base est terminée reste à redémarrer le service apache2 par la commande : jjohnny@johnny-netbook:~$ sudo /etc/init.d/apache2 reload Sécurisation par mot de passe : Pour sécuriser l’accès au site par un mot de passe, il faut déjà spécifier les noms d’utilisateurs et leurs mots de passe dans un fichier que nous appelons dans notre cas users dans /var/www/tsingy/ avec la commande : jjohnny@johnny-netbook:~$ sudo htpasswd /var/www/tsingy/users micro New password: Re-type new password: Adding password for user micro Et d’ajouter dans le fichier default dans /etc/apache2/sites-available/ le bout de code suivant : ,[object Object], Une fois les changements sont effectués il faut redémarrer le service apache2 pour qu’ils puissent prendre effet. Ainsi, l’installation et la configuration du serveur Apache est achevée, toutefois notre serveur est vulnérable, même si son accès est limité par une authentification ou le mot de passe transite en claire, ce moyen reste inefficace face à des utilisateurs mal intentionnés qualifiés et il faut donc le sécuriser par des moyens robustes. Sniffing avec wireshark : Wireshark anciennement appelé ethereal est un outil d’analyse de protocoles. C’est l'analyseur réseau le plus populaire au monde. Cet outil extrêmement puissant fournit des informations sur des protocoles réseaux et applicatifs à partir de données capturées sur un réseau.Comme un grand nombre de programmes, Wireshark utilise la librairie réseau pcap pour capturer les paquets il est facile à installer (dans différentes plateformes), facile à utiliser (interface graphique), présente de très grand nombre de fonctionnalités. Dans cette partie, nous allons démontrer que la sécurisation par password sans chiffrement de ce dernier ne sert à rien. Pour cela, nous connectons la machine hébergeant apache2 (donc serveur) avec une autre qui jouera le rôle d’un client. Nous configurons les adresses IP : serveur : 192.168.0.12 client : 192.168.0.123 avec la commande ifconfig Sur le serveur nous exécutons : jjohnny@johnny-netbook:~$ sudo Wireshark pour lancer Wireshark en tant que super-utilisateur (sinon on n’aura pas accès aux interfaces) : Figure SEQ Figure ARABIC 1 : page d’accueil de wireshark (commande sudo wireshark) On configure l’interface en eth0 et le filtre http : Figure SEQ Figure ARABIC 2 : sélection du filtre HTTP Lors de la première tentative d’accès au répertoire protégé (login et mot de passe expressément falsifié pour la démo) nous pouvons voir le login et mot de passe en clair : le premier GET/test/admin http/1.1. qui indique le répertoire protégé est sélectionné. Figure SEQ Figure ARABIC 3 : résultat au niveau de la première fenêtre, le premier GET Plus bas au niveau de l’autorisation, puis credentials, on arrive à lire le login : mot de passe en clair : « randriamampionona :josejohnny » Figure SEQ Figure ARABIC 4 : le résultat En zoomant : Figure SEQ Figure ARABIC 5 : le résultat au niveau de la 2e fenêtre (login/password en clair) OpenSSL Présentation OpenSSL OpenSSL est une boite à outils de chiffrement, sous une licence de type Apache, comportant deux bibliothèques (une de cryptographie générale et une implémentant le protocole SSL - Secure Sockets Layer-), ainsi qu'une ligne de commande. OpenSSL est basé sur SSLeay d’Eric Young et Tim Hudson. Les bibliothèques (qui sont écrites en langage C) implémentent les fonctions basiques de cryptographie et fournissent un certain nombre de fonctions utiles. Grâce aux wrappers (adaptateurs), il est possible d'utiliser la bibliothèque OpenSSL dans une grande variété de langages informatiques. Les paramètres de la ligne de commande OpenSSL sont très nombreux ; ils permettent d'indiquer entre autres l'un des nombreux types de chiffrement (exemple : blowfish, DES ou Triple DES, DSA, RC4, RC5, RSA...), d'encodage (base64 ou autres) et de hachage (MD5, SHA-1...). Cet utilitaire et les bibliothèques associées sont disponibles pour la plupart des Unix (dont Linux et Mac OS X), mais aussi pour Microsoft Windows, DOS, OpenVMS. Depuis la version 0.9.7, le support des cartes accélératrices câblées est inclus dans la branche principale des releases alors que précédemment elles étaient séparées et suffixées par le terme -engine-. Installation d’OpenSSL sous UNIX/Ubuntu 9.10 On commence par faire une mise à jour d’OpenSSL intégré par défaut sur les stations GNU/Linux avec la commande : jjohnny@johnny-netbook:~$ sudo apt-get update openssl #mise-à-jour jjohnny@johnny-netbook:~$sudo a2enmod ssl #démarrage et activation Après la mise à jour d’openssl, on va créer un certificat et une clé qui vont être utilisés pour la sécurisation de notre site web, ceci se fait via la commande (dans Ubuntu Karmic Koala openssl est par défaut installé donc l’installation est omise) : jjohnny@johnny-netbook:~$ sudo mkdir /etc/apache2/ssl/ssl-crt /etc/apache2/ssl/ssl-key jjohnny@johnny-netbook:~$ sudo openssl req –x509 –days 365 –newkey rsa:1024 –out /etc/apache2/ssl/ssl-crt/tsingy.crt –keyout /etc/apache2/ssl/ssl-key/tsingy.key Figure SEQ Figure ARABIC 6 : le terminal sous Ubuntu 9.10 lors de la création de certificat et des clés -x509 -nodes donne le type de certificat -days 365 indique la durée de validité (en jours) -newkey rsa:1024 demande une clé RSA de 1024 bits - d'après la doc apache, il est déconseillé de créer une clé plus grosse pour des histoires de compatibilité -out /etc/apache2/tsingy.crt est le chemin -keyout /etc/apache2/tsingy.key est le chemin de la clé privée Une fois qu’on a créé la clé de chiffrement et le certificat, on doit reconfigurer notre hôte virtuel pour pouvoir écouter le port associé à OpenSSL à savoir le port 443 existant par défaut dans /etc/apache2/ports.conf, pour se faire on introduit le changement suivant: NameVirtualHost * :443 # tout le monde peut y accéder d’une manière #chiffrée ,[object Object], < VirtualHost * :443> ServerName tsingy.ma DocumentRoot /var/www/tsingy SSLEngine on#on active openssl SSLCertificateFile /etc/apache2/ssl/ssl-crt/tsingy.crt # tenez donc le certificat et SSLCertificateKeyFile /etc/apache2/ssl/ssl-key/tsingy.key #n’oublie pas la clé Ci-après quelques prises d’écran d’un utilisateur qui essai de parcourir à partir de la page d’accueil jusqu’à la page protégée (utilisateur enregistré) Figure SEQ Figure ARABIC 7 : premier test sans OpenSSL On suit le lien vers tsingy … Figure SEQ Figure ARABIC 8 : le lien https://localhost est redirigé vers https://tsingy.ma On accepte le risque Figure SEQ Figure ARABIC 9 : fenêtre d’ajout de l’exception Avant de confirmer, essayons de voir les caractèristques de ce certificat en cliquant sur view Figure SEQ Figure ARABIC 10 : détails concernant le certificat Plus en détails, par exemple le serial number Figure SEQ Figure ARABIC 11 : certificat plus en détail Ajoutons maintenant l’exception : Figure SEQ Figure ARABIC 12 : après avoir accepté le certificat, de nouveau le mot de passe et login Le prompt du mot de passe vient et en même temps http devient https ….saisissons le mot de passe et notre login : Figure SEQ Figure ARABIC 13 : pop-up pour saisir le login/mot de passe Et voilà on valide et tout finit bien . Figure SEQ Figure ARABIC 14 : la page tsingy.ma Le certificat vient d’un certain tsingy.ma. Figure SEQ Figure ARABIC 15 : certificat auto signé Remarque : Le sniffing avec wireshark est ici quasiment inutile étant donné que le mot de passe et le login sont cryptés. Néanmoins, l’utilisation de ssl est loin d’être optimale, en effet, il est conseillé de ne pas dépasser 1024 pour la taille des clés, en outre la distribution BackTrack dérivée de Slackware (du moins jusqu’à la version 3, la version 4 est combinée avec Debian) utilisée par les professionnels pour faire des audits des réseaux, des tests de vulnérabilité et surtout des pénétrations (privilege escalation ..), contient un shell propre pour sniffer et décrypter les mots de passe et login chiffrés par SSL. Conclusion Les vulnérabilités des applications web peuvent être catégorisées de la manière suivante : Vulnérabilités du serveur web. Ce type de cas est de plus en plus rare car au fur et à mesure des années les principaux développeurs de serveurs web ont renforcé leur sécurisation ; Manipulation des URL, consistant à modifier manuellement les paramètres des URL afin de modifier le comportement attendu du serveur web ; Exploitation des faiblesses des identifiants de session et des mécanismes d'authentification ; Injection de code HTML et Cross-Site Scripting ; Injection de commandes SQL. Les attaques visant les applications web sont toujours nuisibles car elles donnent une mauvaise image de l'entreprise. Les conséquences d'une attaque réussie peuvent notamment être un effacement de site web, un vol d'informations, une modification de données, notamment modification de données personnelles d'utilisateurs ou une intrusion sur le serveur web. Dans la mesure où les serveurs web sont de plus en plus sécurisés, les attaques se sont progressivement décalées vers l'exploitation des failles des applications web. Ainsi, la sécurité des services web doit être un élément pris en compte dès leur conception et leur développement. Webographie : www.openssl.org www.wikipedia.com www.ubuntu.com www.backtrack.com www.wireshark.org http://drakkar.imag.fr/users/

Apache Open SSL

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (19)

Ähnlich wie Apache Open SSL

Ähnlich wie Apache Open SSL (20)

Mehr von Anouar Loukili

Mehr von Anouar Loukili (6)

Apache Open SSL