Le but de cette section est de mettre en place le routage avant de passer aux fonctions de filtrage réseau proprement dites. Elle correspond à la vue Topologie PPP et routage.
Voici une liste de fonctions de protection à mettre en œuvre sur tous les types de routeurs.
- Protection contre l'usurpation des adresses sources, rpfilter, BCP38
-
Ces fonctions de protection comprennent une partie noyau ainsi qu'une partie filtrage avec le module
rpfilterà implanter dans la tablerawqui assure un filtrage sans état. Voir Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing.Les tests de validation de ces mécanismes peuvent se faire à l'aide de la commande hping3. Les résultats doivent être visibles aussi bien dans les journaux systèmes que sur les compteurs des règles de la table
raw. En avant pour la chasse aux martiens ! - Protection contre les dénis de services
ICMP, module
netfilterlimit -
Les routeurs doivent s'assurer que le volume de trafic qui est présenté en entrée est compatible avec un fonctionnement nominal des services.
- Protection contre les robots de connexion au service SSH, fail2ban
-
Les routeurs ont besoin d'un accès d'administration à distance via SSH. Pour autant, cet accès doit être protégé contre les tentatives d'intrusion par dictionnaire de couples d'authentifiants.
L'outil fail2ban fourni avec le paquet du même nom introduit une chaîne de filtrage dédiée à ces tentatives d'intrusion.
|
Q7. |
Comment afficher la liste des règles de
filtrage de la table Rechercher dans les pages de manuels de la commande iptables les options relatives aux listes et aux compteurs. La visualisation des compteurs de correspondance des règles de filtrage est indispensable pour qualifier le fonctionnement du filtrage |
|
C'est l'option C'est l'option Voici un exemple dans le contexte de la maquette sur le routeur
Spoke1Vert. Une règle a déjà été insérée
dans la table |
|
|
Q8. |
Comment activer la protection contre l'usurpation des adresses sources au niveau du noyau ? Rechercher les informations relatives à la fonction Reverse Path Forwarding du noyau Linux. Identifier les rôles des 3 valeurs possibles de cette fonction. La documentation est à cette adresse : Kernel IP sysctl. |
|
Le fichier de configuration principal Voici la liste des valeurs actives au moment de l'exécution de la commande. Voici l'extrait de la documentation officielle qui donne les
explications sur les 3 valeurs possibles du paramètre rp_filter - INTEGER
0 - No source validation.
1 - Strict mode as defined in RFC3704 Strict Reverse Path
Each incoming packet is tested against the FIB and if the interface
is not the best reverse path the packet check will fail.
By default failed packets are discarded.
2 - Loose mode as defined in RFC3704 Loose Reverse Path
Each incoming packet's source address is also tested against the FIB
and if the source address is not reachable via any interface
the packet check will fail.
Current recommended practice in RFC3704 is to enable strict mode
to prevent IP spoofing from DDos attacks. If using asymmetric routing
or other complicated routing, then loose mode is recommended.
The max value from conf/{all,interface}/rp_filter is used
when doing source validation on the {interface}.
Default value is 0. Note that some distributions enable it
in startup scripts. |
|
|
Q9. |
Comment enregistrer les tentatives d'usurpation d'adresses dans les journaux système ? Rechercher les entrées de l'arborescence Rechercher aussi le paramètre relatifs aux “martiens“ dans le
fichier |
|
On a activé la “journalisation des martiens“ en éditant le
fichier On vérifie que le paramètre est bien actif sur le système. Si ce n'est pas le cas, il ne faut pas oublier de parcourir à nouveau les fichiers de paramètres à l'aide de la commande sysctl. |
|
|
Q10. |
Comment valider la fonction de blocage des tentatives d'usurpation d'adresses entre le routeur Hub et les routeurs Spoke ? Installer le paquet Rechercher dans les pages de manuels de la commande hping3 les options qui permettent de générer du trafic ICMP avec des adresses source aléatoires à destination d'un conteneur hébergé sur un routeur Spoke. |
|
Voici un premier exemple de test effectué sur le routeur Hub dans le contexte de la maquette. L'option Côté routeur Spoke, on peut consulter les traces des tentatives d'usurpation d'adresses à l'aide de la commande suivante. Il est aussi possible de lancer un test avec une série d'adresses IP source aléatoires. Voici un exemple de commande qui provoquera un nombre de blocages aléatoire en fonction des correspondances. |
|
|
Q11. |
Comment filtrer les tentatives d'usurpation d'adresses source au plus tôt de façon à limiter le coût de traitement de ces paquets falsifiés sur le système ? Identifier le nom de la table de filtrage sans état et
rechercher la fonction associée au filtrage des adresses sources
usurpées. Rechercher dans les pages de manuels Ajouter une règle spécifique dans la table de traitement sans état pour les protocoles IPv4 et IPv6. |
|
La table de filtrage sans état est appelée :
On peut ensuite sauvegarder ces règles dans les fichiers
systèmes utilisés par le service
|
|
|
Q12. |
Comment caractériser les nouvelles règles de filtrage entre le routeur Hub et les routeurs Spoke ? Pour les tests IPv4, il suffit de reprendre les mêmes tests que ceux effectués plus haut avec la commande hping3. Installer le paquet Rechercher dans les pages de manuels de la commande atk6-thcping6 les options qui permettent de générer du trafic ICMP avec une adresse source falsifiée à destination d'un conteneur hébergé sur un routeur Spoke. |
|
Dans le contexte de la maquette, les requêtes falsifiées sont émises depuis le routeur HubBleu à destination du routeur Spoke1Vert sur lequel les règles de filtrage IPv4 et IPv6 ont été implantées.
|
|
Q13. |
Comment peut-on se protéger contre un nombre de sollicitations ICMP trop important ? Rechercher dans le guide Tutoriel iptables la correspondance Limit qui permet de définir un seuil au delà duquel les nouveaux flux réseau ne sont plus acceptés. Il faut ajouter une règle spécifique au protocole ICMP après celle qui assure le traitement des flux déjà enregistrés dans les tables de suivi d'état (Stateful). |
|
Dans le contexte de la maquette, les nouvelles règles de filtrage sont appliquées sur le routeur Spoke2Vert et le trafic “malveillant“ est généré sur le routeur HubBleu à destination des conteneurs du réseau local du site distant. On commence par afficher la liste des règles de la table par
défaut appelée netfilter de façon à
vérifier si la règle générale de suivi des enregistrements est
présente ou non dans les chaînes Dans la copie d'écran ci-dessous, on constate qu'aucune règle de filtrage n'a été appliquée au moment du test. Le résultat de la commande On ajoute les deux règles générales de suivi des conversations
en premier dans les chaînes
On ajoute aussi deux règles identiques pour le protocole IPv6.
Maintenant que le trafic relatif ou appartenant à un flux
enregistré dans la table de suivi d'état est accepté, nous pouvons
définir les conditions dans lesquelles un nouveau flux entre de le
système de suivi d'état. Ici, on s'intéresse au protocole
ICMP et au module Limit. Voici un exemple de règle qui restreint le
trafic ICMP à 2 nouvelles
entrées par seconde sur les chaînes
|
|
|
Q14. |
Comment qualifier le fonctionnement des règles de limitation du nombre de nouvelles requêtes ICMP ? Rechercher les options de la commande hping3 qui permettent de générer des flux ICMP en utilisant des adresses IPv4 source aléatoires. Attention ! Il faut positionner la politique par défaut en mode "tout ce qui n'est pas autorisé est interdit“ sur le routeur cible le temps du test de qualification. |
|
On rappelle que dans le contexte de la maquette, les règles de filtrage sont appliquées sur le routeur Spoke2Vert et le trafic “malveillant“ est généré sur le routeur HubBleu à destination des conteneurs du réseau local du site distant.
|