Auteur Sujet: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?  (Lu 11708 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 33 377
    • Twitter LaFibre.info
IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
« Réponse #108 le: 19 novembre 2019 à 22:56:11 »
Sur ce point c'est vrai il y a vraiment trop de combinaison pour faire du scan.

Maintenant mes deux exemples démontrent qu'il est relativement facile de récupérer des IPv6 complètes pour ensuite les scanner afin de trouver des vulnérabilités permettant de rentrer.

Hugues

  • AS57199 MilkyWan
  • Expert
  • *
  • Messages: 7 608
  • Paris (15ème)
    • Twitter
IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
« Réponse #109 le: 19 novembre 2019 à 22:57:32 »
Vivien soulignait le fait que faute de firewall sur ipv6, tout repose sur le fait que l'ipv6 est plus difficile à découvrir (alors qu'en ipv4 l'usage massif de masquerading rend la découverte de l'ip peu impactante).

J'insiste, les deux cas cités sont valables en v6 ou en v4. Le fait de penser qu'en v6, ce genre cas augmentera, c'est juste un raisonnement idiot :
- Les gens qui veulent DDoS d'autres gens le feront en v4 ou en v6
- Les gens qui piratent des webcam existent déjà en v4, et penser qu'il y'aura plus de caméras vidéo ouvertes à cause d'IPv6 est absurde. Les gens qui configurent mal leur webcam sont ceux qui configurent mal leur routeur.


Non franchement, c'est absurde de A à Z.

Jojo78

  • Client K-Net
  • *
  • Messages: 3 114
  • sud 78 et Nord 14
IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
« Réponse #110 le: 19 novembre 2019 à 23:01:23 »
Du coup, je coche ou pas la case firewall IPV6? :)

vivien

  • Administrateur
  • *
  • Messages: 33 377
    • Twitter LaFibre.info
IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
« Réponse #111 le: 19 novembre 2019 à 23:07:01 »
Non franchement, c'est absurde de A à Z.

Non ton PC Windows il sera joignable directement en IPv6 et pas en IPv4.

Une petite faille dans le protocole SMBv1 (utilisé par WannaCry, ransomware qui a touché plus de 200 000 utilisateurs dans 150 pays) et là tu peut infecter les utilisateurs directement.

WannaCry devait être introduit sur un réseau local (derrière le firewall) pour se propager ensuite aux autre machines du réseau.

Tu comprends là où est le pb ?

kazyor

  • Expert SFR
  • Expert
  • *
  • Messages: 611
  • Lyon 7ème (69)
IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
« Réponse #112 le: 19 novembre 2019 à 23:10:15 »
J'insiste, les deux cas cités sont valables en v6 ou en v4. Le fait de penser qu'en v6, ce genre cas augmentera, c'est juste un raisonnement idiot :
- Les gens qui veulent DDoS d'autres gens le feront en v4 ou en v6
- Les gens qui piratent des webcam existent déjà en v4, et penser qu'il y'aura plus de caméras vidéo ouvertes à cause d'IPv6 est absurde. Les gens qui configurent mal leur webcam sont ceux qui configurent mal leur routeur.


Non franchement, c'est absurde de A à Z.

Le point n'est pas de dire qu'avec ipv6 il y en aura plus qu'en ipv4.
Mais qu'en ipv6 sans firewall, si celle-ci fuite où est récupérée, il risque d'y en avoir plus qu'avec le bête nat ipv4.

Hugues

  • AS57199 MilkyWan
  • Expert
  • *
  • Messages: 7 608
  • Paris (15ème)
    • Twitter
IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
« Réponse #113 le: 19 novembre 2019 à 23:22:49 »
Tu comprends là où est le pb ?
On est d'accord que SMBv1 est par défaut bloqué par le firewall de la machine, et que donc sauf action expresse de l'utilisateur, inaccessible en remote ?
On est d'accord que Wannacry ne s'est pas propagé à cause des ports ouverts sur les machines ?
On est d'accord que, de toute manière, avec Privacy extensions qui fait que les services ne bind pas sur les IP Temporary, on s'en contrefiche ?

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 598
  • La Madeleine (59)
IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
« Réponse #114 le: 20 novembre 2019 à 00:05:44 »
J'aimerai faire dévier l'échange sur un point spécifique qui, si je ne m'abuse, n'a pas été abordé précédemment

À mes yeux, le principal soucis du concept de "firewall comme outil de sécurité" est le biais cognitif nuisible que cela engendre dans l'esprit des gens, renforcé par l'individualisme de notre société et la non responsabilité de nos concitoyens.

Le phénomène est d'autant plus visible lorsque le groupe concerné est grand : grosse structure avec de nombreuses équipes, ou encore plusieurs équipes qui ne sont pas directement reliés, comme c'est le cas entre l'équipe qui conçoit le boitier "iot" et l'équipe qui gère le réseau domestique.
Dans ce cadre, la sécurité devient l'affaire des autres.

Pourquoi concevoir un produit sécurisé ? Après tout, le "firewall" (ou quoi que ce soit, ce n'est pas mon périmètre) va s'occuper de protéger tout ça !
Bon, j'utilise un système d'exploitation déprécié, ou encore non maintenu, ou encore notablement faillible, mais ce n'est pas grave, je suis "protégé" !

Le firewall a l'effet d'un garde-fou le long d'une route, sur laquelle les conducteurs ne se sentent plus concernés par la ceinture de sécurité ou la limitation de vitesse. Étrangement, lorsque la vie dudit conducteur est en jeu, le phénomène suscité ne s'applique plus beaucoup.

Je côtoie des professionnels qui ne pratique pas de patch management. Mais attention : il y a un firewall, #toutestokmaintenant !
Ma société a mis tout ses collaborateurs en "télétravail", sans outil interne, suite à un ransomware. Nous savons que Microsoft Windows est un risque conséquent (à partir de quand peut-on parler de certitude ?), l'effort est cependant mis sur le cloisonnement réseau, et sur les firewall, donc. Avec beaucoup de succès, visiblement.

Les produits IOT sont notablement mal sécurité, non maintenu. La question que l'on peut se poser : pourquoi, en tant que constructeur, devrai-je changer cet état de fait ? Après tout, les produits sont protégés par un firewall, non accessible d'internet.


Et finalement, pourquoi est-ce que ces pratiques ne fonctionnent pas ?
Pourquoi ne peut-on pas raisonnablement sécuriser un périmètre avec des firewall ?

On peut noter plusieurs raisons
La première, surement, est que la majorité de ces réseaux fonctionnent selon le bien connu principe du poulailler : une porte, un grillage autour, et des poulets sans défense au milieu : lorsque le loup est rentré, c'est la boucherie.

La deuxième raison : le firewall ne fait pas d'analyse sémantique. Je ne vais pas parler des aberrations, comme le SSL spoofing, qui n'ont guère d'avenir. Le firewall, donc, doit lire les paquets réseaux, et miraculeusement séparer le bon grain de l'ivraie. N'étant pas magique, on se rabat sur des heuristiques simples: port destination, ip source, protocole .. Hors, comme l'équipement au sain du réseau doit bien pouvoir sortir de ce dernier, et qu'il n'est pas possible sainement de maintenir une liste des "gentils" sur internet (liste exhaustive, de l'oublions pas), on en arrive à dire : "en sortie, #toutestokmaintenant". L'équipement est donc libre de ramener ce qu'il veut à l'intérieur du réseau, voir la raison #1 pour la suite de l'histoire.


Pour conclure, je prétends que l'utilisation du firewall comme base de la sécurité a un impact négatif, car remplaçant de manière nécessairement insuffisante la base réelle de sécurité du périmètre concerné.

"La sécurité, c'est comme le TCP : ça se fait sur les endpoints."

PhilippeMarques

  • Expert
  • *
  • Messages: 246
IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
« Réponse #115 le: 20 novembre 2019 à 06:36:31 »
Le débat va être houleux, parce qu'il mets dos à dos, la responsabilité individuelle à la responsabilité collective.
Il y a les partisans de laisser le choix de la protection individuelle à l'individu, ou de gérer cette protection collégialement.
Encore faut il que l'individu soit suffisamment formé pour peser les risques de ses actions.

Sur cet aspect il faut lever le nez de la technique, et adopter un comportement rationnel et de bon sens.
Ce n'est pas au sein du réseau que cela se joue, l'enjeux est sur le terminal de connexion.

Je comprends le concept de la task-force, mais à un moment donné il faut savoir se déclarer incompétent dans le domaine ( dans le sens incompétence juridique) ce n'est pas du ressort de l'ARCEP

Vous pouvez toujours en discuter, mais cela relève plus des choix des constructeurs,de leur implémentation des protocoles.

vivien

  • Administrateur
  • *
  • Messages: 33 377
    • Twitter LaFibre.info
IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
« Réponse #116 le: 20 novembre 2019 à 10:07:32 »
On est d'accord que SMBv1 est par défaut bloqué par le firewall de la machine, et que donc sauf action expresse de l'utilisateur, inaccessible en remote ?
On est d'accord que Wannacry ne s'est pas propagé à cause des ports ouverts sur les machines ?
Non !

Wannacry infecte une première machine du réseau via une pièce jointe contaminée, la méthode traditionnelle.

Une fois la machine bureautique contaminée, elle scan le réseau local et là comme dit jack dans le principe du poulailler : le ransomware auto-répliquant est derrière le firewall, le loup est rentré, c'est la boucherie.

Les PC Windows vulnérables écoutent sur le port 445 (SMBv1) et si ils n'ont pas le dernier patch Microsoft, ils sont infectés. D'où des réseaux industriels entiers qui sont attaqués alors qu'il n'ont aucun accès à Internet.

Ce que IPv6 sans firewall change ? Il permet d'attaquer directement les machines, sans passer par la case "pièce jointe contaminée". Seul nécessité récupérer des IPv6 car le scan n'est pas pertinent, et j'ai indiqué deux méthodes dans mon précédent message.

Bien sur le faille est corrigée, mais le même scénario pourrait se reproduire avec d'autre failles. Je rappelle que Microsoft à publié le 14 mai 2019 un patch pour Windows XP pour une faille hautement critique (cf https://support.microsoft.com/en-us/help/4500705/customer-guidance-for-cve-2019-0708 ) car exploité il pouvait entrainer des désastres capables de mettre des vie en danger en faisant tomber des réseaux entiers type hôpitaux ou industrie. (après la question d'avoir du Windows XP dans des infra hautement critique en 2019 se pose aussi - même si ces Windows XP ne sont pas connectés directement à Internet. La SNCF serait bien embêtée si elle perdait tous ses écran qui annoncent les trains au niveau national)


Thornhill

  • Client SFR fibre FTTH
  • *
  • Messages: 2 470
  • Saint-Médard-en-Jalles (33)
IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
« Réponse #117 le: 20 novembre 2019 à 10:52:36 »
On est d'accord que, de toute manière, avec Privacy extensions qui fait que les services ne bind pas sur les IP Temporary, on s'en contrefiche ?

Je n'ai pas l'impression que ce soit vrai, il semble que par défaut les sockets sont en LISTEN sur toutes les IP ?

C:\>netstat -an |find "LISTEN"|find "::"
  TCP    [::]:135               [::]:0                 LISTENING
  TCP    [::]:445               [::]:0                 LISTENING
  TCP    [::]:5357              [::]:0                 LISTENING
  TCP    [::]:7680              [::]:0                 LISTENING
  TCP    [::]:8192              [::]:0                 LISTENING
  TCP    [::]:49496             [::]:0                 LISTENING
  TCP    [::]:49497             [::]:0                 LISTENING
  TCP    [::]:49664             [::]:0                 LISTENING
  TCP    [::]:49665             [::]:0                 LISTENING
  TCP    [::]:49666             [::]:0                 LISTENING
  TCP    [::]:55585             [::]:0                 LISTENING

Le délai par défaut de validité de l'adresse temporaire est de 7 jours, elle sera utilisée en adresse source pendant  24h, je vous laisse juger si c'est suffisant pour être détecté et servir de cible pour une attaque :

C:\>netsh interface ipv6 show privacy
Recherche du statut actif...

Paramètres d'adresses anonymes
-----------------------------------------------------
Utiliser les adresses anonymes               : enabled
Tentatives de détection d'adresses en double : 3
Durée de vie maximale                        : 7d
Durée de vie maximale préférée               : 1d
Temps de régénération                        : 5s
Temps aléatoire maximale                     : 10m
Temps aléatoire                              : 5m4s



De plus j'ai l'impression que l'utilisation des adresses temporaires n'est pas systématiquement activée par défaut, par exemple sur une distrib RHEL :

[root@lala ~]# sysctl -a 2>/dev/null |grep use_tempaddr
net.ipv6.conf.all.use_tempaddr = 0
net.ipv6.conf.default.use_tempaddr = 0
net.ipv6.conf.eth0.use_tempaddr = 0
net.ipv6.conf.eth1.use_tempaddr = 0
net.ipv6.conf.eth2.use_tempaddr = 0
net.ipv6.conf.lo.use_tempaddr = -1


Bref, on retombe sur le débat des défaut de protection des endpoints et de l'utilité d'activer un filtrage en bordure (firewall).


kgersen

  • Client Bouygues FTTH
  • Modérateur
  • *
  • Messages: 6 461
  • FTTH 1Gb/s sur Paris (75)
IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
« Réponse #118 le: 20 novembre 2019 à 14:20:00 »

Ce que IPv6 sans firewall change ? Il permet d'attaquer directement les machines, sans passer par la case "pièce jointe contaminée". Seul nécessité récupérer des IPv6 car le scan n'est pas pertinent, et j'ai indiqué deux méthodes dans mon précédent message.


non la car par défaut un smb server actif sur une machine Windows n'autorise que les connections venant du meme subnet.
Pour autoriser ::/0 a accéder a son serveur smb il faut explicitement le faire.

Y'a vraiment beaucoup trop de 'suppositions/théories' et pas assez d'expériences concretes dans les discours ici.



PhilippeMarques

  • Expert
  • *
  • Messages: 246
IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
« Réponse #119 le: 24 novembre 2019 à 09:01:09 »
Je viens de voir une de tes réponses  Optix sur nextImpact:
Je cite : "Je sais, mais il faut s'adapter aux gens qui n'ont pas les connaissances nécessaires pour faire la migration.
C'est pour cela que je dis qu'il faut recréer l'illusion du NAT pour filtrer les connexions entrantes, car ça rassure les abonnés avec qq chose qu'ils connaissent."

Le NAT a été inventé en V4 pour palier à la pénurie d'adresses V4 temporairement (comme beaucoup d'autres artifices -ie notation et routage CIDR-). Les utilisateurs se sont habitués et ont assimilé le concept en le déclinant comme un outil de sécurité.
Il va être nécessaire de modifier les esprits à ce sujet, tous les "devices" peuvent avoir l'attribution d'une adresse IPv6 sans artifices de translation d'adresse ou de ports.
Délimiter la zone de responsabilité entre l'opérateur et le client est le point crucial de toute cette histoire de Firewall.
Pour une question de neutralité, l'opérateur se doit de délivrer tout les flux, quels qu'il soient au client.C'est de la responsabilité de l'opérateur, ne pas le faire implique d'autres problématiques.
C'est aussi au client de se prémunir,s'il est en mesure de comprendre, envers d'éventuelles mésaventures.
Si on regarde les parts de marchés, il y a très peu d'OS "exotiques"  sur les devices,et majoritairement iOs, Android, Windows, MacOs ( certainement quelques autres ) utilisés. Mais cela complète la majorité du marché des utilisateurs béotiens.
Si on place la responsabilité de l'utilisateur sur le "device terminal", les constructeurs réfléchissent déjà à l' implémentation d'un firewall v6.
On a donc, deux catégories de population, ceux qui n'y connaissent rien du tout et ceux-ci doivent être protégés par défaut. Et ceux qui ont un minimum de connaissances et à qui on doit donner la possibilité de gérer par eux mêmes.
L'implémentation de firewall V6 sur les terminaux est du ressort de ceux qui construisent l'OS de ces terminaux, il serai peut-être judicieux de les convier à faire partie de votre task-force ( si ce n'est pas déjà le cas).

 

Mobile View