GuiGui's Show

« Les lignes directrices publiées par les CNILs européennes éludent de manière irresponsable les graves problèmes soulevés par l'arrêt de la Cour de Justice de l'Union européenne. Le droit au déréférencement met directement en cause la liberté d'expression et d'accès à l'information. En confiant aux moteurs de recherches et à des autorités administratives le soin d'arbitrer entre le droit à la vie privée et la liberté d'expression, l'arrêt de la Cour aggrave la dérive vers une régulation extra-judiciaire du Net. Or, les lignes directrices consacrent ce recul de l'État de droit, plutôt que d'inviter les législateurs à préciser le droit afin de poser les conditions d'une conciliation équilibrée entre vie privée et liberté d'expression. Si rien n'est fait, la CNIL risque de donner son aval de fait à une censure privée du Net [...] »

L'initiative est bonne (peu de prestas communiquent autant sur les incidents) mais le rapport manque encore de détails (marque(s) des appliances anti-DDoS, composition du trafic, description technique *précise* des problèmes rencontrés, ...).

« A new customer signed up for our service and brought in multiple domains that were already facing a DDoS attack. The customer had already tried at least 2 other providers before DNSimple. Once the domains were delegated to us, we began receiving the traffic from the DDoS.

[...]

The volume of the attack was approximately 25gb/s sustained traffic across our networks, with around 50 million packets per second. In this case, the traffic was sufficient enough to overwhelm the 4 DDoS devices we had placed in our data centers after a previous attack (there is also a 5th device, but it was not yet online in our network).

[...]

Second, even once the device was in place, the amount of traffic that was actually passed through the device caused our name server software to crash shortly after having receiving the volume of requests.
[ On note l'enseignement : lutter contre un DDoS, ce n'est pas uniquement un frontal à poser là et basta. ]

[...]

By about 6 AM UTC we had restored UDP traffic to the majority of our systems. We were still experiencing resolution failures for A records in our Amsterdam and Tokyo data centers, but other record types were resolving properly. After some research (many thanks to Peter van Dijk of PowerDNS for his help here), we decided to disable the DNS defense mechanism from DDoS protection device in the Amsterdam facility. Once we did this, all resolution returned to normal there.

We were still showing resolution issues with some public resolvers (such as Google's Public DNS). We went through the remaining data centers and removed the DNS defense mechanism from other DDoS protection devices and eventually we were able to get successful resolution from Google's public DNS.
[ Pas mal, ces dommages collatéraux. ]

We do not have the skills and budget to develop a complete DDoS solution internally. It is a very expensive endeavor and requires expensive equipment, lots of bandwidth, and deep knowledge on how to mitigate attacks. We have signed a contract with a well-known third-party service that provides external DDoS protection using reverse DNS proxies. Presently, our primary objective is to get all DNS traffic routed through the vendor first so that they can cache and deflect volumetric attacks like the one we just experienced.
[ La lutte anti-DDoS, une façon de centraliser le net ? Tout comme l'externalisation des mails (office365 par exemple), je me demande si une solution interne est vraiment plus coûteuse en terme de coûts directs (payer le presta "au fil de l'eau" versus investir matos+humain sur la durée) et indirects (effets collatéraux, dépendance à un presta, concentration des acteurs, risque d'attaques plus grand si tout est centralisé chez quelques prestas, ... ].

We are also well aware that one mitigation strategy is to allow customers to have secondary servers that can slave to our primary servers, and that this would have allowed many customers to continue operating, albeit at a possibly degraded level.
[ Ça c'est une "bonne" piste comparée à la précédente, je trouve. ] »

Via https://twitter.com/jedisct1/status/540079258807189504

« Donc, sur le top 1000 #alexa, on compte : 465 serveurs DNS akamai, 296 google, 104 cloudflare, 155 ultradns, 81 dnsmadeeasy, 52 verisign. Oups pardon, y’a des petits malins qui changent de domaines pour chaque zone… Donc 354 awsdns en plus, et 442 dynect. Sur 3714 NS DNS, il n’y a que 500 providers différents. Dont 20 seulement pour gérer 2230 NS soit 60% du top 1000 mondial… Juste les 10 1ers gèrent 53% des NS, les 5 1ers 44%, les 3 1ers 34% et le 1er 12% !!! Pour résumer, vous trouillotez Akamai, Dynect, AWSDNS, Google, UltraDNS et Cloudflare, vous chopez 51.29% du traffic DNS du top1000 #Alexa… Le 1er truc qui semble hébergé en propre sans provider de DNS, ça semble être #wikimedia \o/ Derrière 2424 autres trucs… /o\ »

« Le top [des hébergeurs DNS] reste (dans l’ordre) : aws, akamai, dynect, cloudflare, ultradns, dnsmadeeasy, google, domaincontrol. 42% des NS. »

Problème de concentration des hébergeurs DNS aussi mis en exergue par l'Observatoire de la Résilience de l'Internet français encore en 2013, voir : http://shaarli.guiguishow.info/?xVseHw

Sources :
https://twitter.com/aeris22/status/538851126410739712
https://twitter.com/aeris22/status/538851656033914881
https://twitter.com/aeris22/status/538852563907776512
https://twitter.com/aeris22/status/538855799519711232
https://twitter.com/aeris22/status/538852978988687360
https://twitter.com/aeris22/status/539188899479052288

ÉDIT du 19/02/2015 à 10h40 : pour une version formatée, voir : http://shaarli.guiguishow.info/?7NeDJA FIN DE L'ÉDIT.

« Cependant, contacté plusieurs fois depuis jeudi par Numerama, l'expert Bruno Bonnaure du cabinet Expertis Lab mandaté par l'UMP ne nous a pas répondu. "Je ne me parviens pas à me libérer. Ce sera difficile avant le lancement du vote UMP de ce jour", nous a-t-il tout de même adressé par SMS. Interrogé par ce biais pour savoir si son rapport avait bien été remis à la CNIL comme le prévoit la recommandation de 2010, et s'il serait rendu public, celui-ci ne a pas répondu à l'heure où nous publions ces lignes.

De même pour la CNIL, qui avait déjà brillé par son silence en 2012, alors qu'elle avait permis au vote d'être organisé dans des conditions de sécurité catastrophiques, malgré la réception au tout dernier moment du rapport d'audit (à 48 heures du vote, il n'était toujours pas sur le bureau de la CNIL). Contactée deux fois ce vendredi, elle n'a pas pu ou pas souhaité nous répondre, prétextant un agenda surchargé en cette fin de semaine.

Même silence enfin côté UMP. Contactée jeudi, la Haute Autorité de l'Union, censée rassurer sur les conditions d'organisation du scrutin, ne nous a pas répondu concernant la réception et les conclusions du rapport d'audit qu'elle a commandée.

A quelques heures de l'ouverture du vote, rien n'est donc publié qui puisse certifier de la sincérité et la confidentialité du vote. Or il y a des raisons de s'inquiéter. Interrogé par France Télévisions, le directeur de campagne de Bruno Le Maire a déclaré que l'expert s'était montré "plutôt rassurant", tandis que l'expert Bruno Bonnaure a répondu que son cabinet s'était "voulu rassurant car le dispositif répond à beaucoup de nos questions". Mais pas toutes ?

Il y a encore trois semaines, c'est le cabinet Bureau Veritas qui devait se charger de l'audit de la solution de vote électronique. Mais il a préféré jeté l'éponge, en expliquant que les "délais très courts ne lui permettaient pas de conduire sérieusement cette expertise". En cause, notamment : des affrontements autour du refus de décompter les votes par fédération, qui aurait permis de mieux identifier d'éventuelles fraudes. »

« Nous constatons à ce moment là, le niveau zéro de la sécurisation dont le backoffice fait l’objet : n’importe quel internaute peut se balader dans les répertoires destinés à l’application de traitement des votes. Des numéros sont attribués à ces répertoires, ils se réfèrent chacun à un scrutin. Tout ceci est clairement écrit dans des fichiers javascripts, parfaitement accessibles de tous et des développeurs à leur simple lecture en attraperaient des boutons. Dans ces fichiers, on trouve évidemment en clair le nom des répertoires destinés à accueillir les votes… ça sent très mauvais.

[...]

Les premières déclarations tombent rapidement et on apprend qu’entre 20h15 et 22h, le site aurait été victime d’une attaque par saturation de 26 000 connexions par secondes émanant d’un seul serveur. [NDLR : la partie mauvaise foi : « Le problème de plomberie, c’est cette attaque on ne peut plus classique par saturation (déni de service) venant d’un seul serveur se bloque en un clin d’œil, un simple ligne de commande pour ajouter une directive au firewall suffit. » -> ouuuuuais : saturation des uplinks en fonction de la capacité réseau de l'attaquant, de plus on se base sur les stats (26000/un seul serveur) fournies par des cadres du parti ... prudence quoi. ]

[...]

des vulnérabilités de plus de 6 mois dont tous les médias ont pourtant abondamment parlé n’étaient pas corrigées. La version d’OpenSSL installée sur le backoffice était vulnérable à la célèbre attaque Heartbleed (CVE-2014-0160 datant d’avril 2014) et à une autre faille critique, dite CCS ( CVE-2014-0224 datant de juillet 2014).

[...]

À ce niveau, on peut parler de failles inadmissibles et les faits observés parlent d’eux mêmes :
    - la sécurité de l’infrastructure n’a pas été sérieusement vérifiée. Elle n’était pas même à jour de vieilles vulnérabilités bien connues de n’importe quel administrateur système digne de ce nom ;
    - la lecture du code accessible (le code javascripts servant au traitement des données) ne fait que confirmer ce que nous avons observé, le système de vote en ligne n’est pas au niveau ;
    - les tentatives de corrections au fil de l’eau ont été elles aussi une superbe démonstration d’amateurisme, à l’image du placement dans l’urgence d’un fichier « index.html » pour « sécuriser » un répertoire au lieu d’une simple directive dans un fichier de configuration du serveur à même de sécuriser l’ensemble des répertoires du serveur ou de l’application.

L’UMP a peut-être essuyé une attaque par déni de service, mais Paragon Elections, à qui incombe la partie applicative et la sécurité du système de vote, nommé Smartvotation, est loin d’être la forteresse imprenable que l’on nous a présenté.

[...]

Dans ces conditions, il est légitime de se demander si le vote des primaires de l’UMP n’a pas été altéré par des tiers. »

Ce qui m'attriste le plus : « Au-delà des mésaventures UMP, il faut se rappeler que le vote électronique a pour principale propriété d'empêcher le contrôle par l'électeur » (https://twitter.com/bortzmeyer/status/538628770543185920). Par un grand parti politique de France. Les vulnérabilités vont être oubliées et "on" se souviendra que le vote électronique, ça marche, c'est pratique et tout ce qu'on veut. :(

« Je vois souvent des explications sur le système des noms de domaine qui tentent de donner des noms aux différentes parties d'un nom. Par exemple, pour www.example.com, on voit parfois des explications du genre « www est un sous-domaine, example est le nom de domaine et com est l'extension ». Ces explications sont toutes fausses et je vais essayer d'expliquer pourquoi.

[...]

Le fait qu'ils aient un nombre différent de composants (la partie entre les points) ne change rien. Beaucoup de gens croient qu'un nom de domaine comporte forcément deux (ou trois, selon les sources) composants mais c'est tout à fait faux.

[...]

On entend parfois le terme de « sous-domaine ». Malheureusement, il est souvent utilisé en supposant qu'il y a des domaines qui sont des sous-domaines et d'autres qui seraient des « vrais » domaines. Mais ce n'est pas le cas. Tous les domaines sont des sous-domaines d'un autre (à part le cas particulier de la racine, le début des domaines). Ainsi, signal.eu.org est un sous-domaine de eu.org, lui-même un sous-domaine de org, lui-même sous-domaine de la racine.

[...]

Souvent, les gens sont intéressés par le domaine enregistré, le nom de domaine qui a été loué auprès d'un registre de noms de domaine, le nom pour lequel on a acquis un droit d'usage (droit qui inclut la possibilité de créer des noms plus spécifiques). Par exemple, dans www.toyota.co.jp, le nom qui a été enregistré (à JPNIC) était toyota.co.jp. Beaucoup de gens croient que le nom enregistré est composé des deux derniers composants mais c'est inexact (comme dans l'exemple japonais plus haut). Beaucoup de gens pensent qu'on ne peut créer des noms que sous un domaine d'enregistrement comme fr ou com mais non : tout titulaire d'un nom peut créer des noms sous ce nom. Si je suis titulaire de example.com, je peux créer, mettons compta.paris.example.com.

[...]

Un autre terme utilisé, et qui recouvre parfois une réalité importante, par exemple pour déterminer la loi nationale applicable en cas de conflit) est TLD (Top-Level Domain) qui désigne le composant le plus général (le plus à droite). fr, net et pizza sont tous les trois des TLD. (On note parfois le TLD avec un point devant, pour bien montrer que c'est un nom de domaine.) Formé de la même façon, on rencontre parfois le sigle SLD, pour Second-Level Domain comme gouv.fr ou ovh.com.

On voit parfois le terme d'« extension » être utilisé, mais sans qu'il soit jamais défini. Parfois, c'est un synonyme de TLD (mais en moins clair, car on peut confondre avec l'extension du nom de fichier), parfois un synonyme de domaine d'enregistrement. Un terme aussi flou est donc à fuir. »

« Le Conseil européen d’hier s’est finalement soldé par un échec. Les représentants de gouvernements ne sont pas arrivés à trouver un accord, ni sur la neutralité du Net, ni sur les frais d’itinérance. Leurs discussions devraient donc durer encore plusieurs mois, ce qui repousse inexorablement l’adoption d’une éventuelle réforme du « paquet télécom ».

[...]

Sauf qu’à l’approche du Conseil européen d’hier, les inquiétudes se sont multipliées. Les opposants à un Net à deux vitesses craignent que les représentants des gouvernements des États membres ne vident cette définition de sa substance, en la transformant en simple et vague objectif à suivre (voir notre article).

Du côté des dispositions sur le roaming, dont l’objectif est de permettre aux citoyens européens d’appeler ou de recevoir un appel sans surcoût depuis n’importe quel pays de l’Union d'ici Noël 2015, les points de frictions sont plus techniques puisqu’ils reposent notamment sur les modalités de compensation pour les opérateurs (prix de gros).

[...]

Les divergences sur ces deux sujets sont d’ailleurs telles que le Conseil européen a conclu hier que « davantage de travail technique était nécessaire afin d'avoir une position commune sur l'itinérance et la neutralité du Net ». En clair, aucun n’accord n’a été trouvé, et les discussions vont continuer au moins pendant plusieurs mois. Le communiqué dévoilé à l’issue de la réunion précise au passage que les pourparlers avec le Parlement européen ne pourront commencer que lorsque les représentants des États membres se seront mis d’accord entre eux...

Sur la neutralité du Net, on apprend que la proposition « molle » concoctée par l’Italie a été considérée par « la plupart des États membres » comme une « bonne base de travail », et que « quelques délégations » ont exprimé leur soutien envers un projet porté par les Néerlandais, visant à interdire toute « discrimination de prix ».

S’agissant du roaming, les États membres se sont accordés sur le fait qu’il convenait d’agir « le plus tôt possible », sauf que « la plupart d’entre eux ont exprimé le besoin d’avoir plus de temps pour analyser la meilleure approche à retenir », précise le communiqué final. Certains pays réclament une meilleure régulation des prix de gros et une définition du « fair use ».

[...]

Hasard du calendrier, les eurodéputés ont adopté hier une importante résolution pour « invite[r] instamment le Conseil à progresser rapidement et à ouvrir des négociations avec le Parlement sur [cette] proposition de règlement ». Les nouveaux élus ont apporté un puissant soutien politique au texte voté par leurs prédécesseurs (le Parlement ayant été renouvelé cet été), en affirmant en direction des gouvernements que « l'ensemble du trafic internet doit être traité de façon égale, sans discrimination, limitation ni interférence, indépendamment de l'expéditeur, du destinataire, du type, du contenu, de l'appareil, du service ou de l'application ». »

« Un document fuité1 (note et addendum), présenté par la présidence italienne le 14 novembre dernier, révèle le mauvais tournant que les États membres de l'UE sont en train de prendre sur la neutralité du Net pendant les négociations concernant le règlement européen sur le marché unique des télécommunications. En avril dernier, le Parlement européen a adopté en première lecture une version du texte qui inclut une forte protection de la neutralité du Net, conçue pour protéger les communications en ligne des citoyens européens contre toute discrimination. Aujourd'hui, les gouvernements européens sont en train de démanteler ce texte totalement.

[...]

La proposition de la présidence italienne suggère, entre autres, la suppression des définitions de la « neutralité du Net » et des « services spécialisés », ce qui efface toutes les protections que le texte du Parlement européen avait élevées pour structurer un Internet ouvert contre les stratégies commerciales nocives des plus grandes entreprises de l'Internet.

Pour couronner le tout, la présidence italienne — et de nombreux autres États membres, dont la France, semblent accepter cette idée — propose également de limiter les restrictions pour les opérateurs en matière de mise en œuvre des mesures de gestion du trafic. En particulier, le texte pourrait autoriser les blocages de sites Internet décidés par les agences gouvernementales en charge de la régulation du secteur des télécoms, sans aucune intervention judiciaire.

[...]

« Le retournement de veste de la présidence italienne — avec la complicité active d'États membres comme la France ou la Grande-Bretagne — est une trahison regrettable, particulièrement si nous nous souvenons des bonnes intentions proclamées au début du mandat italien. Le document de travail actuellement discuté par le Conseil de l'UE est une claque donnée à tous les citoyens et législateurs qui ont combattu pour une vraie protection de la neutralité du Net au printemps. »

On a un processus syslog-ng qui reçoit des logs locaux et réseaux (TCP et UDP). Les flux réseau sont conséquents mais loin d'être ingérables. Pourtant le processus syslog-ng consomme de 36% à 40% du temps CPU.

Le problème venait d'un bloc comme celui-ci dans les fichiers de conf (/etc/syslog-ng/conf.d/*) :
destination lala { program("/opt/bin"); };
log { source(lol); destination(lala); };

On cherche donc à transférer les logs qui arrivent par la source nommée « lolo » sur l'entrée standard du binaire « /opt/bin ». Mais ce binaire n'existe plus. syslog-ng passe son temps à vérifier encore et toujours sa présence et paf, 20% de charge CPU. Si vous avez deux blocs comme celui-ci, ce qui était mon cas, vlam 36-40%. Après correction : 0-2% CPU \o/

Relecture des confs "sûres" et strace FTW. \o/

Comme quoi, la mécanique de la peur, le caractère anxiogène de l'information diffusée, c'pas tellement nouveau ...

Via http://seenthis.net/messages/307239