<style>body {text-align: justify}</style>
# Rapport - Sécurité dans les réseaux
## Étudiants
- CARLENS Jean Philippe
- PREVOST Thomas
- MARSAIS-LACOSTE Marcel
## Contexte
Nous allons prendre le rôle d'une petite association humanitaire nécessitant d'avoir un serveur web, mail et VPN. Nous avons donc besoin d'instances sécurisées sans pour autant devoir "serrer les vis au maximum".
# Réalisation d'un serveur web sécurisé
Nous allons employer une machine tournant sur LXLE, une distribution Linux basée sur la dernière version LTS Ubuntu utilisant LXDE.
## Génération des clefs et certificats pour le HTTPS
Notre serveur web va utiliser HTTPS et pour ce fait nous allons devoir générer avec `openssl` la clef privée et le certificat qui va être employé par la couche TLS/SSL.
```sh
openssl req -x509 -nodes -days 365 -newkey rsa:4096 -keyout server.key -out server.crt
sudo mv server.key /etc/ssl/private
sudo mv server.crt /etc/ssl/certs
```
## Installation et configuration de Apache
Nous nous assurons que les modules `ssl`, `headers` et `cgid` sont activés, et que les chemins vers la clef et le certificat dans `/etc/apache2/sites-available/default-ssl.conf` sont à jour.
Puis nous relançons le serveur avec la commande suivante.
```sh
sudo systemctl restart apache2
```
Le serveur est en ligne.
## Configuration du firewall
Nous allons autoriser uniquement le trafic HTTP et HTTPS entrant et sortant, et bloquons le reste. Nous n'ouvrons pas le port SSH car nous voulons accéder à la machine uniquement physiquement dans les locaux de l'association.
```sh
sudo ufw allow http
sudo ufw allow https
```
---
# Configuration du routeur pfSense
Nous allons configurer un routeur pfSense afin de pouvoir gérer nous-mêmes l'adressage IP des machines sur le réseau de l'association ainsi que les requêtes DNS.
Cela peut, entre autres, nous permettre de réguler un minimum les sites auxquels il est possible d'accéder au sein de nos locaux, et bien sûr de pouvoir configurer nos paramètres réseau à notre guise.
## Configuration de l'interface réseau
Nous allons créer sur un réseau virtuel de type Host-Only. Nous allons prendre soin de ne pas demander au logiciel de VM de gérer le DHCP sur ce réseau car nous allons par la suite léguer ce rôle à pfSense. Ainsi, nous pouvons voir ci dessous que le réseau à pour adresse IP `192.168.126.0`.
IP du pfSense : **192.168.126.10**
WAN : NAT, **192.168.5.130**
## Configuration de pfSense
Nous utilisons l'ISO officiel, basée sur FreeBSD de pfSense, et suivons la procédure d'installation.
Au démarrage, nous pouvons voir que le routeur à pour IP LAN `192.168.126.10`.
Nous allons donc maintenant configurer le routeur pour utiliser les DNS Cloudflare `1.1.1.1` en primaire et Google `8.8.8.8` en secondaire. Les futures machines connectées au retour utilisant le DNS local utiliseront donc en réalité ces derniers.
### DHCP
Tout d'abord récupérons l'adresse MAC du serveur LXLE : `00:0c:29:37:e1:6b`.
Nous définissons un mapping DHCP statique pour celui-ci en faisant attention de ne pas être dans la range DHCP d'allocation d'IP dynamique.
### DNS
Maintenant, nous définissons les noms de domaine de nos machines locales dans notre serveur DNS.
Cela va nous permettre, au sein de l'association, d'accéder à nos machines sur le réseau sans utiliser d'adresses IP brutes. Par exemple nous pourrons accéder à l'interface de configuration pfSense via l'URL `pfsense.cs.sr`.
Nous définissons également les champs MX pour permettre la future configuration d'un serveur mail sur la machine LXLE.
```sh
server: local-zone: "cs.sr" typetransparent
server: local-data: "cs.sr IN MX 10 lxle.cs.sr."
server: local-data: "lxle.cs.sr IN A 192.168.126.11"
```
## Test de bon fonctionnement
Nous redémarrons notre serveur LXLE en nous assurant qu'il a pour seule interface réseau l'interface connectant au réseau privé `Host-Only` que nous avons créé précédemment.
Auparavant, il ne pas oublier sur Windows de supprimer la route créée par défaut depuis l'host.
```sh
route delete 0.0.0.0 mask 0.0.0.0 192.168.126.10 (en tant qu’administrateur)
```
Une fois redémarré, nous pouvons constater que l'host possède bel et bien l'adresse IP que nous avons définie dans notre mapping DHCP statique `192.168.126.11`.
De plus, nous pouvons également voir que notre configuration DNS fonctionne, car l'adresse `pfsense.cs.sr` est atteignable et pointe bien vers le routeur pfSense.
Nous configurons le firewall et les règles NAT de pfSense pour pouvoir accéder au serveur web uniquement via le routeur et un port forwarding.
Et le tout fonctionne.
Avec la configuration actuelle, le serveur web de notre association est vulnérable à l'ARP-poisoning. Par exemple, il est possible d’intercepter le login et le mot de passe envoyés par le formulaire http simple.
Pour empêcher la connexion non sécurisée de s’établir, il faut que le virtualhost qui écoute sur le port 80 n’ait pour seule utilité que de rediriger le navigateur vers la connexion HTTPS. On peut aussi activer HSTS (HTTP Strict Transport Secure).
Client : **192.168.5.1**, serveur : **192.168.5.128**, pirate : **192.168.5.129**.
Lorsque l’attaque MITM n’est pas active, la table ARP du client correspond bien aux adresses physiques des machines.
Il est en de même pour le serveur :
Lorsque l’attaque MITM est active, le client croit que l’adresse MAC du serveur est celle du pirate.
Le serveur croit que l’adresse MAC du client est celle du pirate :
Afin de procéder à une attaque MITM sur une connexion SSL, il est nécessaire d’activer les redirections iptables dans le fichier /etc/ettercap/etter.conf.
Cette configuration faisant planter l’interface graphique d’ettercap, il est nécessaire d’utiliser la version en ligne de commande :
```sh
sudo ettercap -T -q -M arp:remote /192.168.5.1// /192.168.5.128// -w result
```
Il est nécessaire d’accepter le nouveau certificat dans le navigateur, puisque ce dernier a changé. C’est le certificat d’ettercap (les empreintes sont différentes) :
|Certificat avant l’attaque | Certificat pendant l’attaque |
|---------------------------|------------------------------|
| | |
Les identifiants sont bien interceptés.
Il faut donc éviter d'accepter un certificat inconnu.
Nous allons donc préinstaller les certificats signés sur les machines de l'association et utiliser une chaîne de certification.
# Ajout d'un serveur de mails
## Introduction
Nous allons ajouter un serveur mail au sein de notre association. C'est un serveur essentiel car les mails sont un outil indispensable pour nos bénévoles, permettant de communiquer avec le reste du monde. Au vu de son importance, c'est également un des plus grands vecteurs d'attaque pour les personnes malintentionnées.
## Configuration
Après avoir configuré Postfix, nous pouvons envoyer un email en telnet sur le port 25 ou avec la commande mail, et nous nous apercevons que le mail a été traité dans /var/log/mail.log.
Alice peut lire son mail dans /var/mail/alice.
Nous changeons ensuite les interfaces d’écoute.
L'adresse est inconnue :
Pour se connecter depuis kali, il ne faut pas oublier d’ouvrir le port 25 sur le parefeu :
```sh
sudo ufw allow 25
```
L’envoi de mail fonctionne correctement.
Si nous changeons la configuration de ssmtp, nous pouvons utiliser sendmail.
Après avoir configuré Thunderbird pour utiliser STARTTLS sur le port 443, avec le nom d’utilisateur alice, nous avons :
Si le serveur SMTP n’est pas correctement configuré, cela semble très imprudent de le laisser ouvert à l’extérieur.
Il doit être possible de retrouver son mot de passe si Alice se connecte par IMAP dans le cas où le mot de passe n’est pas hashé, ou bien d’intercepter la connexion pour la forcer à envoyer ses mots de passe en clair.
### Tunnel SSH :
On ouvre le port sur LXLE :
```sh
sudo ufw allow 22
```
Sur kali, on crée le tunnel suivant :
```sh
ssh -L 2023:localhost:143 thomas@192.168.126.11
```
Il ne reste plus qu’à utiliser le port 2023 et l’hôte localhost sur Thunderbird sur kali.
On observe sur Wireshark que tout le trafic transite via SSH.
## Conclusion
Il est important de s'assurer de la sécurisation du serveur mail. C'est la plus grande porte d'entrée vers notre association, et donc la plus grande cible d'attaques extérieures. Il faut mettre en place différents filtres anti-phishing et autres, et s'assurer de former les membres aux éventuels risques. Dans notre cas, notre trafic est chiffré, sous un firewall, et sera à l'avenir écouté par un antivirus.
# Installation d'un service OpenVPN
## Introduction
Nous allons ajouter un service OpenVPN pour permettre aux membres de notre association de pouvoir travailler notamment à distance, en utilisant ce service. Ce dernier s'occupera de les connecter via un tunnel au réseau interne (pfSense) de l'association à distance de manière sécurisée.
## Configuration de OpenVPN
Nous commençons par créer le certificat d’autorité.
Nous nous en servons ensuite pour signer un nouveau certificat de serveur.
Nous créons l’utilisateur Alice, avec un certificat signé par le certificat d’autorité.
Nous créons la configuration OpenVPN sur le serveur.
Il ne faut pas oublier de configurer en « remote access user » :
Pour installer le paquet **openvpn-client-export**, nous avons dû reconfigurer les adresses DNS dans la configuration pfSense afin qu’elles fonctionnent sur la connexion de l’université.
Configuration réseau :
|Réseau | Adresses |
|-----------------------|-------------------------------|
|WAN | 192.168.5.130 |
|LAN | 192.168.126.10 |
|IPv4 tunnel net | 192.168.189.0/24 |
Nous n’oublions pas d’autoriser le port OpenVPN dans le parefeu :
On peut considèrer le réseau interne OpenVPN comme sûr parce qu’il n’y a que des administrateurs qui vont s’y connecter. Nous laissons donc passer tout le trafic :
Nous téléchargeons le fichier de configuration client, nous le lançons avec les identifiants d’Alice et nous nous retrouvons connectés avec l’adresse 192.168.189.2 (gateway = 192.168.189.1).
Maintenant, lorsque nous tentons de communiquer avec l’hôte LXLE (192.168.126.11), tout le trafic transite par OpenVPN (capture Wireshark).
## Conclusion
En utilisant un VPN, nous évitons d'exposer notre parc de machines au monde, avec par exemple un site public disposant d'une page d'authentification.
Ici, nous exigeons un accès double-authentifié, et sécurisé pour pouvoir interagir avec le réseau. Nous allions sécurité et praticité car nous sommes ainsi littéralement au sein du réseau. Avec cela, nous pouvons ainsi réduire la surface d'attaque envers le réseau informatique de notre association.
# Réalisation d'audits de sécurité
## Introduction
Nous allons maintenant scanner le réseau, chercher des vulnérabilités et mettre en place des correctifs avec l'aide de différents outils.
## Nessus - Scanning
L'utilisation de Nessus est important pour scanner les vulnérabilités d'un réseau.
<!--  -->
Nous pouvons créer 2 scans, un pour l'interface WAN, et un autre pour le réseau LAN.
### WAN - Scanning de 192.168.186.128 (interface WAN du routeur pfSense)
<!--  -->
### LAN - Scanning de 192.168.59.0/24 (réseau LAN)
<!--  -->
La machine tournant sur Kali Linux et scannant le réseau est donc celle qui a l'adresse IP 192.168.59.129.
Par exemple, pour la machine 192.168.59.3, Nessus a trouvé quelques vulnérabilités et fait certaines suggestions de correctifs.
## Metasploit - Pentesting
Avec Metasploit, nous pouvons identifier les machines du réseau LAN et voir s'il y a des faiblesses sur celles-ci.
<!-- 
### Premier scan
### Deuxième scan pour essayer d'avoir plus d'informations -->
## Lynis - Audit et sécurisation
Nous pouvons utiliser Lynis pour faire des audits et nous aider dans la sécurisation des machines en corrigeant les failles signalées.
<!--  -->
<!-- ### Possibilité de faire des audits en remote en suivant quelques étapes
[](https://i.imgur.com/XWcxlXp.png)
### Audit local par machine -->
Lynis permet de faire des audit en local comme en remote. Nous avons ici opté pour l'audit en local sur la machine lxle.
Nous remarquons par exemple qu'aucun mot de passe n'a été utilisé pour déverrouiller la machine.
Les informations de test et de debug sont ensuite mises dans le fichier /var/log/lynis.log.
Le rapport se trouve, quant à lui, dans le fichier /var/log/lynis-report.dat.
## Conclusion
Il est donc important de mettre à jour les services, d'utiliser des certificats SSL de confiance, de configurer des mots de passe, de se pencher sur toute faille potentielle sur le réseau LAN.
Finalement, en utilisant ces différents outils d'audit et de suggestion de correctifs, nous pouvons rendre la surface d'attaque du réseau LAN beaucoup plus complexe pour l'attaquant, et ainsi mieux sécuriser notre association.
Sign in with Wallet
Connect another wallet