Le principe d’un Datacenter est d’exposer et d’isoler des services. L’exposition d’un service, par exemple une base de données, permet de le rendre accessible d’un ou plusieurs utilisateurs visés.
En partant de ce principe, vous disposez de deux méthodes :
- exposer tous les services et filtrer selon la source
- ou bien isoler tous les services et “ouvrir” le nécessaire.
La plus simple est d’isoler tous les SERVEURS du Datacenter, de facto, les services proposés par ces serveurs le seront aussi.
“J’interdis tout et n’autorise que ce qu’on me demande…”
Pour permettre l’isolation des serveurs situés à l’intérieur du Datacenter, nous allons nous appuyer sur les technologies de réseaux.
Tous les serveurs du Datacenter seront situés sur un ou plusieurs réseaux privés.
Les communications d’un réseau privé ne sont pas “transportables” sur le réseau internet (réseau public) et des réseaux différents ne peuvent communiquer, naturellement, entre eux.
Un réseau est défini par son adresse et son masque. Il existe deux type d’adressage : IPV4 et IPV6 (pour comprendre lisez le contenu du lien relatif au réseau public - pénurie d’adresses IPV4).
Cet article n’aborde que la partie IPV4.
Le masque de réseau ou plus familièrement sous-réseau se note de ces deux manières :
- notation clasique : 255.255.255.2555
- notation courte ou CIDR : /24
Pour isoler un serveur ou un groupe de serveurs, il suffit de leur affecter un réseau différent de ceux déjà en place dans l’organisation.
Si il n’existe aucun appareil permettant l’accès à ce réseau, le réseau est isolé, seules les machines appartenant un même réseau peuvent communiquer entre elles sur un réseau IP. Cette isolation va se faire par rapport au plan d’adressage.
NB : Concernant les réseaux utilisés localement dans votre organisation, utilisez toujours des réseaux privés
Et bien entendu, les réseaux vont pouvoir communiquer entre eux, au moyens de routeurs.
Le routeur principal du Datacenter
Les fournisseurs d’accès (FAI) proposent généralement du matériel (Livebox pour Orange, freebox pour free, etc…) paramétrés pour fournir les réseaux 192.168.0.0/24 ou 192.168.1.0/24. Etant donné le nombre de matériels sur le marché, je vous invite à lire la documentation de l’appareil connecté à internet et proposé par votre fournisseur d’accès, qui est également un routeur, c’est à dire un pont entre votre réseau local et le réseau internet. Vous n’aurez généralement pas besoin d’avoir accès à son paramétrage.
Le prédicat est toujours d’isoler l’ensemble du Datacenter de notre réseau principal et bien entendu de lui laisser une porte d’entrée (routeur principal) afin d’avoir accès à ses services et que les serveurs de cette zone puissent atteindre l’internet :
Dans le cas de cet exemple, l’unique moyen pour atteindre le serveur situé dans le Datacenter sera de passer par le routeur principal du Datacenter. Ce routeur sera un serveur situé dans le Datacenter et doté de deux interfaces réseaux.
Quand je parle d’interface réseau, il s’agit généralement d’une carte réseau. Généralement, car une carte réseau (matériel) peut supporter plusieurs interfaces réseaux. Il est tout à fait possible de paramétrer plusieurs adresses IP, de réseaux différents ou non, sur une seule carte réseau. Ceci est valable quand le trafic est modéré et pour réduire la facture matériel.
S’agissant des unités que nous utilisons, RaspberryPi ou Rock64, elles ne disposent que d’une seule carte réseau, j’ai donc ajouté une carte réseau USB. Il en existe plusieurs modèles, vous prenez celle qui vous convient le mieux.
Préparation du routeur principal
Pré-requis
- 1 RaspberryPi ou Rock64. Avant la version 4, les RaspberryPi disposent d’une carte réseau 100 Mbits/sec, alors que la version 4 propose une interface 1000 Mbits/sec (gigabits).
- 1 switch pour le Datacenter, tous les serveurs y seront connectés, je préconise directement l’achat d’un switch 1000Mbits/sec, pas tellement plus cher et en accord avec les nouvelles versions de RaspberryPi
- 1 carte réseau USB 1000Mbits/sec
- câbles réseaux de catégorie 5e ou 6
Installation
Commençons par installer le système d’exploitation (suivre la procédure concernant l’installation des systèmes d’exploitation). Connecter la carte réseau USB sur ce serveur en la reliant à votre box FAI, et la carte réseau de l’unité sur le switch du Datacenter. Nous disposons maintenant d’une “porte” entre les deux “mondes”, fermée pour l’instant.
Paramétrages des cartes réseaux.
On a vu que l’appareil proposé par votre fournisseur d’accès, dispose d’un réseau de type privé. Ce réseau est paramétré automatiquement, c’est à dire, quand un appareil est connecté sur ce réseau, la box va fournir une adresse IP à ce matériel et pourra par conséquent communiquer avec tous les appareils de ce même réseau et aussi vers le “réseau Internet”.
Carte Réseau USB
Le serveur est allumé, la carte réseau USB n’est pas connectée, pour découvrir le nom des interfaces, ouvrir une console sur ce serveur, et tapez :
ip link
1: lo: <LOOPBACK,UP,LOWER_UP> [...]
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> [...]
Nous voyons, deux interfaces, la loopback (lo), l’interface réseau du serveur.
Connectez la carte réseau USB au serveur, le noyau va découvrir une nouvelle interface et l’instancier, exécutez de nouveau la commande précédente :
ip link
# réponse :
1: lo: <LOOPBACK,UP,LOWER_UP> [...]
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> [...]
3: eth1: [...]
L’interface réseau USB a été détectée, et porte, dans mon cas, le nom “eth1”.
Adapter la valeur “eth1” à votre configuration (ex: ens1p3,etc…)
Modifiez le fichier : “/etc/network/interfaces” en ajoutant les paramétres de configuration IP pour cette nouvelle interface :
# Au début du fichier insérer :
auto eth1
allow-hotplug eth1
iface eth1 inet dhcp
Enregistrer, puis exécuter : ifdown eth1;ifup eth1
Pour découvrir l’adresse IP fournie par votre “box” à cette interface :
ip addr eth1
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether xxxxxxx brd ff:ff:ff:ff:ff:ff
inet 192.168.0.56/24 brd 192.168.0.255 scope global eth1
La valeur située après “inet” est l’adresse IP affectée à cette interface.
Carte Réseau Unité
L’adresse Ip de la carte interne réseau du serveur disposera d’une adresse IP situé sur un réseau différent de celui de l’interface USB (isolation). Vous allez donc déterminer le réseau que vous souhaitez mettre en place :
- taille adapté au nombre de serveurs prévus dans votre infrasctructure
- et bien ententu privé : 10.0.0.0/8 ou 172.16.0.0/12 ou 192.168.0.0/16
Les box internet utilisent souvent les réseaux 192.168.0.0/24 ou 192.168.1.0/24. Prenons par exemple le réseau 10.0.1.0/24 qui est un réseau privé pouvant supporter 255 appareils, de 1 à 254, la dernière adresse “255” est réservée pour le broadcast.
Pour vous aider : Taille des réseaux.
Par contre, dans ce cas précis, je vais attribuer une adresse IP fixe à ce serveur. Ce “nouveau” réseau ne dipose pas de système permettant de distribuer dynamiquement des adresses aux serveurs qui s’y connecte (notion de DHCP). Et généralement comme ce serveur est un routeur, on lui attribue l’adresse précédent celle du broadcast : 10.0.1.254 (dans notre exemple).
Adapter la valeur “eth0” à votre configuration (ex: ens0p3,etc…)
Modifiez le fichier : “/etc/network/interfaces” en ajoutant les paramétres de configuration IP pour cette nouvelle interface :
auto eth0
allow-hotplug eth0
iface eth0 inet static
address 10.0.1.254
netmask 255.255.255.0
**netmask : notre exemple indique le réseau 10.0.1.0/24 - /24 est le CIDR de 255.255.255.0
Enregistrer, puis exécuter : ifdown eth0;ifup eth0
Vérifiez que l’adresse IP est bien attribuée à votre interface réseau :
ip addr eth0
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether xxxxxxx brd ff:ff:ff:ff:ff:ff
inet 10.0.1.254/24 brd 10.0.1.255 scope global eth1
La valeur située après “inet” est l’adresse IP affectée à cette interface.
Nous obtenons ceci :
Activation du routage (avec iptables)
Sans rentre dans le détail, je n’utilise pas de routage dynamique (RIP) mais un firewall qui sert de passerelle (gateway) entre les deux réseaux. Le routage des paquets d’un réseau à l’autre se fera au travers de l’application “iptables”.
Toujours avec l’exemple de notre serveur de base de données situé dans le Datacenter sur le serveur “Databases”, l’utilisatrice “Alice” souhaite atteindre le port de service de cette application. Ce service est disponible sur le port (appelé communément service) : “5432”
Vous entendez souvent : “j’ai ouvert le port…”, mais c’est quoi ouvrir un port ? C’est ouvrir l’accès à un service. Pour être joignable, un service situé sur un réseau IP, utilise la notion de port. C’est à dire un point d’entrée sur le réseau du serveur, son adresse IP/masque/port. Le serveur dispose d’un adresse IP sur le réseau, et susceptible d’exposer 216 soit 65536 ports. Certains numéros de ports sont normalisés. Si vous créez une application utilisant le réseau IP, évitez ainsi d’utiliser un numéro de port communément attribués à certains services, comme le port 5432 utilisé par Posgresql (ports standards).
Notre routeur va, par conséquent, devenir un relais de service. En plus d’être relai, “iptables” permet aussi de filtrer les communications, notion de “Firewall”.
Pour joindre ce port 5432, Alice va donc passer par notre routeur. Le routeur va intercepter tous les paquets à destination de son port 5432 et les diriger vers le serveur de bases de données “10.0.0.10”. Ainsi Alice n’a pas connaissance du serveur final, elle sait qu’en envoyant une requête sur le port 5432 du routeur, elle obtiendra une réponse d’un serveur de base de données.
Activation du forward
La première opération à réaliser est d’autoriser le noyau à faire transiter les paquets entre les interfaces réseaux :
# De manière temporaire
echo 1 > /proc/sys/net/ipv4/ip_forward
# Si le serveur reboot, le forward ne sera pas activé au redémarrage
# Pour l'appliquer de manière définitive
sysctl -w net.ipv4.ip_forward=1
Pour vérifier que le forward est activé :
cat /proc/sys/net/ipv4/ip_forward
# doit renvoyer : 1
Translatioin d’adresse (NAT)
Vous trouverez la documentation officielle “iptables” ici.
Nous allons aborder la notion de translation d’adresse (NAT). Souvenez-vous, deux réseaux différents ne peuvent pas communiquer ensemble. Le processus NAT permet de corriger ce problème, en altérant les paquets en entrée par une modification de l’emetteur et remettre en place ces informations lors du retour.
- Alice envoie un paquet vers le port 5432 du routeur (à partir de son ip 192.168.0.24)
- Le routeur sait qu’il doit le renvoyer vers le serveur Database 10.0.0.10
- Les adresses ne sont pas sur le même réseau, il l’envoie vers NAT
- NAT remplace l’adresse IP 192.168.0.24 par son adresse interne pouvant circuler sur le réseau du Datacenter 10.0.1.254
- Le serveur Database recoit le paquet, le traite et renvoi une réponse vers l’emetteur 10.0.1.254
- Le routeur recoit le paquet, l’envoi vers NAT
- NAT recherche dans sa table de correspondance si ce paquet est à adresser à un autre demandeur, il trouve la demande originale : 192.168.0.24
- Il altère le destinataire avec 192.168.0.24
- Le routeur envoie le paquet vers son destinataire 192.168.0.24
- Alice (192.168.0.24) recoit le paquet avec les données qui l’interresse
“Iptables” est un firewall qui sait inspecter l’état d’une connexioin (nouvelle, déjà établie, relatif à une connexion déjà établie), et ces notions doivent être prises en compte dans vos règles afin de limiter la surface d’attaque.
Nous sommes toujours dans le cas de l’accès d’Alice à une base de données sur les port de service 5432.
Je vais indiquer ici les bases de notre Routeur/Firewall. Charge à vous d’agrémenter selon vos besoins.
Pour continuer la suite de cet exercice, vous devez vous connecter “root” et installer le paquet “iptables-persistent”
apt update
apt install -y iptables-persistent
ATTENTION : A partir d’ici, vous allez manipuler le firewall du serveur, si vous commettez une erreur, ceci peut le rendre inaccessible du réseau. Par conséquent, je vous conseille de travailler directement sur le serveur et non par le réseau.
Créer le fichier “~/myrules” et ajouter
*raw
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
# NAT en sortie eth0 (10.0.1.254) - Cas ou un paquet provient de l'extérieur de son résau, l'extérieur est l'initiateur de la connexion
-A POSTROUTING -o eth0 -j MASQUERADE
# NAT en sorit eth1 (192.168.0.56) - Cas ou un serveur du Datacenter sort de son réseau, il est l'initiateur de la connexion
-A POSTROUTING -o eth1 -j MASQUERADE
COMMIT
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
:LOGGING - [0:0]
# refuse tout
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP
## Autorise le forward du port 5432 de eth1 vers eth0
-A FORWARD -i eth1 -o eth0 -p tcp -m tcp --dport 5432 -j ACCEPT
## Autorise le retour de communication de eth0 vers eth1 - state est limité, veut dire que eth0 peut répondre à une communication déjà établie
## par l'extérieur mais l'intérieur ne peut pas initier de communication vers l'extérieur. Ceci est très important. Dans le cas d'un serveur compromis
## à l'intérieur du Datacenter, ceci permet de limiter ses moyens de communication avec l'extérieur.
-A FORWARD -o eth0 -i eth1 -p tcp -m tcp --sport 5432 -m state --state RELATED,ESTABLISHED -j ACCEPT
Ajouter ces quelques règles supplémentaires
- Autoriser toutes les communications sur le loopback
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
- Pour pouvoir se connecter au firewall depuis l’extérieur, nous pouvons ouvrir le port 22 :
## Autorise les clients ssh a se connecter sur le firewall par son interface USB
-A INPUT -i eth1 -p tcp -m tcp --dport 22 -j ACCEPT
## Autorise le retour de communication vers eth1
-A OUTPUT -o eth1 -p tcp -m tcp --sport 22 -m state --state RELATED,ESTABLISHED -j ACCEPT
et/ou installer un service VPN, qui n’exposera par conséquent pas le port 22. La connexion au firewall s’opérera toujours pas ssh mais à travers un tunnel VPN. L’installation d’un VPN fait l’objet d’un autre chapitre, et il s’agit du moyen le plus sûr de se connecter à votre Firewall.
- Autoriser les serveurs du Datacenter à sortir sur le port 443 : La plupart des serveurs du Datacenter n’ont pas besoin de d’initier des communications avec l’extérieur (à leur initiative), sauf dans les cas de mise à jour et d’installation de paquets. Par conséquent, les serveurs vont devoir, eux aussi, utiliser la gateway (firewall) pour communiquer avec l’extérieur.
Pour les autoriser, ajouter ces règles au fichier précédemment créé :
## Autorise le forward du port 443 de eth0 vers eth1
-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 443 -j ACCEPT
## Autorise le retour de communication de eth1 vers eth0
-A FORWARD -o eth1 -i eth0 -p tcp -m tcp --sport 443 -m state --state RELATED,ESTABLISHED -j ACCEPT
Cependant, notez que ce type d’ouverture est déconseillé, si l’un de vos serveurs est compromis, il pourra initier une connexion sur le port 443 d’un hôte distant et communiquer avec celui-ci.
Dans la pratique, on installe un serveur miroir (apt-mirror), seul autorisé a communiquer avec les repository extérieurs Debian. Les serveurs du Datacenter se connecteront à ce miroir pour obtenir leurs mises à jour.
- Vous devrez aussi autoriser les communications vers les DNS
## Autorise le forward du port 53/TCP de eth0 vers eth1
-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 53 -j ACCEPT
## Autorise le retour de communication de eth1 vers eth0
-A FORWARD -o eth1 -i eth0 -p tcp -m tcp --sport 53 -m state --state RELATED,ESTABLISHED -j ACCEPT
## Autorise le forward du port 53/UDP de eth0 vers eth1
-A FORWARD -i eth0 -o eth1 -p udp -m udp --dport 53 -j ACCEPT
## Autorise le retour de communication de eth1 vers eth0
-A FORWARD -o eth1 -i eth0 -p udp -m udp --sport 53 -m state --state RELATED,ESTABLISHED -j ACCEPT
TERMINER le fichier par :
COMMIT
Avec ces quelques règles de départ, les serveurs du Datacenter peuvent être mis à jour : apt-get update;apt-get upgrade.
Persistence (après reboot) et application des règles
si le résultat est concluant, vous pouvez rendre ces règles persitentes, c’est à dire : appliquées au reboot du serveur en copiant le fichier ~/myrules vers “/etc/iptables/rules.v4”
cp ~/myrules /etc/iptables/rules.v4
Pour appliquer les règles
iptables-restore < /etc/iptables/rules.v4
La pratique régulière “d’iptables” est le seul moyen de vraiment comprendre son fonctionnement. Il est important de maîtriser cet outil pour bien protéger votre Datacenter.
Vous pouvez aussi manipuler ces chaînes directement avec la commande : iptables, vous pourrez consulter ce site interressants.
Il existe plusieurs outils qui vous permettront de gérer toutes ces règles comme ufw,…
ATTENTION : Si vous constatez des anomalies dans cet article, je vous invite à me les communiquer.