pare-feu iptables + visibilité du client NAT


0

Le contexte

J'ai deux réseaux, de confiance: 10.0.1.0/24 et non fiable: 10.0.2.0/24, avec une jolie configuration standard qui fait ce qui suit:

  • NAT / masq
  • les invités des deux réseaux peuvent se connecter à Internet
  • les invités des deux réseaux peuvent se connecter aux services (dns, dhcp) du pare-feu

Actuellement, tous les invités des deux réseaux peuvent voir les autres invités sur leur propre réseau.

Problème

Quelle règle peut empêcher les clients du réseau non approuvé de se voir ou les clients du réseau approuvé?

Par exemple, 0.0.2.12 ne devrait pas voir 10.0.2.13 ou 10.0.1.11.

Les clients du réseau approuvé doivent se voir et se voir les clients non approuvés (cela fonctionne maintenant).


Il est facile d'empêcher les clients non approuvés de voir des clients approuvés (moins facile si vous avez toujours besoin de clients fiables pour voir des clients non approuvés). Ce qui n’est pas facile, c’est que les clients non fiables ne se voient pas. Cela s'appelle PVLAN et ce n'est pas résolu au niveau 3 (IP) mais au niveau 2. iptables travaillant sur le niveau 3, la solution ne peut pas être faite avec iptables seul. informations ici: en.wikipedia.org/wiki/Private_VLAN . Ne laissez pas le "VLAN" vous induire en erreur en lui faisant croire que ce n’est pas pertinent. C'est toujours le concept, et vous pourriez avoir besoin d'utiliser des ponts, des VLAN, d'autres outils comme ebtables et / ou arptables
AB

@AB Faites-en une réponse et je l'accepterai :)
Wilbert le

Fera ensuite (avec réponse pour les 2 premières "questions")
AB

Réponses:


1

Vous avez trois questions en une. Étant donné que je n'ai pas la configuration complète, je donne des commandes simples qui peuvent fonctionner ou qui doivent éventuellement être adaptées à votre configuration.

  • Comment empêcher l'accès au réseau local sécurisé d'un réseau local non approuvé?

    iptables -A FORWARD -s  10.0.2.0/24 -d 10.0.1.0/24 -j DROP
    

Auto-explicatif: les paquets de la source 10.0.2.0/24 ne peuvent jamais passer à 10.0.1.0/24.

  • Comment toujours autoriser l'accès à un réseau local non sécurisé à partir d'un réseau sécurisé?

    iptables -I FORWARD -s  10.0.2.0/24 -d 10.0.1.0/24 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
    iptables -I FORWARD 2 -s 10.0.1.0/24 -d 10.0.2.0/24 -j ACCEPT
    

Notez l'utilisation de -Ipour que ces commandes soient placées avant la commande dans la réponse à la première question et 2pour conserver l'ordre habituel. La deuxième commande n'est pas obligatoire, elle est là pour indiquer l'intention. Elle dépend de votre configuration, que vous en ayez besoin ou non. La première commande permet aux paquets de réponses de non fiables de revenir à sécurisés, en interrogeant la fonction conntrack de netfilter . Cela ne fonctionnerait entre les deux réseaux locaux que pour les connexions déjà établies de confiance à non fiable. Habituellement, cette première commande est écrite globalement une fois (sans l’utiliser -sni la -dlimiter à ces deux réseaux locaux).

  • Comment empêcher l'accès des hôtes non approuvés à partir d'autres hôtes non approuvés du même réseau local?

Alors que les deux premières questions peuvent être traitées avec un routeur, en travaillant à la couche 3: IP, la dernière question ne peut pas être résolue aussi facilement: les hôtes ne sont pas routés (c'est-à-dire à la couche 3) entre eux dans leur réseau local, ils partagent une couche 2 équipements tels qu'un interrupteur et les outils travaillant à ce niveau doivent être utilisés. iptablestravailler à la couche 3 ne peut pas être utilisé seul. L'implémentation d'isolation correspondante est appelée VLAN privé . Cette fonctionnalité est généralement implémentée directement sur les équipements du réseau.

Si la même chose était faite sur un serveur Linux standard, il faudrait un grand nombre d'interfaces réseau pour fonctionner comme un commutateur (la gestion de l'environnement virtuel facilite la tâche car l'ajout des interfaces est libre). Le pare-feu au niveau 2 pour cela est fait en utilisant ebtables. Voici quelques questions / réponses sur ce sujet: https://unix.stackexchange.com/questions/12026/private-vlans-under-linux https://serverfault.com/questions/388544/is-it-possible-to -enable-port-isolation-on-linux-bridge

Si le serveur Linux a un nombre limité de ports, donc ne pas agir lui - même comme le commutateur, il faudrait un moyen de recevoir tout le trafic du réseau local non sécurisé et ont une étiquette sur chaque paquet pour identifier sa source, ce qui nécessite probablement un nombre anormalement élevé des VLAN et de toute façon une configuration spécifique sur les équipements réseau.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.