Michel,
Je me demande si ton raisonnement n'est pas ici un poil naïf.
Tu pars du principe que dans un monde sans NAT, le pare-feu d'une box resterait
une passoire mais personne ne sait si ce serait vraiment le cas. A l'heure
actuelle, vu que le NAT permet une sécurité basique, effectivement, les box
opérateurs ont des pare-feu rudimentaires mais rien ne permets d'affirmer que
ça aurait été le cas sans NAT en fait.
Les FAI GP ne pouvant pas compter sur le NAT et ne souhaitant pas que leur
client soit à poil sur le net auraient peut-être tenter plus des choses niveau
sécurité. Je suis peut-être candide en penssant ça, je l'avoue mais ton
raisonnement me paraît un brin simplificateur.
7 févr. 2021, 08:15 de mic...@arneill-py.sacramento.ca.us:
>> Oliver Varenne a écrit :
>> Alors crier sur le NAT tout le temps, je conçois, mais ça n'est pas quelque
>> chose qui va faire avancer le schmilblick.
>>
>
> En plus, il y a des cas ou NAT, ça fait un peu pour la sécurité.
>
> Pour simplifier, prenons l'exemple répandu d'un site PME avec 1 IP publique.
> Généralement, ça serait plutôt 5 utilisables, mais 1 ça simplifie.
>
> Sur cette IP, il y a souvent un service ouvert vers l'extérieur : HTTPS
> (souvent plus, mais je simplifie aussi).
> La réalité, c'est que le "pare-feu" est souvent la machinbox du FAI, qui ne
> fait pas grand-chose à part la fonction "diode", et que "l'ingénieur réseau"
> a ouvert le port 443 vers l'adresse du serveur qui fait Web/OWA/SSTP. Normal,
> il faut que le serveur soit accessible de l'Internet. Et quand c'est pas la
> machinbox, j'essaie de pas être méchant mais Linksys et Netgear, euh comme
> pare-feu je passe.
>
> Là ou NAT aide : l'autre serveur interne (celui qui n'a pas le port "ouvert")
> qui aussi a une page HTTPS, (je dévie : sans le certificat qui va, et que les
> utilisateurs y sont tellement habitués qu'ils ne regardent même plus le
> message qui dit que la sécurité est pas bonne), il n'est pas exposé.
>
> Pourquoi : parce que le port 443, avec NAT, il est configuré pour n'aller que
> sur le serveur qui est exposé vers l'extérieur.
> Malgré tout ce que les merdiciels qui exposent les hôtes derrière NAT peuvent
> faire, ils ne vont pas re-router le port configuré manuellement.
>
> Dans la pratique : Claude Michu a 1 adresse IP publique 30.123.123.123/32.
> Tout est derrière NAT; a l'intérieur, le "routeur" a une IP de 192.168.1.1/24
> et le serveur 192.168.1.2/24.
> L'ingénieur réseau a ouvert le port 443 dans le "routeur" pour permettre les
> requêtes pour 30.123.123.123:443 d'être NATées sur 192.168.1.2:443. Tout le
> monde est content.
>
> Là ou NAT ça aide un peu : l'autre serveur 192.168.1.3:443, il n'est pas
> exposé. Pourquoi : à parce que le port 443, il a été configuré pour aller
> vers 192.168.1.2:443, pas vers 192.168.1.3:443.
> Le serveur 192.168.1.3:443, comme il est "privé", la sécurité fait chier tout
> le monde donc n'est pas sécurisé.
>
> Pourquoi NAT ça sert un peu encore à quelque chose : imaginons un monde sans
> NAT, ou il n'y a pas de pénurie. Au lieu d'une IP publique, Claude Michu a un
> /24 :
> 286.123.321.0/24. (*) Comme il n'y a pas de NAT, naturellement il n'y a plus
> de RFC1918 et donc le serveur qui était 192.168.1.2 devient 286.123.321.2 et
> le serveur qui était 192.168.1.3 devient 286.123.321.3.
> Pas de NAT, ça veut dire qu'on met une IP publique sur chaque machine. C'est
> la raison de ne pas avoir NAT : traverser NAT c'est une chienlit, tout le
> monde le sait. Donc au lieu de configurer le serveur avec une adresse
> RFC1918, on lui donne une IP publique, unique, qui évite la chienlit de NAT
> et les conflits quand les entreprises fusionnent. La raison de ne pas avoir
> NAT, c'est d'éviter NAT, non ? plus de conflit d'adresse, plus d'ALG, plus de
> chienlit avec les protocoles de merde qui encapsulent l'adresse à l'intérieur
> du payload. Host-to-host direct, la transparence; NAT ça casse le modèle (**).
>
> Eh bien, sans NAT, le serveur 286.123.321.3 il est à poil sur l'Internet.
> Avec une IP publique, sans pare-feu, c'est du suicide. Même si le pare-feu
> interne à chaque machine a fait des progrès considérables, exposer un serveur
> privé à l'Internet entier, c'est du suicide.
>
> Je vous vois venir : ah mais, Claude Michu, elle a un "pare-feu" (ouais, la
> machinbox du FAI) qui interdit les connexions venant de l'extérieur.
> Faux. Utilisant exactement les mêmes outils qui exposent les services
> derrière une IP privée à travers NAT (slipstream), l'attaqueur va exposer
> l'autre serveur.
> Avec NAT, il n'y a qu'un seul hôte en interne qui est exposé; configuré
> statiquement; 1 IP publique, 1 hôte vulnérable sur le port en entrée. Sans
> NAT, si chaque hôte a une adresse publique, tous les merdiciels qui "ouvrent"
> le NAT stateful diode vont exposer le port du machin IOT pas protégé.
>
> Le bousin IOT à 192.168.1.3:443, il est protégé par NAT si il y a un serveur
> à 192.168.1.2:443 configuré.
> Peut-être pas à 100%, mais il y a du boulot, y compris que soudainement le
> serveur à 192.168.1.2:443 va plus marcher; que l'utilisateur moins con que la
> moyenne a changé admin/admin.
>
> Le bousin IOT à 286.123.321.3:443, il n'est pas protégé par le pare-feu de
> merde que Claude Michu peut s'offrir; slipstream peut ouvrir le port, et en
> plus ça ne va pas tuer 286.123.321.2:443.
>
> Michel.
>
> (*) Attention aux commentaires négatifs à propos de cette adresse IP; ça fait
> assez longtemps que je fais du réseau. Un monde sans pénurie.
> (**) Le FUD, ce n'est pas moi qui l'ai écrit mais j'y ai cru. Il y a
> longtemps.
>
>
> ---------------------------
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
