La Fibre

Télécom => Réseau => reseau IPv6 => Discussion démarrée par: tivoli le 28 mars 2018 à 12:14:19

Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: tivoli le 28 mars 2018 à 12:14:19
J'ai la chance d'avoir deux providers (des gros pas des alternatifs) et pourtant aucun acces IPv6 (Red FTTLA et Bouygues FTTH)

Autre point que ce soit bien ou pas beaucoup se sentent proteges par le NAT et il me semble qu'il n'y a pas une vision acceptée de ce que doit fournir un FAI comme protection en IPv6
Titre: IPv6: Le firewall
Posté par: vivien le 28 mars 2018 à 13:45:21
il me semble qu'il n'y a pas une vision acceptée de ce que doit fournir un FAI comme protection en IPv6

Tout à fait.

- Vision Free : tous les périphériques IPv6 sont accessibles directement depuis Internet, vu qu'il n'y a pas de NAT.

- Vision Orange / Orne THD : Pour offrir la même sécurité que le NAT, par défaut tous les ports entrants sont bloqués en IPv6, il faut donc ouvrir un par un les port souhaités, comme si on était derrière e un NAT, sur le firewall de la box.

- Vision Bouygues (sur le mobile comme sur la Bbox) : Tous les ports entrants sont bloqués en IPv6 et il n'est pas possible d'autoriser les flux entrants.

Qui a raison ?
Titre: IPv6: Le firewall
Posté par: tivoli le 28 mars 2018 à 13:54:14
Ma vision :
On doit protéger par défaut ET permettre l'ouverture des ports donc plutot version orange

La protection me semble necessaire car 90% des gens ne savent pas se proteger eux meme et n'avaient quasi pas a le faire en IPv4 il est donc de leur interet et de celui des hotlines d'avoir un firewall.
Il doit neanmoins etre possible de faire ce que l'on veut a l'aide d'option (gratuites)

Titre: IPv6: Le firewall
Posté par: Hugues le 28 mars 2018 à 14:36:05
A titre perso, je choisis la proposition Free : C'est au périphérique de se sécuriser.
Et avec les Privacy Extensions, la surface d'attaque est tellement énorme que je ne suis pas spécialement inquiet.

Après, un firewall qui bloque tout par défaut, pourquoi pas, juste pas celui d'Orange.
Titre: IPv6: Le firewall
Posté par: Free_me le 28 mars 2018 à 14:46:46
Ma vision :
On doit protéger par défaut ET permettre l'ouverture des ports donc plutot version orange


j'ai pas envie qu'on me protege de force. Si je veux mettre un FW c'est moi qui le met.
Titre: IPv6: Le firewall
Posté par: Nh3xus le 28 mars 2018 à 14:48:49
Parmi les abonnés chez Free, il y a aussi Monsieur et Madame tout le monde.

Tu te sens prêt à leur expliquer la conf d'un firewall perso ?
Titre: IPv6: Le firewall
Posté par: Free_me le 28 mars 2018 à 14:50:33
Parmi les abonnés chez Free, il y a aussi Monsieur et Madame tout le monde.

Tu te sens prêt à leur expliquer la conf d'un firewall perso ?

bah pour eux on leur met une option sur la box 'protection internet' activée/desactivée
Titre: IPv6: Le firewall
Posté par: Free_me le 28 mars 2018 à 14:52:39
en fait je comprend meme pas comment on peut accepter le FAI se permette de bloquer par defaut des paquets qui te sont destinés....
et bouygues ca a l'air d'etre le pire puisque tu peux rien faire a part pleurer ?
Titre: IPv6: Le firewall
Posté par: Nh3xus le 28 mars 2018 à 14:53:22
bah pour eux on leur met une option sur la box 'protection internet' activée/desactivée

Très bonne idée...

Mais pourquoi cette fonction n'est toujours pas présente alors qu'elle a été demandée en 2011 ? ( https://dev.freebox.fr/bugs/task/4110 )
Titre: IPv6: Le firewall
Posté par: Hugues le 28 mars 2018 à 14:53:35
Parce que les gens sont des cons.

Si tu laisse tout ouvert, ton réseau devient un vecteur de DoS, tes users se font trouer... Et ça te retombe dessus.
Titre: IPv6: Le firewall
Posté par: Free_me le 28 mars 2018 à 14:58:32
Parce que les gens sont des cons.

Si tu laisse tout ouvert, ton réseau devient un vecteur de DoS, tes users se font trouer... Et ça te retombe dessus.

mouais je vois.

m'enfin c'est quand meme pitoyable. En gros c'est comme si pour traverser la rue y a un flic qui doit te tenir la main et sans lui ben tu peux pas traverser. Tout ca parce que que globalement y a trop de cons qui se pourraient se faire ecraser...
Titre: IPv6: Le firewall
Posté par: Hugues le 28 mars 2018 à 15:02:15
Les gens utilisent un PC sans savoir comment il fonctionne. Moi c'est un truc qui me gave au quotidien. Mais bon, faut savoir faire avec. Sans des gens comme ça, aussi noobz soient-ils, j'aurais pas de salaire a la fin du mois :p
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: tivoli le 28 mars 2018 à 15:13:11
j'ai pas envie qu'on me protege de force. Si je veux mettre un FW c'est moi qui le met.

Le probleme c'est que avant IPv6 on etait protege, faire un changement qui impacte les utilisateurs c'est quand meme pas ideal.

Ca se finirait par : IPv6 c'est pourri depuis que je l'ai je me fais pirater
Titre: IPv6: Le firewall
Posté par: kgersen le 28 mars 2018 à 16:06:18
mouais je vois.

m'enfin c'est quand meme pitoyable. En gros c'est comme si pour traverser la rue y a un flic qui doit te tenir la main et sans lui ben tu peux pas traverser. Tout ca parce que que globalement y a trop de cons qui se pourraient se faire ecraser...

C'est simpliste et faux comme comparaison.

Si on cherche des coupables ca serait plutot Windows et les autres systèmes non sécurisés.
Ca seraient les "appliances" (imprimantes, IoT, routeur, etc) pleines de failles de sécurité.

Bref ce n'est pas l'utilisateur le responsable mais ce qu'il utilise et il n'a pas vraiment le choix.

Aujourd'hui quand une société se fait attaquer par un botnet, les IPs des attaquants sont transmisses a l'ANSSI qui renvoi le blâme aux FAI (en gros c'est aux FAI de 'faire' quelque chose).

Maintenant si chaque fois qu'un PC Windows (ou une appliance) se faisait contaminer on faisait payer une amende a Microsoft (ou au constructeur de l'appliance) au lieu de mettre ca sur le dos du FAI peut-être que les choses changeraient.

En automobile quand un véhicule a un défaut grave c'est le constructeur qui est responsable pas le conducteur ou celui qui fourni la route.

Titre: IPv6: Le firewall
Posté par: doctorrock le 28 mars 2018 à 16:46:07
En automobile quand un véhicule a un défaut grave c'est le constructeur qui est responsable pas le conducteur ou celui qui fourni la route.

Le parallèle avec la voiture et l'informatique marche dans de nombreux cas.

J'achète une voiture qui roule physiquement jusqu'à 240Km/h , mais les routes de mon pays sont limitées par les autorités à 130Km/h.
Libre à moi de franchir la limite, ou pas ; mais moi utilisateur final : j'ai le choix , et le constructeur ne m'a pas bridé.

Je n'aime pas penser que mon FAI filtre mon trafic en amont , genre il le firewalise.
Mais j'aime l'idée que des prestataires externes - comme nous , majoritairement pro - puissent aller sécuriser madame Michu si elle le demande, car son FAI ne lui propose qu'une connexion "brute" et "non sécurisée".

Concernant IPV4, IPV6 , comme pour tout, c'est la pression financière qui gagnera.
J'aime l'idée de proposer une connexion IPV6 gratuite, et de faire payer très cher la connexion IPV4  (côté client, comme serveur).

C'est en faisant en sorte que le diesel monte à un tarif délirant (c'est en cours), qu'on sortira du diesel , pas avant.  Idem pour IPV4 : tant qu'on ne tape pas fort dans le porte-feuille , rien ne bougera jamais
Titre: IPv6: Le firewall
Posté par: raf le 28 mars 2018 à 20:39:37
Ca se finirait par : IPv6 c'est pourri depuis que je l'ai je me fais pirater
Juste qu'avec les malware qui sont pas mal distribues via navigateur, ca marche tout aussi bien avec IPv4 derriere NAT.
Titre: IPv6: Le firewall
Posté par: vivien le 28 mars 2018 à 21:03:36
Plusieurs acteurs de l'internet des objets refusent IPv6, pour éviter d'être exposé directement à Internet, donc je pense qu'une protection par défaut des flux entrant est nécessaire.

Il est par contre évident qu'il faut qu'elle puisse être désactivé entièrement ou configurer pour ouvrir certains ports vers certaines IPv6 ou l'ensemble du /64.
Titre: IPv6: Le firewall
Posté par: obinou le 28 mars 2018 à 21:04:37
A titre perso, je choisis la proposition Free : C'est au périphérique de se sécuriser.
Et avec les Privacy Extensions, la surface d'attaque est tellement énorme que je ne suis pas spécialement inquiet.

Après, un firewall qui bloque tout par défaut, pourquoi pas, juste pas celui d'Orange.

Moi j'aime bien la solution d'Orange, justement : La box ne fait plus NAT mais t'a bien un firewall par défaut, que tu peux débloquer.
Après tout, actuellement quand t'a ce type de besoin t'es bien déjà obligé de rediriger un port (Ou d'utiliser UPNP... qu'on pourrait étendre pour la même logique).
Ya des tuto partout pour expliquer ce système de redirection, et si ca arrive en IPv6 t'inquiète pas que les gens le feront vite aussi.

Le truc c'est que même avec une surface d'attaque réduite (via l'utilisation - non systématique :-( - de la rfc privacy extension) , on peut très bien imaginer que la collecte des IP se fasse différemment , via des exploits sur les serveurs web ou mail, de routeurs...

Ca me dérange pas la sécurité par défaut tant que l'utilisateur a le contrôle. La "solution" de bouygues .... j'en reste sur le derrière , ça veux dire qu'un mec qui veux héberger un NAS doit se monter un tunnel...  :o
 
(Moi sur ma BBox, déjà j'ai pas d'IPV6 (je pige pas pkoi),  le port 25 est bloqué par défaut, mais tu peux le désactiver. Par contre je me suis rendu compte que le réseau bouygues refuse d'acheminer les paquets sortant sur le port 445 vers leur destination, et ça c'est pas configurable ....  J'en comprends la raison mais quand même)

Bref sur ces points-là, Bouygues, que par ailleurs j'aime bien, me saoule au plus haut point en m'obligeant à utiliser des VPN partout pour ce genre de détails .

Titre: IPv6: Le firewall
Posté par: kgersen le 29 mars 2018 à 08:49:55
Moi j'aime bien la solution d'Orange, justement : La box ne fait plus NAT mais t'a bien un firewall par défaut, que tu peux débloquer.
Après tout, actuellement quand t'a ce type de besoin t'es bien déjà obligé de rediriger un port (Ou d'utiliser UPNP... qu'on pourrait étendre pour la même logique).

sauf que l'implèmentation d'Orange est mal faite. Le firewall IPv6 est une simple copie du firewall IPv4 donc ne fonctionne qu'avec UDP et TCP: on ne peux ouvrir une IPv6 entière sur l’extérieur , on ne peut ouvrir que des ports UDP ou TCP. En plus la box ne permet pas d'exploiter le /56. Le déblocage c'est tout ou rien donc on ne peut exposer a 100% que quelques IPv6. C'est tout le /64 ou rien.

Un des avantages d'IPv6 étant justement de pouvoir enfin utiliser autre chose qu'UDP et TCP c'est un très dommage.
Titre: IPv6: Le firewall
Posté par: obinou le 29 mars 2018 à 08:54:31
sauf que l'implèmentation d'Orange est mal faite. Le firewall IPv6 est une simple copie du firewall IPv4 donc ne fonctionne qu'avec UDP et TCP: on ne peux ouvrir une IPv6 entière sur l’extérieur , on ne peut ouvrir que des ports UDP ou TCP. En plus la box ne permet pas d'exploiter le /56. Le déblocage c'est tout ou rien donc on ne peut exposer a 100% que quelques IPv6. C'est tout le /64 ou rien.

Un des avantages d'IPv6 étant justement de pouvoir enfin utiliser autre chose qu'UDP et TCP c'est un très dommage.

Ah ok , ça je ne savais pas - je ne suis pas familier des livebox.

Effectivement, je te rejoins à 100% sur ces points - d'autant que j'utilise IPIP et GRE à titre perso.

Il doit y avoir une raison pour laquelle ça marche si mal. Chez Free c'est pareil, j'ai jamais réussi à utiliser leur système , vu qu'ils ne diffusent que le /64 au lieu du /60 attribué, ce qui complique largement la gestion de sous-réseaux. Bref.... :-(


Titre: IPv6: Le firewall
Posté par: Hugues le 29 mars 2018 à 12:50:00
Ne vous en faites pas. Vu les performances à pleurer en v6 sur autre chose que TCP/UDP, c'est pas une grosse perte.
Titre: IPv6: Le firewall
Posté par: kgersen le 29 mars 2018 à 14:23:36
Ne vous en faites pas. Vu les performances à pleurer en v6 sur autre chose que TCP/UDP, c'est pas une grosse perte.

performances de quoi? des stacks des OS?
t'as des exemples/benchs ?
un routeur highperf qui route du v6 s'en tape si c'est de l'udp ou du tcp ou autre non ?

et on peut tres bien vouloir utiliser autre que chose que tcp/udp sans pour autant avoir besoin de perf. cf DCCP par exemple.
Titre: IPv6: Le firewall
Posté par: doum le 29 mars 2018 à 17:28:46
mouais je vois.

m'enfin c'est quand meme pitoyable. En gros c'est comme si pour traverser la rue y a un flic qui doit te tenir la main et sans lui ben tu peux pas traverser. Tout ca parce que que globalement y a trop de cons qui se pourraient se faire ecraser...

comparaison completement nul
traverser une rue c'est un truc que tes parents t'aprennent des ton plus jeune age (attendre le feu vert, regarder a gauche et a droite), et c'est a la portée de tout le monde, y compris les moins doués.
savoir sécurisé un systeme informatique (ouais parceque faut arreter, y'a pas que Windows qui a des failles loin de la...) ca ne l'est pas.

Si tu veux une offre pro y'en a, tu prends une offre pro et tu mets le firewall que tu veux, ou rien si t'es un warrior.

faut pas oublier que sur nos reseaux domestique il n'y a pas qu'un ordi...Il y a une console de jeu (va savoir si y' a des failles et va y installer un firewall...), des lecteurs multimedia, des NAS, des decodeurs tv, de la domotique, et demain des frigos...

donc dans le cadre d'une offre grand public, je trouverai hallucinant qu'on fournisse un truc en mode open bar tout ouvert et demerde toi. Tout le monde n'est pas ingé réseau.

Pour moi la meilleure solution c'est tout fermé par défaut, mais avec une bonne interface et des bonnes features pour que ceux qui savent puissent faire ce qu'ils veulent.
Titre: IPv6: Le firewall
Posté par: Hugues le 29 mars 2018 à 18:07:00
performances de quoi? des stacks des OS?

De la livebox. Elle sature a 150-200Mbit/s (selon tes règles de FW) sur autre chose que TCP ou UDP.

Mes tunnels GRE6 ont besoin de patate, eux :)
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: obinou le 29 mars 2018 à 20:13:08
.... avec une bonne interface
... bien sécurisée pour éviter qu'un simple coup de javascript puisse pourrir les réglages :-)
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: patrick_01 le 30 mars 2018 à 13:34:43
Ma réponse à la question d'origine : à choix, avec trois options :
- tout bloqué (pour ceux qui n'y connaissent rien)
- bloqué par défaut, avec la possibilité par une interface basique d'ouvrir des ports/destinations (pour ceux qui y connaissent quelque chose, mais qui ne sont pas certains de savoir ce qu'ils font)
- aucun blocage, le client sécurise ses machines et/ou installe son firewall (pour ceux qui connaissent vraiment)

Le parallèle avec la bagnole a quand même ses limites :

Il y a des lois qui m'obligent à rouler au-dessous de 130 sur autoroute et prévoient une punition même si mon dépassement de vitesse est sans conséquences.
Il n'y a pas de loi qui m'oblige à protéger mon équipement informatique et qui me punira en cas de négligence, tant que cette négligence ne nuit à personne d'autre que moi. Ce n'est que dans des cas - rares - où le défaut de sécurisation a des conséquences qui, elles, tombent sous le coup de la loi, qu'on va retenir ma négligence contre moi.
Je ne suis pas juriste, mais il me semble que ça change quand même un peu la donne...
Et puis, la différence de niveau de maîtrise de l'équipement informatique entre des clients sans connaissances et les gens qui visitent ce forum - par exemple - est quand même plus large que la différence ce maîtrise de leur voiture entre deux conducteurs.
Titre: IPv6: Le firewall
Posté par: raf le 31 mars 2018 à 04:42:59
Si tu laisse tout ouvert, ton réseau devient un vecteur de DoS, tes users se font trouer... Et ça te retombe dessus.
Essaye ca en IPv6.....
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: raf le 31 mars 2018 à 04:50:27
- tout bloqué (pour ceux qui n'y connaissent rien)
- bloqué par défaut, avec la possibilité par une interface basique d'ouvrir des ports/destinations (pour ceux qui y connaissent quelque chose, mais qui ne sont pas certains de savoir ce qu'ils font)
Il me semble assez raisonnable de supposer qu/une personne qui n'y connais rien ne peut pas ouvrir des "ports/destinations" dans son firewall. Ce qui rend l'option "tout bloque (point)" inutile.
En effet l'option "tout bloque (point)" ne devais pas exister en tant que tel.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Kingsize le 15 mai 2018 à 00:34:33
Il paraît même que des gens utilisent des voitures sans être expert en mécanique et électronique ;).

Plus sérieusement si je peux ajouter un mot sur la discussion : on ne maîtrise pas tout sur son LAN... Imprimante, caméra, tv, console de jeu, smartphone ... Le pc finalement c'est un élèment minoritaire
Alors faudra faire un choix entre "je veux pas être bloqué de force par mon fai" et "j'ai aucun contrôle sur la moitié (les 3/4?) de mon lan..."

Perso je préfère que personne ne parle à mo  n imprimante ou ma caméra... Voire j'aime autant qu'une caméra ne parle aussi à personne en dehors de mon lan...
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: patrick_01 le 16 mai 2018 à 22:18:10
Il paraît même que des gens utilisent des voitures sans être expert en mécanique et électronique ;).
C'est vrai. C'est mon cas, d'ailleurs, et mon garagiste se frotte les mains à chaque fois que je dois lui amener ma voiture...

Plus sérieusement si je peux ajouter un mot sur la discussion : on ne maîtrise pas tout sur son LAN... Imprimante, caméra, tv, console de jeu, smartphone ... Le pc finalement c'est un élèment minoritaire
(...)
C'est aussi vrai. Le vrai problème, c'est souvent plus ce qui sort que ce qui rentre.

Il n'y a pas besoin d'avoir des "ports ouverts" pour choper des saloperies généralement les connections viennent de l'intérieur.
Et de plus en plus de gadgets connectés, en plus de "téléphoner maison" dès qu'ils sont connectés à quelque chose, sont une vaste rigolade en termes de sécurité.

La configuration idéale, c'est des réseaux séparés pour les machines d'utilisation sérieuse sur lesquelles on fait un peu gaffe, celles éventuelles de jeu en ligne ou autres trucs qui sont moins sécurisés, et les gadgets où on n'a pas du tout la maîtrise de l'OS/du firmware, j'inclus d'ailleurs dans cette catégorie les smartphones et tablettes d'un bord ou de l'autre.
Plus naturellement une DMZ pour les trucs qui doivent vraiment être accessibles depuis le wild internet, mais c'est généralement pas là qu'il y a le plus de risques si on sait tenir à jour ses serveurs.
Évidemment, avec ce genre de config on se retrouve vite avec cinq ou six LANs, donc il faut le matos qui va bien et savoir le configurer, c'est le cas de beaucoup qui traînent sur ce forum, mais pas forcèment dans la vraie vie.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: vivien le 16 mai 2018 à 22:27:21
Il n'y a pas besoin d'avoir des "ports ouverts" pour choper des saloperies généralement les connections viennent de l'intérieur.

Oui, aujourd'hui le ports sont fermés et pourtant il existe des objets connectés qui sont utilisés dans des botnet sans ports ouverts.

Mais si tous les objets co / smarphones avaient une IP publique visible de l'intégralité de l'Internet, je t'assure qu'on aurait bien plus de cas...

D'ailleurs une bonne partie des objets co en botnet sont ceux avec un port ouvert (type caméra de vidéosurveillance)
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Nh3xus le 16 mai 2018 à 23:26:20
Citer
D'ailleurs une bonne partie des objets co en botnet sont ceux avec un port ouvert (type caméra de vidéosurveillance)

Merci l'Upnp qui est une cochonnerie dont abusent les caméras et les consoles de jeux.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Kingsize le 17 mai 2018 à 00:00:45


La configuration idéale, c'est des réseaux séparés pour les machines d'utilisation sérieuse sur lesquelles on fait un peu gaffe, celles éventuelles de jeu en ligne ou autres trucs qui sont moins sécurisés, et les gadgets où on n'a pas du tout la maîtrise de l'OS/du firmware, j'inclus d'ailleurs dans cette catégorie les smartphones et tablettes d'un bord ou de l'autre.
Plus naturellement une DMZ pour les trucs qui doivent vraiment être accessibles depuis le wild internet, mais c'est généralement pas là qu'il y a le plus de risques si on sait tenir à jour ses serveurs.
Évidemment, avec ce genre de config on se retrouve vite avec cinq ou six LANs, donc il faut le matos qui va bien et savoir le configurer, c'est le cas de beaucoup qui traînent sur ce forum, mais pas forcèment dans la vraie vie.


Hello!
C'est peut-être ideal pour la sécurité mais c'est pas terrible pour utiliser son lan :)
Connecter un camera au nas ?
Utiliser une appli domotique sur son smartphone avec son serveur orange pi ?
Transferer des fichier de la tablette au tel ?
Lire la musique du nas depuis une playstation ?

Quelques exemples qui deviennent vite compliqués si on segmente tout
Personnellement j'ai pas grand chose sur mon lan qui peut vivre seul dans son coin.
Mais bon chacun a une situation différente !

Pour revenir au sujet, non un firewall n'assure pas une protection totale, mais c'est deja ça + le petit bonus de pouvoir bloquer certaines connexions sortante (les  "téléphoner maison")
A l'époque où j'avais un pc Windows (c'était xp... Ca vous donne une idée de l'époque), je me souviens de quantités d'applications qui voulaient une connexion sortante (j'avais un firewall qui me posait la question).
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Optix le 17 mai 2018 à 07:36:51
A l'époque où j'avais un pc Windows (c'était xp... Ca vous donne une idée de l'époque), je me souviens de quantités d'applications qui voulaient une connexion sortante (j'avais un firewall qui me posait la question).

ZoneAlarm ? :p
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: patrick_01 le 17 mai 2018 à 09:23:43
C'est peut-être ideal pour la sécurité mais c'est pas terrible pour utiliser son lan :)
Oui, c'est certain, le plus sûr n'est pas le plus simple à utiliser ni à mettre en place.
C'est comme dans la vie physique. J'aimerais bien pouvoir laisser toutes les portes ouvertes chez moi, au travail, ne pas devoir cadenasser mon vélo et ne pas me promener avec une dizaine de clés en permanence dans la poche.

Connecter un camera au nas ?
Utiliser une appli domotique sur son smartphone avec son serveur orange pi ?
Transferer des fichier de la tablette au tel ?
Lire la musique du nas depuis une playstation ?
Ce n'est jamais que des règles d'accès sur un routeur ou un firewall.

Personnellement j'ai pas grand chose sur mon lan qui peut vivre seul dans son coin.
Moi non plus, d'ailleurs par définition un truc qui vit tout seul dans son coin n'a pas besoin d'être en réseau. Mais ne pouvoir atteindre que ce qui est justifié, ce n'est déjà plus être tout seul dans son coin.

Oui, aujourd'hui le ports sont fermés et pourtant il existe des objets connectés qui sont utilisés dans des botnet sans ports ouverts.
C'est sûr, c'est pour ça qu'il ne faut, dans la mesure du possible, soit pas leur donner accès à autre chose qu'à un truc local (cas de la caméra qui enregistre sur le NAS), soit les laisser libres d'accéder à l'extérieur mais dans ce cas leur interdire les connexions vers l'intérieur du réseau.

Les fabricants de matos connectés, téléphones et autres préfèrent qu'on mette tout sur le même LAN, et que ce LAN ait un accès complet à Internet, évidemment. Les opérateurs de botnet aussi. Et les opérateurs livrent des "box" qui sont plus ou moins faites pour ça, et tout le monde s'en contente...
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: raf le 18 mai 2018 à 21:53:10
Cote securite end-user:
Ca fait deja 8 and que chez moi je tourne avec IPv6 sans firewall. Quand je dis sans firewall je veux dire que les connexions entrantes sont autorises au niveau du routeur. Plusieurs equipements : PC Linux et Windows (commence avec du XP, puis 7, 8, 8.1, 10), plusieurs telephones et tablettes (Apple et Android), imprimante et encore 2-3 autre choses qui utilisent de l'IPv6. Cahcun avec sa facon de s'autosecuriser (ou pas).

Pendant quelques annees (surtout a l'epoque du XP) je faisais encore des scans reguliers, je regardais ce qui se passe sur v6. Resultat des courses : JAMAIS RIEN. Ca fait un bon bout de temps que j'ai arrete.

Explication: un seul subnet en IPv6 c'est par default 64 bits. Ca fait 4 milliards de fois tout l'espace d'adressage IPv4 pour un seul pauvre subnet. Combien avec les "privacy adresses" (default sur tous les OS recents), et le fait d'utiliser pas mal des 64 bits disponibles, meme en adressage statique, il devient totalement impossible de tomber sur un equipement actif au hasard. Il y a certes des choses beaucoup plus avances pour detecter les hosts dans un /64, mais la on passe dans des attaques ciblees. Il faut trouver un raisonnement bien plus interessant que trouver quelques hosts mal/non-securises pour ajouter a un botnet.

Donc meme si le fait de vouloir mettre un niveau de securite cote routeurs/IAD/CPE est un chose louable, techniquement c'est un chose parfaitement inutile. Comme je disais, il y a des saloperies qui se propagent tres bien vers des PC v4-only derriere NAT/firewall/whatever.

Repetez donc apres moi: IPv6 est naturellement plus secure en raison de la taille de l'espace d'adressage.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Hugues le 18 mai 2018 à 22:02:30
+1, pareil ici, et jamais rien :)
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: kgersen le 18 mai 2018 à 23:24:22
Repetez donc apres moi: IPv6 est naturellement plus secure en raison de la taille de l'espace d'adressage.

non. c'est aussi faux que dire IPv4 est secure a cause du NAT.

Ton exemple unique ne fait pas une généralité. En plus t'es du métier, encore heureux que tu te soit pas fait 'percer'.

Le souci c'est l'utilisateur lambda pas le pro du métier. Le souci sont les bugs/failles exploitables parce que c'est ouvert.

Les PC Windows qui partagent des fichiers en ouvrant tout parce que l'utilisateur n'a pas fait les bonnes manips sont fréquents et meme si on ne peut 'deviner' leur IPv6 on peut facilement en recuperer par fishing via emails ou sites 'attrape pigeons'.

Idem pour les web cam réseau mal configurées.

En plus faire un scan régulier ne prouve rien, si a un moment quelqu'un est entré et a fait quelque chose tu ne l'a peut-être pas vu (je dis pas que c'est ton cas juste que le scan ne prouve rien).

Le plus gros souci c'est qu'IPv6 devient de plus en plus fréquent en grand public et de plus en plus connu et utilisé du coté des 'bad guys' aussi. On est phase de monter assez forte donc il faut s'attendre a de plus en plus de problemes.

C'est pour ca qu'au minimum un statefull firewall par defaut, pour le grand public, est plus que louable. En plus ca ne genre en rien.

petit exemple: https://www.shodan.io/search?query=%28%22openwrt%22+OR+%22dd-wrt%22+OR+%22dnsmasq%22+OR+%28%22tomato%22+%22firmware%22%29%29+port%3A53+has_ipv6%3Atrue (ne pas se fier au pays indiqué, la base IPv6 de shodan n'est pas géolocalisée).
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: kazyor le 19 mai 2018 à 11:56:07
Repetez donc apres moi: IPv6 est naturellement plus secure en raison de la taille de l'espace d'adressage.

Mmmh, un billet de blog que j'ai lu récemment : http://netpatterns.blogspot.fr/2016/01/the-rising-sophistication-of-network.html (http://netpatterns.blogspot.fr/2016/01/the-rising-sophistication-of-network.html)

En résumé :


Bref, de mon côté, je me suis intéressé à ipv6 et à sa sécurité (firewall / fail2ban / etc.) que récemment.
Je n'ai toujours pas l'impression de maitriser. Du coup je suis plutôt du genre à recommander aux Mme Michus qui m'entourent de ne pas l'activer quand ils ont le choix avec leur FAI ...
Pour eux, avec ipv6 le gain est nul et pour moins c'est des problèmes en moins à gérer :D
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: kazyor le 19 mai 2018 à 11:59:10
A l'époque où j'avais un pc Windows (c'était xp... Ca vous donne une idée de l'époque), je me souviens de quantités d'applications qui voulaient une connexion sortante (j'avais un firewall qui me posait la question).

Amusez-vous à installer sur Android l'appli NetGuard (opensource et pas besoin de root) vous serez surpris par toutes les requêtes sortantes ...
Et en mode paranoïa, ça fait peur :)
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Hugues le 19 mai 2018 à 12:28:19
En résumé :
  • Tous les appareils font une requête sur les pools NTP à un moment ou un autre.
  • Les pools officiels et defaults de debian contiennent des serveurs ipv6 qui collectent les ip sources.
  • Shodan lance un scan sur l'ip peut après.
C'est pour ça qu'on a mis en place les Privacy Extensions :)
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Nh3xus le 19 mai 2018 à 12:32:07
C'est pour ça qu'on a mis en place les Privacy Extensions :)

Oui voilà.

C'est très rare de voir un système qui utilise l'EUI-64 à la place des privacy extensions par défaut.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: kazyor le 19 mai 2018 à 12:36:32
Faut que je me renseigne sur ce point alors :)

Rapidement, je lis que le Time Out classique est de 24h ... Suffisant ?
J'ai aucune idée de la fréquence "classique" des requêtes NTP :)
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: raf le 19 mai 2018 à 17:24:36
Le souci c'est l'utilisateur lambda
Justement, a ce niveau la il y a de moins en moins de soucis.

Le souci sont les bugs/failles exploitables parce que c'est ouvert.
Ce n'est plus un souci. C'est ce que j'essaye d'expliquer. Un /64 ca fait 18446744073709551616 adresses. Trouve dedans les 10 ou 100 ou 1000 qui sont sur un equipement.

Les PC Windows qui partagent des fichiers en ouvrant tout parce que l'utilisateur n'a pas fait les bonnes manips sont fréquents et meme si on ne peut 'deviner' leur IPv6 on peut facilement en recuperer par fishing via emails ou sites 'attrape pigeons'.
N'importe quoi:
 - des default des OS recent sont immensement plus securises qu'il y a 5 ou 10 ans.
 - si on doit passer par la casse phishing, il y a deja assez de degats pour pouvoir tranquilement dire que l'IPv6 n'a strictement aucune importance. Ca marche sufisamment bien en IPv4 derriere NAT.

Idem pour les web cam réseau mal configurées.
Toujours le meme n'importe quoi.

En plus faire un scan régulier ne prouve rien, si a un moment quelqu'un est entré et a fait quelque chose tu ne l'a peut-être pas vu (je dis pas que c'est ton cas juste que le scan ne prouve rien).
Vu comme ca, tous tes arguments ne prouvent rien. Je vois de plus en plus d'utilisateurs qui ne savent plus utiliser le partage de fichier ou des equipements qui malgre le fait qu'ils ne supoprtent pas IPv6 sont bel et bien hackables.

Le plus gros souci c'est qu'IPv6 devient de plus en plus fréquent en grand public et de plus en plus connu et utilisé du coté des 'bad guys' aussi. On est phase de monter assez forte donc il faut s'attendre a de plus en plus de problemes.
Le vrai probleme c'est que les "bad guys" n'ont pas besoin d'IPv6, je dirais meme que ce leur rapporte quasiment rien (tres peu et pour des cas tres specifiques).

C'est pour ca qu'au minimum un statefull firewall par defaut, pour le grand public, est plus que louable. En plus ca ne genre en rien.
Ca rend la situation quasiment au meme niveau qu'en IPv4 avec NAT. De point de vue pratique c'est exactement au meme niveau.

petit exemple: https://www.shodan.io/search?query=%28%22openwrt%22+OR+%22dd-wrt%22+OR+%22dnsmasq%22+OR+%28%22tomato%22+%22firmware%22%29%29+port%3A53+has_ipv6%3Atrue (ne pas se fier au pays indiqué, la base IPv6 de shodan n'est pas géolocalisée).
Exemple de quoi ? De resolvers DNS, plus precisement dnsmasq ? Essaye avec un des parametres un peu plus realistes (deja enleve dnsmasq), ca change...

Va falloir arreter la paranoia, la securite par le reseau il faut uniquement la faire de facon 100% controlee - ce qui n'est pas le cas quand c'est le FAI qui te l'impose, en plus avec un box qui doit couter au minimum et doit avoir plusieurs chats (plus importants) a fouter.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: kgersen le 19 mai 2018 à 17:39:21
Toujours le meme n'importe quoi
pourtant je vois tout les jours des webcam laissées avec le mdp par défaut. tres facile a choper par js via un site.

Je crois qu'on se comprend pas sur le fait qu'IPv6 n'apporte pas plus de sécurité qu'IPv4 (ce qui je pense). Le fait que les IPv6 soient difficiles a trouver ou non permanentes est une illusion de sécurité et protection.

Ca rend la situation quasiment au meme niveau qu'en IPv4 avec NAT. De point de vue pratique c'est exactement au meme niveau.
la dessus on est d'accord. IPv6 n'apporte pas plus de sécurité.

Va falloir arreter la paranoia, la securite par le reseau il faut uniquement la faire de facon 100% controlee - ce qui n'est pas le cas quand c'est le FAI qui te l'impose, en plus avec un box qui doit couter au minimum et doit avoir plusieurs chats (plus importants) a fouter.

on demande juste un opt-in par défaut du fw avec un opt-out manuel , rien de plus. De toute facon les FAI le feront d'eux-même quand le nombre d'IPv6 participants a des botnets que l'ANSSI lui rapportera sera trop important a gerer (ce qui fut le cas avec IPv4).
Tu peux pas demander a mr tout le monde d'assumer lui-meme sa sécurité.

Certes les PC et autres devices font des progrès aussi mais on en est pas encore au point ou tout est blindé pour être a nu en direct sur le Net. Dans le future peut-être quand IPv6 sera la norme et que tout sera 'battle tested' avant d'être mis entre les mains du grand public.

fait le test https://ipv6.chappell-family.com/ipv6tcptest/ avec un android par exemple derriere une box sans firewall IPv6.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: raf le 19 mai 2018 à 17:40:08
  • Tous les appareils font une requête sur les pools NTP à un moment ou un autre.
  • Les pools officiels et defaults de debian contiennent des serveurs ipv6 qui collectent les ip sources.
  • Shodan lance un scan sur l'ip peut après.
Oui et ?
Ok, ca trouve des choses.
Ok, certains equipements en question n'utilisent pas les privacy addresses
Ok, certains ne sont pas derriere un firewall

1. Le dataset : ca fait quelle taille ? ca represente quoi exactement ? qui a acces ? (OK, tout le monde ou presque)
2. Qui d'autre peut mettre en place quelque-chose de similaire pour collecter des donnees a un tel niveau ? Qui peut faire mieux ?

Une fois qu'on a repondu correctement a ces questions, les choses n'ont plus l'air pareil.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: raf le 19 mai 2018 à 17:48:38
pourtant je vois tout les jours des webcam laissés avec le mdp par défaut. tres facile a choper par js via un site.

Je crois qu'on se comprend pas sur le fait qu'IPv6 n'apporte pas plus de sécurité qu'IPv4 (ce qui je pense). Le fait que les IPv6 soient difficiles a trouver ou non permanentes est une illusion de sécurité et protection.
la dessus on est d'accord. IPv6 n'apporte pas plus de sécurité.
Effectivement on se comprend mal. IPv6 en mode open bar n'apporte pas plus d'INsecurite.

on demande juste un opt-in par défaut du fw avec un opt-out manuel , rien de plus. De toute facon les FAI le feront d'eux-même quand le nombre d'IPv6 participants a des botnets que l'ANSSI lui rapportera sera trop important a gerer (ce qui fut le cas avec IPv4).
En attendant, pas de firewall vaut mieux qu'un mauvais firewall (pas deactivable ou qui fait shuter vilamment les performances).
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: kgersen le 19 mai 2018 à 17:51:44
En attendant, pas de firewall vaut mieux qu'un mauvais firewall (pas deactivable ou qui fait shuter vilamment les performances).

ca c'est certain.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Hugues 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...
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: vivien 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.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Hugues 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.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Fuli10 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).
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: jack 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,
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: vivien 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 (https://tools.ietf.org/id/draft-camwinget-tls-use-cases-00.html), 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.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: kgersen 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.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: jack 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 (https://en.wikipedia.org/wiki/Multipath_TCP), 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é)
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: kgersen 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.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: jack 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
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: vivien 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 ?


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 (https://linuxfr.org/news/d%C3%A9couverte-dune-faille-de-s%C3%A9curit%C3%A9-critique-dans-openssl-de-deb) le 15 mai 2008 par Amaury
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: jack 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
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: vivien le 20 mai 2018 à 15:50:21
Mettre une clé SSH et un firewall pour accéder au port d’administration, c'est un exemple concret de double sécurité redondante : une seule sécurité est cesser suffire sauf quand une a un bug.

On peut trouver de nombreux exemple dans les failles multiples utilisées à l’occasion du concours Pwn2own, pour passer plusieurs protections : il faut exploiter plusieurs failles zero-day pour pouvoir réussir à sortir d'une machine virtuelle VMware depuis un navigateur : "Elle a ainsi obtenu la somme de 105 000 dollars pour avoir exploité une vulnérabilité de dépassement de tas dans le navigateur Microsoft Edge qui a été enchaînée avec une vulnérabilité de confusion de type dans le noyau Windows, puis en tirant parti d'un tampon non initialisé dans VMware Workstation." ou "110 000 dollars lui ont été attribué pour avoir exploité une vulnérabilité dans les versions stables et bêta de Google Chrome, via une élévation de la mémoire tampon de ce dernier, le tout en utilisant un point faible au niveau du noyau Windows pour accéder au sein même du système." ou "Les membres de l’équipe ont également réussi à obtenir des privilèges système avec leur attaque. Pour y parvenir, ils ont exploité avec succès quatre vulnérabilités : une dans Chrome, deux dans Flash et une autre dans le noyau Windows." ou "L'exploit combinait deux vulnérabilités, l’une dans Safari et l’autre dans un processus permettant une escalade de privilège." ou  "ils ont utilisé une faille UAF dans Safari qu’ils ont combinée à trois bogues logiques et une dérogation de pointeur null qu’ils ont exploitée sur Safari pour élever leurs privilèges en root sur macOS

Bref, sécuriser de façon redondante limite les risques.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: jack le 20 mai 2018 à 15:53:39
Vu qu'on est parti sur la gloire des firewall et leurs impacts bienveillant sur le monde actuel, voici un autre cas magnifique : le mail (et le spam)

Chez free, ils prennent le problème du spam très au sérieux : le port TCP 25 est bloqué par défaut #team-firewall
Et toujours chez free:
root@debian:~# telnet smtp.free.fr 587
Trying 2a01:e0c:1::25...
Connected to smtp.free.fr.
Escape character is '^]'.
220 smtp4-g21.free.fr ESMTP Postfix
EHLO est.fr
250-smtp4-g21.free.fr
250-PIPELINING
250-SIZE 78643200
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH CRAM-MD5 DIGEST-MD5
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM: vivien@lafibre.info
250 2.1.0 Ok
RCPT TO: testing@jack.fr.eu.org
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: un super test !
 
Blablabl mon body est cool et complétement legit

.
250 2.0.0 Ok: queued as 7C58919F5C6
^]
telnet> q
Connection closed.

Et sur mon serveur:
May 20 15:50:42 jack postfix/smtpd[4762]: NOQUEUE: reject: RCPT from smtp4-g21.free.fr[212.27.42.4]: 550 5.7.1 <testing@jack.fr.eu.org>: Recipient address rejected: Please see http://www.openspf.net/Why?s=mfrom;id=vivien%40lafibre.info;ip=212.27.42.4;r=jack.fr.eu.org; from=<vivien@lafibre.info> to=<testing@jack.fr.eu.org> proto=ESMTP helo=<smtp4-g21.free.fr>

Niquel, merci pour votre participation dans la lutte du spam :)


M'enfin

Tu peux avoir un firewall sur les terminaisons, cela n'a d'impact que pour toi
Avoir un firewall sur un node médian est une catastrophe
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: kgersen le 20 mai 2018 à 23:24:57
le firewall c'est comme la démocratie, c'est le moins pire par rapport a un existant. Dans la théorie et dans l'absolue oui on ne devrait pas avoir de fw et faire tout au niveau 7. Mais la pratique est tout autre du moins sur l'existant actuel et la tonne de trucs 'legacy' a supporter encore.

La sécurité c'est toujours une question de compromis malheureusement.
Vouloir un absolue parfais ou chaque élèment du réseau est parfais c'est en l'état actuel complètement utopique. D'autant que souvent le problème est humain (erreur de paramètres , mauvaise config (le copier/coller idiot de stackexchange est très a la mode de nos jours), bugs de soft, etc).

y'a des trucs tellement 'unsafe' et pas a jour qu'on trouve sur des LAN que seul un fw en bordure permet de protéger (plus ou moins d'ailleurs). Y'a plein de truc qui n'ont pas d'options au niveau 7 pour la sécurité. Si t'as webcam n'a pas de notion de compte utilisateur faut bien limiter l'accès d'une certaine manière (y'a toujours le reverse proxy mais ca necessite de subnetter  ou autre bidouille).

Apres il faut reconnaître la flemme des admins, l'emprise des vendeurs de firewall sur certains DSI, la pensée unique qui sévit pas mal, etc.

J'ai donné quelques cours sur IPv6 a un moment , 90% des gens ont du mal a raisonner autrement que par rapport a IPv4. C'est très long de faire comprendre que le meilleur moyen d'apprendre IPv6 proprement c'est d'oublié complètement IPv4 avant.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Hugues le 20 mai 2018 à 23:31:37
J'ai donné quelques cours sur IPv6 a un moment , 90% des gens ont du mal a raisonner autrement que par rapport a IPv4. C'est très long de faire comprendre que le meilleur moyen d'apprendre IPv6 proprement c'est d'oublié complètement IPv4 avant.
Complètement. Et le truc qui me gave le plus, c'est les experts (autoproclamés) qui te disent "c'est juste plus d'IPs"
Pour vulgariser au quidam, oui. Pour les admins réseau, c'est une logique totalement différente. Une IP n'est plus un device, un sous réseau est virtuellement infini... Plein de détails... Faudrait en faire un post a l'occasion tiens !
 
Titre: IPv6: Le firewall
Posté par: xillibit le 10 août 2019 à 11:11:54
Tout à fait.

- Vision Free : tous les périphériques IPv6 sont accessibles directement depuis Internet, vu qu'il n'y a pas de NAT.

- Vision Orange : Pour offrir la même sécurité que le NAT, par défaut tous les ports entrants sont bloqués en IPv6, il faut donc ouvrir un par un les port souhaités, comme si on était derrière e un NAT, sur le firewall de la box.

- Vision Bouygues (sur le mobile comme sur la Bbox) : Tous les ports entrants sont bloqués en IPv6 et il n'est pas possible d'autoriser les flux entrants.

Qui a raison ?
Et chez SFR ça se passe comment ?
Titre: IPv6: Le firewall
Posté par: Oyodo le 10 août 2019 à 12:25:18
Et chez SFR ça se passe comment ?

IPv6 toujours en attente chez eux :D

/s
Titre: IPv6: Le firewall
Posté par: tomfibre le 10 août 2019 à 14:54:51
Et chez SFR ça se passe comment ?
D'après ma box (après activation manuel de l'ipv6)
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Strangelovian le 31 août 2019 à 13:20:00
Ma position c'est oui, par défaut.
Je me suis amusé à logguer dans un kibana avec module geo-ip les sollicitations "spontanées" venu depuis le WAN orange.
Au bout de 2 semaines, j'avais tous les pays du monde représentés, sans exception.
Au top, Ukraine, Russie, USA, Chine... (port au top 22 lolilol, mais aussi netbios...  ::))

Avec toutes les merdes IoT qu'on a aujourd'hui, à mon avis c'est plus sur d'autoriser les connexions externes uniquement sur le strict nécéssaire, c'est à dire rien pour monsieur et madame tout le monde.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: cali le 31 août 2019 à 17:26:10
Non.

C'est à l'hôte d'avoir un pare-feu correcte.

Autrement ça ne doit pas avoir le droit de s'appeler accès à l'Internet.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: renaud07 le 31 août 2019 à 17:44:13
Chacun campe sur ses positions...

Pour un LAN, je préfère avoir un pare-feu général, surtout si on a pas trop l'envie de passer sur toutes les machines.

Après dans un contexte hébergeur, chacun doit s'occuper de la protection de ses serveurs, ça me parait évident. Ce n'est pas à l'hébergeur de mettre en place un pare-feu.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: kgersen le 31 août 2019 à 17:52:14
Ma position c'est oui, par défaut.
Je me suis amusé à logguer dans un kibana avec module geo-ip les sollicitations "spontanées" venu depuis le WAN orange.
Au bout de 2 semaines, j'avais tous les pays du monde représentés, sans exception.
Au top, Ukraine, Russie, USA, Chine... (port au top 22 lolilol, mais aussi netbios...  ::))

Avec toutes les merdes IoT qu'on a aujourd'hui, à mon avis c'est plus sur d'autoriser les connexions externes uniquement sur le strict nécéssaire, c'est à dire rien pour monsieur et madame tout le monde.

en IPv6 ? c'est curieux.

en IPv4 il y a plein de boites & services de sécurité qui scannent tout l'espace IPv4 en permanence (shodan.io par exemple) donc toutes les IPv4 au monde vont recevoir régulierement des tentatives de connections sur les ports sensibles (22, netbios, etc).
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Strangelovian le 31 août 2019 à 17:52:51
Non.

C'est à l'hôte d'avoir un pare-feu correcte.

Autrement ça ne doit pas avoir le droit de s'appeler accès à l'Internet.
Tu as raison, bravo. Je m’incline
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Strangelovian le 31 août 2019 à 18:03:23
en IPv6 ? c'est curieux.
C’est vrai qu’il y a une masse de ipv4 dans le lot. Mais j’ai vu des patterns louches en v6 aussi, ça m’a étonné. Simples erreurs envoyées vers les /56 assignés par Orange?
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: kgersen le 31 août 2019 à 18:11:17
Simples erreurs envoyées vers les /56 assignés par Orange?

possible. c'était quelles "interface id" utilisées (4 derniers octets) ? car meme si les prefix sont connus, la difficulté est d'avoir une interface id valide.

(https://mrncciew.files.wordpress.com/2013/04/ipv6-02.png)
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: doum le 02 septembre 2019 à 12:29:25
Non.

C'est à l'hôte d'avoir un pare-feu correcte.

Autrement ça ne doit pas avoir le droit de s'appeler accès à l'Internet.

désolé mais c'est completement con comme argument

deja le fait de bloquer "par defaut" le traffic entrant n'empeche pas du tout d'acceder a internet. d'autant qu’ethnologiquement acceder a internet veut bien dire ce que ca veut dire, tu payes pas un "internet qui accedent a toi" :D
par ailleurs le fait de bloquer par defaut ne veut pas dire que l'utilisateur avancé peut décider d'ouvrir si il le souhaite. :D

enfin "c'est a l'hote d'avoir un pare feu correct" c'est vrai pour les gros systemes, ca l'est bcp moins pour toutes les merdes connectés qu'on va de plus en plus etre amené a branhcer sur nos réseaux domestiques (frigo, domotique, aspirateurs robots et tutti quanti)

Je pense que faire une sécurité a 2 niveaux est largement préférable (a condition que ce soit désactivable pour ceux qui souhaite)
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: vivien le 29 septembre 2019 à 16:59:26
Chez Orne THD, un petit bouton, activé par défaut, bloque les flux entrants IPv6 : (en IPv4, le NAT bloque de fait les paquets entrants)

(https://lafibre.info/images/ipv6/201909_ornethd_ipv6_firewall.png)
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: cali le 30 septembre 2019 à 01:32:26
désolé mais c'est completement con comme argument

deja le fait de bloquer "par defaut" le traffic entrant n'empeche pas du tout d'acceder a internet. d'autant qu’ethnologiquement acceder a internet veut bien dire ce que ca veut dire, tu payes pas un "internet qui accedent a toi" :D
par ailleurs le fait de bloquer par defaut ne veut pas dire que l'utilisateur avancé peut décider d'ouvrir si il le souhaite. :D

L'accès à l'Internet implique l'adressage d'une interface réseau avec une adresse IP publique. Si celle-ci est filtrée et que ledit filtrage est hors du contrôle de l'interface alors cette interface n'a pas un accès propre à l'Internet.

Une configuration avec filtrage par défaut oblige les développeurs de logiciels à implèmenter des serveurs tiers pour établir des connexions alors qu'il n'y en a normalement pas besoin. Par exemple, il n'est pas possible d'utiliser SIP correctement, alors qu'en IPv6 ça devrait être beaucoup plus simple.

Un système correcte demande l'autorisation à l'utilisateur pour écouter sur l'adresse, il n'y a pas besoin de filtrage en amont.

enfin "c'est a l'hote d'avoir un pare feu correct" c'est vrai pour les gros systemes, ca l'est bcp moins pour toutes les merdes connectés qu'on va de plus en plus etre amené a branhcer sur nos réseaux domestiques (frigo, domotique, aspirateurs robots et tutti quanti)

Ça s'appelle de la sécurité par obscurité et c'est stupide. De plus, les trouver sur l'Internet en IPv6 sera difficile contrairement à l'Internet IPv4, donc le vecteur d'attaque sera différent.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: vivien le 30 septembre 2019 à 08:36:31
La bonne solution est bien d'activer le firewall par défaut en IPv6.

J'entends bien tes arguments Cali, "la sécurité doit être gérée sur le terminal", mais si un PC peut la gérer, les objets connectés ont plus de mal : mises à jour rares, manque de CPU / RAM pour mettre tout le nécessaire....

Ton ampoule connectée en Wi-Fi, si elle récupère un IPv6 sans Firewall sera directement exposée sur Internet et à la moindre faille elle peut être contrôlée à distance.

C'est la première raison évoquées par les objets connectés pour ne pas faire d'IPv6.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Optix le 30 septembre 2019 à 08:54:22
Il faut faire des choix pragmatiques.

Moi, j'ai les clients qui appelent au moindre problème (même si c'est dans leur LAN et que c'est pas notre problème).

Donc on filtre par défaut pour éviter les déconvenues, tout en laissant le choix pour ceux qui savent ce qu'ils font.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Free_me le 30 septembre 2019 à 12:45:30
je suis plutot de l'avis de cali.
mais bon malheureusement ipv6 est pas construit pour securiser des ampoules a 2 balles, et c'est effectivement a chaque peripherique de se demerder.
Et comme c'est concretement ingerable, on en reviens avec l'architecture ipv4 un truc qui fait passerelle pour les autres, et on blinde au mieux la passerelle.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Hugues le 30 septembre 2019 à 12:51:05
J'attends encore un exploit réel de vos fantasmes, perso. IPv6 Privacy Extensions suffisant largement...
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: nicox11 le 30 septembre 2019 à 13:58:24
Je vois pas où est le soucis à partir du moment que tu peux désactiver le firewall...

De base Mme Michu est protégée et n'as pas besoin d'y toucher.
Le tech' peut ouvrir certains ports/IP si nécessaire.
Le mec super confiant en chacun de ses endpoints peut désactiver le firewall (dès qu'un de ses endpoints est mal configuré l'ensemble est compromis).

Tout doit être paramétrable, mais la valeur par défaut doit être la plus protectrice à mes yeux.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: vivien le 30 septembre 2019 à 14:05:07
J'attends encore un exploit réel de vos fantasmes, perso. IPv6 Privacy Extensions suffisant largement...

En fait IPv6 Privacy Extensions ne protège pas si l'attaquant peu écouter ton réseau (ou simplement le résolveur DNS) : Il aura rapidement la liste des adresses IP utilisées.

Par contre on d’accord sur le fait que IPv6 Privacy Extensions réduit le risque.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: kgersen le 30 septembre 2019 à 14:32:52
Les Privacy Extensions ont été conçues pour la 'privacy' pas pour la sécurité.

Aller miser sur le fait qu'il est difficile d'obtenir l'IP ou que celle-ci change tout les 10 minutes n'est pas un gage de sécurité.

Le problème ce ne sont pas trop les ampoules ou autres objets connectés qui par nature sont conçus pour être connectés a Internet et n'ont aucun port ouvert accessible. Ils fonctionnement en mode 'pull' avec un service cloud distant (en pratique ce sont des clients https qui interrogent a interval fixe un serveur https et ne font absolument rien d'autre).

Le problème c'est plus pour les objets 'lan' comme les caméra IP ou les imprimantes qui n'ont pas été concus pour être directement exposés sur Internet (du moins les plus anciens d'entres eux). Ces objets, par nature, exposent des ports pour être utilisé/contrôlé, le plus souvent avec une sécurité d'accès inexistante ou minimal (simple mot de passe). C'est ceux-la qui peuvent poser problème dans un contexte IPv6 mais il est fréquent qu'ils ne soient meme pas compatible IPv6 de toute facon...

Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: cali le 30 septembre 2019 à 18:18:45
En fait IPv6 Privacy Extensions ne protège pas si l'attaquant peu écouter ton réseau (ou simplement le résolveur DNS) : Il aura rapidement la liste des adresses IP utilisées.

Par contre on d’accord sur le fait que IPv6 Privacy Extensions réduit le risque.

La merde sera compromise d'une manière ou d'une autre.

Puis, plus la merde sera compromise plus elle disparaîtra rapidement.

Quand on regarde ce que contrôle un botnet, la grande majorité des machines compromises exécutent pourtant le super « antivirus rootkit » qui contrôle toute la machine.

Je vois pas où est le soucis à partir du moment que tu peux désactiver le firewall...

De base Mme Michu est protégée et n'as pas besoin d'y toucher.

Car ne sachant pas comment fonctionne le système, elle aura une expérience dégradée qui requerra l'utilisation de logiciels utilisant des serveurs tiers pour établir des connexions, même pour faire du téléphone...

Elle n'est certainement pas protégée, dans ce cas là vaut mieux lui fournir un accès au minitel contrôlé par une organisation bienveillante.

On achemine bien de la connectivité IPv6 chez quidams qui n'ont même pas idée de ce qu'est l'IPv6 et il y a zéro problème.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: raf le 01 octobre 2019 à 10:05:11
En fait IPv6 Privacy Extensions ne protège pas si l'attaquant peu écouter ton réseau (ou simplement le résolveur DNS) : Il aura rapidement la liste des adresses IP utilisées.

Si l'attaquant peut ecouter ton reseau, il y a une forte probabilite qu'il est DEJA derriere le firewall lui aussi. Quand au DNS, sauf aberrations style DoH/application DNS, c'est le resolver qui fait la demande. Si l'attaquant controle le resolver, encore une fois, il y a des problemes plus importants a resoudre avant.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: vivien le 06 novembre 2019 à 16:48:06
Merci l'Upnp qui est une cochonnerie dont abusent les caméras et les consoles de jeux.
Je cherche une liste des firewall IPv6 de box compatible avec UPnP.

On devrait pouvoir utiliser UPnP pour ouvrir un port sur le firewall IPv6, non ?

Je trouve peu de choses sur Internet, les pages qui parlent d'Universal Plug and Play mentionnent presque jamais IPv6.

Pour pfSense :
UPnP & NAT-PMP and IPv6

As of this writing, the UPnP and NAT-PMP service on current versions of pfSense supports IPv6, but client support is still spotty.

Source : docs.netgate.com/pfsense (https://docs.netgate.com/pfsense/en/latest/book/services/upnp-and-nat-pmp.html)
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: kgersen le 06 novembre 2019 à 18:49:28
Je cherche une liste des firewall IPv6 de box compatible avec UPnP.


tu peux tester toi-meme avec upnpc pour voir si ta box support IDG:2 ( https://openconnectivity.org/developer/specifications/upnp-resources/upnp/internet-gateway-device-igd-v-2-0/ ).

upnpc installable dans ubuntu directement http://manpages.ubuntu.com/manpages/eoan/man1/upnpc.1.html

sinon depuis leur site: http://miniupnp.free.fr/index_fr.html pour d'autres OS.

La 1ere étape est de contrôler si la box répond a IDG:2 avec 'upnpc -S':

voila ce que ca donne derriere une bbox fibre depuis Windows 10 (qui malheureusement n'a pas encore IPv6):
C:\Users\******\Downloads\upnpc-exe-win32-20150918>upnpc-static.exe -S
upnpc : miniupnpc library test client, version 1.9.
 (c) 2005-2014 Thomas Bernard.
Go to http://miniupnp.free.fr/ or http://miniupnp.tuxfamily.org/
for more information.
List of UPNP devices found on the network :
 desc: http://192.168.1.1:50763/rootDesc.xml
 st: urn:schemas-upnp-org:device:InternetGatewayDevice:1

Found valid IGD : http://192.168.1.1:50763/ctl/IPConn
Local LAN ip address : 192.168.1.*
FirewallEnabled: 1 & Inbound Pinhole Allowed: 1
GetFirewallStatus:
   Firewall Enabled: Yes
   Inbound Pinhole Allowed: Yes
Bytes:   Sent: 2790128054       Recv: 3041906074
Packets: Sent: 687349267        Recv: 2097505313

La bbox supporte donc IGD:2 et  devrait en théorie permettre d'ouvrir des flux pour IPv6.

aparté: IGD:2 indique le volume upload/download donc le cross-traffic entre 2 appels a upnpc sans besoin d'un comité avec l'ARCEP & les FAI & les speedtesteurs /s

Si la box est compatible IGD:2, on peut ensuite créer des 'pinhole' (percer des trous) pour ouvrir des flux:

upnpc [options] -A remote_ip remote_port internal_ip internal_port protocol lease_time
-A correspond a 'AddPinhole()' dans la spec: http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf (bas de la page 16).

par exemple:

upnpc -6 -A "" 0  2001:1234:1234::5678 80 tcp 300
demande l'ouverture de n'importe quelle IP source  ,n'importe quel port source vers 2001:1234:1234::5678 port 80 en tcp pendant 300 secondes. Par sécurité, la commande ne marche que si émise par 2001:1234:1234::5678.

Si ca réussi un ID du pinhole crée est retourné.

Il y a d'autres commandes:
-U ID time: change le lease time du pinhole
-K ID : renvoi le compteur de paquets ayant traversé le pinhole
-D ID: supprime le pinhole
-C ID: contrôle si le pinhole fonctionne
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: vivien le 14 novembre 2019 à 12:06:49
Je vais animer un atelier sur ce thème demain.
Voici le résumé des 8 pages et des deux points de vue...

Vision de ceux qui refusent qu’un firewall IPv6 soit activé par défaut :
- C'est aux périphériques de se sécuriser.
- Avec les Privacy Extensions, la surface d'attaque est tellement énorme que je ne suis pas spécialement inquiet (un seul subnet en IPv6 c'est par défaut 64 bits soit 18 446 744 billion d’IP. Ca fait 4 milliards de fois tout l'espace d'adressage IPv4, pour un seul pauvre subnet /64).
- « IPv6 est naturellement plus sécure en raison de la taille de l'espace d'adressage. »
- « IPv6 en mode open bar n'apporte pas plus d'Insécurité»
- « si le fait de vouloir mettre un niveau de sécurité cote box est un chose louable, techniquement c'est un chose parfaitement inutile »
- « Je n'ai pas envie qu'on me protège de force. Si je veux mettre un firewall, c'est moi qui le met. »

Vision de ceux qui sont pour le firewall IPv6 soit activé par défaut :
- Pour offrir la même sécurité que le NAT, par défaut tous les ports entrants sont bloqués en IPv6 « statefull firewall ». Pour autoriser les flux entrants, il faut donc ouvrir un par un les port souhaités, comme si on était derrière un NAT, sur le firewall de la box.
- « Tu peux pas demander à M. tout le monde d'assumer lui-même sa sécurité »
- « On ne maîtrise pas tout sur son LAN... Imprimante, caméra, tv, console de jeu, smartphone... Le pc finalement c'est un élément minoritaire »
- « Les PC Windows qui partagent des fichiers en ouvrant tout parce que l'utilisateur n'a pas fait les bonnes manips sont fréquents et même si on ne peut 'deviner' leur IPv6, on peut facilement en récupérer par fishing via emails ou sites attrape pigeons. Les Privacy Extensions ont été conçues pour la 'privacy' pas pour la sécurité »
- « Je vois tout les jours des webcam laissées avec le mot de passe par défaut. Le fait que les IPv6 soient difficiles a trouver ou non permanentes est une illusion de sécurité et protection. »
- «  La serrure connectée de ton appartement ou ton imprimante , si elle récupère un IPv6 sans Firewall, elle sera directement exposée sur Internet et à la moindre faille, elle peut être contrôlée à distance. »


Même avis tranchés, pour les "zones safe" en entreprise, protégées par un firewall :

« La sécurité n'a aucun sens au niveau réseau "middlebox", seulement au niveau des terminaisons. Les zones 'safe‘ sont une catastrophe : il apparait qu'un élément étranger, parvenant à s'introduire, il prend le rôle de loup dans la bergerie: tout le monde étant à poil, il n'y a plus qu'à se servir. 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 »

vs

« si on suit cette logique les firewall d'entreprise n'ont aucun sens. Il faut juste blinder chaque poste de travail, serveurs, imprimantes, etc... ? »créer 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 façon 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 à gérer. Si j'ouvre un serveur web sur ma webcam, 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 ? »

Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: kgersen le 14 novembre 2019 à 12:39:39
Ma réflexion sur le sujet a changer un peu.

Je pense qu'en IPv6 les box devraient bloquer que TCP uniquement (statefull firewall sur TCP  avec ouverture via UPnP-IGD:2 et/ou l'interface web de la box- et bien sur possibilité pour l'utilisateur désactiver complement le firewall).

et laisser UDP et tout les autres protocoles passer sur IPv6.

L'avenir (20 ans+) est la disparition d'IPv4 et de TCP de toute façon.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Free_me le 14 novembre 2019 à 13:11:04
L'avenir (20 ans+) est la disparition d'IPv4 et de TCP de toute façon.

de tcp ?
pourquoi ? et quoi a la place ?
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: jack le 14 novembre 2019 à 13:40:47
UDP, j'imagine

C'est une vision particulière de kgersen, qui est un peu enthousiaste sur ce genre de sujet
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Thornhill le 14 novembre 2019 à 13:46:12
Même si TCP disparaissait d'un point de vue protocolaire à terme, j'ai du mal à suivre le blocage de TCP uniquement, d'un point de vue sécurité :  pourquoi un service à l'écoute en UDP aurait moins de vulnérabilités qu'un service à l'écoute en TCP ?
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: kgersen le 14 novembre 2019 à 16:19:23
Même si TCP disparaissait d'un point de vue protocolaire à terme, j'ai du mal à suivre le blocage de TCP uniquement, d'un point de vue sécurité :  pourquoi un service à l'écoute en UDP aurait moins de vulnérabilités qu'un service à l'écoute en TCP ?

C'est plus une question de statistiques, le risque zéro n'existant pas. Les trucs éventuellement vulnérables (caméro, IoT, etc) le sont principalement via TCP.

Donc dans un cadre grand public et que grand public, bloquer TCP suffit largement , statistiquement a couvrir les risques les plus importants (caméra/IoT avec login/mdp par défaut, etc).

C'est purement statistique et ca ne couvre pas tout les risques.

de tcp ?
pourquoi ? et quoi a la place ?
UDP, j'imagine

C'est une vision particulière de kgersen, qui est un peu enthousiaste sur ce genre de sujet

Pas qu'UDP mais peut-être aussi j’espère d'autres protocoles. Le pré-requis est qu'une fois IPv6 dominant donc le NAT supprimé on pourra vraiment commencer a utiliser d'autres protocoles qu'UDP et TCP.

Tout le monde s'accorde sur le fait que TCP n'est pas été conçu pour les réseaux actuels (fibre, 5G, etc) et pose pas mal de soucis. TCP doit évolué ou être remplacé. Le NAT d'IPv4 empêche cela.

L'évolution de HTTP/2 c'est HTTP/3 qui n'utilise plus TCP mais UDP. Le taux d'adoption faramineux d'HTTP/2 (40% a ce jour) est très encourageant pour HTTP/3.

Ce choix d'UDP pour HTTP/3 est en partie due a la situation actuelle a cause d'IPv4 qui impose le NAT qui lui impose UDP ou TCP.
 
Quand on leve ce manque de choix grace a IPv6 , on retourne a l'origine d'Internet (lien de niveau 3 IP pur entre 2 machines n'importe ou dans le monde) alors on peut envisager l'utilisation de toute sorte de protocoles de niveau 4.

L'autre partie est l'optimisation des drivers et stacks IP pour TCP et UDP (offloading & co) mais cela se traite aux extrémités, au cas par cas, sans contraire sur les nœuds intermédiaires contrairement au NAT d'IPv4.

Dans 20 ans y'aura surement encore du TCP qui circulera mais ca ne sera peut-être plus le protocole dominant.

tl;dr: IPv4 impose du NAT au milieu du réseau donc des contraintes sur ce qu'on peut utiliser au 2 bouts. IPv6 leve ces contraites et permet d'inventer et d'utiliser de nouveaux protocoles de niveau 4 qui a long terme remplaceront TCP et UDP. ps: donc faut pas bloquer ca par défaut dans les firewall des box.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: mirtouf le 15 novembre 2019 à 10:27:39
De mon point de vue d'utilisateur final, et ceci a déjà peut-être été écrit, j'aimerais qu'il soit possible:
- de recevoir un /56 que l'on pourrait découper en /60
- d'appliquer des politiques de filtrage différentes sur chaque /60 où pour certains préfixes aucun filtrage ne serait appliqué tandis que pour d'autres les entrées seraient filtrées
- les machines recevant un ou plusieurs /64

Mes 2 centimes.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: vivien le 19 novembre 2019 à 13:56:45
Deux citations de l'Anssi que j'ai bien aimé dans le groupe de travail sur le filtrage IPv6 :

Ne pas filtrer le trafic entrant non sollicité et demander aux périphériques de se sécuriser, c’est comme laisser la porte de chez soi ouverte avant de partir et de tout ranger dans des tiroirs fermés à clefs.

Expliquer on ne pourra pas retrouver le terminal du fait du grand nombre d’IPv6, c’est comme avoir de l’argent que l’on cache chez soi et faire le pari que le voleur ne trouvera pas la cachette. Si vous roulez à 130 Km/h dans une voiture connectée, vous préférez que l’attaquant ait peu de chance de trouver votre IPv6 ou que le firewall vous protège ?
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Hugues le 19 novembre 2019 à 14:13:11
Du basique FUD quoi :)
On parle de probabilités dans tous les cas, le Firewall n'est pas un truc magique qui empèche tout le monde de rentrer...
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Anonyme le 19 novembre 2019 à 14:34:44
De mes anciens souvenir d'automatismes, il y avait un "schéma directeur"nommé GEMMA permettant de s'assurer de la sécurité des biens et des personnes.
Superviser tous les "automatismes" avec un bouton d'arrêt d'urgence.

Les questions à se poser, sont, le danger est réel avéré ou imaginaire ?
Quelles sont les conséquences de ne pas intervenir ? Quelles sont les conséquences d'intervenir ?
Quel est le coût d'invervention, quel est le coût de non intervention ?

Pour ma part, je considère que c'est à ceux qui connaissent les dangers de s'assurer de la protection de ceux qui n'en ont aucune idée.

C'est un peu comme si on avait des enfants sous notre protection, sans aucune notion d'un danger et que nous n'intervenions pas pour les en protéger, c'est criminel.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: kgersen le 19 novembre 2019 à 17:42:37
Deux citations de l'Anssi que j'ai bien aimé dans le groupe de travail sur le filtrage IPv6 :
....

Faire des analogies foireuses et FUD c'est le rôle de l'ANSSI ? Pas très sérieux quand même...

D'ailleurs a ce sujet qu'elles sont les recommandations officielles de l'ANSSI concernant les box FAI grand public pour l'IPv6 ?

Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Hugues le 19 novembre 2019 à 21:05:57
Je note que Vivien cite l'ANSSI, mais pas les réponses que Radu ou moi avons formulées contre ce FUD... :(
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: vivien le 19 novembre 2019 à 21:15:25
Je pourrais citer ton intervention avec l'idée "issue d'un forum" de ne filtrer que TCP (ou que TCP/ UDP assez rapidement) qui a plutôt bien été accueillie par l'ANSSI.

Radu était là et je lui ait laissé la parole en premier, connaissant ses positions.

Je note toutefois :
- Que l'ANSSI a fait une réponse a chaque tentative de Radu en demandant de citer des exemples de cas concret où il faut ouvrir les ports pour le grand public. On a trouvé principalement des caméras de surveillance et des jeux et dans les deux cas la préconisation est de le mettre dans le mode d'emploi et que pour une caméra de surveillance, il faut impérativement que l'utilisateur soit conscient de ce qu'il fait vu les risques.
- Que Radu a mis de l'eau dans son vin et est pour filtrer par défaut le trafic entrant non sollicité en entreprise (et même pour le grand public avec les dernière box il dit l'avoir activé)

Bref, contrairement à ce que je m’attendait, un consensus a été presque été trouvé.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Hugues le 19 novembre 2019 à 21:37:09
Ben, bof.

Je pourrais te faire un REX complet de ce que j'ai pensé du débat, mais disons qu'entre le DSI d'une grosse entreprise qui n'avait pas grand chose a voir avec les opérateurs (a mon sens la cible de la task force) et les mecs de l'ANSSI qui n'étaient pas vraiment là pour débattre, ça a été compliqué de pouvoir en placer une.

Moi, j'ai une position très simple :

Mettre un firewall, c'est une rupture du principe de bout-en-bout d'internet, et ça va forcément limiter de futurs usages.

Oui actuellement, vu qu'on est IPv4-Centric, madame michu n'a pas besoin d'ouvrir de ports, parce que c'est un tel calvaire à faire que personne ne développe d'usage qui se sert de ça.

Maintenant, sur la "faille de sécu" que ça apporte :
- Va falloir me prouver qu'on peut compromettre en masse des réseaux "michu like" parce qu'ils ont un firewall ouvert
  - Actuellement, en v4, c'est causé par les scans d'IP, un truc plus possible en v4
- Pour le risque de doxage de l'IP en utilisant des log d'un serveur compromis : Les Privacy Extensions permettent d'éviter ce relai d'attaque
- À part les DDOS Sortants en exploitant des trucs qui se font amplifier (et ça, ça se filtre les doigts dans le pif coté opérateur, même en sortant, surtout avec le SDN Cloud qu'on nous survend), y'a un vrai risque à laisser sa machine (avec un firewall) ou son iOT Shit ouvert ?

Comme les mecs de l'ANSSI, j'attends des cas concrets où la compromission vient d'un firewall d'un routeur désactivé.

Parce que bon, suffit que l'attaquant te fasse DL une merde pour télécharger des films gratos, et ça y'est, il a accès à tout ton réseau local, a ton IOT, à ta friteuse connectée, etc...
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: vivien le 19 novembre 2019 à 21:47:58
La problématique c'est que cela se base uniquement sur le fait que l'IPv6 ne sera pas découverte.

Un exemple qui devrait te parler pour récupérer une IP: Tu postes une petite image sur un forum sur un hébergement perso et tu récupère les IPv6 de tous ceux qui voient l'image et ensuite tu attaque les IPv6 en question.
(Hugues est modérateur d'un forum qui interdit les images externes pour cette raison)

C'est un exemple, il est aussi très simple de mettre en place un serveur NTP, de l'inscrire sur https://www.pool.ntp.org/fr/ et de loguer les IPv6 qui se connectent, dans le lot il y aura pleins de caméra sans aucune sécurité, plus qu'a faire son marché.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Hugues le 19 novembre 2019 à 21:49:28
Un exemple qui devrait te parler pour récupérer une IP: Tu postes une petite image sur un forum sur un hébergement perso et tu récupère les IPv6 de tous ceux qui voient l'image et ensuite tu attaque les IPv6 en question.
(Hugues est modérateur d'un forum qui interdit les images externes pour cette raison)
Ouais, en v4 aussi, aucune différence.

C'est un exemple, il est aussi très simple de mettre en place un serveur NTP, de l'inscrire sur https://www.pool.ntp.org/fr/ et de loguer les IPv6 qui se connectent, dans le lot il y aura pleins de caméra sans aucune sécurité, plus qu'a faire son marché.
Ouais, en v4 aussi, aucune différence.

Merci d'avoir participé ;D
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Thornhill le 19 novembre 2019 à 22:17:30
Ouais, en v4 aussi, aucune différence.
Ouais, en v4 aussi, aucune différence.

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).
Donc ta réponse est un peu légère je trouve.
Tu aurais pu invoquer le fait que l'usage des privacy extensions donne une validité limitée dans le temps à cette ipv6 découverte.
Néanmoins, je me demande si cette durée est suffisamment courte pour se prémunir d'un vecteur d'attaque facile.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: kazyor le 19 novembre 2019 à 22:44:17
On dit souvent qu'en matière de sécurité, le fait de cacher l'information, n'est pas une protection.

En quoi l'histoire de l'ipv6 le deviendrait ?
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: vivien le 19 novembre 2019 à 22:47:18
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).
Donc ta réponse est un peu légère je trouve.
En IPv4 tu as l'IP mais tu n'a accès à rien (sauf cas où le client à ouvert les ports).
En IPv6, sans firewall, la situation est bien différente.

Néanmoins, je me demande si cette durée est suffisamment courte pour se prémunir d'un vecteur d'attaque facile.
La réponse est clairement non.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Thornhill le 19 novembre 2019 à 22:52:51
On dit souvent qu'en matière de sécurité, le fait de cacher l'information, n'est pas une protection.

En quoi l'histoire de l'ipv6 le deviendrait ?

L'idée des défenseurs du "firewall inutile" c'est, j'imagine :
En raison de la randomisation de l'ipv6, on peut assimiler la découverte d'un couple (ipv6, port TCP à l'écoute) derrière un CE router à une attaque de mot de passe long en brute force : très long, très coûteux donc peu probable.

Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: vivien 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.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Hugues 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.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Jojo78 le 19 novembre 2019 à 23:01:23
Du coup, je coche ou pas la case firewall IPV6? :)
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: vivien 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 (https://lafibre.info/ikoula/news-securite/)) 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 ?
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: kazyor 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.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Hugues 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 ?
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: jack 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."
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Anonyme 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.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: vivien 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)

(https://lafibre.info/testdebit/windowsxp/201608_BSOD_SNCF_grande_ligne_windows_xp_1.jpg)
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Thornhill 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).

Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: kgersen 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.


Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Anonyme 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).
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: kgersen le 24 novembre 2019 à 12:03:19
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).

Non pas ceux qui construisent l'OS. ca ne sert a rien.
Ce sont les intégrateurs applicatifs et les éditeurs de logiciels qu'il faut impliquer. La couche 7.

Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Anonyme le 24 novembre 2019 à 20:44:27
Non pas ceux qui construisent l'OS. ca ne sert a rien.
Ce sont les intégrateurs applicatifs et les éditeurs de logiciels qu'il faut impliquer. La couche 7.
Je comprends ton point de vue, mais je ne pense pas que ceux qui développent les OS le voient de cette façon.
C'est sur la couche IP, et les applications utiliseront toujours les "api/librairies" faisant appel à cette couche dans l'OS.
Quand tu vois le contrôle des "stores" d'applications ( même si je comprends la volonté d'intégrer une  "pile TCP/IP minimale" dans l'application type "applets" ou appliances Docker, ce n'est pas la tendance dans les devices, on peut le déplorer mais il va falloir faire avec les incontournables OS encore un certain temps.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: kgersen le 24 novembre 2019 à 21:01:01
Je comprends ton point de vue, mais je ne pense pas que ceux qui développent les OS le voient de cette façon.
C'est sur la couche IP, et les applications utiliseront toujours les "api/librairies" faisant appel à cette couche dans l'OS.
Quand tu vois le contrôle des "stores" d'applications ( même si je comprends la volonté d'intégrer une  "pile TCP/IP minimale" dans l'application type "applets" ou appliances Docker, ce n'est pas la tendance dans les devices, on peut le déplorer mais il va falloir faire avec les incontournables OS encore un certain temps.

je ne sais pas ce que tu appelle 'OS' on doit pas avoir la meme définition...

les 'OS' actuellement utilités sont déjà tous IPv6 ready depuis belle lurette.
Le problème c'est au dessus ceux qui intègrent et/ou font des applications et ce sont de toute facon eux influencent et font des demandes aux 'éditeurs' d'OS.
L'approche est "top-down" pas "bottom-up" surtout sur des environnements limités en cpu/ram/etc.

C'est pour ca que tout cette approche "bottom-up" autour IPv6 (barometre & co) est une perte de temps colossale si on n'implique le maillon le plus en haut.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: kgersen le 19 décembre 2019 à 00:09:54
Apple, Amazon, Google et la Zigbee Alliance* viennent d'annoncer un groupe de travail pour la domotique (smart home) nommé 'Connected Home over IP'.

https://www.connectedhomeip.com/

Il sera intéressant de suivre leur choix de sécurité concernant l'utilisation d'IPv6

* Zigbee Alliance = IKEA, Legrand, NXP Semiconductors, Resideo, Samsung SmartThings, Schneider Electric, Signify (formerly Philips Lighting), Silicon Labs, Somfy et Wulian
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: vivien le 19 décembre 2019 à 06:38:28
Je vois que beaucoup de marques de la Zigbee Alliance sont celles qui bloquaient le passage en IPv6 only sur iOS, avant que Apple introduise le CLAT (c'est introduit à partir de iOS 12) : elles utilisent des IPv4 littérales dans leur application, ce qui fait que le DNS64/NAT64 ne suffit pas.
Titre: IPv6: Le firewall
Posté par: Max284 le 20 décembre 2019 à 19:52:16

Bref ce n'est pas l'utilisateur le responsable mais ce qu'il utilise et il n'a pas vraiment le choix.

Aujourd'hui quand une société se fait attaquer par un botnet, les IPs des attaquants sont transmisses a l'ANSSI qui renvoi le blâme aux FAI (en gros c'est aux FAI de 'faire' quelque chose).

Maintenant si chaque fois qu'un PC Windows (ou une appliance) se faisait contaminer on faisait payer une amende a Microsoft (ou au constructeur de l'appliance) au lieu de mettre ca sur le dos du FAI peut-être que les choses changeraient.

En automobile quand un véhicule a un défaut grave c'est le constructeur qui est responsable pas le conducteur ou celui qui fourni la route.

Je ne suis pas d'accord, lorsqu'un utilisateur télécharge et execute un malware sur son PC, on ne peut pas blâmer le constructeur. La majorité des personnes ne connaît pas les gestes simples de sécurité numérique. Les constructeurs sont responsables dans le cas de failles sur leurs logiciels ou équipements, par exemple dans le cas d'un vers qui utiliserai un exploit pour s'infiltrer.
Il faudrait faire plus de prévention auprès du public je pense.
Titre: IPv6: Le firewall
Posté par: jack le 20 décembre 2019 à 21:07:00
J'ai une chaudière à gaz
Je ne suis pas expert dans le domaine
Je ne risque pas de mettre le feu à mon immeuble en utilisant naïvement la chaudière

Si c'était le cas, le constructeur aurait en effet des comptes à rendre

Bref, je partage l'avis de kgersen

Je ne suis pas d'accord, lorsqu'un utilisateur télécharge et execute un malware sur son PC, on ne peut pas blâmer le constructeur. La majorité des personnes ne connaît pas les gestes simples de sécurité numérique. Les constructeurs sont responsables dans le cas de failles sur leurs logiciels ou équipements, par exemple dans le cas d'un vers qui utiliserai un exploit pour s'infiltrer.
Il faudrait faire plus de prévention auprès du public je pense.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: decalage le 05 juillet 2020 à 14:22:52
Pour info, Bouygues Telecom déploie enfin une MAJ qui autorise l'utilisateur à régler le pare feu ipv6 de sa bbox (https://lafibre.info/bbox-les-news/deploiement-ipv6-bouygues-adsl/msg773845/#msg773845) à sa convenance.
3 réglages : Tout ouvert, ouvert seulement en entrant, tout fermé.
Le choix c'est la vie  ;D
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: vivien le 05 juillet 2020 à 14:38:13
J’espère qu'il sera possible d'ouvrir des ports spécifiques ou de mettre des IPv6 en "DMZ".

C'est un point où il y a une grande marge de progression les firewall IPv6 des box.
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Optix le 05 juillet 2020 à 14:52:46
De notre côté, c'est plus évolué. Tu cliques sur ton device, tu as un onglet pour ouvrir les ports en v6 (uPNP le fait aussi).

Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: decalage le 05 juillet 2020 à 15:13:45
De notre côté, c'est plus évolué. Tu cliques sur ton device, tu as un onglet pour ouvrir les ports en v6 (uPNP le fait aussi).
J'ai pas fait la description exhaustive des possibilités du pare feu v6 de Bouygues mais oui ils proposent bien sûr (au delà des 3 niveaux de sécurité généraux) le filtrage ipv6 par appareil, par port, source ou destination, tcp ou udp ou les 2, de faire des règles en whitelist ou blacklist, etc...
Titre: IPv6: Le firewall doit il bloquer par défaut le trafic entrant ?
Posté par: Optix le 05 juillet 2020 à 15:34:30
Aaah nickel, ça commence à être sympa :)