que les dits serveurs sont tous chez Theo, dans sa cave, pour divers questions de sécurité.
Raisons de sécurité mais pas que, voire même pas prioritairement. Theo avait expliqué dans une conférence il y a un moment (hop là petite excuse pour dire, j'ai cherché sur le net, j'ai pas retrouvé) que le fait de disposer de sa propre infrastructure lui permettait d'effectuer un bon nombre de tests qui sont difficilement réalisables sur des infrastructures tiers, à fortiori des infrastructures de gens qui gagnent leur vie avec.
Des trucs comme "je vais faire des broadcasts DHCP pourri en mode hammer"(1) ou encore "C'est parti pour deux heures de TCP fuzzing"(2) ce sont des choses que les hébergeurs pro (ou même les hébergeurs à but non lucratif mais avec quand même des accords à respecter) n’apprécient pas. En d'autres termes, a moins de pouvoir dédier complètement une branche indépendante de l'infrastructure, les risques de faire tomber tout le système en accueillant les serveurs OpenBSD chez soi sont loin d'être nuls. Et Théo craint tout simplement qu'à la deuxième ou troisième fois ou les tests réseaux assez particuliers qu'il lance plantent le cœur, on le prie gentiment de prendre ses cliques et ses claques et d'aller voir ailleurs.
(1) Technique qui consiste (entre autre) à tenter de renouveler des baux DHCP que l'on a pas instauré. Très pratique pour les attaques man in the middle
(2) Comme pour le code fuzzing, on envoie sur le réseau moult paquets TCP conforme à la norme, mais avec un contenu aléatoire. Vous seriez surpris du nombre de switchs et de routeurs (y compris de grande marque) qui tombent en quelques minutes maximum quand on commence à jouer à ça.
[^] # Re: Oui
Posté par Kaane . En réponse au journal Projets Open Source, des vaches à lait ?. Évalué à 10.
que les dits serveurs sont tous chez Theo, dans sa cave, pour divers questions de sécurité.
Raisons de sécurité mais pas que, voire même pas prioritairement. Theo avait expliqué dans une conférence il y a un moment (hop là petite excuse pour dire, j'ai cherché sur le net, j'ai pas retrouvé) que le fait de disposer de sa propre infrastructure lui permettait d'effectuer un bon nombre de tests qui sont difficilement réalisables sur des infrastructures tiers, à fortiori des infrastructures de gens qui gagnent leur vie avec.
Des trucs comme "je vais faire des broadcasts DHCP pourri en mode hammer"(1) ou encore "C'est parti pour deux heures de TCP fuzzing"(2) ce sont des choses que les hébergeurs pro (ou même les hébergeurs à but non lucratif mais avec quand même des accords à respecter) n’apprécient pas. En d'autres termes, a moins de pouvoir dédier complètement une branche indépendante de l'infrastructure, les risques de faire tomber tout le système en accueillant les serveurs OpenBSD chez soi sont loin d'être nuls. Et Théo craint tout simplement qu'à la deuxième ou troisième fois ou les tests réseaux assez particuliers qu'il lance plantent le cœur, on le prie gentiment de prendre ses cliques et ses claques et d'aller voir ailleurs.
(1) Technique qui consiste (entre autre) à tenter de renouveler des baux DHCP que l'on a pas instauré. Très pratique pour les attaques man in the middle
(2) Comme pour le code fuzzing, on envoie sur le réseau moult paquets TCP conforme à la norme, mais avec un contenu aléatoire. Vous seriez surpris du nombre de switchs et de routeurs (y compris de grande marque) qui tombent en quelques minutes maximum quand on commence à jouer à ça.