Your SlideShare is downloading. ×
Apache Open SSL
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Apache Open SSL

3,151
views

Published on

Published in: Technology, Education

0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,151
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
5
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 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 f h z " Titre 1;2;Titre 2;3;Titre 3;4;Titre;1" Sommaire PAGEREF _Toc251573771 h 1
    Liste des figures PAGEREF _Toc251573772 h 2
    A.Introduction PAGEREF _Toc251573773 h 3
    B.Serveur Apache PAGEREF _Toc251573774 h 4
    I.Présentation PAGEREF _Toc251573775 h 4
    II.Apache v.1 vs Apache v.2 PAGEREF _Toc251573776 h 4
    III.Installation du serveur Apache sous UNIX/Ubuntu 9.10 PAGEREF _Toc251573777 h 5
    1.Vérification des ports écoutés PAGEREF _Toc251573778 h 5
    2.Au niveau du navigateur web PAGEREF _Toc251573779 h 5
    3.Création des Hôtes virtuels PAGEREF _Toc251573780 h 6
    4.Sécurisation par mot de passe PAGEREF _Toc251573781 h 7
    5.Sniffing avec wireshark PAGEREF _Toc251573782 h 7
    C.OpenSSL PAGEREF _Toc251573783 h 10
    I.Présentation OpenSSL PAGEREF _Toc251573784 h 10
    II.Installation d’OpenSSL sous UNIX/Ubuntu 9.10 PAGEREF _Toc251573785 h 10
    III.Remarque PAGEREF _Toc251573786 h 14
    D.Conclusion PAGEREF _Toc251573787 h 15
    Webographie PAGEREF _Toc251573788 h 16
    Liste des figures :
    TOC h z c " Figure" Figure 1 : page d’accueil de wireshark (commande sudo wireshark) PAGEREF _Toc251572618 h 8
    Figure 2 : sélection du filtre HTTP PAGEREF _Toc251572619 h 8
    Figure 3 : résultat au niveau de la première fenêtre, le premier GET PAGEREF _Toc251572620 h 8
    Figure 4 : le résultat PAGEREF _Toc251572621 h 9
    Figure 5 : le résultat au niveau de la 2e fenêtre (login/password en clair) PAGEREF _Toc251572622 h 9
    Figure 6 : le terminal sous Ubuntu 9.10 lors de la création de certificat et des clés PAGEREF _Toc251572623 h 10
    Figure 7 : premier test sans OpenSSL PAGEREF _Toc251572624 h 11
    Figure 8 : le lien https://localhost est redirigé vers https://tsingy.ma PAGEREF _Toc251572625 h 11
    Figure 9 : fenêtre d’ajout de l’exception PAGEREF _Toc251572626 h 12
    Figure 10 : détails concernant le certificat PAGEREF _Toc251572627 h 12
    Figure 11 : certificat plus en détail PAGEREF _Toc251572628 h 13
    Figure 12 : après avoir accepté le certificat, de nouveau le mot de passe et login PAGEREF _Toc251572629 h 13
    Figure 13 : pop-up pour saisir le login/mot de passe PAGEREF _Toc251572630 h 13
    Figure 14 : la page tsingy.ma PAGEREF _Toc251572631 h 14
    Figure 15 : certificat auto signé PAGEREF _Toc251572632 h 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
    # valable sur tout les IP que apache écoute
    ServerAdmin admin@tsingy.ma
    ServerName tsingy.ma # le nom du domaine (i.e. de l’hôte virtuel)
    DocumentRoot /var/www/tsingy # là ou il y tous les fichiers du site
    # options par défaut du répertoire
    Options FollowSymLinks # on suit les liens symboliques
    AllowOverride None # pour les accès plus tard


    Options Indexes FollowSymLinks MultiViews
    AllowOverride None # options par défaut
    Order allow,deny
    allow from all


    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 :

    AuthName " Access restreint"
    AuthType Basic
    AuthUserFile /var/www/tsingy/users
    Order deny,allow
    require valid-user

    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

    ServerName tsingy.ma
    Redirect permanent / https://tsingy.ma/ # on redirige tout tentative #vers la page sécurisée

    < 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/