# Architecture sécurisée des réseaux
**Sujet** : https://perso.isima.fr/~frbreuil/tp_archi_secu_reseau/2021-2022/

## Installation
Modifier VirtualBox pour enregistrer les données dans /VM :
Préférence > Général > Rentrer le nom
Sur les VMs > Settings > Général > Changer le nom

OpenBSD coté SAJ :
- eth0 : MAC > 080027D08AA8 // IP > 192.168.102.96
- dmz : MAC > 080027D1A1D7 // IP > 10.0.0.1
- lan : MAC > 080027531EE8 // IP > 10.0.1.1

Regénérer @MAC --> permet de ne pas faire de conflits avec les autres machines de la salle
Adresse IP => fichier hostname.*nom interface* contient soit "dhcp" soit l'adresse de l'interface

Pour avoir le scroll on se connecte en SSH à la VM OpenBSD à l'adresse publique (192.168.102.96)(shift + pageUP/ shift + pageDOWN ça fonctionne aussi).

Debian Bullseye coté SAJ :
Par quel fichier de configuration est configurée l'addresse de son interface ?
/etc/network/interfaces
Montre que l'adresse est setup en DHCP
Adresse IP > 169.254.3.179 -> Car n'arrive pas à joindre le serveur DHCP

Il faut mettre son adresse IP en statique (10.0.0.1)
sudo vim /etc/network/interfaces
Ajouter les lignes

auto enp0s3
iface enp0s3 inet static
    address 10.0.0.2/24
    gateway 10.0.0.1

`systemctl restart networking` pour réinitialiser l'adresse IP
`ifdown enp0s` pour "débrancher" le fil et `ifup enp0s3` pour rebrancher et ainsi actualiser l'adresse IP

Windows :
On les mets dans le réseau LAN niveau cartes réseau
Windows 7 mdp = gonfle!
Adresse d'autoconfiguration IPv4 > 169.254.85.114
--> A changer plus tard avec un serveur DHCP

Windows 2004 = student
Adresse d'autoconfiguration IPv4 > 169.254.136.4 ???
--> A changer plus tard avec un serveur DHCP
`rcctl set dhcpd flags em1`
<span style="color:red">Adresses en 169.254.x.x = pas d'adresses configurées (adresse APIPA)</span>

## Partie I : Le Firewall
Last matching rule wins : on bloque tout en premier puis on autorise petit à petit (du plus général au plus précis)
--> Dans PacketFilter et systèmes BSD

### Sécurisation par défaut en entrant depuis Internet

/etc/pf.conf pour faire le changement de configuration

Fichier avant modifs :


block drop in on em0 // Utile puisqu'il y a des block avant ???
pass in on em0 proto icmp

Commande pfctl -f /etc/pf.conf
Reload le file et si il y a une erreur dedans ça l'indique et ça reload pas.

Ping okay
SSH ne marche pas depuis l'extérieur sur le firewall
--> La règle marche bien

### Ouvrir uniquement les ports nécéssaires
On autorise SSH sur le firewall depuis notre machine

pass in on em0 proto tcp from 192.168.102.3 to em0 port 22 // Adresse Justine

On précise une destination avec l'interface et un port destination SSH

On teste en se connectant à SSH depuis notre machine au firewall : ça marche !

Logger les connexions bloquées:

block drop in log on em0

--> Pas d'options nécéssaires

On teste en prenant un PC non autorisé et en tentant une connexion SSH
La connexion SSH ne marche pas

Le log a sa propre interface (pflog0) donc pour capter si des logs sont enregistrés on tcpdump l'interface
`tcpdump -n -e -i pflog0`
On voit lors d'une connexion non autorisée un log qui apparait dans l'output de la commande

On peut aussi faire pour visualiser les règles dans l'ordre
`systat rules`
Qui donne l'output suivant

Le fichier de règle à la fin de cette question est :

### NATer la DMZ
Déja en réseau interne, déja IP statique et gateway
Elle est accessible depuis le firewall

- *Pouvez vous vous connecter en tant que root via ssh depuis le firewall vers le serveur debian ? Pourquoi ?*

On peut car le trafic est bloqué seulement sur l'interface entrante du firewall (em0) et non sur la sortie donc lui il peut pas pas les PC de l'extérieur

Configurer NAT sur interface em1 de OpenBSD (pour que l'intérieur de la DMZ puisse accéder à Internet avec des adresses publiques) :

Dans /etc/sysctl.conf :
Régler configuration réseau et système
Pour faire du NAT il faut autoriser le ip forwarding avec l'option net.inet.ip.forwarding à mettre à 1
--> Permet aux paquets de voyager entre les interfaces des machines

Créer fichier : /etc/sysctl.conf car il existe pas et on ajoute la ligne net.inet.ip.forwarding=1

On reload ensuite (en redémarrant la machine car on ne trouve pas la bonne commande)

On vérifie la valeur en faisant la commande
`sysctl net.inet.ip.forwarding`
--> La valeur est bonne

Dans /etc/pf.conf :

pass out on em0 from 10.0.0.0/24 to any nat-to em0

--> out on em0 parce que on veut que la translation se fasse en sortie du firewall vars Internet
--> from 10.0.0.0/24 permet de cibler le flux à l'origine de ce réseau pour avoir Internet
--> nat-to em0 pour mettre une adresse publique automatiquement

Pour vérifier que la machine Debian a accès à Internet, on ping 8.8.8.8 (pas encore de résolution de noms de domaines donc pas de google.com)
--> Ca marche

Que faut t'il configurer pour que cette machine puisse résoudre des noms DNS ?
/etc/resolv.conf
On a déja dans ce fichier domain local.isima.fr qui fait de la résolution basique pour nous

### Configurer le serveur DHCP
Configurer dhcpd :
On créé le fichier /etc/dhcpd.conf dans OpenBSD

On ajoute dedans les lignes :

option domain-name-servers 192.168.100.74; // Récupérer le DNS public (adresse IP dans resolv.conf)
subnet 10.0.1.0 netmask 255.0.0.0 {
    range 10.0.1.2 10.0.1.10;
    option routers 10.0.1.1; // Route par défaut
};

dhcpd -n --> qu'est ce qui ne va pas dans le fichier de conf

Pour recharger la configuration:

rcctl set dhcpd flags em2
rcctl enable dhcpd

Log dans /var/log/deamon pour voir qui demande des IP
--> Les machines Windows ont bien des IP

Windows 2004 : 10.0.1.2
Windows 7 : 10.0.1.3 (faut forcer pour qu'il réessaye)

### NATer les postes de travail
Mode réseau interne déja fait, adresses DHCP récupérées sur les Windows.

Configurer NAT sur em2 pour accéder à internet :

Pas besoin de refaire de l'ip forwarding

Dans /etc/pf.conf :

pass out on em0 from 10.0.1.0/24 to any nat-to em0

Les postes de travail ont accès à Internet

### Port forwarding
Machine hôte = PC Justine
Justine doit pouvoir être connecté à la machine Debian en faisant ssh firewall -p 2222 directement

Dans /etc/pf.conf:

pass in on em0 proto tcp from 192.168.102.3 to em0 port 2222 rdr-to 10.0.0.2 port 22

--> on met l'adresse publique du firewall car c'est à lui que le client peut accéder

Pour tester
`ssh test@192.168.102.96 -p 2222`
--> Ca marche depuis la machine de Justine et pas depuis la machine de Stacy donc c'est nice

Fichier /etc/pf.conf après modifications :

### Redirection de ports pour l'accès public

Redirection les connexions de l'extérieur à destination de HTTP vers Debian :
Dans /etc/pf.conf:

pass in on em0 proto tcp from any to em0 port 80 rdr-to 10.0.0.2

En tapant l'adresse IP du firewall dans un navigateur on obtient une page web valide

Où sont stockés les fichiers journaux du serveur HTTP ?
/var/log/lighttpd/error.log
--> On n'a pas les permissions et c'est seulement our les erreurs

On y accède avec
`journalctl -u lighttpd`

Vérifier que les connexions faites sont bien enregistrées. Si ce n'est pas le cas, que faut il faire pour logguer chaque requête faite par un client ?

Pour voir les connexions, on regarde dans le fichier
*/etc/lighttpd/lighttpd.conf*

Il n'y a pas de fichier pour accesslog donc on va rajouter la ligne
`accesslog.filename = "/var/log/lighttpd/access.log"`
Ca va enregistrer nos connexions dans le fichier précisé.

Dans */etc/lighttpd/lighttpd.conf* on ajoute "mod_accesslog" dans server_module:


Résultat dans le fichier :

### Filtrage sortant

Dans /etc/pf.conf :
Pour filtrer les accès à Internet depuis le LAN

block drop in on em2
pass in on em2 proto tcp from any to any port {80,443}

On tente de se connecter à Internet depuis une VM Windows pour voir si ça marche et ça c'est bon.
Le ping ne passe pas par contre.

Autoriser le ping:

pass in on em2 proto icmp

Le ping marche mais pas sur un nom de domaine car on n'autorise pas le dns

Autoriser DNS:

pass in on em2 proto udp from any to any port 53

Bonne pratique : mettre log sur toutes les règles pour voir quelle requête passe avec quelle règle puis vérifier avec tcpdump

Fichier après modification :


### Filtrage simple des connexions bruteforce

On veut modifier la règle faisant le port forwarding vers Debian

Dans /etc/pf.conf:

pass in on em0 proto tcp from 192.168.102.3 to em0 port 2222 rdr-to 10.0.0.2 port 22 keep state (max-src-conn-rate 3/60, overload <bad_hosts> flush global)

--> 3/60 = 3 connexions échouées en 60 secondes
--> <bad_hosts> est une table présente dans la doc et on suppose qu'elle existe

On essaye de se connecter 3 fois et au bout de la 4ème on a plus de réponse de la machine

Observer la table PF:

`pfctl -t bad_hosts -T show`


Enlever le blacklistage :

`pfctl -t bad-hosts -T delete 192.168.102.4`


Comment faire pour s'assurer que certaines IP ne seront jamais blacklistées ?
Création d'une table whitelist et autorisation des addresses de cette tables à se connecter sans connection rate maximal :

table <whitelist> {192.168.102.4}
pass in on em0 proto tcp from <whitelist> to am0 port 2222 rdr-to 10.0.0.2 port 22


## Partie II : Le VPN

Avant mise en place iked :

- noter les configurations réseau/tables de routage :
Sur le firewall
Sur Windows

- tester la connectivité via ping, la résolution DNS via nslookup
`ping 192.168.102.96`
`nslookup google.com`

- faire une connexion avec nom d'utilisateur/mot de passe en clair (telnet/FTP) et écouter le traffic via wireshark sur la machine hôte, simulant ainsi un attaquant potentiel
Aller sur ent.uca.fr et entrer des identifiants bidon et capturer le trafic en clair avec wireshark

Après mise en place du VPN :
- noter les configurations réseau/tables de routage
- tester la connectivité via ping, la résolution DNS via nslookup
- faire une connexion avec nom d'utilisateur/mot de passe en clair (telnet/FTP) et écouter le traffic via wireshark sur la machine hôte, simulant ainsi un attaquant potentiel

### IKEv2

#### Utilisation de ikectl

S'assurer d'un heure correcte via la commande `rdate poll.ntp.org`

Création d'une CA : `ikectl ca serveurPKI create`

Implique la création de fichiers :


La machine windows étant à l'extérieur, son addresse IP est 192.168.102.121
Création du couple de clés :
- Création des certs
Pour le client, (**attention** il faut préciser l'IP du client Windows dans CN, ou par defaut) :
`ikectl ca serveurPKI certificate 192.168.102.121 create`
Pour le serveur (**attention** même nom que le CN) :
`ikectl ca serveurPKI certificate 192.168.102.96 create`
- Installation en local des certificats du serveur :
`ikectl ca serveurPKI install`
`ikectl ca serveurPKI certificate 192.168.102.96 install`
- Export pour récupérer les certificats de la machine (peer)
`ikectl ca serveurPKI certificate 192.168.102.121 export` (préciser un mdp: client)
Transfert vers la machine windows :
1. `scp doc.tgz test@10.0.0.2:~/`
2. Copie du doc vers notre home
3. Décompression `tar -xzpf doc.tgz -C /var/www/html`
4. Autoriser le listing de directory sur le serveur web. Ajouter l'option `server.dir-listing="enable"` dans le fichier `/etc/lighttpd/lighttpd.conf`

#### Configuration serveur OpenBSD

1. Il faut que le nom du certificat soit le nom du Common Name donné lors de la génération du certificat (screen avant modification du CN ci-dessous).
2. Création d'un fichier `/etc/iked.conf` en mode 640 (`iked -n` pour vérifier la config)
3. Autoriser IPsec à passer sur le réseau
4. Ajout de l'authentification CHAP-V2
--> Il faut remplacer from any to 10.0.0.0/24 par from any to dynamic

Démarrer le VPN, et s'assurer qu'il fonctionne correctement en observant les fichiers journaux du système, la liste des interfaces, ainsi que les serveurs en écoute.
Démarrer le VPN : `iked -S`


Option pour le démarrer en foreground et très verbeux `iked -dv`

On voit que les clés et certificats ne sont pas au bon endroit(je sais pas comment)
Il faut ajouter donc les clés du serveur (create et install) ainsi que **copier** les certificats du client pour que le serveur sache qui va se connecter à lui


Quand ils le sont on a des nouvelles lignes ca... avec un OK à la fin

Une nouvelle interface est apparue *enc0*. -> Nop, toujours là

Les serveurs en écoute avec la commande `netstat -lnt`
On peut voir que le port *4500* est en écoute, c'est le port précisé par iked (cf. affichage ci-dessus).

Activer iked(8) au démarrage de la VM.
`rcctl enable iked`

Quelles sont les régles de firewalling à ajouter pour qu'un client puisse se connecter au VPN ?
Voir screen pf.conf

Quels sont les fichiers de clefs de la PKI qui vont être utilisés par le serveur ?
les .crt ???

Quelles sont les IP utilisées par le VPN ?
10.0.2.0/24 normalement ?

#### Configuration client Windows
Dans Virtualbox, reconfigurer l'interface de la machine virtuelle Windows pour qu'elle soit en mode pont sur eth0. Vérifier qu'elle récupère bien une adresse via DHCP depuis le serveur de la salle.
-> OK, adresse 192.168.102.121

Quels sont les fichiers/certificats transmis au client ?
Le .tgz entier donc avec tout ses bidules au client

Quels sont les paramêtres à utiliser pour la configuration du client ?
Il faut importer les certificats dans le certificate store local de la machine Windows
oir/debugguer le traffic passant à travers le
`mmc` dans cmd
"Ajouter/supprimer un composant logiciel"
--> Liens MMC : https://www.thesslstore.com/knowledgebase/ssl-install/how-to-import-intermediate-root-certificates-using-mmc/
https://wiki.strongswan.org/projects/strongswan/wiki/Win7Certs
Ajouter le Certificate store.
Dans **Personal**, click droit, importer : on ajoute le certificat client.
Dans **Trusted Certification Authorities**, same : on ajoute le certificat CA.

Pour se connecter, cherche VPN dans les paramètre Windows et ajouter notre serveur, ainsi que nos identifiants :

Resolution : mettre IKEv2 en type de réseau privé virtuel

Résolution : mettre tout par défaut dans les certificats (noms doivent être les même que le CN)

On a une adresse dans 10.0.2.0/24 donc c'est bien

Test du ping vers 10.0.0.2:
Marche pas

Règle à mettre (merci Andy):

pass in on em0 proto udp from any to 192.168.102.96 port {500,4500}
pass in on em0 proto esp from any to 192.168.102.96

pass in on enc0 proto tcp from 10.0.2.0/24 to 10.0.0.2 port http

Test du ping vers 10.0.0.2:
C'est bon


Le curl marche aussi !

#### Route par défaut ?
2 modes:
- Uniquement pour le traffic à destination des réseaux privés du coté du serveur. Tout le reste du traffic passe par la connexion internet existante, et n'est pas chiffré.
- Tout le traffic passe par le VPN. C'est la configuration par défaut du client IKEv2 de windows. Comment modifier ce comportement ?

Pour modifier le comportement par défaut du client IKEv2 Windows on fait...
https://forums.clavister.com/viewtopic.php?t=6089
Split tunneling

https://windowsreport.com/fr/tunnel-divise-vpn-win-10/
Avec ce tuto on dirait que la configuration split tunneling est deja faite par défaut, c'est bizarre.
On décoche Utiliser passerelle par défaut

Changer la configuration du VPN :


Dynamic = adresse des clients VPN
from ... = je suis le VPN et j'ai tels réseaux derrière
--> de base on avait any donc tout les réseau donc le client passait par là mais maintenant on dit qu'on a que le réseau local 10.0.0.0/24

On arrive à ping google --> il ne passe pas par le VPN
On arrive à curl 10.0.0.2 --> il passe par le VPN pour allez sur le réseau local

Comment voir/debugguer le traffic passant à travers le VPN ?
Avec tcpdump -nei enc0 // interface du VPN

ipsecctl -sa --> on voit les sous réseaux qui sont connectés au VPN

Quels sont les avantages/inconvénients des deux méthodes ?
Google

Comparer l'utilisation du réseau en utilisant les deux méthodes.
Le firewall est moins chargé et le VPN aussi donc connexion plus rapide ?

Quelles sont les différentes méthodes possibles pour que les réseaux 10.0.0.0/24 et 10.0.2.0/24 se "voient" ?
On tente de ping 10.0.2.227 (la windows) depuis le serveur web et ça ne marche pas donc partie VPN peut voir partie "DMZ" mais pas l'inverse
Pour débloquer, on peut enlever des règles de firewall entre les deux
Il faut aussi la règle from 10.0.0.0/24 to dynamic

Que faut il configurer sur le firewall pour qu'un client VPN puisse accéder à internet ?
Un serveur DNS ???

Tenter une connexion SSH depuis le client VPN vers le serveur dans l'autre sous-réseau.
ssh test@10.0.0.2
--> Marche sans redirection puisque c'est seulement de l'extérieur qu'on fait le port 2222

### Jonction de deux sites

On fait une configuration site-to-site plutot que client/serveur
Il faut suivre la page de FAQ

http://www.openbsd.org/faq/faq17.html

On prends la clé du serveur 2 (/etc/iked/local.pub) dans le serveur 1 (/etc/iked/pubkeys/fqdn/serveur2.domain) et inversement.
On a pas besoin de déplacer notre local.pub à nous, c'est fait automatiquement.

em0 est une adresse publique donc pas besoin de la changer.
On change l'adresse du réseau LAN pour éviter les conflits --> pour serveur 1 c'est 10.0.3.0/24 (dans bullseye /etc/network/interfaces et on restart networking)
On devra aussi choisir une autre adresse de translation VPN

serveur 2 = 192.168.102.98
serveur 1 = 192.168.102.96

Dans pf.conf

pass in log on em0 proto udp from 192.168.102.98 to em0 port {isakmp, ipsec-nat-t} tag IKED
pass in log on em0 proto esp from 192.168.102.98 to em0 tag IKED

Dans iked.conf (serveur 1 - responder):
On commente l'ancienne configuration de VPN

ikev2 'serveur1_rsa' passive esp \
        from 10.0.3.0/24 to 10.0.2.0/24 \
        local 192.168.102.96 peer 192.168.102.98 \
        srcid serveur1.domain

Dans iked.conf (serveur 2):

ikev2 'serveur2_rsa' active esp \
        from 10.0.2.0/24 to 10.0.3.0/24 \
        peer 192.168.102.96 \
        srcid serveur2.domain

On redémarre tout (rcctl restart iked; iked -S)
iked -dv ???? Sur la page FAQ ça dit "Using iked -dv can help you understand the exchange" mais c'est un peu complexe
ipsecctl -sa

## Partie III : CARP/Pfsync
https://www.it-connect.fr/fail-over-pfsense-via-carp-et-pfsync/

### Généralités
cloner la machine virtuelle OpenBSD (on aura donc fw1 et fw2)
ne pas oublier de réinitialiser les adresses MAC : network > advanced > reinit
changer son hostname : hostname nom
supprimer les clefs ssh dans /etc/ssh/ pour éviter des alertes de ssh (elles seront regénérées au démarrage de la VM)

Dans les deux firewall :
dans VirtualBox, activer une 4e interface physique dans la configuration réseau (support a pfsync) > internal network, name = firewall_internal (réseau distinct de dmz et lan pour simuler une connection directe entre les 2 machines)

dans VirtualBox, choisir 'tout autoriser' pour le mode promiscuité des 3 premières interfaces (nécessaire pour le bon fonctionnement de carp dans virtualbox) --> network > promiscious mode > allow all

dans OpenBSD, modifier les configurations des deux firewall pour que chacune des interfaces 'clones' se retrouvent dans le même sous-réseau :
* em0 reste en DHCP sur fw1 et fw2, qui doivent donc chacun récupérer une IP publique distincte
* em1 sur fw1 aura l'addresse 10.0.0.100 et 10.0.0.200 sur fw2
* em2 sur fw1 aura l'addresse 10.0.1.100 et 10.0.1.200 sur fw2
* em3 sur fw1 aura l'addresse 10.0.10.1 et 10.0.10.2 sur fw2, sur un sous-reseau en /30 (c'est l'interface pour pfsync(4))

en faisant des cat et modifiant /etc/hostname.emX on peut voir les adresses ou si c'est en DHCP ou non et ajouter des adresses statiques

fw_1 :
- em0 : 192.168.102.96 (bien en DHCP)
- em1 : 10.0.0.100/24
- em2 : 10.0.1.100/24
- em3 : 10.0.10.1/30

fw_2 :
- em0 : 192.168.102.161 (bien en DHCP)
- em1 : 10.0.0.200/24
- em2 : 10.0.1.200/24
- em3 : 10.0.10.2/30
-

### Failover
https://www.openbsd.org/faq/pf/carp.html

Activer PfSync:
vi /etc/hostname.pfsync0
Dedans on ajoute : up syncdev em3
--> On lie les deux firewall (à faire dans les 2)

Activer CARP:
sysctl -w net.inet.carp.allow=1

Activer la préemption (pour bascule automatique):
sysctl -w net.inet.carp.preempt=1

Les modifications CARP peuvent se faire via ifconfig mais ces changements sont temporaires. Il faut donc créer des fichiers hostname

Sur fw1:
vi /etc/hostname.carp0
-->inet 192.168.102.200 255.255.255.0 192.168.102.255 vhid 200 carpdev em0 pass carp0

vi /etc/hostname.carp1
-->inet 10.0.0.1 255.255.255.0 10.0.0.255 vhid 1 carpdev em1 pass carp1

vi /etc/hostname.carp2
-->inet 10.0.1.1 255.255.255.0 10.0.1.255 vhid 2 carpdev em2 pass carp2

Sur fw2, on créé aussi les fichiers mais au lieu de mettre les adresses des interfaces on garde les adresses des interfaces du fw1 à redonder.

Sur fw2:
vi /etc/hostname.carp0
-->inet 192.168.102.200 255.255.255.0 192.168.102.255 vhid 200 carpdev em0 pass carp0 advskew 100

vi /etc/hostname.carp1
-->inet 10.0.0.1 255.255.255.0 10.0.0.255 vhid 1 carpdev em1 pass carp1 advskew 100

vi /etc/hostname.carp2
-->inet 10.0.1.1 255.255.255.0 10.0.1.255 vhid 2 carpdev em2 pass carp2 advskew 100

On reload les interfaces:
sh /etc/netstart

Comment est utilisée la valeur fournie via advskew ?
Plus la valeur est grande, moins l'hote à de chance de devenir master et donc d'avoir la priorité --> on dévie la advbase de plus en plus lors des publication CARP

Mettre une passphrase pour éviter les intrusions

Les adresses et vhid à mettre sont dans le TP
On met un vhid unique sur l'interface extérieure pour éviter les conflit avec les autres groupes

Autoriser le traffic du protocole carp :

pass on {em0 em1 em2} proto carp keep state (no-sync)
set skip on pfsync0

Modifications du VPN (iked.conf dans les 2 firewall):

La local est l'adresse publique du firewall (carp0)

Ce principe de failover permet d'éviter de devoir refaire toutes les règles de firewall puisqu'on prends uniquement les interfaces carp en compte.

Changement des règles de réseau pas au niveau pass in on em0 mais plutot pour les parties où les noms d'interfaces remplacent des adresses IP précises (to... par exemple).
On modifie dans les règles de nat et de manière générale dans toutes les règles utiles à ce moment là

Les clients connectés sur dmz et lan devraient avoir accès à Internet --> depuis la dmz c'est bon

Que faut il faire pour que le VPN marche sur l'ip flottante ?
ip flottante = carp0
La local est l'adresse publique du firewall (carp0)
Il faut aussi modifier l'adresse du serveur dans le client VPN

Est-ce que le VPN peut gérer le failover ?
Oui puisqu'il se connecte à l'ip flottante

vérification des états de connexions bien synchronisés :
systat states


On voit bien des connexions carp
Il faut que les connexions soient identiques sur le résultat des deux firewall (carp et autres). Ca indique que la redondance est faite et qu'en eteignant le master ça change rien à la co des utilisateurs
Si il n'y a pas la même chose c'est que pfsync ne marche pas

Pour vérifier, on fait un ping depuis debian vers 8.8.8.8 et on le laisse tourner, on éteint le fw1 et si le ping continue malgré le firewall éteint c'est que fw2 a pris le relais

Certains états ne devraient pas être synchronisés, lesquels, pourquoi, et comment s'assurer qu'ils restent locaux a chacun des firewall ?
???

Faut t'il modifier la rêgle de NAT pour les différents réseaux ?
il faut faire nat-to carp0 et non em0 pour que ça marche même en cas de failover (sinon ça translate sur un réseau dirigé que par un firewall...)

Quels sont les conséquences sur les paquets en provenance des sous-réseaux ?
Ils sont natés et ils peuvent sortir sur Internet ?

La bascule se fait bien lorsque l'on coupe un firewall (le ping jusqu'à la machine debian ne s'arrête pas).

### Load balancing

SI QUELQU'UN TROUVE COMMENT FAIRE MARQUEZ SVP

Commande exemple : `ifconfig carp0 192.x.x.x carpdev em0 carpnodes 1:0,2:100` *(vhid:advskew)*
Carpnodes permet de définir le load balancing sur les carp ayant les vhid 1 et 2. Si une machine a 1:0 et l'autre 1:100, la première sera préférée à la seconde en terme de load balancing, pour le carp ayant le vhid 1. donc il faut alterner parmi les carp pour que les machines se les partagent et donc se partagent la charge.

Dans un des fichiers carp (genre hostname.carp0)
inet 192.168.102.200 255.255.255.0 192.168.102.255 carpdev em0 vhid 200 pass carp0
DEVIENS
inet 192.168.102.200 255.255.255.0 192.168.102.255 carpdev em0 carpnodes 1:0, 2:100

--> sur l'autre firewall on fera 1:100, 2:0

Mode IP

Mode ARP
balancing arp ?

net.inet.carp.arpbalance

## Partie IV : Reverse Proxy

### Généralités


### Proxy niveau 3 / redirection web avec loadbalancing

Faire un clone :

Quels sont les fichiers a remodifier sur le clone ? Vérifier que les deux firewall peuvent y accéder.
Une fois le clone fait, il faut modifier :
- */etc/network/interfaces* sur la machine pour modifier l'addresse en 10.0.0.3 et faire `systemctl restart networking`
- */etc/pf.conf* sur les firewall, copier la règle de redirection de port SSH
`pass in on em0 proto tcp from any to carp0 port 2223 rdr-to 10.0.0.3 port 22`
- */var/www/html/index.html* sur la machine pout savoir quel serveur répond.

Curl pour tester les modifs de la page, depuis l'autre debian parce que flemme LUL

Ne pas oublier d'activer le logging des requêtes dans les configurations de lighttpd (lighttpd-enable-mod accesslog). Suivre le log via tail -f /var/log/lighttpd/access.log.

*Configurer un relai dans relayd(8) pour qu'il distribue les requêtes sur le port 80 sur les deux serveurs web, en mode round-robin (les requêtes vont arriver alternativement sur les deux serveurs. Quels sont les autres modes ?)*

Pour configurer relayd :
- Créer le fichier de configuration */etc/relayd.conf* sur fw1

    redirect "www" {
        listen on 192.168.102.200 port 80
        forward to 10.0.0.2 check http "/" code 200 mode roundrobin
        forward to 10.0.0.3 check http "/" code 200 mode roundrobin
    }

- Reload relayd `relayd -f /etc/relayd.conf`
c'est plutôt :`relayd -n`

Autre modes que round robin :
- **mode hash** [key]
Balances the outgoing connections across the active hosts based on the key, IP address and port of the relay. Additional input can be fed into the hash by looking at HTTP headers and GET variables; see the PROTOCOLS section below. This mode is only supported by relays.
- **mode least-states**
Forward each outgoing connection to the active host with the least active pf(4) states. This mode is only supported by redirections.
- **mode loadbalance** [key]
Balances the outgoing connections across the active hosts based on the key, the source IP address of the client, and the IP address and port of the relay. This mode is only supported by relays.
- **mode random**
Distributes the outgoing connections randomly through all active hosts. This mode is supported by redirections and relays.
- **mode roundrobin**
Distributes the outgoing connections using a round-robin scheduler through all active hosts. This is the default mode and will be used if no option has been specified. This mode is supported by redirections and relays.
- **mode source-hash** [key]
Balances the outgoing connections across the active hosts based on the key and the source IP address of the client. This mode is supported by redirections and relays.

*Que faut t'il configurer dans pf(4) pour que relayd puisse fonctionner correctement ? Observer les règles PF et les tables.*
Il faut supprimer la règle de redirection vers le port 80 de la machine 10.0.0.2 pour qu'il ne redirige pas directement vers cette machine uniquement.

relayctl show summary -> on voit bien nos connexions

cat /var/log/daemon -> voir les logs

dans pf.conf il faut ajouter : anchor "relayd/*", puis reload relayd.conf

pf.conf va remplacer cette anchor par les règles créées automatiquement par relayd (notamment pour liste et les redirect)


Marche, donne les pages des deux serveurs une fois sur 2

#### Failover

Quand on éteint un serveur, une seule des deux pages s'affiche (normal)

Vérification de la somme de contrôle de la page donnée sur le serveur web avant de forwarder la requête:

Le digest est obtenu grâce à la commande "ftp -o -http://*adresse_serveur* | sha1"

Sachant que les deux html sont les mêmes, on voit bien que les deux sont up quand on fait "relayctl show summary"
MAIS quand on change un des deux html on voit que un des deux est down.

Modifier le contenu d'une page pour tester ce contrôle. A quoi sert ce mode ?

Cela permet d'avoir une vérification plus poussée que juste en vérifiant avec un ping.

Configurer un fallback :
2ème instruction de forward to dans une autre liste

`table <fallback> disable { 10.1.5.1 retry 2 }`

#### Reverse proxy simple relai niveau 7
reverse-proxy dit applicatif

reverse proxy lui-même qui ouvre la connection vers le serveur final, va faire la requête, et transmettre le résultat au client qui attend sur la connection que ce dernier a ouvert avec le reverse-proxy - mais c'est transparent pour le client

Rajouter un virtual host:
Dans un des serveurs web,

https://www.osradar.com/configure-virtual-hosts-lighttpd/

mkdir -p /var/www/html/www.test
chmod -R 755 /var/www/html/www.test
chown -R www-data:www-data /var/www/html/www.test
cat "<html><body>welcome to www.test2.osradar.lan </body></html>" | /var/www/html/www.test/index.html
mkdir -p /etc/lighttpd/vhosts.d/

Ajouter la ligne : include_shell "cat /etc/lighttpd/vhosts.d/*.conf"
à la fin de /etc/lighttpd/lighttpd.conf

vi /etc/lighttpd/vhosts.d/www.test.conf


systemctl restart lighttpd

On ajoute 192.168.102.200 www.test dans le /etc/hosts du client (un PC hôte à l'extérieur du firewall)

Relays will forward traffic between a client and a target server. In contrast to redirections and IP forwarding in the network stack, a relay will accept incoming connections from remote clients as a server, open an outgoing connection to a target host, and forward any traffic between the target host and the remote client, operating on layer 7. A relay is also called an application layer gateway or layer 7 proxy.

Pour configurer relayd, on va faire relay et non redirection comme pour le niveau 3

relayd -n

Attention, pour relayd ce n'est plus une redirection niveau 3, mais un relai niveau 7. Pourquoi ?
Bonne question, parce qu'il y a une URL ? Parce qu'il analyse la requête maintenant.
Il est intelligent, relayd recoit direct la requête et l'analyse lui même sans besoin de pf

--> Il n'y a plus besoin d'anchor et il faut une règle pour autoriser les paquets à arriver sur le port 80 sinon rien n'arriverait à relayd


On vérifie le nom de domaine demandé puis on forward au bon serveur

Dans chacun des cas, quelle est l'ip cliente enregistrée dans le log de serveurs web ? Que faut t'il faire dans la configuration de relayd pour que le serveur web ait une information correcte ?
tail -f /var/log/lighttpd/access.log

10.0.0.100 --> @ carp

Pour mettre la vraie adresse de la source, il faut faire un match-address ?



## Partie V : Proxy sortant

### Généralités

Un proxy peut-être configuré de deux manières principales :

en mode transparent/interception: l'utilisateur ne sait pas qu'il passe par un proxy, c'est le firewall qui détourne les requêtes du client sur le port 80 de manière transparente vers le proxy
en mode classique: le navigateur/poste client doit être configuré pour utiliser le proxy sur un couple adresse:port connu. Dans ce cas, le proxy peut demander une authentification au client pour faire du suivi. Généralement dans ce cas le firewall bloque complètement l'accès au port 80 en sortant pour obliger tout les clients à passer par le proxy.

On parle de proxy sortant quand on reçoit la requête d'un client interne à notre réseau à destination d'un serveur web à l'extérieur, et on ne la transmet pas directement à la cible - on va d'abord l'analyser pour savoir si cette requête est légitime, ou cacher éventuellement la réponse pour la resservir à un autre futur client.

### Proxy filtrant

/etc/tinyproxy.conf

https://wiki.deimos.fr/TinyProxy_:_Mise_en_place_d%27un_proxy_simple_et_rapide.html

/etc/tinyproxy/filter
--> liste des adresses à bloquer (isima.fr)

Dans /etc/tinyproxy.conf
Filter "/etc/tinyproxy/filter"

rcctl restart tinyproxy

Reconfigurer le navigateur dans les clients du LAN pour utiliser l'ip et le port du proxy (pour tout les protocoles y compris ssl).
Quelle IP:port utiliser ?

### Proxy cache