Scéance pratique 4

• Slides de la présentation de session 4 en français

L’objectif de cette séance est de créer le réseau suivant :

Il s’agit du réseau d’une entreprise qui s’est vu attribué l’adresse 100.10.0.0/24. Ce réseau est composé:

• d’un sous-réseau correspondant à l’intranet (100.10.0.0/25), et, d’un sous-réseau appelé DMZ (100.10.0.128/25) qui correspond à une zone jouant le rôle de tampon entre l’Internet (réseau 200.10.0.0/16) et l’intranet (réseau 100.10.0.0/25) de l’entreprise.

L’objectif est de configurer ce réseau et de le sécuriser.

Pour cela, nous allons configurer:

• le proxy qui se trouve dans la DMZ
• le réseau IP dans son ensemble, ce qui inclue :
  • l’intranet (réseau 100.10.0.0/25)
  • la DMZ (réseau 100.10.0.128/25)
  • l’Internet (réseau 200.10.0.0/16)
• un serveur HTTP apache qui sera installé sur la machine wserver
• un reverse proxy ningx qui sera installé sur la machine proxy et qui fera suivre le trafic http vers le site web
• les deux routeurs jouant le rôle de firewall, à savoir fw1 et fw2
• un serveur https apache qui sera aussi installé sur la machine wserver

Configuration du reverse proxy de la DMZ

Nous allons utiliser nginx en tant que reverse proxy http(s), sachant qu’il peut jouer le rôle de reverse proxy pour d’autres types de services. Nous devons dans un premier temps rendre opérant nginx ce qui consiste à l’inclure dans le container docker quagga qui est désormais opérant.

Comme expliqué à l’url suivante: https://github.com/KatharaFramework/Docker-Images nous allons donc altérer l’image quagga qui est stockée localement. Il se peut que vous ayez besoin de droit d’aministrateur/root (il faut par exemple taper sudo avant chaque commande avec ubuntu).

Commencer par lancer docker (en sélectionnant le menu de votre système d’exploitation et en lancant l’application docker.

Vous allez ensuite taper les commandes suivantes pour arrêter les container exécutés par kathara, puis vérifier que kathara/quagga est bien disponible et vérifier qu’aucun container quagga ne s’exécute.

kathara wipe 
docker images 
docker ps -a 

Pour altérer l’image de quagga en y rajoutant le service nginx, vous allez taper les commandes suivantes :

docker run -tid --name containerquagga kathara/quagga
docker exec -ti containerquagga bash
    
apt-get update 
apt-get install nginx
service nginx start
exit
docker commit containerquagga kathara/quagga
docker rm -f containerquagga

Nginx est désormais disponible dans le container quagga de kathara que nous utiliserons par la suite une fois que le lab sera mis en place.

Mise en place du Lab

Pour vous aider, nous vous mettons à disposition un zip du lab qui contient les fichiers de configuration des différents équipements: dmz.zip

Après avoir décompressé ce fichier zip dans un répertoire de travail dédié, étudiez les fichiers de configuration de l’exercice (fichier lab.conf). et des équipements (pc1.startup ect…). La configuration des firewalls (les tables de routage de fw1 et fw2) n’a pas été effectuée non plus. Pour cela, nous utilisons quagga et zebra qui permettant de gérer le routage IP et d’effectuer les mises à jour nécessaires dans notre cas de la table de routage du noyau, des consultations d’interfaces et une redistribution des routes entre différents protocoles de routage. Vous pouvez consulter le lien suivant pour plus d’information sur quagga : documentation.

Nettoyage préalable

Comme nous avons besoin d’une image de machine virtuelle avec des services dédiés à un routeur (avec zebra + quagga), reconfigurer katara en tapant la commande suivante :

kathara settings

Le menu suivant apparait. Attention, si le menu qui apparait est un peu différent, vous devrez faire avec et faire attention de bien choisir l’option qui nous intéresse.

. Sélectionner l’option Choose default image en tapant 2 (comme indiqué ci-dessous, toutefois, sil le numéro correspondant n’est pas deux dans le menu qui apparait, taper le bon numéro)

. Sélectionner l’option kathara quagga en tapant 8 (comme indiqué ci-dessous, toutefois, sil le numéro correspondant n’est pas deux dans le menu qui apparait, taper le bon numéro)

. Sélectionner l’option exit en tapant 16 (comme indiqué ci-dessous, toutefois, sil le numéro correspondant n’est pas deux dans le menu qui apparait, taper le bon numéro)

Quagga est désormais utilisé comme image de base.

Démarrage du Lab

Dans le répertoire de travail où vous avez décompressé le fichier “dmz.zip”, lancez kathara en tapant la commande suivante :

kathara lstart

Configuration IP du réseau

Objectif :

1. Vérifier les configurations de pc1, de wserver, de proxy et de pc3.

2. Vous pouvez faire un ping entre le pc1 et le wserver pour vérifier que l’ensemble est opérationnel.

3. Il vous faut configurer (comme lors de la session précédente) fw1 et fw2 de manière à ce que leur table de routage disposent des routes nécessaires pour acheminer les paquets entre les différents réseaux.

3.1 Dans la console des routeurs fw1 et fw2, taper la commande suivante pour vous connecter au deamon zebra :

telnet localhost zebra

3.2 Les interfaces de fw1 ont déjà été configurées. Pour fw1, il ne vous reste plus qu’à ajouter une route vers le réseau distant 200.10.0.0./16 accessible en passant par le routeur fw2 (adresse ip 100.10.0.130). Taper sur fw1 les commandes suivantes :

enable 
configure terminal
ip route 200.10.0.0/16 100.10.0.130
end
quit
exit

3.3 Les interfaces de fw2 ont déjà été configurées. Il ne vous reste plus qu’à ajouter une route vers le réseau distant 100.10.0.0/25 accessible en passant par le routeur fw1 (adresse ip 100.10.0.129). Taper sur fw2 les commandes suivantes :

enable 
configure terminal
ip route  100.10.0.0/25 100.10.0.129
end
quit
exit

4. Effectuez des pings entre pc1 et pc3 puis pc1 et proxy pour vérifier que votre configuration est bonne.

Un intranet constitué d’un ordinateur et d’un serveur Web reliés par un pont

L’intranet ressemble beaucoup à l’exercice de la session précédente dans lequel un ordinateur pc1 et un serveur wserver héberge une page web alors qu’un pont transmet les paquets entre les deux.

Vous allez maintenant héberger une page web (rudimentaire) sur le serveur wserver. A cet effet, vous allez utiliser le serveur web open source apache disponible sous window, macos, linux. Vous allez développer une page web index1.html qui sera hébergée sur le serveur apache2 de la machine wserver.

1. Développer une page Web Pour écrire une page web (html), vous pouvez pour cela vous référer à la séance pratique 2.

Créer le fichier /var/www/html/index1.html qui contient votre page web.

2. Pour que ce site Web soit disponible, il vous faut créer un fichier de configuration qui lui est dévolu. Le nom de ce fichier de configuration est 100.10.0.3.conf si l’adresse de votre machine est 100.10.0.0.3 Dans le répertoire /etc/apache2/sites-available , créer ce fichier de configuration. Attention, si l’adresse IP de wserver, n’est pas l’adresse IP mentionnée ci-dessus, vous devez renommer le fichier en conséquence. Ajouter dans ce fichier de configuration le contenu suivant:

<VirtualHost *:80>
        # The ServerName directive sets the request scheme, hostname and port th
at
        # the server uses to identify itself. This is used when creating
        # redirection URLs. In the context of virtual hosts, the ServerName
        # specifies what hostname must appear in the request's Host: header to
        # match this virtual host. For the default virtual host (this file) this
        # value is not decisive as it is used as a last resort host regardless.
        # However, you must set it for any further virtual host explicitly.
        #ServerName www.example.com

        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html
        ServerName 100.10.0.3
        # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
        # error, crit, alert, emerg.
        # It is also possible to configure the loglevel for particular
        # modules, e.g.
        #LogLevel info ssl:warn

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

        # For most configuration files from conf-available/, which are
        # enabled or disabled at a global level, it is possible to
        # include a line for only one particular virtual host. For example the
        # following line enables the CGI configuration for this host only
        # after it has been globally disabled with "a2disconf".
        #Include conf-available/serve-cgi-bin.conf
</VirtualHost>

3. Pour rendre le site disponible, taper la commande suivante (remplacer 100.0.0.3 si l’adresse IP de wserver n’est pas celle ci!):

a2ensite 100.10.0.3

service apache2 reload

4. utiliser tcpdump (au niveau de pc1) et wireshark pour analyser les échanges http qui vont avoir lieu (à cet effet, vous pouvez vous référer à la séance pratique 3).
   
   

5. sur pc1, générez une requête http pour obtenir la page web

   curl -v http://100.10.0.3/index1.html

   On peut observer la requête HTTP GET ainsi que la réponse renvoyée par le serveur web.

6. vous pouvez observer le trafic qui a été échangé.

Le cas d’une zone démilitarisée

Typiquement, les serveurs d’application (tout comme un serveur Web) sont généralement situés en interne (au sein de l’intranet de l’entreprise). Si le besoin se fait sentir d’accéder à ces ressources depuis l’Internet- comme c’est le cas avec le serveur Web d’une entreprise par exemple - quelques scénarios dont le notre, peuvent être considérés.

Une approche courante vise à installer les serveurs (et les services qu’ils hébergent) dans une zone du réseau de l’entreprise physiquement ou logiquement isolée des autres (et notamment de l’intranet). Cette zone est appelée DMZ (Demilitarized zone) est soumise à un filtrage s’effectuant idéalement via 2 parre-feux IP alors que les serveurs serveurs sont installés dans l’intranet. Il s’agir d’une architecture typique trois tiers.

Les requêtes externes en provenant de l’Internet (zone de danger) passent par les deux pare-feux (firewalls) qui filtrent les messages. Ces deux pare-feux sont installés aux deux points de passage obligatoires entre le réseau interne à protéger (intranet), la DMZ et le réseau externe non sécuritaire (l’internet. La DMZ, est ainsi créée pour servir d’intermédiaire entre le danger en provenance de l’extérieur et les services de back-end de l’intranet. Idéalement, chaque service devrait être isolé sur son propre serveur. Mais ce n’est pas toujours envisageable.

Dans notre exemple, un seul serveur apache http est disponible dans l’intranet et un reverse proxy nginx fait suivre les requêtes provenant de l’Internet vers ce serveur.

Paramétrage du reverse proxy nginx

Un reverse proxy est un erveur qui se place entre les clients (dans notre cas un client correspond à un client http munis d’un navigateur et se trouvant typiquement sur internet, comme pc3) et un ou plusieurs serveurs backend (dans notre cas un serveur web apache se trouvant dans l’intranet de l’entreprise). Le reverse proxy intercepte les requêtes des clients et les redirige vers le serveur approprié (ici wserver), puis, il retourne la réponse aux clients comme si elle provenait directement de lui-même.

Un reverse proxy améliore la sécurité au sens où :

• Les serveurs internes (backend servers comme le serveur web se trouvant dans l’intranet) ne sont plus exposés car la topologie de l’intranet reste cachée/moins facilement accessible du point de vue de l’Internet. En particulier, le reverse proxy masque les adresses IP des serveurs backend et peut bloquer des requêtes malveillantes, protégeant ainsi l’infrastructure.
• Les applications vulnérables peuvent aussi être protégées en plaçant un pare-feu HTTP (fw1 et fw2 dans notre cas).

Dans le proxy, taper la commande suivante :

/# ls -l /etc/nginx/sites-enabled/
total 0
lrwxrwxrwx 1 root root 34 Feb  9 09:12 default -> /etc/nginx/sites-available/default

Nous allons commencer par faire que le fichier de configuration default qui est situé dans le répertoire /etc/nginx/sites-enabled/ ne pointe plus vers le fichier de configuration par défaut:

 unlink /etc/nginx/sites-enabled/default

cd /etc/nginx/sites-available

Editer le fichier 100.10.0.3.conf sachant que 100.10.0.3 correspond à l’adresse IP du site web qui doit être pris en charge par le reverse proxy:

nano 100.10.0.3.conf

Ce fichier doit contenir :

server {
        listen 80;
        server_name 100.10.0.3;
        access_log /var/log/nginx/reverse-access.log;
        error_log /var/log/nginx/reverse-error.log;
        location / {
                    proxy_pass http://100.10.0.3;
        proxy_set_header Host $host; # Forwarded host
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}

Dans l’exemple fourni, toutes les requêtes reçues par le reverse proxy nging sur le port 80 (listen 80; listen [::]:80;) seront réacheminées à l’adresse l’url http://100.10.0.3

Les logs seront stockés dans les fichiers /var/log/nginx/reverse-access.log et /var/log/nginx/reverse-error.log .

Faite un lien pour que le fichier /etc/nginx/sites-enabled/reverse-proxy.conf pointe sur le fichier /etc/nginx/sites-available/reverse-proxy.conf en tapant la commande suivante :

ln -s /etc/nginx/sites-available/100.10.0.3.conf /etc/nginx/sites-enabled/100.10.0.3.conf

Tester que nginx n’a pas de problème avec le fichier de configuration que nous avons modifié :

nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Taper l’une des deux commandes ci-dessous pour que le reverse proxy soit opérationnel.

systemctl restart nginx
systemctl reload nginx

Au niveau de pc1, ou pc3, taper la commande suivante :

curl http://100.10.0.131/index1.html

Configuration de la DMZ et de ses firewalls

Nous allons utiliser la commande nftables pour configurer le sous-système de traitement des paquets réseau du noyau Linux qui opère au niveau de la couche 3 (couche résau) du modèle OSI. L’objectif est que les deux firewalls protègent le réseau de l’entreprise en filtrant les paquets indésirables et en ne laissant passer que les paquets désirables.

Quelques explications sur le traitement/filtrage d’un paquet sur un firewall utilisant nftables

Voici un shémas simplifié de netfilter qui explique le chemin que va parcourir un paquet dans un ordinateur ou un routeur firewall:

Une décision de routage est prise lorsqu’un paquet arrive sur une interface d’entrée (input interface) : le paquet est soit destiné à un processus local soit il faut le faire suivre (forwarder) vers une interface de sortie. Par exemple, si un pc ping un routeur, le paquet est destiné à un processus local du routeur. Au contraire, si un pc échange des paquets http avec un serveur web, le traffic http transitant par le routeur doit être transferé (forwardé et peut être possiblement filtré, c-à-d supprimé si cela est désiré) vers une interface de sortie du routeur.
Un processus local peut aussi générer un paquet (c’est le cas si l’on tape une commande ping sur le routeur firewall). Dans ce cas, une décision de routage est prise et le paquet est ainsi forwardé vers une interface de sortie. Netfilter propose la notion de hook qui est un point de branchement où il est possible d’intervenir et par exemple de prendre une décision de filtrage.
Il existe plusieurs hooks: prerouting, forward, input, output, postrouting qui permettent d’effectuer des actions comme par exemple un filtrage à chacun de ces niveaux.

nftables nous permet ici de définir des règles pour filtrer - même si nftables permet aussi de manipuler, ou rediriger le trafic réseau - en prenant en compte les conditions que nous aurons spécifiées.
nftables dispose de tables, de chaînes, et de règles:

• Une table est un conteneur pour des chaînes et des règles. Par exemple, la table inet que nous allons utiliser ci-après- nous permettra de gérer le filtrage de paquets.

Chacune des tables comporte des chaînes (ou séquences) de règles de traitement.

• Une chaîne contient des règles pour traiter des paquets. Il existe des chaînes prédéfinies comme INPUT, OUTPUT, et FORWARD.
• Une rêgle correspond à une action à appliquer au paquet, comme par ex. accepter, refuser, ou rediriger.
  Le fonctionnement d’une rêgle est simple. Voici la commande typique qui permet d’ajouter une rêgle à une table (qui se nomme ici une table) et à une chaine (qui se nomme ici unechaine):

nft add rule unetable unechaine condition 1, condition 2, ..., condition n,   action1, action2....```

Cette rêgle est appliquée de la façon suivante : tant qu’un paquet vérifie une condition, on vérifie la condition suivante … et si toutes les conditions sont vérifiées, toutes les actions (action 1, …) sont appliquées.
Si une seule condition n’est pas remplie, la rêgle n’est pas appliquée et on passe à la rêgle suivante. Par défaut quand on ajouter une rêgle, elle est ajoutée à la fin de la chaîne qui est stipulée. Voici un exemple de rêgle qui accepte un paquet entrant tcp dont le port de destination est 23 et qui est rajoutée à une chaîne d’appelant filter :

nft add rule filter input tcp dport 23 accept

Vérifier l’opérationalité de nftables et prendre connaissance des configurations des firewalls

Avant de commencer, sur les deux firewalls (fw1 et fw2), nous allons vérifier que le status du service nftables en tapant la commande suivante sur les deux firewalls:

systemctl status nftables.service

Si le service nftables n’est pas démarré, démarrez le en tapant la commande suivante :

systemctl start nftables.service

Voici des commandes qui que vous pouvez taper sur les deux firewalls dès maintenant pour afficher des informations relatives à nft:

• nft list tables : pour lister les tables existantes
• nft list ruleset : pour lister les rêgles
• nft list chains: pour lister les chaînes

Pour l’instant vous n’avez rien configuré, donc peut d’informations s’affichent, ce qui est normal.

Le fichier de configuration contenant les configurations effectuées par neftables est le fichier
nftables.conf qui se trouve dans le répertoire /etc/. Vous pouvez éditer ce fichier en tapant la commande suivante :

nano /etc/nftables.conf

Dans la section qui suit, vous allez voir de quelle manière opérer pour pouvoir ajouter des rêgles dans un firewall (tel que fw1 ou fw2). Quelques exemples seront présentés. Il vous faudra par la suite vous même ajouter vos propres rêgles pour sécuriser le réseau d’entreprise que vous avez conçu.

Comment ajouter des rêgles de filtrage avec nftables

• Créer une table (à qui vous donnez un nom qui n’est pas déjà utilisé) pour gérer les filtres.
• Ajouter une chaîne de filtrage.

nft add chain filter input { type filter hook input priority 0\;}

• Ajouter la rêgle qui vous intéresse et qui bloque/accepte par exemple le trafic HTTP(s) vers le réseau donné.

• nft flush ruleset : pour surpprimer toutes les rêgles

• nft add : pour ajouter des tables, chaînes ou règles.

• nft delete : pour supprimer des éléments.

• nft delete table inet filter : pour supprimer la table inet filter. - nft flush table ip filter : pour supprimer toutes les chaines de la table ip appelée filter

• nft list : pour afficher la configuration actuelle.

Exemple pratique : supposons que vous vouliez configurer un pare-feu simple avec nftables :

a. Créer une table de filtrage qui s’appelle inet (et s’applique souvent à ipv4/6 mais vous pouvez lui donner un autre nom):

nft add table inet filter

b. Créer des chaînes dans la table filter :

b.1 on ajoute une chaine input avec une politique par défaut qui est de faire du drop. On a rajouté un hook qui s’accroche à input dans netfilter

nft add chain inet filter input { type filter hook input priority 0; policy drop ;}

b.2 on ajoute une chaine output avec une politique par défaut qui est de faire du drop

nft add chain inet filter output { type filter hook output priority 0; policy drop ;}

b.3 on ajoute une chaine forward avec une politique par défaut qui est de faire du drop

nft add chain inet filter forward { type filter hook forward priority 0; policy drop ;}

c. Ajouter des règles pour accepter les flux générés par le routeur :

c.1 accepter le traffic de l’interface de loopback lo :

nft add rule inet filter input iifname "lo" accept

c.2 accepter les pings, traceroute (et donc le protocole icmp) :

nft add rule inet filter input ip protocol icmp accept

c.3 Ajouter une règle pour accepter les connexions SSH (port 22) au niveau de la chaine input :

nft add rule inet filter input tcp dport 22 accept

c.4 Ajouter une règle pour accepter les paquets entrants sur le port 80 (HTTP)

nft add rule inet filter input tcp dport 80 accept

c.5 Ajouter une règle pour bloquer le trafic HTTP (port 80) vers 192.168.1.0/24

nft add rule inet filter input ip daddr 192.168.1.0/24 tcp dport 80 drop

d. Ajouter des règles pour les flux en sortie d.1 En sortie, rajouter un rêgle pour accepter les flux de l’interface de loopback :

nft add rule filter output oifname "lo" accept

d.2 En sortie, rajouter un rêgle pour accepter les flux ICMP :

nft add rule filter output ip protocol icmp accept

d.3 En sortie, accepter le trafic http (port 80, tcp) et https (port 443, tcp) :

nft add rule filter output ip protocol tcp tcp dport {80,443} accept

d.4 En sortie, accepter le trafic dns (udp port 53)

nft add rule filter output ip protocol udp udp dport 53 accept

e. Ajouter des rêgles pour les flux en transit (forward)

e.1. En transit (forward), accepter de faire transiter (forward) les paquets tcp http et https (port 80 et 443) à destination de l’adresse 10.10.10.40

nft add rule filter forward ip protocol tcp ip daddr 10.10.10.40 tcp dport {80,443} accept

Une fois les règles ajoutées, vous pouvez sauvegarder la configuration de nftables :

nft list ruleset > /etc/nftables.conf

A vous de jouer : protégez votre réseau en configurant vos deux firewalls …

A cet effet, il vous faut réflechir à (voir dessiner) quels sont les traffics que vous laissez passer (et dans quel sens c-à-d vers quel destinataires/réseaux).

Par exemple, le firewall fw1 devrait s’assurer que seul le reverse proxy envoie des paquets http à wserver.

A vous de définir quelles flux sont autorisés à transiter par les deux firewalls et à configurer vos firewalls en conséquence.

Pour vous aider dans cet opération, voici le contenu du fichier nftables.conf de fw1.

#!/usr/sbin/nft -f
\00\DC
flush ruleset
\00\DC
table inet filter {
chain input {
type filter hook input priority filter; policy drop;
\00\DC
 iifname lo accept \
comment "Accept any localhost traffic"
\00\DC
 ct state { established; related } accept \
comment "Accept traffic originated from us"
\00\DC
 ct state invalid drop \
comment "Drop invalid connections"
\00\DC
 log prefix "[nftables] Inbound Denied: " counter drop \
comment "Logging of denied inbound traffic"
}
\00\DC
 chain forward {
type filter hook forward priority filter; policy drop;
\00\DC
 ct state { established; related } accept \
comment "Accept established and related traffic"
\00\DC
 ct state invalid drop \
comment "Drop invalid connections"
\00\DC
 ip protocol icmp icmp type {
echo-reply, # type 0
destination-unreachable, # type 3
echo-request, # type 8
time-exceeded; # type 11
parameter-problem, # type 12
} accept \
comment "Accept ICMP"
\00\DC
 iifname eth0 accept \
comment "Accept all intranet traffic"
\00\DC
 ip daddr 100.10.0.131 tcp dport 80 accept \
comment "Accept HTTP from any to proxy"
\00\DC
}

}
log prefix "[nftables] Forward Denied: " counter drop \
comment "Logging of denied forward traffic"
chain output {
type filter hook output priority filter; policy accept;
}

Pour fw1, vous pouvez appliquer ces rêgles édictées ci-dessous en éditant le fichier /etc/nftables.conf. Pour cela, tapez la commande suivante :

nano /etc/ntables.conf

Supprimez le contenu du fichier et remplassez le par le contenu donné ci-dessus.

A vous maintenant de réfléchir pour fw2.

Sécurisation du serveur HTTP (en HTTPS)

Il est possible d’une part d’observer, voir aussi d’intercepter puis modifier le trafic, en particulier, le contenu des messages et l’identité des émetteurs/récepteurs. Nous allons voir en quoi https peut aider à éviter cela et peut nous garantir la confidentialité, l’intégrité et l’authenticité du serveur Web.

La confidentialité

La confidentialité est une propriété visant à ce qu’une information (un message, par exemple) ne soit pas divulguée à des entités non autorisées.

L’intégrité

Garantir l’intégrité des données consiste à déterminer si les données ont changé entre le moment où elles ont été créées, stockées et/ou transmises, et le moment où elles ont été récupérées et/ou reçues. Si l’intégrité des données ne peut être garantie, l’idée est plutôt de fournir un moyen de détecter les changements. En pratique, un code d’intégrité des données est calculé sur les données au moment de leur création, avant leur stockage ou transmission, et calculé à nouveau lorsque les données sont extraites ou reçues. La vérification de la concordance du résultat de ces calculs permet de garantir l’intégrité des données.

L’authentification

L’authentification de la source est un processus utilisé pour garantir la source de l’information. Elle comprend l’authentification de l’identité, qui garantit à l’une des parties d’une communication (par exemple, Bob) qu’elle reçoit des données d’une autre partie (par exemple, Alice). Selon la méthode utilisée, l’authentification à la source pourrait également permettre la non-répudiation, qui implique l’assurance que les données proviennent d’Alice qui ne peut le nier.

Avant de commencer, en utilisant le site https://www.ssllabs.com/ssltest/index.html, vous pouvez obtenir des informations relatives au certificat d’un site web utilisant https. Vous pouvez tester celui d’IMT Atlantique en entrant comme hostname : www.imt-alantique.fr

Le certificat

Un certificat est associé (contient) une clé publique ; la clé privée correspondant à la clé publique, quant à elle, n’est jamais partagée.
Dans notre cas, le certificat contenant la clé publique est utilisé pour sécuriser le site web (c-à-d les échanges avec le site web). Le certificat est donc hébergé sur le site Web. Dans notre cas, la clé privée du site Web est gardée secrête par ce dernier.

Les informations essentielles contenues dans un certificat sont relatives à la clé publique (du site web ici), une signature qui est apposée par une autorité de certification (une signature est apposée sur les informations contenues dans ledit certificat).

L’autorité de certification

L’autorité de certification est l’application de contrôle qui détermine que le titulaire (le site web https) d’un certificat est bien celui qu’il prétend être, avec un niveau d’assurance spécifié. Tous les certificats portent la signature de l’autorité de certification pour en garantir l’authenticité. Le système de clés publiques/privées permet aux données cryptées par une clé d’être décryptées par l’autre.

Les navigateurs modernes disposent d’une liste de certificats provenant de différentes Autorités de Certification importantes. En pratique, un site web HTTPS génère une clé publique et une clé privée. Puis, il envoie à une autorité de certification une demande de signature de certificat (Certificate Signing Request) contenant sa clé publique ainsi que des informations le concernant. L’Autorité de Certification, au moyen de sa propre clé privée, signe le certificat et le transmet au site web. Le site web peut ainsi transmettre ce certificat à tout utilisateur.

Comme nous venons de voir, une autorité de certification (un tiers de confiance, qui peut s’apparenter à un notaire) participe à la génération, mais pas dans le cas que nous allons voir et pour lequel le site web s’auto-certifie, ce qui n’est pas courant. Dans notre cas, nous supposons que l’utilisateur de pc1 dispose du certificat du site web qui s’est auto-certifié. Par exemple, l’utilisateur de pc1 et l’administrateur du site web ont échangé pour cela une clé USB contenant le certificat de manière à l’installer sur pc1. Nous serons amené à faire de même avec le simulateur kathara.

Rendre opérationnel HTTPS grace à un certificat auto-certifié

Pour rendre opérationnel HTTPS, nous allons effectuer les étapes que nous allons détailler ci-après. Ces configurations ne doivent pas être appliquées sur pc1, mais sur le serveur Web Apache. Apache doit rendre opérant le module SSL/TLS.

1. Rendre opérant le module SSL/TLS

En utilisant la commande a2enmod, nous allons rendre opérant le module SSL :

a2enmod ssl

2. Redémarrer Apache pour rendre ce module opérant

service apache2 restart

Pour vérifier l’activation du module :

a2query -m ssl

3. Générer un nouveau certificat accompagné d’une clé secrète

Un certificat contient des informations concernant le site HTTP. Nous allons par la suite utiliser openssl, qui est un outil populaire pour créer et gérer les certificats. Les options d’openssl utilisées en ligne de commande sont les suivantes :

-req : pour utiliser un certificat X.509 qui est une norme d’infrastructure de clés publiques à laquelle SSL et TLS adhèrent

-x509 : pour créer un certificat auto-signé au lieu de générer une demande de signature de certificat, comme cela devrait normalement être le cas -nodes : pour ignorer l’option permettant de sécuriser notre certificat avec une phrase de passe, car nous avons besoin qu’Apache puisse lire le fichier sans l’intervention de l’utilisateur -days 365 : pour définir la durée pendant laquelle le certificat sera considéré comme valide (un an) -newkey rsa:2048 : générer un nouveau certificat et une nouvelle clé secrète -keyout : pour indiquer l’endroit où est placée la clé générée -out : pour indiquer l’endroit où est placé le certificat et d’autres fichiers

Taper la commande invokant openssl avec les options suivantes :

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/apache-selfsigned.key -out /etc/ssl/certs/apache-selfsigned.crt

Après avoir entré la commande, vous serez dirigé vers une invite où vous pourrez entrer des informations sur votre site web (dans notre exemple ci-dessous, le site web est hébergé sur wserver qui a pour adresse IP 100.10.0.3, si tel n’est pas le cas pour vous, vous devez utiliser l’adresse IP qui vous convient).

Country Name (2 letter code) [XX]:FR
State or Province Name (full name) []: FR
Locality Name (eg, city) [Default City]:BREST  
Organization Name (eg, company) [Default Company Ltd]:ma compagnie
Organizational Unit Name (eg, section) []: DEPARTEMENT
Common Name (eg, your name or your server's hostname) []:100.10.0.3 
Email Address []:

Créer et éditer le fichier 100.10.0.3.conf dans le répertoire /etc/apache2/sites-available. Editer ce fichier (en tapant sous linux la commande suivante: )

nano /etc/apache2/sites-available/100.10.0.3.conf

Le contenu du fichier est le suivant:

<VirtualHost *:80>
    ServerName 100.10.0.3 
    DocumentRoot /var/www/html   
</VirtualHost>

<VirtualHost *:443>
ServerName 100.10.0.3
DocumentRoot /var/www/html

SSLEngine on
SSLCertificateFile /etc/ssl/certs/apache-selfsigned.crt
SSLCertificateKeyFile /etc/ssl/private/apache-selfsigned.key
</VirtualHost>

Les informations contenues dans ce fichier stipulent que fichier contenant le certificat auto-signé est apache-selfsigned.crt et se trouve dans le répertoire /etc/ssl/certs. Le fichier apache-selfsigned.key où se trouve la clé privée (chiffrée) est acessible dans le répertoire /etc/ssl/private/. Enfin https est acessible sur le port 443.

Pour afficher le contenu de ce certificat, taper la commande suivante :

 openssl x509 -in /etc/ssl/certs/apache-selfsigned.crt -text -noout command

Pour rendre opérationel le fichier de configuration et reloader apache:

a2ensite 100.10.0.3.conf
service apache2 reload 

Au niveau du serveur web , vous allez copier dans le répertoire shared (crée au préalable) comme dans la session précédent, le fichier contenant le certificat qui a été généré.

cp /etc/ssl/certs/apache-selfsigned.crt /shared/apache-selfsigned.crt 

Puis, au niveau de pc1 maintenant, vous allez copier le certificat dans votre répertoire courant.

cp /shared/apache-selfsigned.crt   ./apache-selfsigned.crt

Vous allez utiliser wireshark et tcpdump (comme dans lors de la séance précédente) pour voir les messages qui vont transiter sur le réseau. C’est au niveau de pc1 que vous lancerez la commande tcpdump.
Une fois la commande tcpdump lancée, vous pouvez lancer toutes les commandes ci-dessous.

Sur pc1, relancer la commande suivante pour télécharger (en utilisant http) la page web dévelopée

curl -v http://100.10.0.3/index1.html

Vous verrez apparaitre le traffic http et la page web transitant en clair.

Sur pc1, si vous tapez la commande curl comme définis ci-dessous, un message d’erreur devrait apparaitre. Il spécifie que le certificat du site http est auto-signé (signé par lui-même, ce qui est notre cas, mais ce qui n’est pas très sécure, ce qui explique le message d’alerte généré).

curl -v https://100.10.0.3/index1.html
*   Trying 100.10.0.3:443...
* Connected to 100.10.0.3 (100.10.0.3) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: self-signed certificate
* Closing connection 0
curl: (60) SSL certificate problem: self-signed certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Par contre, si vous utilisez le certificat copié localement, et que vous tapez la commande suivante, aucun message ne s’affiche et la page web est transferrée puis s’affiche à l’écran.

curl --cacert ./apache-selfsigned.crt https://100.10.0.3/index1.html 

Pour voir le contenu du certificat sur pc1, taper la commande suivante :

 openssl x509 -text -noout -in  ./apache-selfsigned.crt

Avec wireshark, vous verrez que le contenu des messages TCP échangés qui sont relatifs à https et qui sont chiffrés donc illisibles… La confidentialité est donc guarantie.

Nous venons de voir qu’un certificat disponible sur pc1, ne peut être utilisé nin pour assurer la confidentialité, l’intégrité et l’authenticité des messages renvoyés par le site Web.
Supposons que pc1 envoie un message contenant un challenge appelé aussi NONCE (Number used ONCE, soit en francais un numbre utilisé une seule et une seule fois) qui correspond par exemple à un nombre aléatoire ou un chiffre incrémenté à chaque fois. pc1 envoie donc au serveur serveur web un message aléatoire crypté avec la clé publique du serveur web.