Différences entre versions de « Transparent firewall »
Ligne 36 : | Ligne 36 : | ||
Notre bridge est donc accessible à l'adresse ''10.0.0.20'' et nos serveurs le seront aux adresses 10.0.0.21, 10.0.0.22, ... | Notre bridge est donc accessible à l'adresse ''10.0.0.20'' et nos serveurs le seront aux adresses 10.0.0.21, 10.0.0.22, ... | ||
− | De la sorte, il n'y a aucune translation d'adresse, ce qui peut être intéressant pour | + | De la sorte, il n'y a aucune translation d'adresse, ce qui peut être intéressant pour certains protocoles (eg. IPSec, AH, ...) et on peut également filtrer les accès à ces machines sans appliquer aucune ligne de commande sur ces dernières. |
− | |||
= Embrayes Iptables ! = | = Embrayes Iptables ! = |
Version du 10 mars 2014 à 18:12
Introduction
Le proxy transparent permet de mettre en pratique la stratégie par goulet d’étranglement abordée dans le cours sur les implémentations concrètes de la sécurité.
L'objectif est de constituer un point de passage obligatoire pour tout le trafic, ce qui peut, par exemple, être intéressant pour filtrer le trafic d'une DMZ publique, construire des statistiques sur le trafic sur un LAN, etc...
Pré-requis
Je vous laisse mettre en place la machine grâce au TP sur les bridges
Configuration réseau
Les machines sont sur le LAN 10.0.0.0/16 et le bridge est configuré comme suit:
# ip a sh 1: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether de:b4:49:a5:3a:07 brd ff:ff:ff:ff:ff:ff inet6 fe80::dcb4:49ff:fea5:3a07/64 scope link valid_lft forever preferred_lft forever 2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 2e:f9:02:e5:f2:5c brd ff:ff:ff:ff:ff:ff inet6 fe80::2cf9:2ff:fee5:f25c/64 scope link valid_lft forever preferred_lft forever 3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether 2e:f9:02:e5:f2:5c brd ff:ff:ff:ff:ff:ff inet 10.0.0.20/16 brd 10.0.255.255 scope global br0 inet6 fe80::2cf9:2ff:fee5:f25c/64 scope link valid_lft forever preferred_lft forever
Notre bridge est donc accessible à l'adresse 10.0.0.20 et nos serveurs le seront aux adresses 10.0.0.21, 10.0.0.22, ...
De la sorte, il n'y a aucune translation d'adresse, ce qui peut être intéressant pour certains protocoles (eg. IPSec, AH, ...) et on peut également filtrer les accès à ces machines sans appliquer aucune ligne de commande sur ces dernières.
Embrayes Iptables !
Les puristes diront tout de suite: impossible d'activer Iptables (IP → niveau 3 OSI) sur un bridge (MAC → niveau 2 OSI)...
Eh ben si !
Comme tout paramètre en relation avec le noyau, éditons le fichier /etc/sysctl.conf et passons le paramètre net.bridge.bridge-nf-call-iptables de 0 à 1
# vi /etc/sysctl.conf ... # Disable netfilter on bridges. net.bridge.bridge-nf-call-ip6tables = 0 net.bridge.bridge-nf-call-iptables = 1 net.bridge.bridge-nf-call-arptables = 0 ...
On n’oublie pas de recharger les paramètres du noyau
# sysctl -p
C'est fini !! Enfin presque, il ne reste plus qu'à configurer les règles de filtrage dans la chaine FORWARD
On peut s'en rendre compte grâce au compteur de la chaîne FORWARD qui ne fait qu'augmenter:
# iptables -nvL FORWARD Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 5 215 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Exemple de configuration
On va configurer le pare-feu pour que le serveur de mails ainsi que le serveur web puisse avoir accès à Internet (pour les mises à jour) et que les clients puissent les joindres
Mise en place
Tout d'abord on va autoriser tout le trafic initié depuis l'intérieur (par les deux serveurs)
-A FORWARD -m state --state RELATED,ESTABLISHED -o br0 -j ACCEPT
On va accepter tous les paquets DHCP
-A FORWARD -i br0 -p udp --dport 67 -j ACCEPT -A FORWARD -i br0 -p udp --dport 68 -j ACCEPT
On va maintenant autoriser les requêtes DNS
-A FORWARD -i br0 -p udp --dport 53 -j ACCEPT
On va autoriser le trafic SMTP et HTTP
-A FORWARD -i br0 -p tcp --dport 25 -j ACCEPT -A FORWARD -i br0 -p tcp --dport 80 -j ACCEPT
De manière optionnel on peut autoriser le PING
-A FORWARD -i br0 -p icmp -j ACCEPT
Enfin on DROP tout le reste !
-A FORWARD -j DROP
Test
Tout d'abord, on va lancer la commande suivante qui va afficher les compteurs de la chaîne FORWARD toutes les secondes
# watch -n 1 'iptables -nvL FORWARD'
Et si vous faites une requête HTTP on voit bien le compteur de la ligne -A FORWARD -i br0 -p tcp --dport 80 -j ACCEPT s'incrémenter.
Une fois que la connexion TCP est établie (3 échanges) on passe par la ligne -A FORWARD -m state --state RELATED,ESTABLISHED -o br0 -j ACCEPT
Every 1,0s: iptables -nvL FORWARD Tue Feb 18 08:03:21 2014 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 4 224 ACCEPT all -- * br0 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT udp -- br0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:67 0 0 ACCEPT udp -- br0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:68 0 0 ACCEPT udp -- br0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 1 60 ACCEPT tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT icmp -- br0 * 0.0.0.0/0 0.0.0.0/0 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Si on récapitule:
Index | Paquet | Sens de ciculation | Règle Iptables |
---|---|---|---|
1 | SYN | Client → Serveur | -A FORWARD -i br0 -p tcp --dport 80 -j ACCEPT |
2 | SYN+ACK | Client ← Serveur | -A FORWARD -m state --state RELATED,ESTABLISHED -o br0 -j ACCEPT |
3 | ACK | Client → Serveur | -A FORWARD -m state --state RELATED,ESTABLISHED -o br0 -j ACCEPT |
4 | GET / | Client → Serveur | -A FORWARD -m state --state RELATED,ESTABLISHED -o br0 -j ACCEPT |
5 | CONTENU | Client ← Serveur | -A FORWARD -m state --state RELATED,ESTABLISHED -o br0 -j ACCEPT |
On a bien 5 paquets, le compte y est !