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

0 Membres et 1 Invité sur ce sujet

Hugues

  • AS2027 MilkyWan
  • Modérateur
  • *
  • Messages: 12 423
  • Lyon (69) / St-Bernard (01)
    • Twitter
IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
« Réponse #48 le: 19 mai 2018 à 18:02:47 »
Je suis partagé.

D'un côté je suis d'accord que la taille des plages IPv6 et leur génération aléatoire apporte une sécurité. Et que c'est comme ca que je fais chez moi.

D'un autre côté, je trouve que c'est une sécurité "de facto", comme le NAT en IPv4.

Pour moi, un Firewall Stateful qui drop tout en entrée, pourquoi pas, mais combien d'attaques ça bloque vraiment ? Les attaques aujourd'hui ne se basent plus sur un port laissé ouvert, sauf exception.

Donc bon, dans tous les cas c'est pas idéal...

vivien

  • Administrateur
  • *
  • Messages: 47 079
    • Twitter LaFibre.info
IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
« Réponse #49 le: 19 mai 2018 à 18:09:50 »
Mon avis, c'est que l'on peut encore augmenter le niveau de sécurité que l'on connaît aujourd'hui sur IPv4 en combinant deux choses :
- une IPv6 qui change régulièrement et qui est perdue au milieu de 18446744073709551616 adresses inutilisées du /64
- un firewall qui bloque par défaut les flux entrants

Un firewall couvre des cas qui ne sont pas couvert, notamment quand l'IP remonte par un moyen ou un autre, rien que sniffer une requete DNS permet de récupérer les IP.

Inversement, WannaCrypt aurait peut être eu plus de mal a infecter d'autres ordinateurs du réseau local si il n'était pas possible de scanner rapidement les IP du réseau local.

bref, pour moi il y a des cas un peu spécifiques où les deux se complètent.

- des default des OS recent sont immensement plus securises qu'il y a 5 ou 10 ans.
C'est c'est une certitude.

Rappelez-vous de Windows 9x avec possibilité d'accéder au disque dur sans mot de passe.
Windows NT 4.0 a fait un premier grand pas au niveau sécurité.
Avec Windows le service pack 2 de Windows XP on a eu le droit a encore une grade évolution de la sécurité
Windows Vista a encore monté le niveau...
Maintenant on a de plus en plus un disque chiffré par défaut.

Seul Windows 3.1 était imbattable : pas de TCP/IP par défaut, il fallait insérer une disquette avec TCP/IP pour installer le protocole.

Hugues

  • AS2027 MilkyWan
  • Modérateur
  • *
  • Messages: 12 423
  • Lyon (69) / St-Bernard (01)
    • Twitter
IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
« Réponse #50 le: 19 mai 2018 à 18:13:47 »
Pour le réseau local, suffit de lire la table NDP et tu as les IP fixes de chaque device IPv6.

Fuli10

  • Abonné Free fibre
  • *
  • Messages: 1 004
  • Conflans Sainte Honorine (78)
IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
« Réponse #51 le: 19 mai 2018 à 23:14:21 »
Il y a aussi un truc si on laisse l'autoconf générer son IPv6.
J'ai remarqué que l'IPv6 donné contient l'adresse MAC et 2 bytes systématiquement les mêmes. Donc si on doit scanner pour un matériel précis  (camera IP), l'OUI (les 3 premiers bytes de la MAC) sera toujours le même. Du coup avec 3 bytes connus, 2 bytes générés, il ne reste plus que 3 bytes à scanner pour trouver la webcam. Donc 16M d'entrées, ce qui est beaucoup moins que les 2^64 du range. Encore moins si les 3 bytes restants ne sont pas aléatoires...
Bref j'aurais une camera IP supportant l'IPv6 mettant tous ses services à poils sur le net, je le protègerai avant que quelqu'un trouve la faille sur le serveur web embarqué  (dont la dernière mise à jour de sécurité date de 2010).

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 674
  • La Madeleine (59)
IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
« Réponse #52 le: 20 mai 2018 à 01:47:08 »
(hugues & raf, je vous aime)


Je suis pour la vision "free" dans le domaine, entendu que les deux autres visions posent un danger au reste de l'internet, c'est à dire à 100% des usagers.

TLS 1.3 a mis 4 ans, et il a fallu redoubler d'ingéniosité et d'intelligence, pour finalement sortir la version définitive, du fait de la concrétisation de la vision "orange & bytel" par de nombreux acteurs de l'internet (c'est juste un exemple, le dernier en date peut-être).

La sécurité n'a aucun sens au niveau réseau "middlebox", seulement au niveau des terminaisons.
Tout le reste (incluant le (cg)nat, les acl random, les IPS, toutes les technos de mangling au sens large, antiddos et whatever) n'est qu'absurdité ayant plus ou moins de conséquence sur le produit, et sur le reste de la communauté.

Cordialement,

vivien

  • Administrateur
  • *
  • Messages: 47 079
    • Twitter LaFibre.info
IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
« Réponse #53 le: 20 mai 2018 à 09:43:54 »
Pour TLS 1.3, je pense que ce que tu appelles la vision d'Orange/Bouygues est plus la vision des banques (et des organismes qui réalisent du man-in-the-middle pour manager leur réseau), que la vision Orange ou Bouygues.

A noter qu'il me semble que c'est la vision sécurité sur les terminaux qui a gagné dans TLS 1.3 (vs la sécurité par des IPS qui réalisent du man-in-the-middle).

Voici un extrait d'un Internet-Draft où ceux qui souhaitent que le réseau puisse faire de la sécurité avec TLS 1.3 présentent la situation proposée par le brouillon de TLS 1.3 et donnent ensuite un ensemble représentatif de scénarios de cas d'utilisation de sécurité basés sur le réseau qui sont négativement impactés par TLS 1.3 et ne se prêtent pas à une solution alternative basée sur les terminaux.

Pour moi, il me semble qu'ils n'ont pas été écoutés dans TLS 1.3 qui a été approuvé par l'IETF à la fin du mois de mars 2018.

Les solutions de sécurité réseau telles que Firewalls (FW) et Intrusion Prevention Systems (IPS) reposent sur l'inspection du trafic réseau pour mettre en œuvre des stratégies de sécurité périmétriques. Selon les fonctions de sécurité requises, ces boîtiers de médiation peuvent être déployés en tant que périphériques de surveillance du trafic ou en tant que périphériques en ligne actifs. Un boîtier de surveillance de trafic peut par exemple effectuer une détection de vulnérabilité, détection d'intrusion, crypto-audit, surveillance de conformité, etc. Un middlebox actif en ligne peut par exemple empêcher le téléchargement de logiciels malveillants, bloquer les URLs malveillantes connues, interdire l'exfiltration des données, etc. Une partie importante de ces politiques de sécurité nécessite une inspection du trafic en texte clair au-dessus de la couche 4, ce qui devient problématique lorsque le trafic est chiffré avec Transport Layer Security (TLS). Aujourd'hui, les solutions de sécurité basées sur le réseau résolvent généralement ce problème en devenant un man-in-the-middle (MITM) pour la session TLS selon l'un des deux scénarios suivants:
1/ Session sortante, où la session TLS provient d'un client à l'intérieur du périmètre vers une entité à l'extérieur
2/ Session entrante, où la session TLS provient d'un client à l'extérieur du périmètre vers une entité à l'intérieur

Pour le scénario de session sortante, MITM est activé en générant un certificat racine local et une paire de clés publique / privée (locale) associée. Le certificat racine local est installé sur les entités internes pour lesquelles le trafic TLS doit être inspecté et le ou les périphériques de sécurité réseau stockent une copie de la clé privée. Lors de l'établissement de liaison TLS, le périphérique de sécurité réseau (ci-après appelé proxy TLS) modifie le certificat fourni par le serveur (extérieur) et le (re) signe avec la clé privée du certificat racine local. A partir de là, le proxy TLS a une visibilité sur d'autres échanges entre le client et le serveur, ce qui lui permet de décrypter et d'inspecter le trafic réseau ultérieur.

Pour le scénario de session entrante, le proxy TLS est configuré avec une copie du (des) certificat (s) des serveurs locaux et des clés privées correspondantes. Sur la base du certificat de serveur présenté, le proxy TLS détermine la clé privée correspondante, ce qui permet à nouveau au proxy TLS d'avoir plus de visibilité sur les échanges ultérieurs entre le client et le serveur et donc de déchiffrer le trafic réseau ultérieur.

À ce jour, il existe un certain nombre de scénarios de cas d'utilisation qui reposent sur les capacités ci-dessus lorsqu'ils sont utilisés avec TLS 1.2 ou une version antérieure. TLS 1.3 introduit plusieurs modifications qui empêchent un certain nombre de ces scénarios d'utilisation d'être satisfaits des types de capacités basés sur le proxy TLS qui existent aujourd'hui.

Il a été noté que les proxies TLS actuellement déployés (boîtiers de médiation) peuvent réduire la sécurité de la connexion TLS elle-même en raison d'une mauvaise implèmentation et configuration, et qu'ils peuvent compromettre la confidentialité lors du décryptage d'une session TLS. En tant que tel, il a été soutenu que la prévention des proxies TLS devrait être considérée comme une caractéristique de TLS 1.3 et que la bonne façon de résoudre ces problèmes est de s'appuyer sur des solutions basées sur des terminaux (clients et serveurs).

[...]

2.1. Incidences du changement de session entrante

2.1.1. Suppression des suites de caractères statiques RSA et Diffie-Hellman

TLS 1.2 prend en charge les suites de chiffrement RSA et Diffie-Hellman statiques, ce qui permet de partager la clé privée du serveur avec des boîtiers intermédiaires côté serveur. TLS 1.3 a supprimé la prise en charge de ces suites de chiffrement en faveur du mode éphémère Diffie-Hellman afin de fournir une confidentialité parfaite (PFS). De ce fait, il n'est plus possible qu'un serveur partage a priori une clé avec le boîtier de médiation, ce qui implique que le boîtier de médiation ne peut pas accéder aux données de la session TLS.

Les exemples de scénarios impactés incluent la surveillance du réseau, le dépannage, la conformité, etc.

Pour plus de détails (et une solution suggérée), veuillez vous référer à [ID.green-tls-static-dh-in-tls13] .


2.2. Impacts du changement de session sortante

2.2.1. Certificat de serveur chiffré

Dans TLS 1.2, le message ClientHello est envoyé à l'adresse de transport du serveur (IP et port). Le message ClientHello peut inclure l'indication de nom de serveur (SNI) pour spécifier le serveur réel que le client souhaite contacter. Ceci est utile lorsque plusieurs "serveurs virtuels" sont hébergés sur une adresse de transport donnée (IP et port). Il fournit également des informations sur le domaine que le client tente d'atteindre.

Le serveur répond par un message ServerHello, qui contient les paramètres de connexion sélectionnés, suivi d'un message Certificate, qui contient le certificat du serveur et, par conséquent, son identité.

Dans TLS 1.2, les messages ClientHello, ServerHello et Certificate sont tous envoyés en texte clair, cependant dans TLS 1.3, le message Certificate est crypté, cachant ainsi l'identité du serveur à partir de n'importe quel intermédiaire. Notez que même si le SNI est fourni (en clair) par le client, il n'y a aucune garantie que le serveur réel qui répond est celui indiqué dans le SNI du client.

Les exemples de scénarios impactés impliquent une sécurité réseau sélective, telle que des listes blanches ou des listes noires basées sur des informations de sécurité, des exigences réglementaires, des catégories (par exemple, services financiers), etc. Certains de ces scénarios exigent que le boîtier intermédiaire effectue l'inspection. tandis que d'autres scénarios exigent que le boîtier de médiation n'effectue pas d' inspection.


2.2.2. Reprise et clé pré-partagée

Dans TLS 1.2 et ci-dessous, la reprise de session est fournie par "ID de session" et "tickets de session". Si le serveur ne veut pas honorer un ticket, il peut simplement initier un handshake TLS complet avec le client comme d'habitude.

Dans TLS 1.3, le mécanisme ci-dessus est remplacé par des clés pré-partagées (PSK), qui peuvent être négociées dans le cadre d'une prise de contact initiale, puis utilisées dans une prise de contact ultérieure pour effectuer une reprise à l'aide du PSK. TLS 1.3 stipule que le client DEVRAIT inclure une extension «key_share» pour permettre au serveur de refuser la reprise et de revenir à une prise de contact complète, mais ce n'est pas une exigence absolue.

Les scénarios d'exemple qui sont impactés par ceci sont des boîtiers de médiation qui ne faisaient pas partie de la poignée de main initiale, et par conséquent ne connaissent pas le PSK. Si le client n'inclut pas l'extension "key_share", le boîtier de médiation ne peut pas forcer un retour à la prise de contact complète. Si la stratégie du boîtier de médiation l'oblige à inspecter la session, elle doit échouer à la place.


2.2.3. Possibilité de désactiver le proxy Middlebox

Les boîtiers de sécurité réseau interceptent ou transmettent des sessions TLS pour une politique d'utilisation acceptable, une inspection de protocole, une analyse de logiciels malveillants et d'autres objectifs. Pour des raisons de conformité et de confidentialité, les boîtiers de médiation doivent être en mesure d'engager et de désengager la fonction proxy de manière transparente sans affecter l'expérience de l'utilisateur. Par exemple, les lois sur la protection de la vie privée peuvent interdire aux boîtiers de médiation d'intercepter le trafic bancaire même si celui-ci se trouve dans le réseau de l'entreprise et le trafic réseau sortant est soumis à une inspection légale.

Il existe plusieurs techniques qui peuvent être utilisées. Ces techniques fonctionnent avec TLS 1.2 et versions antérieures mais pas avec TLS 1.3.

Une technique consiste pour le boîtier de médiation à négocier le même secret maître avec le client et le serveur TLS d'origine, comme si les deux points d'extrémité traitaient directement. Ceci est également connu comme "Triple Handshake" utilisé par les boîtiers de médiation légitimes. [BreakTLS] décrit les méthodes avec les échanges de clés RSA et DH. Lorsque les clés de session proxy sont les mêmes que pour une prise de contact directe, le boîtier de médiation est capable de "découper" les deux sessions proxy TLS lorsqu'il termine l'inspection de sécurité.

Cette technique n'est pas fonctionnelle avec TLS 1.3 puisque le hachage de transcription sur les messages de prise de contact fait partie de la procédure de dérivation de clé.


2.2.4. Négociation de version et protection de downgrade

Dans TLS, le message ClientHello inclut une liste des versions de protocole prises en charge. Le serveur sélectionnera la version prise en charge la plus élevée et indiquera son choix dans le message ServerHello.

TLS 1.3 modifie la manière dont la négociation de version est effectuée. Le message ClientHello indiquera TLS version 1.3 dans la nouvelle extension «supported_versions», cependant pour une rétrocompatibilité avec TLS 1.2, le message ClientHellow indiquera TLS version 1.2 dans le champ «legacy_version». Un serveur TLS 1.3 reconnaîtra que TLS 1.3 est en cours de négociation, tandis qu'un serveur TLS 1.2 verra simplement un ClientHello TLS 1.2 et procédera à la négociation TLS 1.2.

Dans TLS 1.3, la valeur aléatoire dans le message ServerHello inclut une valeur spéciale dans les huit derniers octets lorsque le serveur négocie TLS 1.2 ou TLS 1.1 et inférieur. La ou les valeurs spéciales permettent à un client TLS 1.3 de détecter un attaquant actif lançant une attaque de rétrogradation lorsque le client a effectivement atteint un serveur TLS 1.3, à condition que des chiffrements éphémères soient utilisés.

Du point de vue de la sécurité du réseau, l'impact principal est que TLS 1.3 exige que le proxy TLS soit un man-in-the-middle actif dès le début de la prise de contact. Cependant, un boîtier de médiation qui ne prend en charge que TLS 1.2 peut laisser le TLS 1.3 ClientHello initial entraîner une TLS 1.3 ServerHello du serveur, que le boîtier de médiation ne prend pas en charge. En fonction de la stratégie configurée, le proxy TLS peut rejeter la session à ce stade.

Si le boîtier de médiation TLS 1.2 prend un rôle actif dès le début, alors le boîtier de médiation procédera effectivement entre un client-à-boîtier de médiation et une connexion TLS de boîtier à serveur, auquel cas l'établissement de liaison réussira (mais TLS 1.2 ). Notez qu'en raison de la protection de rétrogradation, le proxy ne peut pas simplement rétrograder la version TLS à 1.2 dans ClientHellow, ce qui lui permettrait de se désengager de la prise de contact plus tard.


2.2.5. Chiffrement SNI dans TLS par tunneling

Comme indiqué ci-dessus, avec les certificats de serveur cryptés, l'indication de nom de serveur (SNI) dans le message ClientHello est la seule information disponible en clair pour indiquer le serveur cible du client, et le serveur réel peut différer.

TLS 1.3 propose de cacher le SNI dans le ClientHello à partir des boîtiers de médiation.

Les exemples de scénarios impactés impliquent une sécurité réseau sélective, telle que des listes blanches ou des listes noires basées sur des informations de sécurité, des exigences réglementaires, des catégories (par exemple, services financiers), etc. Certains de ces scénarios exigent que le boîtier intermédiaire effectue l'inspection. tandis que d'autres scénarios exigent que le boîtier de médiation n'effectue pas d'inspection, mais sans le SNI, le boîtier de médiation peut ne pas disposer des informations nécessaires pour déterminer le scénario réel avant qu'il ne soit trop tard.[/b]
[/size]

Source : TLS 1.3 Impact sur la sécurité réseau, 30 octobre 2017.

Je n'ai pas repris ici les scénarios de cas d'utilisation de sécurité basés sur le réseau qui sont négativement impactés par TLS 1.3 et ne se prêtent pas à une solution alternative basée sur les terminaux, mais vous les trouverez dans le document.

Voici tout de même un cas qui parle de NAT, lié au manque d'IPv4 :

3.2. Cas d'utilisation I2 - Fonctionnement de l'application sur NAT

La fonction de traduction d'adresse réseau (NAT) traduit les adresses et ports L3 et L4 lorsque le paquet traverse le périphérique réseau. Les dispositifs NAT sophistiqués peuvent également implèmenter des moteurs d'inspection d'application pour corriger les données L3 / L4 incorporées dans les messages de contrôle (par exemple, message de contrôle FTP, messages de signalisation SIP) afin qu'elles soient cohérentes avec les en-têtes externes L3 / L4.

Sans la correction, les connexions de données secondaires (FTP) ou de média (SIP) atteindront probablement une mauvaise destination.

L'opération de correction d'adresse et de port intégrée nécessite l'accès à la charge utile L7 qui pourrait être protégée par cryptage.

Bien que TLS 1.3 n'empêche pas le boîtier de médiation d'exécuter cette fonction, une fois qu'une fonction de proxy est établie, le boîtier de médiation n'est pas en mesure de se retirer du chemin du paquet pour la session en question.



J'ai repris ici un document des pro "man-in-the-middle", mais a titre personnel je suis plutôt contre leur idées qui baissent le niveau de la sécurité. Pour prendre l'exemple "dans TLS 1.3, le message Certificate est crypté, cachant ainsi l'identité du serveur à partir de n'importe quel intermédiaire", on voit que des FAI mobiles américains brident le débit en fonction du certificat TLS, pour réduire la consomation data sur des sites de vidéos en bloquant la résolution en 480p. Il semble donc pertinent de le crypter, pour un peu plus de neutralité [il y a aussi bien d'autres raisons de le crypter].

Il est probable que TLS 1.3 soit désactivé pendant de nombreuses années dans les sociétés qui utilisent du "man-in-the-middle", mais c'est une autre histoire.

Si je ne suis pas pour la sécurité basé sur du "man-in-the-middle", je pense que des petits équipements connectés peuvent avoir du mal a assurer eux même leur propre sécurité et le fait que le réseau bloque par défaut les flux entrants peut aider sans être le remède miracle.

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
« Réponse #54 le: 20 mai 2018 à 12:42:21 »
Je suis pour la vision "free" dans le domaine, entendu que les deux autres visions posent un danger au reste de l'internet, c'est à dire à 100% des usagers.

on est tout d'accord la dessus 'en theorie' (encore que voir plus bas) mais en pratique dans un contexte grand public c'est juste pas réaliste.
Free joue avec le feu et changera surement sa "vision" quand des incidents graves arriveront.
Car le probleme c'est l'inertie et les équipements anciens deja compatibles IPv6 mais qui ne se mettent  pas ou se mettront pas a jour.

Dans 10 ans pourquoi pas mais d'ici la il est plus safe d'avoir un bon firewall avec opt-in par défaut.

La sécurité n'a aucun sens au niveau réseau "middlebox", seulement au niveau des terminaisons.
Tout le reste (incluant le (cg)nat, les acl random, les IPS, toutes les technos de mangling au sens large, antiddos et whatever) n'est qu'absurdité ayant plus ou moins de conséquence sur le produit, et sur le reste de la communauté.


si on suit cette logique les firewall d'entreprise n'ont aucun sens. Il faut juste blinder chaque poste de travail, serveurs, imprimantes, etc... ?

Je ne suis pas d'accord ,dans un contexte entreprise et même grand public on peut creer des zones 'safe' ou chaque équipement dans ces zones peut considérer qu'il n'a pas gérer lui-même la sécurité ou même le contrôle d'accès.

Tant qu'on a pas un standard pour administrer de facon centraliser la sécurité embarqué dans chaque device du réseau on est un peu obligé d'avoir une centralisation dans un firewall en bordure. sinon c'est juste un cauchemar a gerer.

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 674
  • La Madeleine (59)
IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
« Réponse #55 le: 20 mai 2018 à 13:02:29 »
Citer
si on suit cette logique les firewall d'entreprise n'ont aucun sens.
Exactement, j'irai même jusqu'à dire qu'ils posent un grave danger à la sécurité de l'entreprise.

Ta "zone safe" est une catastrophe : il apparait qu'un élèment étranger, parvenant à s'introduire dans la "zone safe", prend le rôle de loup dans la bergerie : tout le monde étant à poil, il n'y a plus qu'à se servir. Tu vois de quoi je parle ?

Une autre facette, c'est "si tu es dans un subnet / vlan, alors tu peux accèder à certaines ressources qui sont openbar" : c'est le même problème, il "suffit" qu'un type parviennent à abuser d'un défaut dans le réseau local (qui a parlé de wifi ?) ou qu'un PC se fasse trouer pour que l'exploitation soit totale


Citer
Tant qu'on a pas un standard pour administrer de facon centraliser la sécurité embarqué dans chaque device du réseau on est un peu obligé d'avoir une centralisation dans un firewall en bordure. sinon c'est juste un cauchemar a gerer.
Un standard ?
La seule chose qui n'est pas mitigé, en standard, par à peu près 100% des kernels (je place un joker sur hurd  :P), ce sont les attaques dites volumétriques (c'est à dire, saturation de la couche 1)
Pour tout le reste, il n'y a rien à faire


Citer
Free joue avec le feu
Free, pour une fois, fait son travail convenablement


@Vivien: c'est la même chose
J'espère en effet que les livebox, freebox et autres box sont transparentes au niveau TLS, il n'empêche que l'on parle de routeur qui sont loin d'être de simple routeur, et que cela freine considérablement (voir bloque complétement) une certaine évolution des protocoles réseaux, à tel point que la plupart des innovations de nos jours se base non plus sur IP, mais sur UDP ou TCP directement, ce qui est plutôt absurde
Un autre exemple des dernières années: mptcp, les mecs ont conçu le protocole expressèment pour se comporter, d'un point de vu extérieur, comme du TCP (contrairement à ses prédécesseurs, qui sont mort-né)

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
« Réponse #56 le: 20 mai 2018 à 13:23:26 »
Exactement, j'irai même jusqu'à dire qu'ils posent un grave danger à la sécurité de l'entreprise.

Ta "zone safe" est une catastrophe : il apparait qu'un élèment étranger, parvenant à s'introduire dans la "zone safe", prend le rôle de loup dans la bergerie : tout le monde étant à poil, il n'y a plus qu'à se servir. Tu vois de quoi je parle ?

Une autre facette, c'est "si tu es dans un subnet / vlan, alors tu peux accèder à certaines ressources qui sont openbar" : c'est le même problème, il "suffit" qu'un type parviennent à abuser d'un défaut dans le réseau local (qui a parlé de wifi ?) ou qu'un PC se fasse trouer pour que l'exploitation soit totale

Un standard ?
La seule chose qui n'est pas mitigé, en standard, par à peu près 100% des kernels (je place un joker sur hurd  :P), ce sont les attaques dites volumétriques (c'est à dire, saturation de la couche 1)
Pour tout le reste, il n'y a rien à faire


"La seule chose qui n'est pas mitigé, en standard" -> j'ai l'impression que tu limites ta perception a la couche 3.

L'abus et le loup dont tu parles c'est pareil que de choper le mot de passe de quelqu'un. on est dans la sécurité 'physique' ou l’ingénierie sociale.

Apres donc dans ta logique, si j'ouvre un serveur web sur ma webcab c'est que dans l'OS de ma webcam que je dois gérer les IP qui ont accès ?

et si j'ai 10 webcam je dois passer sur les 10 pour faire la manip ?

En grand public peut-etre, en entreprise franchement c'est pas si simple et en pratique c'est souvent plus simple et moins cher (en coût humain/admin) de centraliser tout dans un fw.

Car a l'arrivé on a un fw dans chaque appareil vs un seul fw non ? conceptuellement c'est ca.

Free, pour une fois, fait son travail convenablement
Free est opportuniste et 'lazy'. Si y'a pas de fw IPv6 dans la Freebox Router V6 c'est simplement que c’était plus simple et rapide et surtout pour pas que les performances en fibre en souffre ;)

cela dit, je suis d'accord sur l'aspect nouveaux protocoles et en finir avec "TCP+UDP only". C'est pourquoi le firewall IPv6 de la Livebox est une grosse merde et donne le mauvais exemple. Il lui manque l'ouverture au niveau 3, la il ne travaille qu'un niveau 4 , tcp et udp.

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 674
  • La Madeleine (59)
IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
« Réponse #57 le: 20 mai 2018 à 13:44:58 »
"La seule chose qui n'est pas mitigé, en standard" -> j'ai l'impression que tu limites ta perception a la couche 3.

L'abus et le loup dont tu parles c'est pareil que de choper le mot de passe de quelqu'un. on est dans la sécurité 'physique' ou l’ingénierie sociale.

et si j'ai 10 webcam je dois passer sur les 10 pour faire la manip ?

En grand public peut-etre, en entreprise franchement c'est pas si simple et en pratique c'est souvent plus simple et moins cher (en coût humain/admin) de centraliser tout dans un fw.

Car a l'arrivé on a un fw dans chaque appareil vs un seul fw non ? conceptuellement c'est ca.

Non, je n'ai pas de firewall.
Comme dit, le kernel fait le travail comme un grand, et ce par défaut, il n'est nullement nécessaire de repasser dessus

Si tu configures des services openbar, le soucis n'est pas technique, mais humain, il est peut-être temps de changer de métier

Pour information, j'ai sur mon PC une IP publique, fixe, accessible via un réseau ouvert, depuis des années, c'est ce que je pratique également sur mes infrastructures;


Citer
Apres donc dans ta logique, si j'ouvre un serveur web sur ma webcab c'est que dans l'OS de ma webcam que je dois gérer les IP qui ont accès ?
Par rapport à ce point spécifique, je me permet de préciser: l'authentification ou même l'identification par IP est disfonctionnelle et n'a aucun sens en 2018.

Cela fait plus de 20ans qu'un IP n'identifie pas une personne, ni une machine, et cela va de pire en pire d'année en année, en particulier en v4
Et on en revient au non-sens de gérer l'AAA "via un firewall": ce dernier n'a pas les informations pour faire ce travail, seul la couche 7, et une couche 7 spécifique à l'application, peut et doit faire ce travail

vivien

  • Administrateur
  • *
  • Messages: 47 079
    • Twitter LaFibre.info
IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
« Réponse #58 le: 20 mai 2018 à 14:43:32 »
Si tu configures des services openbar, le soucis n'est pas technique, mais humain, il est peut-être temps de changer de métier

Cela fait plus de 20ans qu'un IP n'identifie pas une personne, ni une machine, et cela va de pire en pire d'année en année, en particulier en v4
Et on en revient au non-sens de gérer l'AAA "via un firewall": ce dernier n'a pas les informations pour faire ce travail, seul la couche 7, et une couche 7 spécifique à l'application, peut et doit faire ce travail

En fait le Firewall est souvent utilisé comme une sécurité supplèmentaire.

Tous les jours on découvre des failles de sécurité. Certaines sont critiques et ce qui bloque, c'est pour les exploiter il faut une seconde sur la seconde protection.

Un Firewall peut jouer ce rôle de seconde protection en cas de faille critique de sécurité.

Pour ne pas parler dans le vent, imagine que ce type de faille en 2008 se reproduise aujourd'hui :


Découverte d'une faille de sécurité critique dans OpenSSL de Debian

Le 13 mai, un message publié sur la liste de sécurité Debian identifiait une anomalie impactant le paquet openssl. Ce bug a été introduit par un mainteneur Debian, qui a eu la main lourde en voulant "corriger" des alertes remontées par Valgrind (un logiciel qui audite le code). Résultat des courses : le générateur de nombres aléatoires, composant critique de nombreux systèmes de chiffrements, n'est au final pas si aléatoire que ça, voire carrèment prévisible.
En conséquence, tous les certificats et clefs SSL/SSH générés sur une Debian (ou dérivée) depuis 2006 l'ont été à partir d'un univers des possibles très restreint (environ 250 000 clefs, à confirmer) et présentent donc un niveau de sécurité largement inférieur à celui estimé.

Cette vulnérabilité touche Debian ainsi que toutes les distributions utilisant des paquets Debian (Ubuntu, Xandros...).

Pour prendre un exemple parlant, imaginez Securor, un fabricant de serrures qui seraient utilisées un peu partout sur la planète. Au bout de deux ans, alors que des millions de personnes ont installé des serrures pour protéger leur maison, on se rend compte qu'en fait il n'existe que 3 modèles uniques de clefs, les autres ne sont que des copies d'un des 3 modèles d'origine. Si bien qu'un voleur peut très facilement concevoir un trousseau contenant les 3 modèles de clefs, en ayant la certitude que toute serrure rencontrée pourra être ouverte avec l'une de ces clefs...

Concrètement, si vous utilisez une Debian, ou dérivée, vos VPN peuvent être cassés (adieu confidentialité des échanges), des faux certificats peuvent être signés (adieu confiance en votre système de PKI), votre serveur SSH ne filtre plus grand monde (adieu système sécurisé)...

Que faire ?

  • Mettre à jour votre distribution Debian pour installer les nouveaux paquet.
  • Vérifier sur tous vos systèmes qu'une clé faible n'est pas présente. Pour cela, un outil est disponible : dowkd.pl
    Si une clé faible est présente, il sera nécessaire de la générer à nouveau, avec tous les impacts que cela peut avoir (fichiers authorized_keys & know_hosts obsolètes...). Même problème pour les certificats : j'espère que personne n'a mis en place de PKI sous Debian depuis 2006, il va falloir regénérer les certificats...
  • lire le wiki Debian http://wiki.debian.org/SSLkeys qui vous guidera pas à pas en fonction des logiciels installés sur votre machine.

Reste à savoir quelles seront les conséquences de cette affaire : depuis 2 ans, un bug introduit par un contributeur et impactant un système critique est resté indétecté dans une des distributions les plus utilisées au monde...

Source : LinuxFr.org le 15 mai 2008 par Amaury

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 674
  • La Madeleine (59)
IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
« Réponse #59 le: 20 mai 2018 à 15:27:06 »
En fait le Firewall est souvent utilisé comme une sécurité supplèmentaire.

Vraiment ? Ce n'est pas plutôt souvent utilisé à la place de tout le reste, comme le dit kgersten ? C'est malheureusement ce que je constate régulièrement, avec les impacts négatifs que cela apporte :/

Merci pour le lien linuxfr.org
De mon point de vue, l'exploitation de ce défaut passe majoritairement par le MitM : la clé privée d'un serveur (ssh, tls, etc) peut être devinée, ce qui permet de parfaire l'illusion
Je ne vois pas ce qu'un firewall change à cela