TP 11 · BTS CIEL · Réseaux et services

Corrigé : serveur web Apache sur Kali Linux

Réponses aux sept questions de synthèse du TP. Essayez d’y répondre vous-même avant de lire le corrigé.

01Démarrage automatique

Pourquoi Apache ne démarre-t-il pas automatiquement sur Kali, alors qu’il le fait sur Debian ?

Kali est basée sur Debian, mais elle applique une politique de sécurité : les services réseau sont désactivés par défaut après installation. Une machine d’audit ne doit exposer aucun service sans que l’utilisateur l’ait décidé.

Sur Debian, Apache est activé et démarré dès l’installation. Sur Kali, systemctl status affiche active (running) (si on l’a lancé) mais disabled.

02Les commandes systemctl

Quelle différence y a-t-il entre start et enable ? Entre restart et reload ?

Commande	Effet
`start`	Lance le service maintenant, une seule fois. Il ne repartira pas au prochain démarrage de la machine.
`enable`	Configure le démarrage automatique au boot. Ne lance rien tout de suite, sauf avec `enable --now`.
`restart`	Arrête puis relance le service : les connexions en cours sont coupées, toute la configuration est relue.
`reload`	Relit la configuration sans arrêter le service : les connexions en cours ne sont pas coupées. À préférer en production après une modification de configuration.

03Port et protocole

Sur quel port Apache écoute-t-il par défaut ? Quel protocole utilise-t-il ?

Apache écoute par défaut sur le port 80/TCP, avec le protocole HTTP.

Le port 443/TCP sert à HTTPS, quand SSL/TLS est activé.

04Un chmod dangereux

Pourquoi la commande chmod a+w /var/www/html est-elle dangereuse ?

Elle donne le droit d’écriture à tous (a = all : propriétaire, groupe et autres). N’importe quel utilisateur ou processus du système peut alors modifier, remplacer ou ajouter des fichiers du site.

Un attaquant qui obtient un compte quelconque peut défigurer le site ou y déposer un script malveillant (webshell) que le serveur exécutera.

Bonne pratiqueDonner les droits au strict nécessaire : un propriétaire ou un groupe précis avec chown, puis chmod 755 ou 775.

05Droits sur les logs

Pourquoi les fichiers de logs ne sont-ils pas lisibles par tous les utilisateurs ?

Les logs contiennent des données sensibles :

les adresses IP des visiteurs ;
les URL demandées, parfois avec des paramètres, identifiants ou jetons ;
les user-agents et les erreurs, qui révèlent la structure interne du serveur.

Ils servent aussi de preuve en cas d’incident, donc ils ne doivent pas être modifiables. Ils appartiennent à root:adm : seuls root et le groupe adm peuvent les lire.

06L’en-tête Server

Quelles informations un attaquant peut-il tirer de l’en-tête Server ?

Cet en-tête indique en général le logiciel, sa version et l’OS, par exemple Apache/2.4.x (Debian). L’attaquant peut :

savoir quel logiciel tourne, et dans quelle version ;
chercher les vulnérabilités connues (CVE) de cette version précise ;
connaître la distribution, ce qui oriente ses attaques.

Contre-mesureServerTokens Prod et ServerSignature Off : l’en-tête n’affiche plus que « Apache ».

07Chiffrer le trafic

Le trafic de votre serveur circule en clair. Quel protocole faudrait-il mettre en place pour le chiffrer ?

HTTPS, c’est-à-dire HTTP sur TLS (anciennement SSL).

Concrètement :

activer le module : a2enmod ssl ;
configurer un VirtualHost sur le port 443 avec un certificat ;
rediriger le port 80 vers 443.

Le certificat peut être auto-signé en TP, ou délivré par une autorité comme Let’s Encrypt en production.

Mise en place pas à pas (certificat auto-signé)

1. Activer le module SSL

$ a2enmod ssl

2. Générer la clé et le certificat (valable un an)

$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout /etc/ssl/private/apache-tp.key \
  -out /etc/ssl/certs/apache-tp.crt \
  -subj "/C=FR/O=TP BTS CIEL/CN=kali.local"

-x509 produit directement un certificat auto-signé.
-nodes laisse la clé sans mot de passe, sinon Apache le demanderait à chaque démarrage.
CN doit correspondre au nom ou à l’IP utilisé dans le navigateur.

3. Créer le VirtualHost dans /etc/apache2/sites-available/tp-ssl.conf

<VirtualHost *:443>
    ServerName kali.local
    DocumentRoot /var/www/html

    SSLEngine on
    SSLCertificateFile    /etc/ssl/certs/apache-tp.crt
    SSLCertificateKeyFile /etc/ssl/private/apache-tp.key

    ErrorLog  ${APACHE_LOG_DIR}/ssl_error.log
    CustomLog ${APACHE_LOG_DIR}/ssl_access.log combined
</VirtualHost>

Sur KaliUn modèle existe déjà : a2ensite default-ssl l’active directement, avec le certificat « snakeoil » fourni par le système.

4. Activer le site, tester la syntaxe, recharger

$ a2ensite tp-ssl
$ apachectl configtest      # doit afficher : Syntax OK
$ systemctl reload apache2

5. Vérifier

$ ss -tlnp | grep :443
$ curl -kI https://localhost

-k dit à curl d’accepter le certificat auto-signé.

6. Rediriger le port 80 vers 443 (facultatif) : dans le <VirtualHost *:80> de 000-default.conf, ajoutez

Redirect permanent / https://kali.local/

puis systemctl reload apache2.

À savoirLe navigateur affichera un avertissement « connexion non sécurisée » : personne n’a signé ce certificat, mais le chiffrement fonctionne. En production, utilisez Let’s Encrypt (certbot --apache) avec un nom de domaine public. La clé privée reste dans /etc/ssl/private/, illisible pour les autres utilisateurs.