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 clef 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 clef 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.