Outils pour utilisateurs

Outils du site


sisr5:iptablestp

Firewalling à base d'iptables

Pour partir sur le bon... pied !

La virtualisation peut conduire à des résultats différents de la correction qui sera proposée ! Si vous avez besoin de machines virtuelles de type “Container-LXC”, n'hésitez pas à en créer !
L'objectif de ce TP n'est pas de construire un firewall mais de vous mettre à l'aise avec la syntaxe quelque peu difficile à digérer… au début ! 8-)

Sauf spécification contraire, les questions sont INDEPENDANTES !

En fin de TP, vous construirez un pare-feu simple pour synthétiser vos connaissances !


Problème connu ! 8-)

Si un message de ce type s'affiche dans un container LXC

iptables v1.4.19.1: can't initialize iptables table `filter': Table does not exist (do you need to insmod?) Perhaps iptables or your kernel needs to ..

Alors… sur la machine hôte Debian, vous exécuterez une commande “iptables” de ce type :

root@netLXC2018:/home/btssio# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
root@netLXC2018:/home/btssio#

L'utilisation de “iptablesdans les containers LXC devrait alors être possible ! 8-)

L'auteur de ces lignes va chercher une rustine plus élégante ! :-(

Proposition de maquette pour expérimenter... "iptables"

C'est parti !

Se familiariser avec la syntaxe "iptables"

1 – activer la fonction de routage.

2 – Vérifier la présence de l'utilitaire iptables. L'installer le cas échéant.

3 – Lister les trois chaînes de la table filter. Notez les politiques de sécurité retenues.

4 – Mettre en place la politique ACCEPT sur la chaîne INPUT, la politique DROP sur la chaîne OUTPUT. Vérifiez.

5 – Faites un ping sur localhost. Que se passe-t-il ? Expliquez.

6 – Mettez la politique ACCEPT sur la chaîne OUTPUT. Faites un ping sur localhost. Que se passe-t-il ? Expliquez.

7 – Ajoutez une règle de filtrage qui interdit tout envoi de paquets vers localhost. Vérifiez. Détruisez la règle de filtrage.

8 – Ajoutez une règle de filtrage qui interdit tout envoi de paquets depuis localhost. Vérifiez. Détruisez la règle de filtrage.

9 – Reprenez les questions 7 et 8 mais en ne filtrant que les paquets protocolés icmp en spécifiant l'interface de sortie.

10 – Filtrer tous les paquets fragmentés protocolés icmp.

11 – Vérifier que vous êtes connecté à l'Internet. Filtrer et supprimer tous les paquets entrants sur votre machine par le protocole http port 80, netcat est votre ami !.

12 – Filtrer et supprimer tout ce qui sort par le protocole tcp et qui passe par l'un des ports 3128, 21 et 1000.

14 – Filtrer et accepter tout ce qui sort par le protocole tcp et qui passe par l'un des ports compris entre 1024 et 2042.

15 - « Droper » tous les paquets icmp type 8 (machine non connectée au réseau) sur la chaîne INPUT. Vérifiez.

16 – Interdire tout paquet en entrée ayant pour adresse MAC celle de la machine située à votre droite… (si elle existe ! sinon… il faut la créer… Vive netLXC !).

17 – Afficher l'ensemble des règles de toutes les chaînes avec le maximum d'informations possibles; les règles seront numérotées.

18 – Un peu de ménage : purger avec le moins de commandes possibles les chaînes de la table filter.

19 – Autoriser tout paquet qui entre par l'interface eth0 (ou autre interface bien déterminée), protocolé tcp et qui a pour port de destination le port http 80. Le paquet doit demander une nouvelle connexion ou être déjà associé à une connexion. Quel est l'intérêt de ce type de règle ?

20 – L'administrateur a parfois intérêt à garder la trace des paquets « dropés » dans un journal pour analyse ultérieure :

  • créer une nouvelle table nommée « DROP_LOG »
  • tout ce qui sera « droppé » sera « logué » dans la table DROP_LOG.

21 – Ajouter une règle qui accepte les paquets en transit et qui sont destinés au serveur de messagerie (port TCP 25) qui possède l'adresse 173.17.5.3

22 – Rejeter tous les paquets transitant par la machine.

23– Créer une chaîne utilisateur qui applique une même logique pour les paquets transitant ou destinés au parefeu : on accepte tous les paquets associés aux connexions existantes et on refuse les autres. Bien entendu, il faut évidemment ajouter au préalable des règles qui acceptent les connexions.

24 – Interdire les connexions venant du réseau 173.17.0.0/16 destiné au serveur Web. Renvoyer un message icmp en retour.

Construire un pare-feu

Construction d'un pare-feu complet sans masquerading :

Architecture réseau :

Il existe 2 réseaux reliés à notre parefeu :

  • le réseau extérieur est le réseau 173.17.0.0/16. On l'atteint par l'interface eth1 d'adresse 173.17.0.1
  • le réseau intérieur est le réseau 192.168.218.0/24. Il est relié au parefeu par l'interface eth0 d'adresse 192.168.218.11

Règles de sécurité :

  • tous les accès du réseau intérieur en tant que client Web sont autorisés.
  • Les demandes de connexion de l'extérieur sont refusées, sauf celles destinées au serveur 192.168.218.1 et seulement pour le service WEB.
  • Dans un premier temps, les messages ICMP sont autorisés à des fins de tests. Ils seront ultérieurement limités.
  • Dans un premier temps, la connexion au pare-feu via telnet est autorisé à partir du serveur Web interne.
  • Le reste est interdit.
sisr5/iptablestp.txt · Dernière modification: 2021/04/20 18:13 de lefou