Glandos a écrit 1345 commentaires

J'ai bien vu que c'était un troll, mais c'est l'occasion de remettre un lien vers notre informateur réseau favori : http://www.bortzmeyer.org/nat-et-securite.html
J'avoue qu'à l'époque, j'ai un peu formalisé mon savoir sur la différence entre le NAT (enfin, le NAPT), et le pare-feu.

ce truc coûte 24k€.

C'est vrai ? Tu as une source mentionnant cette somme ? C'est quand même assez cher. Je dis pas que ça coûte moins de 1000 €, mais quand même, 24k€…

Il n'est jamais trop tard pour se réveiller je pense.
Et ça fait bien longtemps que j'ai constaté cette « invasion » en effet. Des années. Quand tu dis que tu hurles, tu hurles à qui ? À l'administration elle-même ? Je chercherais bien un moyen de le leur dire, c'est un peu le but de ce journal d'ailleurs. Je sais bien que le lectorat de linuxfr est déjà convaincu…

Sinon, effectivement, FranceConnect est bien plus envahi de CDN que ce que je pensais. J'utilise Decentraleyes pour ça. C'est dur de vérifier son efficacité au quotidien, mais c'est déjà ça.

Enfin, provoquer l'ANSSI comme ça, c'est un peu inutile et non constructif. C'est mon avis ;)

Si, mais ce n'est pas un litige. Je ne suis pas utilisateur du site.

MacServerLocale="00:00:00:00:00:00" => l'adresse MAC de votre server (tapez ifconfig sur votre serveur pour la voir)

Non, non, et non.
Tapez ip link s'il vous plaît. ifconfig est déprécié depuis de nombreuses années.

Foutu pour foutu, autant le tirer par les cheveux à fond la caisse :

Des commentaires comme ça, j'en ai fait le tri c'tantôt. Et si tu nies, tôt ou tard, tu verras que le rot, bin il n'y a que lui qui s'y fie, l'hippie, n'est-ce pas ? À moins que l'abbé ne dicte sa foi…

On pourra avoir les statistiques quand même ? Anonymisées, cela va de soi !

Raisonnement de témoin de Jéhovah, ça va un peu loin, mais bon, je vois l'idée.

Oui, je pense avoir une obligation morale de moyens. Et heureusement que je ne me mets pas la pression pour une obligation de résultats : c'est le rôle d'un activiste. Ils sont importants, je les respecte. Mais je ne suis pas un activiste, pour différentes raisons. Finalement, je pense qu'avoir une obligation de moyens, c'est déjà mieux que rien du tout. Je n'essaye pas de parler de ce sujet à tout bout de champ; quand la situation se présente, j'en parle, avec des arguments. C'est une sorte de sensibilisation à un sujet que beaucoup de gens voudraient qu'on ignore.

Ensuite, considérer que les gens n'ont rien à faire des lamentations, c'est un peu les prendre pour des idiots. Parfois, amener un sujet avec les bons arguments permet de faire connaître un problème. Comme tous ces reportages « choc » à la télévision. Certains seront marqués plus ou moins longtemps. Beaucoup ne feront rien sans solution pragmatique. Mais dès qu'un once de solution apparaîtra, certains n'hésiteront pas à l'utiliser.

J'ai un doute que quiconque sur ce site soit la réelle cible de ce livre. Mais voilà, je fais partie de ceux qui, parfois, tentent d'expliquer que la surveillance automatisée, c'est pas bien. Certains le savent et me disent : « oui, ben c'est comme ça », comme si c'était le progrès et qu'il faut faire avec. Et bien ceux là, ce sont les plus compréhensifs…
Je mettrais bien ce bouquin dans la main de plein de gens. Même pas dans l'espoir qu'ils prennent en compte ce qu'il raconte, mais pour que, le jour où un vrai problème arrivera, ils ne puissent pas être surpris.

Donc je résume : c'est sûrement pas avec un livre qu'on fera changer les choses, mais franchement, c'est déjà mille fois mieux que rien du tout. Donc merci.

Ah, et une autre critique du livre par le fameux Stéphane Bortzmeyer

Tu as une box « fibre » ? Donc théoriquement, assez de bande passante montante pour héberger ton propre « cloud », non ?
Il y a beaucoup d'outils plutôt bien fait pour faire ça (comme ownCloud ou NextCloud), et le gros inconvénient de l'autohébergement en ADSL, c'est la bande passante. Y a-t-il un prérequis qui n'est pas mentionné ?

Et enfin, une bonne conclusion, avec laquelle, je n'ai pas peur de le dire, je suis bien d'accord : https://www.scrye.com/wordpress/nirik/2016/10/01/how-to-reignite-a-flamewar-in-one-tweet-and-i-still-dont-get-it/ (Lien envoyé par un membre timide qui ne voulait pas l'envoyer lui-même ;) )

Je vous laisse lire, bande de flemmards. Bon, c'est vrai, c'est un peu pédant pour ceux qui ne lisent pas l'anglais.

Une meilleure adresse : https://medium.com/@davidtstrauss/how-to-throw-a-tantrum-in-one-blog-post-c2ccaa58661d

Bon, je vais peut-être me faire rabrouer, mais Android a été dans le même état pendant longtemps, non ? C'était bourré de bugs, et iOS était bien plus stable.

Oh, c'est pas du récent :)
En prenant la page de tag : https://linuxfr.org/tags/grsecurity/public

On tombe sur :

• https://linuxfr.org/news/la-fin-de-grsecurity
• https://linuxfr.org/users/pterjan/journaux/qui-va-sauver-grsecurity

Et puis actuellement, des gens se plaignent parce grsecurity n'est disponible en stable que pour les clients qui paient. Personnellement, je n'ai pas d'avis, c'est juste une manière comme une autre de réagir à l'utilisation de leur code.

Exactement. Je préfère installer des paquets prévu pour une distribution en avance que en retard.
Attention, backports est très bien, mais son utilisation est prévue pour la stable (actuellement Jessie).

C'est vrai.
Mais bon, l'ANSSI le recommande dans plusieurs cas d'utilisations. Et oui, j'ai confiance dans l'ANSSI :)

Ah ? C'est vrai ? En tout cas, ça génère des messages d'erreurs de la part de grsec. Mais c'est vrai que les requêtes sont effectuées correctement quand même. Je n'ai pas testé s'il y avait une régression du coup.

On parle de la loi de quel pays ? C'est le Royaume-Uni me semble-t-il. Pour d'instant, ça s'applique en Europe. Pour l'instant…

Comment ça par « dichotomie » ta as « trouvé » 1480 ? De quelle interface parles-tu ? Qu'as-tu testé exactement ? Et qu'as-tu trouvé ?
Ben j'ai changé la MTU progressivement 1500, 1450, 1475, 1482, etc… Et à 1479, ça marche, 1480 aussi, mais pas 1481. Dichotomie quoi ;) Je l'ai fait sur l'interface eth_adsl (reliée à ma Freebox) de mon routeur.

La MTU de 1480 vient, mais c'est une hypothèse, du tunnel 6rd de Free qui doit rajouter des en-têtes. Soit, ce n'est pas vraiment un problème. Par contre, comme je l'ai dit, quand je fais une connexion TCP, ou même un simple ping vers un site distant, je n'ai pas de ICMPv6 "Packet too big". De personne. Par contre, si je fais un ping vers le routeur, avec un payload trop important, je l'ai, et ça met à jour les tables de routage temporaire, et tout marche comme sur des roulettes par la suite.

Du coup, j'avais trouvé la solution de mettre "AdvLinkMTU 1480;" dans mon /etc/radvd.conf. Il se trouve que ça a marché… jusqu'à une mise-à-jour de systemd sous Debian, avec une ligne dans le changelog :

• networkd: Handle router advertisements in userspace again. Drop Revert-Revert-networkd-ndisc-revert-to-letting-the-k.patch. Bug #814566/#815586 got fixed in 230, and #815884 and #815884 and #815793 are unreproducible and need more reporter feedback.

—Martin Pitt mpitt@debian.org Tue, 26 Jul 2016 12:17:14 +0200

Et si on remonte un peu avant :

• networkd: Go back to letting the kernel handle IPv6 router advertisements, as networkd's own currently has too many regressions. Thanks to Stefan Lippers-Hollmann for investigating this! (Closes: #814566, #814667, #815586, #815884, #815793)

—Martin Pitt mpitt@debian.org Sun, 28 Feb 2016 22:16:12 +0100

Donc là, ma vie personnelle fait que j'ai pas eu le temps de m'en occuper plus que ça, mais hein, si c'est pas un micmac avec networkd (que j'utilise sur mon ordinateur de bureau), je sais pas ce que c'est… Ce qui m'embête le plus, c'est de ne pas comprendre pourquoi les paquets ICMPv6 "Packet too big" ne sont pas générés, ni par mon routeur, ni par la Freebox…

Ça me paraît normal sur un 13" d'avoir des touches directionnelles sur une seule rangée, avec les touches haut et bas qui font la moitié de la hauteur. En tout cas, c'est comme ça sur les EliteBook de HP. Oui, c'est un ordinateur du boulot, parce que ça vaut très cher. Mais c'est très bien : après 8 ans, ma moitié (puisque que c'est le terme consacré ;)) le fait encore tourner pendant 2 h sur sa batterie d'origine, avec tous ses composants d'origines, excepté le disque dur.

J'utilisais BackupPC pour sauvegarder tout mon système, serveur et ordinateur personnel sur un même dépôt. Ça marchait très bien, mais j'ai eu le même problème que toi. La copie du dépôt de sauvegarde (sur un disque que je garde tout le temps avec moi) prend réellement 3 jours pour une faible quantité de données. J'utilisais rsync pour synchroniser la copie du dépôt, mais le problème est connu : les hardlinks.

J'ai cherché d'autres solutions, aucune n'est parfaite et je suis resté sur obnam. Ça fait de la déduplication par bloc, et c'est donc stocké sur forme de chunk. La synchronisation de la copie du dépôt prend moins de 20 minutes avec rsync. C'est génial. Mes sauvegardes incrémentales (c'est le seul mode dans obnam) sont aussi plus rapides, puisque je fais une sauvegarde intégrale du système en 20 minutes :

Backed up 1667 files (of 327296 found), containing 6.0 GiB.
Uploaded 369.0 MiB file data in 17m54s at 352.3 KiB/s average speed.
Total download amount 229.0 MiB.
Total upload amount 413.0 MiB. Overhead was 273.0 MiB (66.1 %).

C'est un Atom D2550 qui sauvegarde sur un disque USB 2.0. La source est un disque interne 2"5. Rien de rapide, et pourtant, c'est suffisant.
Avec obnam, la première sauvegarde sera longue, mais y a pas de magie.

Par contre, j'ai eu des corruptions. Oui, c'est un gros défaut. Et non, je ne sais pas dire à quelle fréquence. Mais en général, la corruption n'arrive que sur un chunk, donc c'est limité…

C'est marrant, je me rends compte que je sais tout ça, et quand il faut le mettre en pratique, j'oublie… Comme quoi, la pratique, ça aide à fixer les connaissances. Merci pour le rappel en tout cas.

Effectivement, traceroute permet d'aller plus loin que ce que je pensais (je devrais plus souvent RTFM).

Par contre, par défaut, il fragmente lui-même les paquets en fonction de la MTU de l'interface réseau. Pour forcer la non-fragmentation, il faut mettre -F ce qui permet de voir directement l'erreur.

Et du coup, après avoir fait des tests en touchant la MTU de l'interface avec traceroute, après avoir vu des paquets ICMP6, packet too big avec tcpdump, je me retrouve avec la MTU fixée à 1500, et des connexions qui marchent. ALORS QUE AVANT ÇA MARCHAIT PAS ! Désolé, je m'emporte.

MERCI !

Ah la MTU. Je m'étais jamais frotté à ce problème, même si je le connaissais, donc j'ai jamais pensé à le tester…

Donc oui, par dichotomie avec ip link j'ai bien trouvé 1480 de MTU, au lieu de 1500. Ça marche. Tout marche comme avant. Reste à savoir ce qui a changé, et pourquoi…

Pour info, ma Freebox est en mode bridge, et j'ai mon propre serveur en mode serveur/pare-feu/routeur. Mais j'ai jamais touché à la MTU, et je n'ai jamais eu de souci jusqu'à récemment. Ou alors c'est Debian qui a changé la valeur par défaut de la MTU ?

Et je suis en train de me rendre compte que je vais devoir changer la MTU sur les postes clients… J'ai un DHCP(v4), mais bon, l'IPv4 marche bien avec 1500…

Bref, l'Internet est cassé pour les gens normaux. Mais merci pour la solution.

En soit, ça me paraît louche, mais pourquoi pas.
Par contre, j'accédais bien aux sites sus-mentionnés auparavant. Et pourquoi les paquets ICMP passent, et pas l'HTTP ?