La topologie de cette exemple est **volontairement simplifiée**.
Elle n'est là que pour vous présenter les grands principes de séparation en "zones" de l'architecture réseau d'une entreprise, les "rôles" de ces différentes zones et la manière de les traiter d'un point de vue sécurité.
En réalité, la plupart des réseaux d'entreprise comportent beaucoup plus de ces zones, souvent imbriquées et multiplient les routeurs/pare-feu entre les zones.
4. Lorsque le programme vous le demande (2 fois), sélectionner l'interface réseau à utiliser (votre interface filaire ou wifi branchée au réseau de l'établissement).
Première et dernière ligne de défense entre le réseau de l'entreprise et Internet. Il est en charge de filtrer les communications entre le réseau de l'entreprise et l'extérieur.
Dans notre configuration d'exemple, il assure également le rôle de routeur entre les différentes zones de notre intranet. Il assure donc également le filtrage des communications internes.
---
## La zone "Services Intranet"
Les services "Intranet" sont des services dédiés à l'usage **interne** de l'entreprise. Ce sont souvent des applications "métier", des applications Web de travail collaboratif, des serveurs de fichiers...
Ces services ne sont normalement accessibles que depuis le réseau interne de l'entreprise (notamment les réseaux type "stations de travail").
Les services "Extranet" sont des services dédiés à l'usage **externe** de l'entreprise. Ce sont souvent des sites ou des applications web dédiées à la relation clients et/ou partenaires. Des applications web telles qu'un "webmail" peuvent également être positionnées dans cette zone.
Ces services sont normalement accessibles depuis Internet, très souvent derrière un "mur" d'authentification spécifique ou de type "Single Sign On" (SSO).
---
## Les zones "Stations de travail"
Les stations de travail devraient **être réparties** dans leur propre zone, et si possible **dans des zones dédiées aux différents "corps de métiers"** de l'entreprise.
Ainsi, le service "Comptabilité" ne devrait pas être sur le même réseau que le service "Développement".
Les **règles de communication internes/externes** devraient également être **spécialisées** en fonction des contraintes/besoins des différents corps de métiers.
**Exemple** Les connexions SSH vers l'extérieur ne devraient pas être possibles depuis la zone "Comptabilité" mais certainement autorisées/nécessaires depuis le réseau "Développement".
---
## Règles générales de communication inter-zones
Chaque zone devrait être **notée suivant le risque d'intrusion** et **le potentiel d'impact d'une intrusion**.
Une zone avec un risque d'intrusion de **niveau N ne devrait pas pouvoir initier de communication vers une zone de niveau N-1**.
![center 50%](img/communicationrules.png)
L'application de cette règle générale n'est pas toujours possible et il faut parfois l'adapter aux contraintes de fonctionnement de l'entreprise.
---
## D'autres zones, d'autres usages
- Imprimantes
- Terminaux mobiles (BYOD)
- Internet des objets
- Invités
- etc
---
## Sécurité et configuration d'un serveur GNU/Linux
### Installation du serveur
### Politique d'accès et configuration SSH
### Règles de pare-feu
---
## Installation du serveur
1. Télécharger l'image ISO Ubuntu Server 16.04.*
2. Créer une nouvelle machine dans VirtualBox
3. Configurer le réseau de la nouvelle machine pour utiliser une interface de type "bridge" et autoriser toutes les connexions
4. Démarrer la machine et sélectionner l'image ISO
---
## Règles générales de partitionnement (1)
- Utiliser [LVM](https://wiki.ubuntu.com/Lvm)
- ~300/500M pour `/boot`
- Partition séparée pour `/var` ( via un volume logique)
- Partition séparée pour `/home` (via un volume logique)
- Partition séparée pour `/` (via un volume logique)
- Garder de l'espace pour pouvoir agrandir au besoin une partition LVM
---
### Règles générales de partitionnement (2)
**Exemple** Pour 10G de disque
|Point de montage|Système de fichier|Taille|
|:-|:-|:-|
|`/boot`|ext4 (Primaire)|500M
|`/`|ext4 (LVM)|4G (~30/40%)
|`/home`|ext4 (LVM)|1G (10%)|
|`/var`|ext4 (LVM)|3G (~30/40%)|
|`swap`|swap (LVM)| round(sqrt(RAM) <swap<2*RAM|
Et garder ~10% d'espace libre pour pouvoir agrandir un volume logique au besoin.
---
## Activation des mises à jour automatiques
Si à l'installation l'option n'est pas proposée (sur Debian et dérivées)
Créer un compte utilisateur accessible en SSH pour un de vos collègues. L'authentification par mot de passe doit être désactivée (uniquement clé SSH) et le mot de passe du compte doit être expiré.
### Consignes
1. Créer un compte utilisateur
2. Marquer son mot de passe comme étant expiré
3. Déployer la clé SSH publique de votre collègue sur ce compte utilisateur
Un NIDS ou **Network Intrusion Detection System** est un système informatique dont l'objectif est de détecter les comportements anormaux, souvent synonymes d'intrusions, **sur un réseau**.
Pour ce faire, il analyse les trames transitant sur le réseau et applique des règles de classification permettant de déclencher automatiquement des actions d'alertes ou préventives.
Un HIDS ou **Host Intrusion Detection System** est un système informatique dont l'objectif est de détecter les comportements anormaux, souvent synonymes d'intrusions, **sur une machine**.
Les HIDS peuvent utiliser des sources d'informations très variables en fonction de leur spécialisation: droits sur le système de fichiers, cycle de vie des processus s'exécutant sur le système, règles de pare-feu, fichiers de journalisation...
---
## Exemple: fail2ban
Le projet [fail2ban](https://github.com/fail2ban/fail2ban) est un HIDS simple à mettre en place qui se base sur les fichiers de journalisation d'un serveur.
Il utilise des expressions régulières en temps réels sur les fichiers de journalisation pour détecter les tentatives d'intrusion et extraire les informations nécessaires à la mise en place d'actions préventives, par exemple bloquer l'adresse IP de l'attaquant pendant un certain temps.
**Exemples d'actions détectées** Échecs multiples d'authentification SSH, tentatives d'injections SQL sur une application Web, etc...
---
## Installation de fail2ban
```bash
apt install fail2ban
```
---
## Configuration
### Principaux fichiers et répertoires
-`/etc/fail2ban/fail2ban.conf` - Fichier de configuration général
-`/etc/fail2ban/jail.conf` - Définition des "jails" par défaut
-`/etc/fail2ban/jail.d` - Définitions de "jails" additionnelles
-`/etc/fail2ban/filter.d` - Filtres d'activation des "jails"
-`/etc/fail2ban/action.d` - Définition des actions potentielles à exécuter en cas d'activation d'une "jail".
_La personnalisation de la configuration se fait en créant des fichiers `<nom_fichier>.local`._
---
## Exercice
Configurer fail2ban pour bannir les IP à l'origine de tentatives de connexion échouées sur un site Wordpress.
1. Créer un filtre pour détecter les tentatives échouées de connexion à votre Wordpress. Quelle est la différence dans les logs entre un échec et un succès ?
3. Créer votre filtre `/etc/fail2ban/filter.d/wordpress.conf` avec votre expression régulière. Pour tester:
```
fail2ban-regex --print-all-match <logfile> \
/etc/fail2ban/filter.d/<filter>.conf
```
4. Créer votre propre section "wordpress" dans le fichier `/etc/fail2ban/jail.local` en vous inspirant des exemples déjà présents.
**Ressources**
- [Créer des filtres - Documentation fail2ban](https://fail2ban.readthedocs.io/en/latest/filters.html)
Prometheus stocke des échantillons (mesures) sous la forme de **séries temporelles**. Il créait une nouvelle série pour chaque association **(nom_métrique, label1=value, label2=value, ...)**.
Chaque couple **(label, valeur)** est appelée **dimension** de la métrique.
Un compteur est une métrique dont la valeur ne peut faire qu'augmenter au cours du temps.
> **Exemple** Nombre total de connexions d'un compte sur un site
---
## Jauge
Une jauge est une métrique dont la valeur peut augmenter ou diminuer au cours du temps.
![center 50%](./img/jauge.jpg)
> **Exemple** La température d'une pièce
---
## Histogramme (1)
Un histogramme est une métrique répartissant les données dans des "seaux" (ou "buckets" en anglais) configurables et comptant le nombre total et par "paquet" d'échantillons ainsi que leur somme.
![center 70%](./img/histogram.png)
> **Exemple** Le temps de réponse des requêtes HTTP
---
## Histogramme (2)
### Scénario d'exemple
Soit la métrique `http_request_duration_seconds` un histogramme avec les "buckets" suivants: 0.5, 1, 2, 3, 5.
3 requêtes sont effectuées sur l'application avec des temps de 1s, 2s et 3s respectivements.
On aura sur `/metrics`:
```
http_request_duration_seconds_bucket{le="0.5"} 0
http_request_duration_seconds_bucket{le="1"} 1
http_request_duration_seconds_bucket{le="2"} 2
http_request_duration_seconds_bucket{le="3"} 3
http_request_duration_seconds_bucket{le="5"} 3
http_request_duration_seconds_bucket{le="+Inf"} 3
http_request_duration_seconds_sum 6
http_request_duration_seconds_count 3
```
---
## Les requêtes
---
## Types de données
-`scalar`_Un nombre à virgule flottante_
Exemple: `5.1`
-`instant vector`_Un ensemble de séries temporelles contenant un seul échantillon pour chaque série temporelle, toutes partageant le même horodatage._
Exemple: `http_request_duration_seconds`
-`range vector`_Un ensemble de séries temporelles contenant une gamme de points de données au fil du temps pour chaque série temporelle._
_[Voir la documentation du projet](https://prometheus.io/docs/prometheus/latest/querying/operators/)_
---
## Fonctions
### Quelques exemples
-`rate(range vector)` Retourne la fréquence moyenne d'augmentation par seconde de la série temporelle dans l'espace de temps donné. À utiliser uniquement avec les compteurs.
-`time()` Retourne le nombre de secondes depuis l'Epoch Unix.
-`increase(range vector)` Retourne l'augmentation de la série temporelle dans l'interval de temps donné. À utiliser uniquement avec les compteurs.
Et aussi [histogram_quantile()](https://prometheus.io/docs/prometheus/latest/querying/functions/#histogram_quantile), [predict_linear()](https://prometheus.io/docs/prometheus/latest/querying/functions/#predict_linear()),...
_[Voir la documentation du projet](https://prometheus.io/docs/prometheus/latest/querying/functions/)_
Prédire le remplissage d'un disque sur une machine de l'infrastructure.
### Consignes
1. Sur une des machines virtuelles de la zone "Intranet", installer l'exporteur de métriques [`Node Exporter`](https://github.com/prometheus/node_exporter/) et créer un nouveau service [`systemd`](https://doc.ubuntu-fr.org/creer_un_service_avec_systemd) pour celui ci.
2. Mettre en place une règle d'alerte sur votre instance Prometheus afin de prévenir le remplissage du disque de votre serveur via la fonction [`predict_linear()`](https://prometheus.io/docs/prometheus/latest/querying/functions/#predict_linear())
- [Modifier et créer des fichiers Unit pour systemd - Documentation Red Hat](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/sect-managing_services_with_systemd-unit_files)
Configurer l'application Wordpress pour qu'elle soient utilisable en HTTPS
### Consignes
1. Générer un certificat autosigné
2. Configurer le service Apache2 sur la machine `extranet-wordpress` afin qu'elle écoute sur le port 443 (HTTPS) et que le serveur utilise votre certificat
3. Mettre en place une redirection pour que les utilisateurs soient redirigés automatiquement vers l'adresse en HTTPS