Stéphane Bortzmeyer a écrit 675 commentaires

La supervision est l'ensemble des mécanismes qui teste régulièrement l'état d'un système ou réseau et alerte s'il y a un problème. Par exemple, si on a deux serveurs DNS pour une zone (le minimum recommandé), la panne d'un des deux serveurs n'est pas visible par les utilisateurs, en raison de la redondance du DNS. La supervision permettra à l'admin' système de se dire « ah, il faut réparer ns2.example.com, BIND a encore crashé »

Un adjudant est autoritaire mais un serveur DNS fait autorité.

"Zone BIND" n'a pas de sens. Le format des fichiers de zone n'a rien à voir avec BIND, il est normalisé dans le RFC 1035.

Aussi bien NSD que BIND et Knot ont une configuration très simple dans ce cas, en quatre ou cinq lignes (l'exemple Knot donné dans mon article est complet et marche).

C'est plutôt la supervision qu'il faut soigner.

Mettre quelque chose sur LinuxFr procure un bon référencement ? Ça m'intéresse, alors :-)

Il y a plusieurs solutions. Dans des cas similaires précédents (l'opération Tulipe Noire, par exemple), Google avait utilisé OCSP http://www.bortzmeyer.org/6960.html Il y a aussi des règles spéciales dans Chrome pour prévenir Google en cas de certificats suspects de la maison mère (si l'utilisateur a Chrome). Enfin, il y a la possibilité d'un utilisateur qui détecte le loup (il suffit d'une courte bogue dans le logiciel d'interception qui laisse échapper un message d'erreur non-Googlien), copie le certificat, et l'envoie à Google.

http://www.ietf.org/mail-archive/web/perpass/current/msg01162.html

Je ne comprends pas la remarque sur "une seule IP derrière une URL". C'est clairement faux. (Il y en a trois derrière http://www.bortzmeyer.org/)

Pourquoi gâchée ? Ce n'était pas dans le cahier des charges, c'est tout. Aujourd'hui, ça y est. Participez à perpass plutôt que de regretter le passé :-)

Déjà, c'est mal de dire « cryptage » http://www.bortzmeyer.org/cryptage-n-existe-pas.html

Si, mais cela ne marche pas si on veut TLS et d'autres protocoles (en l'occurrence SSH, car plein de réseaux ne laissent d'accès que via le port 443).

Tout à fait. Une durée de validité des signatures DNSSEC de deux mois me convient tout à fait. Ceci dit, quand la re-signature est automatique (ce qui est fortement recommandé), la question du délai est moins cruciale.

Et la comparaison avec TLS n'est pas bonne car TLS ne permet pas facilement d'attaques par rejeu.

"Certaines" ? Non. Sans authentification, TLS est vulnérable à toutes les attaques de l'homme du milieu. Sans DNSSEC, le DNS est même vulnérable à l'homme du bord (pas besoin d'être homme du milieu pour faire un empoisonnement DNS.) Sans authentification, TLS ne protège que contre un attaquant passif (genre Firesheep).

Tout à fait d'accord sur le risque que la sécurité n'empêche les "petits" acteurs de se développer et les décourage, avant de les jeter dans les bras des gros silos fermés.

Pour LinuxFr, je suppose qu'il y a assez de compétences disponibles. Pour M. Michu qui voudrait faire un truc équivalent, on manque en effet d'outils simples et bien intégrés. Une bonne discussion avait eu lieu sur LinuxFr à ce sujet : https://linuxfr.org/users/bortzmeyer/journaux/rendre-l-auto-hebergement-facile-et-sans-douleur

Attention, c'est vrai qu'il faut re-signer périodiquement lorsqu'on utilise DNSSEC mais ce n'est pas forcément à la main, il est même au contraire très recommandé d'utiliser un outil automatique. Je suggère OpenDNSSEC (libre, évidemment, et tournant sur Linux, évidemment). http://www.opendnssec.org/

C'est pas qu'on s'en éloigne, c'est qu'on file à l'autre bout de la galaxie : la solution OVH est du pur claoude. On peut aimer mais question liberté, c'est pas ça…

L'accès à www.bortzmeyer.org en HTTPS est sur mon TODO. Le principal problème est la pénurie d'adresses IPv4. J'ai peu d'adresses et le port 443 est déjà pris par autre chose.

C'est vrai que seulement deux serveurs de noms pour linuxfr.org, tous les deux chez le même opérateur, ça fait un peu léger. Je suis sûr qu'on trouverait des secondaires volontaires dans la communauté (je suis volontaire, par exemple).

Je ne comprends pas l'allusion à dns2tcp (c'est quoi ? juste un tunnel IP sur DNS ?) Il y a encore des gens compétents (pas des certifiés Cisco) pour limiter la taille des paquets DNS à 512 octets ???

Aucun détail, aucune référence ? Du pur FUD.

Non, IPv6 ne change quasiment rien. Ses propriétés de sécurité sont à peu près les mêmes que celles d'IPv4. http://www.bortzmeyer.org/ipv6-securite.html

Il existe des tas de bonnes raisons de pousser la migration vers IPv6 mais la vie privée n'en est pas une.

Et la disponibilité native d'IPsec est une légende http://www.bortzmeyer.org/6434.html

Une réponse plus détaillée en http://www.bortzmeyer.org/usurpation-adresse-ip.html

Sur le problème des métadonnées, voir http://www.bortzmeyer.org/metadonnees.html

Je ne vois pas non plus la protection de la vie privée dans cette liste très curieuse et très limitée de ce qu'est la sécurité (cette protection s'entend souvent mal avec l'authentification).

Et c'est tout ? La résistance aux pannes n'est pas incluse dans la sécurité (elle s'entend en général mal avec l'authenticité et l'intégrité) ?