Firewall ResEl 3
Tâches
- Création d'un environnement de test
- Création d'une plateforme de script avec interface web, pour faciliter le suivi et la configuration
- Passage à nftables
- Création d'une abstraction pour la définition des règles et leur administration
- Vérification de l'utilité des règles en place (certaines étant historiques)
- Refactoring en profondeur du firewall v2 et de son architecture : mise en place de modules indépendant pour les modules annexes
Lot 1 : Création d'un environnement de test
L'objectif est de créer un environnement vagrant pour réaliser des tests en intégration continue sur le firewall. Les tests peuvent dès à présent être menés sur le firewall v2 (reselqos), l'ensemble des fonctionnalités à tester étant similaire à la v3.
Tests:
- Accès internet/coupure en zone user en fonction du statut (inscription, paiement, banni)
- Scan des ports ouverts à l'extérieur en comparaison à la liste de pat en place
- Tests des pat vers les différentes machines
- Vérification de la zone inscription et de la redirection vers resel.fr
- Tests tcp,udp,icmp dans les différentes conditions
- Tests de débits pour vérifier les shapes
- Tests d'attaques ?
Environnement: Utilisations de plusieurs machines vagrant pour simuler différents éléments réels:
- firewall
- bases de données : mysql & ldap
- machine admin : test de redirection... (même machine que celle des bases de données ?)
- utilisateur
Interfaces du fw de test et adressage :
- eth980 (co adista) - à choisir
- eth990 (co disi) - à choisir
- eth994 (vlan admin pub) - 172.22.42.1
- eth997 (vlan admin) - 172.22.2.36
- eth999 (vlan users) - 172.22.199.100
- tun0 (tunnel) - 172.22.151.1 (pas urgent) Les autres machines ont juste une interface connecté au fw et la gateway par défaut configurée vers le fw.
Routage : Par défaut, via eth980. Routage entre toutes les interfaces pour le reste.
Pb à réfléchir pour plus tard :
- tester la route vers l'école (10.29.0.0/16 via la gateway disi)
- à Rennes le 980 passe par une interco privée portée par peach, il faudrait prévoir de tester ça plus tard
- tester le tunnel
Réalisation des tests avec python unittest. A tester avec la version actuelle du fw. Mise en place incrémentale des tests (pas besoin de faire tout les tests d'un coup, déjà l'environnement et vérifier l'accès à internet c'est une première étape).
Lot 2 : Création d'une plateforme de script
Lot 3 : Passage à nftables
Debian Stretch (9) va être livré avec nftables, youhou \o/ Je vous laisse regarder tout ce que ça apporte en plus par rapport à iptables : En soit la syntaxe est plus simple, et c'est surtout plus rapide. Du coup il faudra utiliser ça pour la prochaine version (stretch devrait sortir bientôt), de plus ça reste très similaire à iptables donc on ne perd pas l'acquis de reselqos.
Lot 4 : Création d'une abstraction pour la définition des règles et leur administration
Politique de redondance
Double redondance (à Brest) :
- 2 machines pour faire s'occuper du fw et du routage
- 2 connections : adista & disi
Le fw se base sur 3 indicateurs pour déterminer d'un changement :
- connectivité interne, le fw vérifie s'il peut accéder à une liste de sites externe
- connectivité externe, une sonde vérifie si elle peut accéder à une liste de sites externe
- connectivité admin, le fw test s'il est coupé ou non du réseau, en pinguant d'autres noeuds (l'autres fw, les sondes, ...)
Le fw actif teste en permanence toutes les connections disponibles pour savoir s'il est utile de switcher.
Politiques
- Perte de connexion, signalée en interne :
- Si une autre connexion est disponible, on bascule dessus
Sinon si un autre fw est disponible, on bascule dessus
Perte de connexion, signalée par la sonde :
- Si la connexion actuelle est vue comme disponible, cela signifie que le problème ne vient pas de la co mais du fw. Si un autre fw est disponible, on bascule alors dessus
Sinon si une autre connexion est disponible, on bascule dessus
Perte de connexion admin : Le fw est vu comme "coupé" du réseau, il va alors se désactiver (i.e. retirer les ips partagées) et attendre d'être reconnecté. L'idéal serait donc de tester sur plusieurs interfaces. Si cette perte survient suite à une mise à jour du git ou de la conf on pourrait imaginer faire un rollback à la précédente version.