Teaching-HEIGVD-SRX-2022-Laboratoire-Firewall

Travail à réaliser en équipes de deux personnes.

ATTENTION : Commencez par créer un Fork de ce repo et travaillez sur votre fork.

Clonez le repo sur votre machine. Vous retrouverez notamment dans ce repo les ficher Dockerfile et docker-compose.yml indispensables pour l'ajout des conteneurs et configuration du réseau.

Vous pouvez répondre aux questions en modifiant directement votre clone du README.md ou avec un fichier pdf que vous pourrez uploader sur votre fork.

Le rendu consiste simplement à compléter toutes les parties marquées avec la mention "LIVRABLE". Le rendu doit se faire par une "pull request". Envoyer également le hash du dernier commit et votre username GitHub par email au professeur et à l'assistant

Table de matières

Cahier des charges du réseau

Regles de filtrage

Installation de l’environnement virtualisé

Tests des connections et exemple de l'application d'une règle

Règles pour le protocole DNS

Règles pour les protocoles HTTP et HTTPS

Règles pour le protocole ssh

Règles finales

Introduction

L’objectif principal de ce laboratoire est de familiariser les étudiants avec les pares-feu et en particulier avec netfilter et nftables, le successeur du vénérable iptables. En premier, une partie théorique permet d’approfondir la rédaction de règles de filtrage.

Par la suite, la mise en pratique d’un pare-feu permettra d’approfondir la configuration et l’utilisation d’un pare-feu ainsi que la compréhension des règles.

La documentation nftables est très complète. Vous en aurez besoin pour réaliser ce laboratoire et pour répondre à certaines questions.

La documentation contient aussi un excellent résumé pour "apprendre nftables en 10 minutes" qui peut vous être utile.

Auteurs

Ce texte se réfère au laboratoire « Pare-feu » à suivre dans le cadre du cours Sécurité des Réseaux, 2022, version 8.0. Au cours du temps, il a été rédigé, modifié et amélioré par les co-auteurs suivants : Gilles-Etienne Vallat, Alexandre Délez, Olivia Manz, Patrick Mast, Christian Buchs, Sylvain Pasini, Vincent Pezzi, Yohan Martini, Ioana Carlson, Abraham Rubinstein et Frédéric Saam.

Echéance

Ce travail devra être rendu le dimanche après la fin de la 2ème séance de laboratoire, soit au plus tard, le 18 Mars 2022, à 23h59.

Réseaux cible

Topologie

Durant ce laboratoire, nous allons utiliser une seule topologie réseau :

Notre réseau local (LAN) sera connecté à Internet (WAN) au travers d’un pare-feu. Nous placerons un serveur Web en zone démilitarisée (DMZ).

Par conséquent, nous distinguons clairement trois sous-réseaux :

Internet (WAN), le réseau de l'école ou votre propre réseau servira de WAN,
le réseau local (LAN),
la zone démilitarisée (DMZ).

Ce réseau sera créé de manière virtuelle. Il sera simulé sur un seul ordinateur utilisant trois conteneurs Docker basés sur le système d’exploitation Ubuntu :

La première machine, Firewall, fait office de pare-feu. Elle comporte trois interfaces réseaux. Afin que ce poste puisse servir de pare-feu dans notre réseau, nftables sera utilisé.
La seconde machine, Client_In_LAN, fait office de client dans le réseau local (LAN).
La dernière machine, Server_In_DMZ, fait office de serveur Web en (DMZ).

Nous allons utiliser les trois interfaces réseaux de la machine Firewall afin de pouvoir connecter le LAN et la DMZ à Internet (WAN). Les machines Client_In_LAN et Server_In_DMZ comportent chacune une interfaces réseau eth0.

Plan d'adressage

Afin de bien spécifier le réseau, il est nécessaire d’avoir un plan d'adressage précis. C'est la liste des réseaux que vous utiliserez, comprenant pour chaque interface l'adresse IP ainsi que le masque de sous-réseau. Pour ce laboratoire, nous vous imposons le plan d’adressage suivant :

Le réseau "LAN" → 192.168.100.0/24
Le réseau "DMZ" → 192.168.200.0/24
Le réseau "WAN" sera défini par le NAT interne du réseau Docker

Les adresses IP sont définies dans le schéma ci-dessous :

Cahier des charges du réseau

Avant de configurer les règles, il est primordial de connaître les besoins de notre réseau. Ceci afin de laisser passer les flux légitimes lors de la rédaction des règles.

Le but du LAN est de fournir aux utilisateurs de votre réseau un accès à Internet ; à certains services de base uniquement en empêchant les connexions provenant de l'extérieur. Il faudra tout de même laisser entrer les paquets répondants aux requêtes de notre LAN. Une seule machine est présente sur ce réseau. Il s’agit de la machine dont le nom est Client_In_LAN. (il est très facile de rajouter de machines supplémentaires sur le LAN utilisant Docker).

La DMZ est un réseau réservé aux serveurs que l'on veut rendre accessibles depuis l'extérieur et l’intérieur de notre réseau. Par exemple, si nous voulons publier un site web que l'on héberge, il faut accepter des connexions sur le serveur web; dans ce cas, nous ne pouvons pas le placer dans le LAN, cela constituerait un risque. Nous accepterons donc les connexions entrantes dans la DMZ, mais seulement pour les services que l'on désire offrir. Le serveur Web situé dans la DMZ est simulé par la machine Server_In_DMZ.

Le WAN n'est que l'accès à Internet. Il est connecté au réseau de l'école ou à votre propre à travers le système de réseau fourni par Docker.

Pour établir la table de filtrage, voici les conditions à respecter dans le cadre de ce laboratoire :

Les serveurs DNS utilisés par les postes dans le LAN sont situés sur le WAN. Les services DNS utilisent les ports UDP 53 et TCP 53.
Laisser passer les PING uniquement du LAN au WAN, du LAN à la DMZ et de la DMZ au LAN pour les tests. Le ping utilise le protocole ICMP (echo request et echo reply).
Les clients du LAN doivent pouvoir ouvrir des connexions HTTP pour accéder au web. Le protocole HTTP utilise les ports TCP 80 et typiquement aussi le 8080.
Les clients du LAN doivent pouvoir ouvrir des connexions HTTPS pour accéder au web. Le protocole HTTPS utilise le port TCP 443.
Le serveur web en DMZ doit être atteignable par le WAN et le LAN et n'utilise que le port 80.
Le serveur de la DMZ peut être commandé à distance par ssh depuis votre client du LAN uniquement. Le service ssh utilise le port TCP 22.
Le firewall peut être configuré à distance par ssh depuis votre client du LAN uniquement.
Toute autre action est par défaut interdite.

Regles de filtrage

En suivant la méthodologie vue en classe, établir la table de filtrage avec précision en spécifiant la source et la destination, le type de trafic (TCP/UDP/ICMP/any), les ports sources et destinations ainsi que l'action désirée (Accept ou Drop, éventuellement Reject).

Pour l'autorisation d'accès (Accept), il s'agit d'être le plus précis possible lors de la définition de la source et la destination : si l'accès ne concerne qu'une seule machine (ou un groupe), il faut préciser son adresse IP ou son nom (si vous ne pouvez pas encore la déterminer), et non la zone. Appliquer le principe inverse (être le plus large possible) lorsqu'il faut refuser (Drop) une connexion.

Lors de la définition d'une zone, spécifier l'adresse du sous-réseau IP avec son masque (par exemple, "/24" correspond à 255.255.255.0) ou l'interface réseau (par exemple : "interface WAN") si l'adresse du sous-réseau ne peut pas être déterminé avec précision.

Adresse IP source	Adresse IP destination	Type	Port src	Port dst	Action
*	*	any	*	*	Drop
192.168.100.0/24	interface WAN	TCP/UDP	*	53	Accept
interface WAN	192.168.100.0/24	TCP/UDP	53	*	Accept
192.168.100.0/24	interface WAN	ICMP	-	-	Accept
interface WAN	192.168.100.0/24	ICMP	-	-	Accept
192.168.100.0/24	192.168.200.0/24	ICMP	-	-	Accept
192.168.200.0/24	192.168.100.0/24	ICMP	-	-	Accept
192.168.100.0/24	interface WAN	TCP	*	80, 8080, 443	Accept
interface WAN	192.168.100.0/24	TCP	80, 8080, 443	*	Accept
interface WAN	192.168.200.3	TCP	*	80	Accept
192.168.200.3	interface WAN	TCP	80	*	Accept
192.168.100.0/24	192.168.200.3	TCP	*	80	Accept
192.168.200.3	192.168.100.3	TCP	80	*	Accept
192.168.100.3	192.168.200.3	TCP	*	22	Accept
192.168.200.3	192.168.100.3	TCP	22	*	Accept
192.168.100.3	192.168.100.2	TCP	*	22	Accept
192.168.100.2	192.168.100.3	TCP	22	*	Accept

Installation de l’environnement virtualisé

Ce chapitre indique comment installer l'environnement. Il se base sur des outils gratuits, téléchargeables sur Internet.

Matériel

Il est possible d’utiliser les mêmes instructions sur une version de Windows ou un système Linux ou Mac OS X.

Afin d'installer les différents logiciels présentés ici, il faut disposer d’un ordinateur (avec les droits administrateur).

Installation de Docker

Docker est un logiciel permettant de créer des conteneurs virtuels afin de simuler diverses configurations. Nous l'utiliserons pour exécuter les trois machines dont nous aurons besoin pour ce laboratoire. L’installation de Docker ne comporte pas de difficulté particulière. Une installation « par défaut » suffira. Il est possible d’utiliser une version que vous avez déjà installée ou une version téléchargée, mais la documentation pour ce laboratoire a été testée avec la version 3.2.2 de Docker Desktop pour Mac. Si vous rencontrez des problèmes, une mise à jour de Docker es peut-être la solution.

Vous pouvez trouver Docker pour Windows et Mac OS ici.

Pour Linux, referez-vous au gestionnaire de paquets de votre distribution.

Installation de Git

Vous avez probablement déjà installé Git pour d’autres cours ou projets. Si ce n’est pas le cas, vous pouvez prendre la bonne version pour votre OS ici.

Démarrage de l'environnement virtuel

Ce laboratoire utilise docker-compose, un outil pour la gestion d'applications utilisant multiples conteneurs. Il va se charger de créer les réseaux `lan` et `dmz`, la machine Firewall, un serveur dans le réseau DMZ et une machine dans le réseau LAN et de tout interconnecter correctement.

Nous allons commencer par lancer docker-compose. Il suffit de taper la commande suivante dans le répertoire racine du labo (celui qui contient le fichier docker-compose.yml:

docker-compose up --detach

Le téléchargement et génération d'images prend peu de temps.

Vous pouvez vérifier que les réseaux ont été créés avec la commande docker network ls. Un réseau lan et un réseau dmz devraient se trouver dans la liste.

Les images utilisées pour les conteneurs sont basées sur l'image officielle Ubuntu. Le fichier Dockerfile que vous avez téléchargé contient les informations nécessaires pour la génération de l'image de base. docker-compose l'utilise comme un modèle pour générer les conteneurs. Vous pouvez vérifier que les trois conteneurs sont crées et qu'ils fonctionnent à l'aide de la commande suivante.

docker ps

Communication avec les conteneurs et configuration du firewall

Afin de simplifier vos manipulations, les conteneurs ont été configurées avec les noms suivants :

Firewall
Client_in_LAN
Server_in_DMZ

Pour accéder au terminal de l’une des machines, il suffit de taper :

docker exec -it <nom_de_la_machine> /bin/bash

Par exemple, pour ouvrir un terminal sur votre firewall :

docker exec -it Firewall /bin/bash

Vous pouvez bien évidemment lancer des terminaux avec les trois machines en même temps !

Configuration de base

La plupart de paramètres sont déjà configurés correctement sur les trois machines. Il est pourtant nécessaire de rajouter quelques commandes afin de configurer correctement le réseau pour le labo.

Vous pouvez commencer par vérifier que le ping n'est pas possible actuellement entre les machines. Depuis votre Client_in_LAN, essayez de faire un ping sur le Server_in_DMZ (cela ne devrait pas fonctionner !) :

ping 192.168.200.3

En effet, la communication entre les clients dans le LAN et les serveurs dans la DMZ doit passer à travers le Firewall. Dans certaines configurations, il est probable que le ping arrive à passer par le bridge par défaut. Ceci est une limitation de Docker. Si votre ping passe, vous pouvez accompagner votre capture du ping avec une capture d'une commande traceroute qui montre que le ping ne passe pas actuellement par le Firewall mais qu'il a emprunté un autre chemin.

Il faut donc définir le Firewall comme passerelle par défaut pour le client dans le LAN et le serveur dans la DMZ.

Configuration du client LAN

Dans un terminal de votre client, taper les commandes suivantes :

ip route del default
ip route add default via 192.168.100.2

Configuration du serveur dans la DMZ

Dans un terminal de votre serveur dans DMZ, taper les commandes suivantes :

ip route del default
ip route add default via 192.168.200.2

service nginx start
service ssh start

Les deux dernières commandes démarrent les services Web et SSH du serveur.

La communication devrait maintenant être possible entre les deux machines à travers le Firewall. Faites un nouveau test de ping, cette fois-ci depuis le serveur vers le client :

ping 192.168.100.3

DMZ to lan Traceroute

LAN to DMZ traceroute

La communication est maintenant possible entre les deux machines. Pourtant, si vous essayez de communiquer depuis le client ou le serveur vers l'Internet, ça ne devrait pas encore fonctionner sans une manipulation supplémentaire au niveau du firewall ou sans un service de redirection ICMP. Vous pouvez le vérifier avec un ping depuis le client ou le serveur vers une adresse Internet.

Par exemple :

ping 8.8.8.8

Si votre ping passe mais que la réponse contient un Redirect Host, ceci indique que votre ping est passé grâce à la redirection ICMP, mais que vous n'arrivez pas encore à contacter l'Internet à travers le Firewall. Ceci est donc aussi valable pour l'instant et accepté comme résultat.

Configuration réseau du firewall

On va fournir une route vers l'internet à travers le firewall aux deux réseaux connectés. Pour cela, on va se servir des premières commandes nftables :

nft add table nat
nft 'add chain nat postrouting { type nat hook postrouting priority 100 ; }'
nft add rule nat postrouting meta oifname "eth0" masquerade

La dernière commande nftables définit une règle dans le tableau NAT qui permet la redirection de ports et donc, l'accès à l'Internet pour les deux autres machines à travers l'interface eth0 qui est connectée au WAN.

Quelle est l'utilité de la première commande ?

Réponse :

On créé une table qu'on appelle nat associée a la famille ip (par défaut). Une table est un conteneur de chains, sets, maps, elle doit être associée a une famille (dans notre cas ip(v4)).

Quelle est l'utilité de la deuxième commande ? Expliquer chacun des paramètres.

Réponse :

On ajoute une chain de type nat a notre table nommée "nat" , on indique que cette chain sera traité en "postrouting" donc après routage du packet, et on lui assigne une priorité (100).

Donc toutes les règles qu'on ajoutera dans cette chain dépendront implicitement de ces paramètres de chain

Cette autre commande démarre le service SSH du serveur :

service ssh start

Vérifiez que la connexion à l'Internet est maintenant possible depuis les deux autres machines ou qu'elle n'utilise plus de reditection. Pas besoin de capture d'écran mais assurez vous que les pings passent sans besoin de redirection de host avant de continuer.

Manipulations

Création de règles

Une règle permet d’autoriser ou d’interdire une connexion. nftables met à disposition plusieurs options pour la création de ces règles. En particulier, on peut définir les politiques par défaut, des règles de filtrage pour le firewall ou des fonctionnalités de translation d’adresses (nat). Vous devriez configurer vos politiques en premier.

nftables vous permet la configuration de pare-feux avec et sans état. Pour ce laboratoire, vous avez le choix d'utiliser le mode avec état, sans état ou une combinaison des deux.

Chaque règle doit être tapée sur une ligne séparée. Référez-vous à la théorie et appuyez-vous sur des informations trouvées sur Internet pour traduire votre tableau de règles de filtrage en commandes nftables. Les règles prennent effet immédiatement après avoir appuyé sur <enter>. Vous pouvez donc les tester au fur et à mesure que vous les configurez.

Sauvegarde et récupération des règles

Important : Les règles de filtrage définies avec nftables ne sont pas persistantes (par défaut, elles sont perdues après chaque redémarrage de la machine firewall). Il existe pourtant de manières de sauvegarder votre config.

Faire une recherche et expliquer une méthode de rendre la config de votre firewall persistente.

Réponse : On ajoute simplement les règles dans un fichier "/etc/nftables.conf" ensuite grace a la commande bash nft -f /etc/nftables.conf la config est reprise par nft.

On remarque qu'un fichier est déja existant avec le Shebang suivant :

#!/usr/sbin/nft -f

suivi de la commande :

flush ruleset

donc quand on a fini d'ajouter une table / chain / rule : on rajoute la table modifée dans ce fichier.

Exemple: On vient de modifier la table "nat" on souhaite la rendre persistente :

nft list table nat >> /etc/nftables.conf

Ou plus directement si on a crée différentes règles dans différentes tables on peut procéder ainsi :

nft list ruleset > /etc/nftables.conf

→ Note : Puisque vous travaillez depuis un terminal natif de votre machin hôte, vous pouvez facilement copier/coller les règles dans un fichier local. Vous pouvez ensuite les utiliser pour reconfigurer votre firewall en cas de besoin.

Quelle commande affiche toutes les règles de filtrage en vigueur ?

Réponse :

nft list ruleset

Quelle commande est utilisée pour effacer toutes les règles de filtrage en vigueur ?

Réponse :

nft flush ruleset

Quelle commande est utilisée pour effacer les chaines ?

Réponse :

pour flush :

nft flush chain mytable mychain

pour delete :

nft delete chain mytable mychain

Tests des connections et exemple de l'application d'une règle

Pour chaque manipulation, il est important de garder les règles déjà créées, les nouvelles sont ajoutées aux existantes.

Pour commencer sur une base fonctionnelle, nous allons configurer le pare-feu pour accepter le ping dans certains cas. Cela va permettre de tester la connectivité du réseau.

Le but est de configurer les règles pour que le pare-feu accepte

les ping depuis le LAN sur les machines de la DMZ,
les ping depuis le LAN sur le WAN,
les ping depuis la DMZ vers le LAN.

Ceci correspond a la condition 2 du cahier des charges.

Commandes nftables :

# Autorise le ping du LAN vers la DMZ
nft add rule ip filter forward icmp type echo-request ip saddr 192.168.100.0/24 ip daddr 192.168.200.0/24 accept
nft add rule ip filter forward icmp type echo-reply ip saddr 192.168.200.0/24 ip daddr 192.168.100.0/24 accept

# Autorise le ping du LAN vers le WAN
nft add rule ip filter forward icmp type echo-request ip saddr 192.168.100.0/24 meta oif eth0 accept 
nft add rule ip filter forward icmp type echo-reply meta iif eth0 ip daddr 192.168.100.0/24 accept 

# Autorise le ping de la DMZ vers le LAN
nft add rule ip filter forward icmp type echo-request ip saddr 192.168.200.0/24 ip daddr 192.168.100.0/24 accept
nft add rule ip filter forward icmp type echo-reply ip saddr 192.168.100.0/24 ip daddr 192.168.200.0/24 accept

Questions

Afin de tester la connexion entre le client (Client_in_LAN) et le WAN, tapez la commande suivante depuis le client :

ping 8.8.8.8

Faire une capture du ping.

Vérifiez aussi la route entre votre client et le service 8.8.8.8. Elle devrait partir de votre client et traverser votre Firewall :

traceroute 8.8.8.8

Testez ensuite toutes les règles, depuis le Client_in_LAN puis depuis le serveur Web (Server_in_DMZ) et remplir le tableau suivant :

De Client_in_LAN à	OK/KO	Commentaires et explications
Interface DMZ du FW	OK
Interface LAN du FW	OK
Client LAN	OK
Serveur WAN	OK

De Server_in_DMZ à	OK/KO	Commentaires et explications
Interface DMZ du FW	OK
Interface LAN du FW	OK
Serveur DMZ	OK
Serveur WAN	KO	Normal car demandé dans le cahier des charges

Règles pour le protocole DNS

Si un ping est effectué sur un serveur externe en utilisant en argument un nom DNS, le client ne pourra pas le résoudre. Le démontrer à l'aide d'une capture, par exemple avec la commande suivante :

ping www.google.com

Faire une capture du ping.

Créer et appliquer la règle adéquate pour que la condition 1 du cahier des charges soit respectée.

Commandes nftables :

# Autorise le DNS en sortie (LAN vers WAN)
nft add rule ip filter forward ip saddr 192.168.100.0/24 meta oif eth0 tcp dport 53 accept
nft add rule ip filter forward ip saddr 192.168.100.0/24 meta oif eth0 udp dport 53 accept 

# Autorise le DNS en entrée (WAN vers LAN)
nft add rule ip filter forward meta iif eth0 ip daddr 192.168.100.0/24 tcp sport 53 accept
nft add rule ip filter forward meta iif eth0 ip daddr 192.168.100.0/24 udp sport 53 accept

Tester en réitérant la commande ping sur le serveur de test (Google ou autre) :

Remarques (sur le message du premier ping)?

Réponse

Le premier ping n'est pas parvenu à résoudre le nom google.com car les ports du DNS n'étaient pas ouverts, donc malgré la présence d'un serveur DNS dans la configuration IP, les trames DNS ne pouvaient pas être transmises entre le client et le serveur DNS. En rajoutant les règles susmentionnées, la résolution de noms s'effectue correctement.

Règles pour les protocoles HTTP et HTTPS

Créer et appliquer les règles adéquates pour que les conditions 3 et 4 du cahier des charges soient respectées. Tester que les règles soient fonctionnelles en utilisant wget depuis le Client_in_LAN pour télécharger une ressource depuis un site Web de votre choix (sur le WAN). Par exemple :

wget http://www.heig-vd.ch

Créer et appliquer les règles adéquates avec des commandes nftables.

Commandes nftables :

# Autorise le HTTP du LAN vers le WAN
nft add rule ip filter forward ip saddr 192.168.100.0/24 meta oif eth0 tcp dport 80 accept
nft add rule ip filter forward ip saddr 192.168.100.0/24 meta oif eth0 tcp dport 8080 accept

# Autorise le HTTP du WAN vers le LAN
nft add rule ip filter forward meta iif eth0 ip daddr 192.168.100.0/24 tcp sport 80 accept
nft add rule ip filter forward meta iif eth0 ip daddr 192.168.100.0/24 tcp sport 8080 accept

# Autorise le HTTPS du LAN vers le WAN
nft add rule ip filter forward ip saddr 192.168.100.0/24 meta oif eth0 tcp dport 443 accept

# Autorise le HTTPS du WAN vers le LAN
nft add rule ip filter forward meta iif eth0 ip daddr 192.168.100.0/24 tcp sport 443 accept

Créer et appliquer les règles adéquates avec des commandes nftables pour que la condition 5 du cahier des charges soit respectée.

Commandes nftables :

# Autorise le HTTP du WAN vers le serveur dans la DMZ
nft add rule ip filter forward meta iif eth0 ip daddr 192.168.200.3 tcp dport 80 accept
nft add rule ip filter forward ip saddr 192.168.200.3 meta oif eth0 tcp sport 80 accept

# Autorise le HTTP du LAN vers le serveur dans la DMZ
nft add rule ip filter forward ip saddr 192.168.100.0/24 ip daddr 192.168.200.3 tcp dport 80 accept
nft add rule ip filter forward ip saddr 192.168.200.3 ip daddr 192.168.100.0/24 tcp sport 80 accept

Tester l’accès à ce serveur depuis le LAN utilisant utilisant wget (ne pas oublier les captures d'écran).

Règles pour le protocole ssh

Créer et appliquer la règle adéquate pour que les conditions 6 et 7 du cahier des charges soient respectées.

Commandes nftables :

# Autorise LAN to DMZ .3 Host
nft add rule ip filter forward ip saddr 192.168.100.3 ip daddr 192.168.200.3 tcp dport 22 accept
nft add rule ip filter forward ip saddr 192.168.200.3 ip daddr 192.168.100.3 tcp sport 22 accept

# Ajout d'une chaîne contenant les règles pour le hook input
nft 'add chain ip filter input { type filter hook input  priority 100 ; policy drop ;}'
# Ajout d'une chaîne contenant les règles pour le hook input
nft 'add chain ip filter output { type filter hook output  priority 100 ; policy drop ;}'

# Autorise LAN to FW
nft add rule ip filter input ip saddr 192.168.100.3 ip daddr 192.168.100.2 tcp dport 22 accept
nft add rule ip filter output ip saddr 192.168.100.2 ip daddr 192.168.100.3 tcp sport 22 accept

Depuis le client dans le LAN, tester l’accès avec la commande suivante :

ssh root@192.168.200.3

Expliquer l'utilité de ssh sur un serveur.

Réponse

SSH est utile pour configurer une machine à distance (remote shell), c'est une manière plus sécurisée de faire du remote management que son ancêtre "telnet"

En général, à quoi faut-il particulièrement faire attention lors de l'écriture des règles du pare-feu pour ce type de connexion ?

Réponse

SSH permet un accès "complet" à la machine il faut donc être très restrictif sur qui peut se connecter à la machine en question. Une machine mal configurée (pas d'auth avec clef SSH, pas de filtre geoIP) pourrait être victime de bruteforce (pour trouver le login root par exemple) !

Règles finales

A présent, vous devriez avoir le matériel nécessaire afin de reproduire la table de filtrage que vous avez conçue au début de ce laboratoire.

Insérer la capture d’écran avec toutes vos règles nftables

theomi/Teaching-HEIGVD-SRX-2022-Labo-Firewall

Teaching-HEIGVD-SRX-2022-Laboratoire-Firewall

Table de matières

Introduction

Auteurs

Echéance

Réseaux cible

Topologie

Plan d'adressage

Cahier des charges du réseau

Regles de filtrage

Installation de l’environnement virtualisé

Matériel

Installation de Docker

Installation de Git

Démarrage de l'environnement virtuel

Ce laboratoire utilise docker-compose, un outil pour la gestion d'applications utilisant multiples conteneurs. Il va se charger de créer les réseaux lan et dmz, la machine Firewall, un serveur dans le réseau DMZ et une machine dans le réseau LAN et de tout interconnecter correctement.

Communication avec les conteneurs et configuration du firewall

Configuration de base

Configuration du client LAN

Configuration du serveur dans la DMZ

Configuration réseau du firewall

Manipulations

Création de règles

Sauvegarde et récupération des règles

Tests des connections et exemple de l'application d'une règle

Questions

Règles pour le protocole DNS

Règles pour les protocoles HTTP et HTTPS

Règles pour le protocole ssh

Règles finales

Ce laboratoire utilise docker-compose, un outil pour la gestion d'applications utilisant multiples conteneurs. Il va se charger de créer les réseaux `lan` et `dmz`, la machine Firewall, un serveur dans le réseau DMZ et une machine dans le réseau LAN et de tout interconnecter correctement.