# Rapport de projet
> CPE - 4ICS année 2022-2023
> Louis Morand, Lucas Hocdé, Wolodia Zdetovetzky

## Sommaire
1. [Introduction](#Introduction)
2. [Découpage réseau](#Découpage-réseau)
3. [Configuration du PFsense et éléments de sécurité](#Configuration-du-PFsense-et-éléments-de-sécurité)
3.1. [Configuration de PFSENSE](#Configuration-de-PFSENSE)
3.2. [Configuration IPS](#Configuration-IPS)
3.3. [Configuration de SquidGuard](#Configuration-de-SquidGuard)
4. [Configuration des machines](#Configuration-des-machines)
5. [Scans avec NMAP](#Scans-avec-NMAP)
6. [Problèmes rencontrés](#Problèmes-rencontrés)
7. [Webographie](#Webographie)

## Introduction

Le but de ce Tp est de nous faire appréhender les principes de mise en place et sécurisation d'une architecture réseau simple, avec un réseau constitué d'un serveur web, d'une machine client, d'un routeur/firewall PFSense, ainsi que d'une machine Kali avec Nmap pour permettre de tester la mise en place et efficacité des mesures prises.

Ci-après, le schéma de l'architecture cible:

## Découpage réseau

Pour permettre de simuler un environnement réseau réaliste, nous avons découpé le réseau en 4 parties:
- Une DMZ, hébergeant le serveur Web, simulé par metasploitable
- Un réseau LAN, hébergeant la VM Ubuntu - LX, servant pour simuler un poste de travail, et étant utilisée pour administrer pfSense
- Un réseau d'interconnexion entre les deux firewalls pfSense, pour permettre la mise en place de HA
- Un réseau WAN, simulant le réseau internet, et servant à héberger la machine Kali.

Ci-après, la liste des addresses des interfaces des machines sur le réseau:

| Adapter's Network | Network | PfSense1 | PfSense2 | VIP |
| -------------------------- | ------- | ------------------ | ------------------ | ------------------- |
| VIP-WAN [11.0.2.0/24] | WAN | 11.0.2.253/24 | 11.0.2.254/24 | 11.0.2.252/24 |
| VIP-DMZ [192.168.200.0/24] | DMZ | 192.168.200.253/24 | 192.168.200.254/24 | 192.168.200.252/24 |
| LAN [192.168.11.0/24] | LAN | 192.168.11.253/24 | 192.168.11.254/24 | 192.168.11.252/24 |
| INTERCO [172.16.0.0/30] | INTERCO | 172.0.16.1/29 | 172.0.16.2/24 | |

Le tableau des réseaux est la suivante:

| **NETWORKS** | **TP-VIP-WAN** | **TP-LAN** | **TP-VIP-DMZ** | **INTERCO** |
| :----------: | :------------: | :---------------: | :----------------: | :-------------: |
| **DHCP** | 11.0.2.0/24 | 192.168.11.0/24 | 192.168.200.0/24 | 172.16.0.0/24 |
| **Start** | 11.0.2.128/24 | 192.168.11.128/24 | 192.168.200.128/24 | 172.16.0.128/24 |
| **End** | 11.0.2.250/24 | 192.168.11.250/24 | 192.168.200.250/24 | 172.16.0.254/24 |

## Configuration des machines

Les addresses IP des machines ont été fixées comme suit :

| VM | Net | Interface IP @ | GW Single FW IP @ |
| ------------------- | --- | ----------------- | ------------------ |
| LX (Ubuntu) | LAN | 192.168.11.1/24 | 192.168.11.253/24 |
| Metasploitable | DMZ | 192.168.200.10/24 | 192.168.200.253/24 |
| Kali [Adapter eth0] | WAN | 11.0.2.66/24 | 11.0.2.253/24 |
| Kali [Adapter eth1] | LAN | 192.168.11.66/24 | 192.168.11.253/24 |

Comme les machines étaient hébergées sur VMWare, pour permettre aux machines d'avoir accès à internet, nous avons configuré l'addresse d'upstream sur PFSENSE comme étant celle de l'interface de sortie du réseau NAT, soit ici 11.0.2.2.

## Configuration du PFsense et éléments de sécurité

Lors de l'installation du PFSense, nous avons réalisé plusieurs taches ayant pour but d'augmenter la sécurité de base.

- **Changement du mot de passe**:
Cela garantit que seules les personnes autorisées ayant le nouveau mot de passe puissent accéder à l'interface d'administration du pare-feu, qui, sans modification, est très facile à deviner. Avec cela, nous avons créé des utilisateurs pour les personnes du groupe, avant de remplacer le mot de passe admin par un mot de passe très complexe.

- **Mise à jour de l'OS**:
Potentiel améliorations de performances, de nouvelles fonctionnalités, des correctifs de sécurité et des modifications de l'interface utilisateur. Les mises à jour sont essentielles pour maintenir le pare-feu à jour et protégé contre les menaces récentes.

- **Activation du HTTPS si n'est pas fait par défaut**:
Lors de l'activiation du protocole HTTPS, la communication entre votre navigateur et l'interface d'administration du pare-feu est chiffrée, protégeant ainsi les données sensibles telles que les mots de passe et les configurations du pare-feu contre les interceptions et les attaques de type "man-in-the-middle". Lors du rechargement de la page on constate l'apparition d'une page d'avertissement car le certificat est un certificat auto-signé. Cependant nous ignorons cette erreur, car nous savons que ce certificat est issu de PFSense. Il pourra etre intéressant de le remplacer plus tard par un certificat issu et controlé par notre organisation.

### Configuration de PFSENSE

La configuration de PFSense a été mise en place afin de permettre une sécurité maximale du trafic tout en permettant aux environnements métier de ne pas etre impactés par les règles mises en place.
Pour cela, nous avons mis en place des règles de NAT et de Firewall, une redondance entre les deux PFSense, ansi qu'une adresse IP virtuelle.

- Pour la configuration du NAT, nous avons mis en place les règles suivantes:
Cette règle permet de s'assurer de la mise en place de l'accès direct vers la machine metasploit depuis la machine Calli située sur le WAN.

- La configuration du firewall est la suivante:
Pour le WAN:
Cette configuration permet de s'assurer que seul le trafic venant du WAN et allant vers la DMZ soit autorisé, sur les ports 443 et 80, relevant pour le trafic internet.

- La configuration du LAN est la suivante:
Cette configuration permet d'autoriser une navigation internet uniquement depuis les machines du domaine. Cette configuration de base permet de limiter les problèmes en autorisant seulement une sortie vers internet. Des règles supplémentaires peuvent etre ajoutées afin de permettre les accès aux serveurs du domaine (DNS, AD, serveurs internes...) spécifiquement à destination des serveurs nécessaires.

- La configuration du réseau d'interconnexion est la suivante:
Ces règles permettent de s"ssurer que le trafic nécessaire à la mise en place des échanges inter-PFSense soient mis en place.

**Règles actuellement configurées:**

- WAN:

| **Permission** | **Porotocol** | **Source** | **Port** | **Destionation** | **Port** | **Gateway** | **Queue** | **Schedule** | **Description** |
|:--------------:|:-------------:|:----------:|:--------:|:----------------:|:-----------:|-------------|-----------|--------------|----------------------------|
| ✔ | IPv4 TCP | * | * | DMZ net | 80 (HTTP) | * | none | | Allow HTTP any to DMZ net |
| ✔ | IPv4 TCP | * | * | DMZ net | 443 (HTTPS) | * | none | | Allow HTTPS any to DMZ net |
| ✘ | IPv4 * | * | * | * | * | * | none | | Block anything else |

- LAN:

| Permission | Porotocol | Source | Port | Destionation | Port | **Gateway** | **Queue** | **Schedule** | **Description** |
|:----------:|:---------:|:-------:|:----:|:------------:|:---------:|:-----------:|:---------:|:------------:|:----------------------------------:|
| ✔ | * | * | * | LAN Address | 80 (HTTP) | * | * | | Anti-Lockout Rule |
| ✔ | IPv4 * | LAN net | * | * | * | * | none | | Default allow LAN to any rule |
| ✔ | IPv4 * | LAN net | * | * | * | * | none | | Default allow LAN IPv6 to any rule |

- DMZ:

| **Permission** | **Porotocol** | **Source** | **Port** | **Destionation** | **Port** | **Gateway** | **Queue** | **Schedule** | **Description** |
|:--------------:|:-------------:|:----------:|:--------:|:----------------:|:-----------:|-------------|-----------|--------------|---------------------------------|
| KO | IPv4 * | DMZ net | * | LAN net | * | * | none | | Block any DMZ net to LAN net |
| OK | IPv4 TCP | DMZ net | * | * | 80 (HTTP) | * | none | | Allow HTTP from DMZ net to any |
| OK | IPv4 TCP | DMZ net | * | * | 443 (HTTPS) | * | none | | Allow HTTPS from DMZ net to any |

#### Redondance des configurations et des routeurs

Pour permettre une redondance des routeurs afin de mettre en place une haute disponibilité, nous avons mis en place une duplication des configurations des routeurs via le protocole pfsync, qui permet de réaliser une synchronisation entre deux routeurs PFSense.

Pour permettre cette configuration, les IP des routeurs en paire doivent etre renseignés sur l'autre routeur, ainsi que le trafic pfsync authorisé sur le réseau d'échange. Par mesure de sécurité, ce réseau d'interconnexion est isolé des autres réseaux , et utilisé uniquement pour les échanges inter-routeurs.

Extrait de la configuration mise en place:

Cette configuration nous permet de synchroniser l'ensemble des informations nécessaires à la bonne marche du routeur, sans avoir à les reporter à la main entre chaque routeur.

Dans un cluster HA (High Availability), il existe deux types de configurations : actif/passif et actif/actif.

Actif/passif : Dans cette configuration, un seul nœud (généralement appelé le nœud principal ou actif) gère le trafic réseau et les autres nœuds (généralement appelés nœuds secondaires ou passifs) restent en attente. Si le nœud principal rencontre des problèmes ou tombe en panne, l'un des nœuds passifs prend le relais et devient le nœud actif. Dans ce cas, les ressources ne sont pas partagées entre les nœuds, et le nœud passif ne traite le trafic que lorsque le nœud actif est défaillant. Cette configuration est souvent utilisée pour assurer la disponibilité des services et minimiser les temps d'arrêt.

Actif/actif : Dans cette configuration, tous les nœuds du cluster sont actifs et traitent le trafic réseau simultanément. Les ressources et les charges sont réparties entre les nœuds pour optimiser les performances et la capacité du système. Si l'un des nœuds rencontre des problèmes ou tombe en panne, les autres nœuds continuent à traiter le trafic sans interruption. Cette configuration est souvent utilisée pour améliorer les performances et la tolérance aux pannes du système.

Ici, le système est un cluster Actif/Passif, le réseau passant en priorité par le noeud principal, et étant redirigé sur le noeud secondaire uniquement en cas de défaillance.

#### Mise en place des VIP

Afin de permettre une redondance transparente pour les utilisateurs, des addresses VIP (Virtual IP) ont été configurées via le protocole CARP (Common Address Redundancy Protocol). Ce protocole permet à plusieurs équipements réseaux de partager une même adresse IP, et permet de définir un équipement « maitre » et les autres « esclaves », destinés à prendre le relai en cas de défaillance du premier équipement.
Dans le cadre d'un Failover HA (High Availability), mettre la VIP (Virtual IP) LAN comme Gateway est une pratique courante pour assurer la disponibilité et la continuité des services réseau. Cela permet d'assurer une disponibilité et une résilience accrues du réseau, en facilitant la gestion des pannes et en simplifiant la configuration des clients et des équipements réseau.

Cela permet d'avoir une redondance invisible pour le client, ici configurée en actif/pssif pour PFSense. En effet, lors des tests, nous avons remarqué que le traffic à destination de la VIP était redirigée en priorité vers le routeur master, et uniquement sur le routeur secondaire lorsque le master est hors service.

Voila la configuration pour l'interface WAN:

Pour l'interface LAN:

Ainsi que pour l'interface DMZ:

Pour permettre la prise en compte du CARP par les machines devant se connecter sur les routeurs, il faut fournir l'IP renseignée du CARP aux machines faute de quoi elles ne pourront bénéficier de la HA.

### Configuration IPS

IPS est l'acronyme de "Intrusion Prevention System" (Système de prévention d'intrusion). C'est une solution de sécurité informatique qui surveille le trafic réseau en temps réel pour détecter les tentatives d'intrusion et les attaques malveillantes.

Un IPS analyse les paquets de données en transit sur le réseau pour détecter les anomalies, les signatures d'attaques connues et les comportements suspects. Lorsqu'une menace est détectée, l'IPS peut prendre des mesures pour bloquer le trafic malveillant, comme la mise en quarantaine du trafic suspect, le blocage de l'adresse IP source ou la suppression des paquets malveillants.

Il existe de nombreuses solution IPS. "Snort" est une solution gratuite, très complète et open-source, cela fait de Snort un très bon candidat en tant qu'IPS. De plus, Pfsense propose une méthode d'instalation de paquet automatiquement, ce qui fait de de lui on excelent canditat.

##### Installation de Snort

Snort est une aplication qui permet de détecter et prévenir les actons malveillante en agissant sur les flux au niveau du réseau.

L'installation se fait à partir du Menue : **System > Packet Manager**. Ici il faudras de chercher et installer snort qui s'installeras automatiquement.

Une fois l'installation terminées, il faut activer toutes les règles non payantes afin de pouvoir surveiller le réseau: Services> Snort > Global Settings. Il est possible d'activer Snort version payante afin d'avoir accès a plus de règles et ainsi une couverture plus complète des menaces.

##### Configuration de Snort
Dans l'onglet "Mise à jour / Update", activer les mises à jours afin qu'elle soit faitent régulièrement afin de conserver des règles en adéquation avec les dernières menaces.

Depuis l'onglet "Pass List", créer une pass list qui n'exclus aucun flux en décochant les cases suivantes :
- Local Networks
- WAN Gateways
- WAN DNS Servers
- Virtual IP Adresses
- VPN Adresses

Depuis l'onglet "Interfaces" de Snort, séléctioner l'interface WAN afin de pouvoir analyser les fluxs venant de l'extérieurs vers le firewall.

Cocher la case "Send Alerts to System Logs". Actuellement, Snort agis comme un IDS, c'est à dire qu'il ne feras que relevé une alerte sans bloquer le flux. Afin de faire de Snort un IPS, il faut également cocher la case "Block Offenders".

Le mode IPS permet deux mode de bloquage :
- Legacy : Le paquet original travers le pare-feu et un clone est créer puis analysé. Si il se trouve être malveillant la suite de la connection est interrompu.
- Inline : Les paquets sont conservés jusqu'à la fin de l'analyse. Ils ne sont donc pas transmis si l'analyse indique un paquet malveillant.

Dans notre cas nous avons choisis Legacy car il permet de maintenir une connexion avec moins de latence. Le mode Inline requière également une interface réseau compatible, et ce n'est pas le cas de l'interface ici.

Dans la catégorie "Detection Management Settings" les options permettent de définir les paramètres utilisé pour la détection des attaques. Pour la méthode de recherche nous avons fait le chois d'utiliser la methode AC-BNFA car elle est adapté a notre environement (faible en ressources). Les autres case on été laissées par défaut.

La section suivante permet d'assigner la passlist à l'interface ainsi que de paramétrer l'inclusion et l'exclution d'autres réseau à l'inspection Snort.
"Home Net" et "External Net" sont laissé par défaut car ce sont les configuration necessaire pour notre environement, puis la pass list est ajoutée dans "Pass list".

Dans le menue IPS Policy Selection nous avons séléctioné Security. Ce mode est un mode moins permissif que le mode par défaut et juste en dessous du mode Max-Detect qui est le plus sensible. Cela permet une sécuritée accrue avec un taux de faux positif qui reste relativement faible. Trop de faux positifs peuvent rapidement devenir un problème car cela parturberait des serviceux normaux.

Finaliser en cliquant sur "Select All" afin d'activer toutes les règles. Ces règles autmentent encore la sécurité en ajoutant des alertes à la la configuration Snort.

##### Finalisation de la configuration

Afin d'appliquer la configuration, il faut retourner dans l'onger "WAN Rules" et séléctioner la catégorie de règles correspondante à ce qui vient d'être configuré. Dand notre cas : IPS Policy - Security

Cliquer **Enable all** puis **Apply** pour ajouter la configuration.

Enfin, redémarer le service Snort pour que la nouvelle configuration sois prise en compte.

##### Test de la configuration Snort

Afin de tester la configuration Snort, nous avons décidé de mener une détection de l'OS du parfeu depuis la machine Kali. La détection d'OS est une forme de reconaissance bien particulière qui permet eventuellement de récupérer des informations afin de pouvoir séléctioner des exploits qui conviendrait plus au système à attaquer.


Ici on voit les logs de l'attaque qui a été detecté par Snort.

En mode IPS les flux sont bloqué et l'attaque de reconaissance est bloqu".

### Configuration de SquidGuard

#### Quest-ce qu'un proxy ?

Un proxy, ou serveur proxy, est un intermédiaire entre un utilisateur et le réseau Internet. Lorsqu'un utilisateur envoie une requête pour accéder à une ressource Web (par exemple, un site Web ou un service en ligne), la requête est d'abord transmise au serveur proxy. Le serveur proxy traite la requête et communique avec le serveur de destination (le serveur hébergeant la ressource demandée) pour obtenir les données. Une fois les données récupérées, le proxy les renvoie à l'utilisateur.

#### Quest-ce que Squid et SquidGuard ?

Squid et SquidGuard sont deux logiciels open-source utilisés pour contrôler et gérer l'accès à Internet dans les réseaux d'entreprise, d'éducation et de gouvernement.

Squid est un serveur proxy open-source qui permet de mettre en cache et de filtrer le trafic Web. Il agit comme un intermédiaire entre les utilisateurs d'un réseau et le réseau Internet, traitant les requêtes pour accéder à des ressources Web. Squid offre plusieurs avantages, tels que la mise en cache des pages Web pour réduire la bande passante utilisée, l'amélioration des performances et la possibilité de filtrer certaines requêtes pour renforcer la sécurité du réseau.

SquidGuard, quant à lui, est un plug-in pour Squid qui permet de définir des règles de filtrage d'URL en fonction de divers critères, tels que les groupes d'utilisateurs, les domaines, les expressions régulières, les plages horaires, etc. SquidGuard permet aux administrateurs système de contrôler l'accès à certains sites Web ou catégories de sites Web pour les utilisateurs de leur réseau. Cela peut être utile pour bloquer l'accès à des sites Web indésirables ou inappropriés, pour limiter la bande passante utilisée ou pour se conformer aux politiques de l'entreprise ou aux réglementations légales.

En résumé, Squid est un serveur proxy qui gère et filtre le trafic Web, tandis que SquidGuard est un plug-in de Squid qui permet d'appliquer des règles de filtrage d'URL personnalisées pour contrôler l'accès à Internet.

### Les proxy transparents et non transparents

Il existe plusieurs types de serveurs proxy, chacun ayant des utilisations et des fonctionnalités spécifiques. Nous allons présenter les différences et avantages des proxy transparent et non transparent.

- Proxy transparent :

- Visibilité :
Un proxy transparent est généralement invisible pour les utilisateurs finaux. Ils ne sont pas conscients qu'ils utilisent un proxy, car il fonctionne sans configuration côté client. Le proxy intercepte automatiquement les requêtes et les traite.

- Modification des requêtes :
Les proxies transparents ne modifient généralement pas les requêtes ou les réponses des clients, ce qui signifie qu'ils n'altèrent pas les en-têtes HTTP ou les informations d'identification.

- Utilisation :
Les proxy transparents sont souvent utilisés pour la mise en cache du contenu, la surveillance du trafic et l'application de restrictions d'accès sans que les utilisateurs ne s'en rendent compte. Ils peuvent également être utilisés pour filtrer le contenu et améliorer les performances du réseau.

- Anonymat :
Les proxies transparents ne fournissent généralement pas d'anonymat, car ils ne masquent pas l'adresse IP de l'utilisateur ou les informations d'en-tête HTTP.

- Proxy non transparent :

- Visibilité :
Un proxy non transparent nécessite généralement une configuration manuelle sur le client, ce qui signifie que les utilisateurs sont conscients qu'ils utilisent un proxy. Les paramètres du proxy doivent être configurés dans le navigateur ou l'application utilisée pour accéder à Internet.

- Modification des requêtes :
Les proxies non transparents peuvent modifier les requêtes ou les réponses des clients en fonction de leur configuration. Par exemple, ils peuvent masquer ou modifier l'adresse IP de l'utilisateur ou les informations d'en-tête HTTP pour assurer l'anonymat.

- Anonymat :
Les proxies non transparents peuvent fournir un anonymat en masquant l'adresse IP de l'utilisateur et en modifiant les en-têtes HTTP pour cacher l'identité de l'utilisateur.

En résumé, la principale différence entre un proxy transparent et un proxy non transparent réside dans la visibilité et la configuration requise pour les utiliser. Les proxies transparents sont généralement invisibles pour les utilisateurs et ne modifient pas les requêtes, tandis que les proxies non transparents nécessitent une configuration manuelle et peuvent modifier les requêtes pour assurer l'anonymat ou contourner les restrictions.

### Pourquoi mettre en place Squid & SquidGuard

Dans le cadre de ce TP, nous avons mis en place Squid et SquidGuard pour les raisons suivantes :

- Sécurité du réseau :
L'utilisation de Squid et SquidGuard renforce la sécurité du réseau en filtrant et en bloquant l'accès à des sites web potentiellement dangereux ou indésirables. Cela aide à prévenir les menaces de sécurité, comme les logiciels malveillants et les attaques par phishing.

- Gestion de la bande passante :
Squid et SquidGuard permettent de mieux gérer la bande passante du réseau en mettant en cache les contenus fréquemment consultés et en limitant l'accès à des sites web ou des catégories de sites à forte consommation de bande passante.

- Conformité aux politiques :
L'implémentation de Squid et SquidGuard aide à garantir que les utilisateurs du réseau se conforment aux politiques de l'organisation en matière d'utilisation d'Internet. Cela peut inclure des restrictions basées sur des catégories de sites web, des plages horaires ou des groupes d'utilisateurs.

- Supervision et suivi :
Squid et SquidGuard fournissent des journaux détaillés sur l'utilisation d'Internet, facilitant la surveillance et le suivi des activités en ligne. Ces informations peuvent être utilisées pour identifier les problèmes de performance, les violations de la politique d'utilisation ou les tentatives d'accès non autorisé.

En somme, l'intégration de Squid et SquidGuard dans ce TP permet l'optimisation de l'utilisation de la bande passante et assurer la conformité aux politiques d'accès à Internet.

### Configuration

Pour mettre en place ces éléments, nous avons suit les étapes suivante :

1. Installation des logiciels

2. Configuration de Squid
Une fois Squid installé, nous avons configuré Squid à l'aide de la GUI. En modifiant des paramètres tels que le port d'écoute, les règles d'accès, le contrôle de la mise en cache et les paramètres de performance.

3. Configuration de SquidGuard
Après l'installation de SquidGuard, nous l'avons également configurer à l'aide de la GUI. Nous avons modifier les listes de contrôle d'accès (ACL) et les redirections et les règles de filtrage.

4. Intégration de SquidGuard avec Squid
Pour que SquidGuard fonctionne avec Squid, il est nécessaire d'ajouter une directive url_rewrite_program dans le fichier de configuration de Squid, pointant vers l'exécutable SquidGuard. Cette étape permet à Squid de transmettre les requêtes à SquidGuard pour le filtrage d'URL.

5. Mise à jour des listes de filtrage
SquidGuard utilise des bases de données externes pour classer les sites Web en différentes catégories. Nous vons télécharger et mit à jour ces bases de données pour assurer un filtrage efficace.

6. Démarrage et vérification des services
Nous avons ensuite démarrer les services Squid et SquidGuard en s'assurant qu'ils fonctionnent correctement.

7. Test et validation
Enfin,nous avons tester et valider le fonctionnement de Squid et SquidGuard en vérifiant que les requêtes sont correctement traitées, que le filtrage d'URL est appliqué et que les règles définies sont respectées.

## Scans avec NMAP

### LAN

Depuis le WAN, en scan le port du LAN à l'aide de nmap on obtient le résultat suivant :


Les paramètres :
- -T4 :
Le paramètre -T (timing) permet de régler le "timing template" (modèle de temporisation) pour le scan. Il est suivi d'un chiffre entre 0 et 5. le timing 0 est extrèmement lent et minitieux, tandis que le 5 est extrêmement rapide et agressif, sans tenir compte des limites du réseau ou des risques de détection. Nous avons choisi le 4 qui est plus rapide que le mode normal, mais il peut causer une surcharge du réseau et une détection accrue.
- -F :
L'option -F (Fast) active le mode "Fast Scan" (scan rapide). Dans ce mode, Nmap scanne uniquement les 100 ports les plus couramment utilisés pour chaque protocole (TCP et UDP) selon les statistiques. Cela permet de gagner du temps en se concentrant sur les ports les plus susceptibles d'être ouverts et en ignorant les autres.

Ainsi, La commande nmap -T4 -F 192.168.11.253 effectue un scan rapide (Fast Scan) sur l'hôte ayant l'adresse IP 192.168.11.253 (IP Lan PFsense1) avec un niveau de temporisation agressif.

Les résultats nous démontre que :
- Le port TCP 53 est ouvert et exécute le service de noms de domaine (DNS).
- Le port TCP 80 est ouvert et exécute le service HTTP (HyperText Transfer Protocol), généralement utilisé pour les serveurs web.

Avec la même commande mais en ajoutant le paramètre -O afin d'identifié l'OS de la cible, on obtient le résultat suivant :


Les résultats nous indiquent :
- l'OS de la machine en DMZ est FreeBSD 11.2-REALEASE.
- Son Adresse MAC est : 00:0C:29:2:EA:A3, une adresse MAC VMware.

Ainsi, pour solutionner ces problèmes de sécurisés il faut que les seuls ports ouvert sont ceux qui permettent l'accès en http a l'interface ainsi que les requettes DNS. Ainsi, nous bloquons tous les autres ports en laissant l'accès uniquement de ces ports sur des requêtes qui viennent du net LAN.

6 états de ports peuvent être reconnus par l’outils:

| **Etat du Port** | **Description** |
|:--------------------:|-------------------------------------------------------------------------------------|
| **Open** | Le port est ouvert et une application écoute. |
| **Closed** | Le port est accessible mais aucun service n'écoute derrière. |
| **Filtered** | L'état du port est inconnue du au filtra qui empèche la detection. |
| **Unfiltered** | Le port est acessible mais Nmap n'arrive pas a déterminé si il est ouvert ou fermé. |
| **Open\|Filtered** | Nmap n'est pas sur si le port est ouvert ou filtré. |
| **Closed\|Filtered** | Nmap n'est pas sur si le port est fermé ou filtré. |

### DMZ

Résultat du scan sur les ports ouverts et l'OS:

Cela nous permet de voir que Snort a bien focntionné, car d'un coté, sur le Kali, nous avons des résultats inexploitables, tandis que sur le PFSense, l'ip d'origine du scan est bloquée.

## Problèmes rencontrés

- Anticipation avant le ping : ajout d'une rule pour acceptée l'ICMP sur PFSense afin d'utiliser les pings.
- Configuration initiale des réseaux avec VMWare pour la bonne communication des machines
- Configuration des règles de Snort
- Compréhension des consignes parfois difficiles.