PARCE QU'UN SYSADMIN NAÎT TOUS LES JOURS...

Transcription

1 PARCE QU'UN SYSADMIN NAÎT TOUS LES JOURS... Cette série a pour objet de montrer comment installer et configurer une suite de logiciels bien connus afin de leur faire faire uniquement ce pour quoi ils ont été conçus initialement. Lorsque l'on essaye pour la première fois d'installer un logiciel «phare» du monde du libre, on est parfois désorienté par l'absence plus ou moins totale de documentation simple. On trouvera nettement plus facilement un tutoriel sur la façon de lui faire faire le café en dansant le sirtaki qu'une explication claire sur comment lui faire faire ce pour quoi il a été développé à l'origine. Ce problème est d'autant plus vrai que le logiciel est ancien et bien connu des «vieux de la vieille». Cependant, ces derniers oublient parfois un peu vite que la jeune génération arrive et que. si on veut qu'ils aient envie d'installer un Apache plutôt qu'un IIS, il faut leur en donner les moyens. II est facile de répondre RTFM sur un forum, mais encore faut-il pouvoir le trouver ce calisse de tabarnak d'ostie de manuel.. Apache Présentation Sauf à sortir d'une hibernation prolongée, tout informaticien digne de ce nom a entendu parler d'apache dont le nom devient synonyme de serveur HTTP presque au même titre que Frigidaire désigne les réfrigérateurs. Apache, surtout dans sa version 2, possède les avantages de ses inconvénients et réciproquement. Il a été conçu pour être modulaire et il l'est... parfois presque à outrance. Si un sysadmin chevronné cherche comment installer Apache en reverse proxy avec authentification LDAPS via un wrapper Python, il trouvera sans doute toute l'aide nécessaire sur le net. Cependant, quid de lui faire faire seulement serveur HTTP(S)? J'en entends déjà qui crient au sacrilège ; quoi, utiliser un si puissant logiciel pour ne faire QUE ça? Quelle honte... Peut-être bien, mais malgré tout, il fut développé pour ça. et mine de rien, il le fait bien. Nous allons donc retrousser nos manches et aller regarder ce qu'il y a sous le capot. Pour connaître un logiciel correctement, il ne faut pas hésiter à commencer petit et à monter en puissance peu à peu. C'est pour cela que notre objectif premier va être de lui faire juste servir une page HTML statique. Ensuite, nous ajouterons le support PHP. puis nous mettrons en place la gestion des virtual hosts et nous finirons avec la mise en place de la sécurité via HTTPS. Afin de ne pas multiplier les commandes, la distribution utilisée sera Debian. Pour les autres, il suffira la plupart du temps d'adapter le gestionnaire de packages et de retrouver les bons répertoires pour les fichiers de configuration. 1.2 Installation de base d'un Apache 2 Dans tout ce qui suit, nous travaillerons avec un serveur dédié (une VM Virtual- ox dans mon cas) ayant une adresse IP égale à et une station de travail avec une interface graphique. Il est parfaitement possible de réaliser la maquette en installant Apache sur votre poste de travail mais une VM permet beaucoup plus de liberté et permet aussi d'éviter de pourrir sa machine en cas de fausse manipulation. Apache 2 se présente sous deux formes principales, une version monothreadée nommée sous Debian

2 apache2-mpm-prefork et une version multithreadée nommée apachez-mpm-worker. N'importe qui de normalement constitué opterait pour la deuxième version, sauf que PHP n'est pas thread safe1... Donc intégrer un module non thread safe dans un serveur fortement multi-threadé comme Apache en version worker risque de générer très vite un crash splendide mais non désiré. Pour cette raison, nous allons donc installer la version multi-processus d'apache : # apt-get install apachez-mpm-prefork Une fois les quelques dépendances descendues et installées aussi, nous pouvons commencer à tester directement si tout s'est bien passé. En effet, la plupart des distributions récentes pré-configurent Apache pour afficher une page HTML d'accueil en écoutant sur le port 80. La première chose à faire consiste à vérifier qu'apache écoute bien sur l'extérieur : root DebianTest:~# netstat -nlp Active Internet connections(only servers) Proto Recv-û Send-0 Local Address Foreign Address :* :25.8..:* ,8.8:* : :*..* 6 : :22.,* 6 8 : 1:25..* 6 8 : : :68 J.8.8:* : :* : :* : :* State PID/Program naie 1203/sshd 1173/exi4 698/rpc.statd 685/port»ap 1283/sshd 1173/exii4 1658/apache2 1194/dhclient 698/rpc.statd 698/rpc.statd 685/portiap Le processus apachez écoutant donc bien sur le port 802 et sur l'ensemble des interfaces, il est temps de tenter de se connecter directement depuis le serveur lui-même : root8debiantest:~# tel net localhost Trying Connected to localhost. Escape character is '*]'. 6ET / HTTP/1.0 Et effectivement, Apache nous répond que ça marche HTTP/ OK Date: Wed, 85 Oct :58:19 GMT Server: Apache/ (Debian) Last-Hodified: Hed, 85 Oct :39:29 GMT ETag: "6667d-l)l-4ae8d5656e640" Accept-Ranges: bytes Content-Length: 177 Vary: Accept-Encoding Connection: close Content-Type: text/htil 1 2 <htiilxbodyxhi>it works!</hl> <p>this is thé default»eb page for this server.</p> <p>the mb server software is running but no content lias been added, yet.</p> </bodyx/html> Connection closed by foreign host. Une fois le bon fonctionnement d'apache établi, nous allons créer notre page à nous. Pour ce faire, nous allons utiliser un framework imposant, doté de fonctionnalités très avancées et capable de gérer intelligemment n'importe quel type de page web, j'ai nommé vim. Pour ceux qui ont suffisamment de doigts (compter entre 15 et 20 par main pour commencer), emacs peut aussi faire l'affaire ;-). Tout d'abord, il nous faut savoir où poser nos pages web statiques dans l'arborescence. Pour cela, il faut demander à Apache où il va les chercher et quel utilisateur est censé les posséder. Regardons donc le fichier de configuration. Pour une Debian, il est situé dans /etc/apachc2 et il s'appelle httpd.conf. Si nous l'éditons, nous constatons avec stupeur qu'il est... vide! En effet, sous Debian, le contenu de l'ancien httpd.conf d'apache premier du nom est dispersé en plusieurs fichiers : -envvars qui contient un certain nombre de variables d'environnement utilisées dans les autres fichiers. La plus intéressante pour le moment est nommée $APACHE_RUN_ USER, qui est fixée à www- data et qui contient l'utilisateur sous le compte duquel Apache fonctionne. Nous savons donc que, pour être tranquille, nos fichiers HTML, PHP ou autres doivent appartenir à www-data. Pour simplifier le travail et éviter les chown toutes les cinq minutes, nous pouvons utiliser une méthode qui va faire hurler les puristes : il suffit de créer un mot de passe et d'affecter un shell propre à l'utilisateur www-data. Ceci constitue effectivement un trou de sécurité énorme, mais il ne faut pas oublier que le développement d'un site ne se fait jamais sur un serveur en production, n'est-ce pas? Comme personne n'oserait développer sur de la prod, nous pouvons donc nous permettre cette horreur sur notre machine de dev :-). - apache2.conf qui constitue le principal fichier de configuration et qui va utiliser les autres. - ports.conf pour configurer les ports TCP sur lesquels Apache écoute. - le répertoire mods-available où sont stockés les modules disponibles. Les modules actifs sont définis par un lien symbolique du répertoire mods-enabled vers mods-available. Des versions étiquetées «thread safe» existent, mais il est fortement conseillé de les oublier pour toute mise en production. Ici. il nous semble qu'apache n'écoute qu'en IPv6. ce qui n'est pas le cas. Cependant, lorsque les logiciels fonctionnent en double pile (IPv4 et IPv6). netstat n'affiche que les sockets ouvertes en IPv6.

3 -le répertoire sites-available où nous posons nos fichiers de configuration de chaque site servi par notre Apache. Cela simplifie pas mal la création de virtual hosts comme nous le verrons tout à l'heure. Pour les activer, un lien symbolique dans sites-enabled et le tour est joué. Et notre page web dans tout ça, me direz-vous? Pour la situer, il nous faut examiner le fichier /etc/apache2/sitesenabled/qog-default qui est un lien vers /etc/apache2/ sites-available/default, ien entendu, pour obtenir ce résultat comme page de garde, il aurait suffi de la nommer index.html. 1.3 Dynamisons un peu Parmi la multitude de langages disponibles pour créer un site web dynamique, le PHP est le plus utilisé. À cela de multiples raisons dont l'une des premières est que c'est l'un des plus simples à appréhender. On pourrait dire que le PHP est le asic de l'époque du Web. Ceci nous apprend entre autres les choses suivantes : Il existe deux méthodes pour faire fonctionner le PHP avec Apache. La première consiste à utiliser les appels CGI et à lan- Le site est accessible sur le port 80 : <VirtualHost *:80>. cer un interpréteur PHP à chaque fois. La seconde passe par -La racine est située dans /var/www : DocumentRoot l'installation du module mod_php qui internalise l'interpréteur /var/www. dans Apache et évite donc une perte de temps monumentale, - Les scripts CGI sont autorisés s'ils sont stockés dans sans parler des problèmes de sécurité inhérents aux CGI. /usr/lib/cgi-bin. L'installation de mod_php s'effectue de la manière suivante sous Debian : - Les logs sont dans $APACHE_LOG_DIR (voir /etc/apache2/ envvars). n apt-get install Iibapache2-mod-php5 Dans un premier temps, nous allons simplement valider nos découvertes en créant un fichier HTML ultra simple et en le posant dans /var/www. Par exemple : <html> <head> <title>test Apache2</title> </head> <body> <center> <h2>my apache webserver is running!</ti2> </center> </body> </ht.ml> Nommons ce fichier test. html, par exemple, et copions-le dans /var/www en l'affectant par précaution à l'utilisateur www-data via un chown qui va bien. Il est à noter que, sous Debian, un simple su - www-data en tant que root nous permet d'avoir un shell de base permettant de travailler, le home directory de www-data étant défini comme /var/www. Cependant, il faut en changer le propriétaire car le répertoire appartient à root par défaut. Pointons ensuite notre navigateur favori depuis notre poste de travail sur ce fichier: html et notre splendide page apparaît :»-- - e pï^ My apache Webserver is rannlng! Figure 1 : Notre première page HTML Une fois le module et ses dépendances installés, nous avons deux nouveaux liens dans/etc/apache2/mods-enabled qui pointent vers /etc/apache2/mod - available/php5.load et /etc/apache2/mods-available/php5.conf. phps.loadsert juste à indiquer à Apache quelle bibliothèque il faut charger (libphps.so dans le cas présent). phps.conf est là pour expliquer à Apache comment reconnaître les fichiers PHP et quoi en faire : <lfmodule mod_php5.c> <FilesMatch "\.ph(p3?ltnl)$"> SetHandler application/x-httpd-php </FilesMatch> <FilesMatch "\.phps$"> SetHandler application/x-httpd-php-source </FilesMatch> # To re-enable php in user directories conment thé following Unes # (froro <IfHodule...> to </IfHodule>.) Do NOT set it to On as it # prevents.htaccess files from disabling it. <IfHodule niod_userdir.c> <0irectory /home/*/publicjtnil> php_admin_value engine Off </Directory> </IfModule> </IfModule> En résumé, si le module nommé mod_php5 est chargé, si le fichier se termine par.php,.php3 ou.phtml, il s'agit alors d'un fichier de type applicaticm/x-httpd-php, autrement dit un exécutable PHP. Si le fichier se termine par.phps, il s'agit d'un fichier PHP source, ce qui sert à afficher proprement les listings. Par défaut, tout fichier placé dans un répertoire utilisateur ne sera pas exécuté. ien que l'installateur Debian ait fait un reload, il est conseillé de relancer Apache complètement après l'installation

4 soit avec la commande apachezctl restant, soit avec un classique /etc/init.d/apache2 restant, le reload n'étant pas toujours suffisant. Une fois ceci fait, nous pouvons valider notre installation. Nous allons créer un script PHP qui sera un monstre de complexité : <VirtualHost *:80> ServerAdmin mail6cpc.niondomaine.fr ServerName cpc.mondoma1ne.fr ServerAlias <?php phpinfoo; Mine de rien, ce petit script est toujours à garder dans un coin de votre machine de développement et surtout à ne jamais mettre sur une machine de production. Il affiche en effet tout un tas d'informations très utiles sur la version de PHP installée, les modules supplémentaires, etc. lé gdft yiex Hiy.ory gookmariis phpinfoli Pour mettre cela en place, il suffit d'aller ajouter les fichiers qui vont bien dans /etc/apache2/sites-available. La (j ] syntaxe est assez simple. Nous allons partir d'une version édulcorée du fichier /etc/apache2/sites-available/ def ault. Pour le site cpc, nous allons créer le fichier suivant en l'appelant cpc : Toots cfelp,4= ,60 - c- PHP Version squeeze3 :. : -* - X^^s^ System UnuK Debianftst »1 SMP fiî Sep 9 20:51:85 <JX 2011 Î6S6 3uild Date ftjn :11:03 Server API Apache 2.0 Hande: Virtual Dlrectory Support disabted Configuration File {php.lnl} Path /et=/phpvap3ch«2 Loaded Configuration /etc^hp5/apach«2/pnp.ini Scan thkdtr for Jdditional.lnlflles Wc/phpS/apach^oned idditional.int flles 'etc/phps/apachez'cofitd'pdo.ini. /«t;pfip5i'âpache2,-corid PHP API PHP Extension «nd Extension Z?nd Extension uild APt22QOS(K25,NTS PHP Extension ufld APUOÛ9062S,NTS D?t>ug 8uild no 3 D/7D " </VirtualHost> La directive «magique» s'appelle ici ServerName. C'est elle qui demande à Apache de comparer le nom dans l'url avec la série de virtual hosts dont il dispose. Nous allons maintenant copier ce fichier au même endroit en l'appelant cette fois pharo. Il suffit ensuite de remplacer dedans toutes les instances de «cpc» par «pharo». Thr*ad Séfety feabbd Zfnd Memory Manager «nabted Z?nd Mulîibyt* Support disamed IPv6 Support «nabled j Rïqistered PHP Strean» https. ftps, iomprasvdic. Cùmprèss.tdp2, php. fi«, qtc-b, jasa, i J 1 F/gure 2 : Module PHP fonctionnel Si un écran similaire à celui de la figure 2 apparaît, c'est que tout va bien, la vie peut commencer... Cet article n'étant pas une initiation à la programmation en PHP, nous allons nous arrêter là sur le sujet. 1.4 Les virtual hosts Utiliser un serveur HTTP aussi performant qu'apache pour ne servir qu'un seul petit site web pourrait s'apparenter à du gâchis. Heureusement, la notion d'hôte virtuel existe. Elle consiste à utiliser l'url et non plus l'adresse IP seule pour faire la distinction entre plusieurs sites. Par exemple, donnera accès à tout ce qui concerne les machines Amstrad CPC3 tandis que mondomaine.fr pointera sur les trucs et astuces Pharo pour les petits jeunes :p * DocumentRoot /var/www/cpc <Directory /> Options FollowSymtinks AllowOverride None </Directory> <D1rectory /var/www/cpc> Options Indexes FollowSymLinks HultiViews AllowOvem'de None Order allow,deny allow from ail </D1rectory> Une fois ceci fait, il nous faut aller créer les deux répertoires /var/www/cpc et /var/www/pharo, puis renseigner nos deux domaines dans /etc/hosts sur le serveur, car évidemment, un DNS sera bien en peine de résoudre nos deux noms de domaines : cpc.mondomaine.fr pharo. uiondouaine.fr Puis nous devons activer ces deux hôtes virtuels. Nous pouvons le faire via un lien symbolique à la main ou utiliser la commande fournie par Apache : # azensite cpc # a2ensite pharo Ensuite, il suffit de poser un index.html différent dans chaque répertoire afin de bien différencier nos sites. Le test de base peut se faire via lynx si nous n'avons pas de surcouche graphique sur notre machine, ce qui semble logique s'il s'agit d'un serveur, ou en renseignant l'adresse IP de notre serveur dans le fichier /etc/hosts de notre station :

5 cpc.nondoniaine.fr pharo.fflondomaine.fr et dans ce cas, nos deux sites devraient s'afficher sans problème. Attention toutefois si vous utilisez un proxy en temps normal, pensez à le désactiver dans la configuration de votre navigateur. Si maintenant vous tentez d'accéder au site en utilisant l'adresse IP, vous devez tomber sur la réponse d'apache par défaut. Ce dernier test valide le bon fonctionnement de l'ensemble. Le principe des virtual hosts est prévu pour fonctionner avec des DNS correctement renseignés et des noms de domaines réels. Utiliser le fichier /etc/hosts comme nous venons de le faire pour les simuler fonctionne mais n'est franchement pas conseillé au-delà de la simple découverte. 1.5 Activer la sécurité Comme tout le monde le sait - ou devrait le savoir - il est possible d'encoder une liaison HTTP en utilisant une surcouche SSL. Pour cela, il faut demander au serveur d'ouvrir une connexion sur le port 443 en plus ou à la place de celle déjà ouverte sur le port 80 et lui fournir ce qu'il faut comme certificats pour qu'il puisse encoder ses flux correctement. En guise de test, une configuration sécurisée est fournie sous le nom de def ault-ssl. Elle reprend exactement la configuration «defaul» sauf qu'elle demande à Apache d'écouter sur le port 443 et ajoute certaines directives propres à SSL condensées ici : # a2enniod ssl Puis nous pouvons activer le default en HTTPS avec la commande habituelle : # a2ensite default-ssl Comme un module vient d'être ajouté, un reload ne sera pas suffisant, il faut redémarrer Apache : /etc/init.d./apache2 restart Pour valider, un petit netstat -nlp grep apache nous montre bien Apache écoutant sur le 80 et sur le 443 : * netstat 6 îcp6 -nlpigrep apache 0 0 ::: /apache2 0 0 ::: /apache2 Pour tester la connexion, nous avons deux moyens, le premier et le deuxième. Le premier consiste à utiliser un navigateur classique que l'on fera pointer sur l'url Il va sans doute râler en nous disant que le certificat n'est pas sûr. ce qui est normal. Nous passons outre et nous obtenons la page classique d'apache : It works! SSLEngine on SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoïl.pem SSLCertifkateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key <FilesMatch "\.(cgi shtmllphtffll php)$"> SSLOptions +StdEnvVars </FilesMatch> <Directory /usr/lib/cgi-bin> SSLOptions +StdEnvVars </Directory> Dans l'ordre, nous activons le moteur SSL en lui indiquant où trouver le fichier de certificats et la clé primaire, certificats et clé qu'il est recommandé de changer bien entendu. Ensuite vient une option pour les scripts qui demande à Apache d'exporter les variables d'environnement SSL_* et TLS_*. Etant donné que cet export est coûteux en termes de CPU, il n'est activé que pour les pages pouvant en avoir besoin. Lefichier/etc/apache2/sites-available/def ault_ssl est très bien commenté dans toute la partie encodage. De nombreuses options sont possibles, notamment en ce qui concerne les ÇA, les contrôles d'accès répertoire par répertoire, etc. Avant de pouvoir activer un site en HTTPS, il nous faut valider le module SSL pour Apache. La commande suivante fait cela très bien : Figure 3 : Apache en HTTPS Le deuxième moyen est un tout petit peu plus «barbu» mais il peut s'avérer fort utile pour du debug de liaisons SSL (HTTPS, IMAPS, POPS, etc.). Il consiste à utiliser OpenSSL en mode client : * openssl s_client -connect :443 Le résultat est sans appel : CONNECÏED ) depth=0 CN = OebianTest.niondomaine.fr verify error:nw=18:self signed certificate verify return:! depth=0 CN = DebianTest.fflondomaine.fr verify return:!

6 Certificate chain 0 s:/cn=debiantest.mondomaine.fr i:/cn=debiantest.mondoma1ne.fr Server certificate EGIN CERTIFICATE END CERTIFICATE subject-/cn-debiantest.mondoraa1ne.fr 1ssuer=/CN=Debi antest.mondomai ne. fr No client certificate ÇA names sent SSL handshake bas read 1467 bytes and written 369 bytes New, TLSvl/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key 1s 2048 bit Secure Renegotiation IS supported Compression: zlib compression Expansion: zlib compression SSL-Session: Protocol : SSU3 Cipher : DHE-RSA-AES256-SHA Session-ID: FD71670C82D8027F77CECC515EC7E C2FD808CF97069DE350FD9 Session-IO-ctx: Master-Key: AA07960C3AEDAAE882CF953693AE246A22F569C4A9707F73511C663A8058A A94F0E78F471D97D92 Key-Arg : None PSK identity: None PSK identity hint: None Compression: 1 (zlib compression) Start Time: Timeout : 7200 (sec) Verify return code: 18 (self signed certificate) Nous pouvons ensuite demander la page d'index comme en telnet : CET / <htmlxbodyxhl>it works!</hl> <p>this is thé defaiflt web page for this server.</p> <p>the web server software is running but no content has been added, yet.</p> </bodyx/html> closed Et voilà, nous avons un site en HTTPS qui fonctionne. ien entendu, le HTTPS est compatible avec les virtual hosts, il suffit de s'inspirer du fichier default-ssl pour modifier la configuration d'un de nos vhosts pour le valider. Ceci sera à titre d'exercice à rendre pour la semaine prochaine! Conclusion Dans ces pages, nous venons tout juste d'effleurer ce que sait faire Apache. De nombreux points n'ont pas été abordés, comme la vérification d'identité avec les. htaccess, l'interfaçage avec un serveur LDAP, les modules Perl, Python et autres, 5 Chiffres de 2010 les proxies... Au fil des années, Apache est devenu un monstre sacré, faisant fonctionner plus de 53 % des serveurs HTTP du Web, loin devant IIS de Microsoft qui est à 25 %5. Cependant, certains reprochent, parfois ajuste titre, sa lourdeur, sa difficulté de configuration et de maintenance,... Pour ceux-là et pour d'autres qui ont envie d'explorer, il existe de nombreux développements, depuis le petit serveur HTTP écrit en 10 lignes de Perl et qui ne servira que des pages fixes, jusqu'aux concurrents plus ou moins sérieux d'apache. Parmi ces derniers, nous pouvons retenir : -NGINX ( qui se pose en challenger direct et qui met l'accent sur la rapidité. - Lighttpd ( qui, comme son nom l'indique, est prédisposé à se satisfaire d'une empreinte mémoire des plus faibles. Lighttpd est conçu pour les systèmes embarqués mais fonctionne aussi très bien sur des serveurs classiques. - Cherokee ( qui a l'avantage d'être entièrement configurable via une interface graphique plutôt bien pensée. Ces trois exemples ne forment absolument pas une liste exhaustive, loin de là. Il en existe plein d'autres, plus ou moins finis, plus ou moins performants ; c'est en fonction de vos besoins qu'il faut effectuer votre choix si vous souhaitez utiliser autre chose qu'apache. Une fois à l'aise avec la configuration de base d'apache, le net regorge d'exemples, de trucs et astuces pour monter un serveur web ultra-sécurisé et très performant. Cela étant, c'est comme tout, si on ne maîtrise pas la base, il n'est pas possible d'évoluer sereinement.