ip r s proto zebra : voir les routes ajoutées dans la FIB par le démon zebra de quagga
ip r s proto bird : même chose mais avec BIRD
ip -6 r s proto ra : même chose mais avec les messages ICMPv6 router advertisement
ip (-6) r s proto kernel : même chose mais avec l'autoconf (link locale v6, route de l'if en v4/v6, ...)

Quand on ajoute beaucoup de routes à partir d'un script par exemple, pourquoi ne pas créer notre numéro de protocole ? La visualisation et la suppression des routes ajoutées en cas d'erreur ou à la fin du process en devient super simple : ip r (show | flush) proto <notre_proto>. Après tout, on peut bien nommer des tables de routage alternatives (c'est dans /etc/iproute2/rt_tables que ça se passe, cf http://shaarli.guiguishow.info/?xT-HMA pour un cas d'usage) alors pourquoi pas un protocole ?

Hé bah si, c'est dans /etc/iproute2/rt_protos que ça se passe !

Exemple :
echo "245 exemple" >> /etc//iproute2/rt_protos
ip r a a 192.0.2.0/24 dev <dev> proto exemple
ip r f proto exemple

Quagga :
hostname bgpd
password toor
log file /var/log/quagga/bgpd.log

router bgp 65000
  bgp router-id 198.18.0.1
  neighbor 198.18.0.2 remote-as 65001
  neighbor 198.18.0.2 ebgp-multihop <nb_routeurs_traversés + 1> (= la sortie d'un traceroute)

sh ip bgp neighbor : « External BGP neighbor may be up to X hops away. »


BIRD :
log "/var/log/bird.log" { error };

router id 198.18.0.2;

protocol bgp test {
  local as 65001;
  source address 198.18.0.2;
  neighbor 198.18.0.1 as 65000;
  multihop <nb_routeurs_traversés + 1> (= la sortie d'un traceroute);
}


Notons qu'en iBGP, BIRD fait la vérification alors que Quagga ne fait ni la vérification ni ne positionne le TTL à la bonne valeur.

OWI, comment injecter des préfixes dans un routeur BGP à partir d'une RIB au format MRT. Pratique quand on veut utiliser une full view dans un lab mais que l'on n'a pas un routeur de la DFZ sous la main.

Seul inconvénient : le parse pour injection avec bgpsimple est long : il faut compter ~20 mns pour un dump de 7,8 millions de lignes et jusqu'à ~1h pour un dump de 13 millions de lignes, en fonction de la vitesse de votre CPU. Bien que la la full view v4 tourne actuellement autour de 513000 routes, il ne faut pas oublier que la taille du dump dépend de la connectivité du routeur qui l'a produit : plusieurs chemins = plusieurs entrées dans la RIB, certains opérateurs désagrègent les préfixes, ...


Quelques améliorations/màj du tuto :

libbgpdump/bgpdump
    * Dernière version de libbgpdump : http://www.ris.ripe.net/source/bgpdump/libbgpdump-1.4.99.13.tgz


    * apt-get install libbz2-dev zlib1g-dev

      Si vous ne le faites pas avec le ./configure, alors vous aurez l'erreur suivante lors de la compilation :
          libbgpdump.a(cfile_tools.o): In function `cfr_open':
          /home/guigui/libbgpdump-1.4.99.13/cfile_tools.c:91: undefined reference to `gzdopen'
          /home/guigui/libbgpdump-1.4.99.13/cfile_tools.c:144: undefined reference to `BZ2_bzReadOpen'
          /home/guigui/libbgpdump-1.4.99.13/cfile_tools.c:147: undefined reference to `BZ2_bzReadClose'
          /home/guigui/libbgpdump-1.4.99.13/cfile_tools.c:162: undefined reference to `gzopen64'
          libbgpdump.a(cfile_tools.o): In function `cfr_close':
          /home/guigui/libbgpdump-1.4.99.13/cfile_tools.c:206: undefined reference to `gzclose'
          /home/guigui/libbgpdump-1.4.99.13/cfile_tools.c:199: undefined reference to `BZ2_bzReadClose'
          libbgpdump.a(cfile_tools.o): In function `cfr_read':
          /home/guigui/libbgpdump-1.4.99.13/cfile_tools.c:307: undefined reference to `gzread'
          /home/guigui/libbgpdump-1.4.99.13/cfile_tools.c:310: undefined reference to `gzeof'
          /home/guigui/libbgpdump-1.4.99.13/cfile_tools.c:267: undefined reference to `BZ2_bzRead'
          /home/guigui/libbgpdump-1.4.99.13/cfile_tools.c:291: undefined reference to `BZ2_bzReadClose'
          libbgpdump.a(cfile_tools.o): In function `cfr_getline':
          /home/guigui/libbgpdump-1.4.99.13/cfile_tools.c:394: undefined reference to `gzgets'
          libbgpdump.a(cfile_tools.o): In function `cfr_strerror':
          /home/guigui/libbgpdump-1.4.99.13/cfile_tools.c:473: undefined reference to `gzerror'
          collect2: error: ld returned 1 exit status

     Vous pourrez toujours relancer la config' de la compil' ou ajouter « -lz -lbz2 » à la variable CFLAGS.


    * « ./configure --disable-ipv6 » -> non, en 2015 on compile avec le support IPv6 !


    * Lors du make install, vous aurez l'erreur suivante :
     
      make: *** Pas de règle pour fabriquer la cible « testbgpdump », nécessaire pour « install ». Arrêt.

      Il suffit de : sed -i s/testbgpdump// Makefile puis de relancer make install


    * bgpdump permet d'écrire directement dans un fichier, pourquoi écrire sur stdout puis rediriger ?
     
      zcat bview.20090820.2359.gz | bgpdump -m - > rib.ris.20090820.2359
        s'écrit
      zcat bview.20090820.2359.gz | bgpdump -m -O rib.ris.20090820.2359 -


    * Dans le même ordre d'idée, bgpdump accepte désormais les fichiers compressés (gzip, bzip2) en entrée

      zcat bview.20090820.2359.gz | bgpdump -m - > rib.ris.20090820.2359
        s'écrit
      bgpdump -m -O rib.ris.20090820.2359 bview.20090820.2359.gz


    * Il n'y a pas que le RIPE qui propose des RIB au format MRT. Le projet Route Views (http://www.routeviews.org/) propose aussi cela.

      Exemple :
        wget ftp://archive.routeviews.org/route-views.linx/bgpdata/2014.12/RIBS/rib.20141230.1400.bz2
        bunzip2 rib.20141230.1400.bz2 ; bgpdump -m -O rib.rw.20141230.1400 rib.20141230.1400 ou, directement : bgpdump -m -O rib.rw.20141230.1400 rib.20141230.1400.bz2




bgpsimple
    * Dernière version de bgpsimple : wget http://bgpsimple.googlecode.com/svn/trunk/bgp_simple.pl

    * chmod +x bgp_simple.pl

    * Par défaut, il écrit les updates qu'il effectue sur stdout même si on ne lui demande pas d'être verbeux ! Ce comportement tue les performances (~6000 lignes parsées par minute avec affichage, ~13000 sans affichage !). Pour virer l'affichage, il faut mettre en commentaire les lignes 640 à 649 :
=pod
                sub_debug ("u", "Send Update: ")                        if (!$dry);
                sub_debug ("u", "Generated Update (not sent): ")        if ($dry);
                sub_debug ("u", "prfx [$prefix] aspath [$aspath] ");
                sub_debug ("u", "locprf [$local_pref] ")                if ($peer_type eq "iBGP");
                sub_debug ("u", "med [$med] ")                          if ($med);
                sub_debug ("u", "comm [@communities] ")                 if (@communities);
                sub_debug ("u", "orig [$nlri[7]] ");
                sub_debug ("u", "agg [@agg] ")                          if (@agg);
                sub_debug ("u", "atom [$atomic_agg] ")                  if ($atomic_agg);
                sub_debug ("u", "nxthp [$nexthop]\n");
=cut


    * Si vous utilisez des routeurs logiciels, il vous faudra deux machines (ou jouer avec les netns / VM) car le routeur d'en face ne se laissera pas berner par une IP locale (une IP présente sur l'une des interfaces de la machine (lo, eth0, ...) + l'option « -nolisten » de bgpsimple. BIRD le signale très clairement : « bird: bgp1: Invalid remote address 198.18.0.1) »


    * À l'usage, j'ai remarqué un problème : dès la fin de l'émission des updates, bgpdump se plaint que le hold timer a expiré. Pourtant le routeur d'en face (pour vérifier avec Quagga : sh ip bgp neighbor) lui a bien envoyé des keepalive régulièrement. Ce comportement est identique que bgpdump soit client ou serveur (que ce soit lui qui initie la connexion ou pas). La solution est que le holdtime soit supérieur à la durée que prendra le parse du fichier. Exemple : s'il faut 20 minutes pour injecter le fichier, un holdtime de 15 minutes ne passe pas. C'est plus ou moins approximatif : s'il faut 22 minutes pour injecter, un holdtime de 20 minutes semble passer.

     Mon avis est que bgpsimple et surtout la lib utilisée, Net::BGP::, ne sont pas multi-threadés. Ils ne font donc qu'envoyer les updates sans prendre en compte les keepalive (la fonction de callback n'est pas exécutée) durant cet intervalle. Donc, à la fin de l'émission des updates, le holdtime a expiré, en effet.

     La seule solution que je vois est de configurer un intervalle de keepalive et surtout un holdtime supérieur à la durée d'injection du fichier. Cela se fait avec les arguments « -keepalive <secs> » et « -holdtime <secs> ». Il faut que ça coïncide avec les intervalles définis dans le routeur à l'autre bout. Sous Quagga « timers bgp <keepalive en secs> <holdtime en secs> ». Pour BIRD : « keepalive time <secs>; » et « hold time <secs>; »




Comment produire vos propres dumps au format MRT avec des routeurs logiciels ?
De tous les messages BGP (OPEN, UPDATE, NOTIFICATION, ...) :
    - Quagga : « dump bgp all path interval » dans bgpd.conf

    - BIRD : « mrtdump "/path/to/filename";» en global puis soit « mrtdump protocols { messages }; » en global pour appliquer à toutes les instances BGP, soit « mrtdump { messages } ; » dans les instances désirées.


De tous les messages UPDATE :
    - Quagga : « dump bgp updates path interval »

    - BIRD : pas d'équivalent


De la RIB BGP :
    - Quagga : « dump bgp routes-mrt path interval ». Exemple :  dump bgp routes-mrt /var/run/bgpdata/%Y-%m/rib.%F.%H%M 15m , le dossier doit exister (même dernier niveau, ici /%Y-%m) et doit être accessible en écriture par l'utilisateur quagga (chown ...)

    - BIRD : pas d'équivalent. mrtdump ne permet pas cela, la commande « dump resources|sockets|interfaces|neighbors|attributes|routes|protocols » de birdc ne produit pas une sortie au format MRT et il s'agit d'un dump de la FIB (on a perdu les attributs BGP autre que préfixe et next-hop, cf code : « FIB_WALK() » dans rt_dump() ). Exemple de sortie :
1.22.89.0      /24 KF=80 PF=00 pref=100 lm=17 p=bgp1 uc=1 RTS_BGP univ UNREACH h=52f2 <-198.18.0.1 EA: [SbC] 01:01.40=i:00000000 01:02.40=P[18]:020400001b6a00000da30000d8720000b1d8 01:03.40=I[4]:3f01000c 01:05.40=i:00000000 01:08.c0=S[8]:88136a1b70916a1b

     Si vous aussi vous cherchez la « debugging output. » dont parle le manuel à propos de la commande dump, il ne s'agit pas des sorties configurées dans le fichier de conf' avec les directives « log » et « debug », non. Si l'on lit le code source (utilisation de la fonction debug() définie dans sysdep/unix/log.c qui écrit dans un handler ouvert par log_init_debug(char *f) toujours dans le même fichier qui elle, est appelée par main() dans sysdep/unix/main.c en fonction des arguments passés à BIRD), il faut lancer BIRD avec les arguments : « -D /path/to/filename » ou « -d (stderr implicite) ». En effet, ça fonctionne mais alors BIRD ne devient plus un démon... Pas top.

On fait un premier bilan posé suite à l'emballement médiatique de ces derniers jours.

C'est tellement vrai... Poodle (cf http://shaarli.guiguishow.info/?GPqmpA), le talk de Jacob et Laura au 31C3 sur NSA versus VPN/Tor/SSH/HTTPS, ... C'est à chaque fois pareil. Prudence et patience, les gens...

Via https://twitter.com/bortzmeyer/status/549870757539356672

C'est le comportement par défaut sous OpenWRT : les paquets reçus sur l'interface WiFi sont balourdés sur l'interface lan et donc sur les ports du switch associés à cette interface et réciproquement pour l'interface lan. Un bridge quoi.

Ce comportement peut être changé : on peut isoler les clients WiFi du LAN, les bridger sur une autre interface à laquelle sera associée un seul port du switch, ...

J'ai eu à installer un Debian Wheezy sur un ordinateur équipé d'une carte mère Asus P5K Prenium. Cette carte mère n'a pas de port floppy. Donc aucune option dans le BIOS pour désactiver un truc qui n'existe pas. ;)

J'utilise une iso netinstall.

Durant l'installation, Debian Installer voit un lecteur de disquettes et forcément, n'arrive pas à interagir avec lui : « Buffer I/O error on device fd0, logical block 0 ». Donc l'installation bloque à 40 % de l'étape de détection des disques...

Dans le BIOS, on voit un paramètre « emulation type » pour les périphériques de stockage USB. Il y a une option « floppy ». Mais par défaut, la valeur est « auto ». La passer cette valeur de « auto » à « hard drive » ne change rien.

Ajouter « rdblacklist=floppy » à la cmdline du noyau depuis le menu de boot ne change rien.

Solution qui a marché pour moi : ouvrir une console dès le début de l'installation, avant d'arriver à la phase de détection des disques durs avec ctrl+alt+F2. Utiliser les commandes :
    - rmmod floppy
    - echo "blacklist floppy" > /etc/modprobe.d/blacklist.conf

Une autre solution qui pourrait fonctionner : https://www.debian.org/releases/stable/i386/ch05s03.html.en#module-blacklist . Via b4n.

L'installation se déroule sans problèmes. Une fois le système installé, refaire préventivement echo "blacklist floppy" > /etc/modprobe.d/blacklist.conf .

Une erreur « fd0 read error » persiste avant l'apparition du menu de GRUB2. On est donc bien avant initrd/linux. Cette erreur n'est pas bloquante mais elle ralentit le processus de boot d'environ 5-7 secondes. Je n'ai pas trouvé de solution et, vu le faible gain possible, j'ai renoncé. Ce problème (en tout cas le lag qu'il produit) semble avoir été corrigé dans la version 2.00-1 de GRUB2, cf : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632408 . Debian Jessie ne devrait donc plus avoir ce problème. Wait&see. Merci à b4n pour l'info.

Lorsque votre /home est totalement plein, Gajim (client XMPP/Jabber) plante (à l'initiation d'une conversation (création de l'historique si activé), lors d'un changement d'état (absent -> disponible), ...). Cela corrompt le cache (ça se voit par exemple au nom de la ressource qui passe du nom compréhensible que j'ai défini dans les options du compte à un ID en hexa).

Ça peut aller jusqu'au fait que vous envoyez des messages à un contact, lui vous lit, vous n'avez pas le retour que le message a été délivré (donc vous avez un panneau signalisation warning qui s'affiche), vous ne voyez pas ses réponses. Que ça soit vous ou lui qui initialisez la conversation, ça ne change rien. Ça touche tous les contacts en même temps. Redémarrer vos serveurs XMPP (le vôtre et celui de votre contact) ne change rien.

Solution : fermer Gajim, supprimer le dossier ~/.cache/gajim, lancer Gajim.

C'est moche. :(

Ce qui m'ennuie, c'est : quelles alternatives à Cyanogen ? Replicant ? Firefox OS ? Trop peu de modèles supportés, partiellement ou en intégralité, des vieux modèles qui n'ont pas toutes les fonctionnalités attendues de nos jours pour un modèle qui dure dans le temps (4G, 4G LTE, ...), un manque de disponibilités des modèles supportés, ...

Je me demande ce qui suit : ok, Cyanogen Inc fait des trucs pas cools et pas éthiques du tout mais si la communauté a encore le code, sous licence libre, qu'elle n'accepte aucune compromission avec des fournisseurs de services (ni avec Cyanogen Inc), qu'on n'achète pas un ordinateur de poche dont des morceaux de code libres ont été adaptés à l'appareil puis mis sous licence privatrice, quel impact cela-a-t-il ? Dit autrement : quelle indépendance la communauté a-t-elle vis-à-vis de Cyanogen ? C'est ça l'important, àmha. Des pilotes/blob proprios, il y'en a déjà dans Cyanogen donc bon...

« It was in the summer of 2012 that the anomalies were initially detected by employees at Belgium’s largest telecommunications provider, Belgacom. But it wasn’t until a year later, in June 2013, that the company’s security experts were able to figure out what was going on. The computer systems of Belgacom had been infected with a highly sophisticated malware, and it was disguising itself as legitimate Microsoft software while quietly stealing data.

Last year, documents from National Security Agency whistleblower Edward Snowden confirmed that British surveillance agency Government Communications Headquarters was behind the attack, codenamed Operation Socialist. And in November, The Intercept revealed that the malware found on Belgacom’s systems was one of the most advanced spy tools ever identified by security researchers, who named it “Regin.”

The full story about GCHQ’s infiltration of Belgacom, however, has never been told. Key details about the attack have remained shrouded in mystery—and the scope of the attack unclear.

Now, in partnership with Dutch and Belgian newspapers NRC Handelsblad and De Standaard, The Intercept has pieced together the first full reconstruction of events that took place before, during, and after the secret GCHQ hacking operation.

[...]

The origins of the attack on Belgacom can be traced back to 2009, when GCHQ began developing new techniques to hack into telecommunications networks. The methods were discussed and developed during a series of top-secret “signals development” conferences, held annually by countries in the so-called “Five Eyes” surveillance alliance: the United States, the United Kingdom, Australia, New Zealand, and Canada.

Between 2009 and 2011, GCHQ worked with its allies to develop sophisticated new tools and technologies it could use to scan global networks for weaknesses and then penetrate them. According to top-secret GCHQ documents, the agency wanted to adopt the aggressive new methods in part to counter the use of privacy-protecting encryption—what it described as the “encryption problem.”

When communications are sent across networks in encrypted format, it makes it much harder for the spies to intercept and make sense of emails, phone calls, text messages, internet chats, and browsing sessions. For GCHQ, there was a simple solution. The agency decided that, where possible, it would find ways to hack into communication networks to grab traffic before it’s encrypted. [ NDLR : de l'importance du chiffrement de bout en bout (OpenPGP) ou d'autohéberger son serveur (TLS) ]

The Snowden documents show that GCHQ wanted to gain access to Belgacom so that it could spy on phones used by surveillance targets travelling in Europe. But the agency also had an ulterior motive. Once it had hacked into Belgacom’s systems, GCHQ planned to break into data links connecting Belgacom and its international partners, monitoring communications transmitted between Europe and the rest of the world. A map in the GCHQ documents, named “Belgacom_connections,” highlights the company’s reach across Europe, the Middle East, and North Africa, illustrating why British spies deemed it of such high value.

[...]

GCHQ had accomplished its objective. The agency had severely compromised Belgacom’s systems and could intercept encrypted and unencrypted private data passing through its networks. The hack would remain undetected for two years, until the spring of 2013.

[...]

By December 2011, as part of a second “surge” against Belgacom, GCHQ identified other cellphone operators connecting to company’s network as part of international roaming partnerships, and successfully hacked into data links carrying information over a protocol known as GPRS, which handles cellphone internet browsing sessions and multimedia messages.

The spy agency was able to obtain data that was being sent between Belgacom and other operators through encrypted tunnels known as “virtual private networks.” GCHQ boasted that its work to conduct “exploitation” against these private networks had been highly productive, noting “the huge extent of opportunity that this work has identified.” Another document, dated from late 2011, added: “Network Analysis on BELGACOM hugely successful enabling exploitation.” »

Via https://twitter.com/KimZetter/status/547459875588935681

« Philippe Aigrain, cofondateur et président de l'association, sonnait l'alerte dans un billet sur son blog : déplorant le manque de mobilisation citoyenne, il rappelait l'évidence, à savoir que la survie même de l'association était en jeu si nous ne récoltions pas 45 000 euros supplémentaires d'ici la fin de l'année et que 40 000 euros de plus étaient nécessaires pour équilibrer le budget 2014.

[...]

La réponse à cet appel a été magnifique et extrêmement réconfortante : en quatre jours, plus de 150 000 € ont été réunis par 6000 donateurs, dont plus de 400 dons récurrents ! Cette fantastique mobilisation va nous permettre de nous concentrer, pour 2015, sur les combats essentiels de La Quadrature du Net

[...]

Certains d'entre vous, en particulier parmi ceux qui nous soutenaient déjà activement, ont été heurtés par le billet de Philippe : nous le comprenons. Beaucoup nous ont également fait part de leur « réveil » lors de cette publication. Ce n'est pas de gaîté de cœur qu'il a fallu en arriver là, et c'est avec tristesse que nous avons constaté qu'il était nécessaire de dire, haut et fort, que l'existence de l'association était menacée. Nous espérons, après cette expérience, que de notre côté nous saurons vous toucher autrement à l'avenir et que du vôtre, le soutien à apporter aux petites associations citoyennes comme la nôtre vous semblera plus évident et plus crucial. »

La priorité maintenant, c'est la pérennisation du soutien avec des dons récurrents.

À lire pour l'excellente formulation de l'article et la clairvoyance de SB en 1995.

« Selon le site TorrentFreak, les studios chercheraient donc désormais à utiliser la législation existante pour arriver à leurs fins et créer « un précédent juridique pour façonner et élargir la loi », [NDLR : O_O ] à en croire un message envoyé par un dirigeant de la MPAA aux patrons des studios, parmi lesquels Sony Pictures.

[...]

On y apprend notamment que les sites qui hébergent des fichiers dans le but de les partager sont la cible numéro 1 de l'association. Pour les faire tomber, elle compte s'en prendre à « leur infrastructure », en faisant pression notamment sur les hébergeurs de ces sites et les régies y affichant de la publicité. [NDLR : rien de neuf ici]

[...]

Une hypothèse examinée consistait à s'en prendre aux DNS (domain name system). [NDLR : faire mentir les récursifs DNS des FAI, rien de neuf ...]. The Verge explique notamment que des avocats des studios hollywoodiens ont organisé une réunion avec un des principaux ingénieurs du grand groupe de médias Comcast, afin d'examiner des solutions techniques pour contrer le piratage. [ Un début de partenariat ... jusqu'à quel point ?]

[...]

D'un point de vue juridique, l'association compte arguer que les serveurs DNS sont des systèmes d'indexation de contenu, et non pas de routage de données. Ils envisagent ainsi de faire pression sur les fournisseurs d'accès de la même manière qu'ils demandent à Google de retirer les liens problématiques de ses résultats de recherches. [ NDLR : la drogue, c'est mal O_O annuaire volontaire (serveur qui fait autorité = volontaire) qui distribue une info à partir d'un nom versus indexation, vous ne voyez pas la différence ? Le nom ou l'annuaire n'est pas le problème dans ce cas, c'est le contenu accessible par ce nom qui l'est potentiellement. Le jour où on aura une œuvre sans posession des droits diffusée dans un RRset TXT ou un nom litigieux en lui-même (exemple : un nom de domaine qui, par son seul intitulé, incite à la haine raciale) on en reparlera. En attendant cette approche est nulle et non avenue. Mais là encore, rien de neuf : la saisie d'un nom de domaine par les autorités car le contenu qu'il pointe est présumé litigieux, c'pas nouveau. ] »

Bref, rien de nouveau. On prend juste connaisance du niveau de l'adversaire, on voit qu'il tape large mais seule leur idée de créer un précédent juridique pour élargir la loi (jurisprudence uniquement, j'espère ?) m'inquiète et on n'a aucune info sur ça. :/

Dans le même genre, je recommande le visionnage du talk de vincb, « Spamker, donner la fessée aux spammeurs francophones » (PSES 2013, voir http://shaarli.guiguishow.info/?seNR1g) pour comprendre les interactions entre les acteurs du spam et pour confirmation de l'inefficacité de Signal Spam.

Via http://sebsauvage.net/links/?-4e19g

C'pas un scoop mais c'est bien exposé, notamment :
« Les horoscopes là aussi pour exercer un contrôle social

Quel mal à publier des billevesées tant que les ventes grimpent et que le lecteur est content? pourrait-on se dire. Le hic, c’est que certains horoscopes, en particulier ceux de la presse féminine, sont rédigés avec une fonction bien précise. Celle d’exercer un «contrôle social», d’assurer «la transmission des normes en adéquation avec les idéologies dominantes»

[...]

Même analyse quelques décennies plus tard de Patrick Perett-Watel sur celui rédigé par Elizabeth Teissier dans Télé 7 Jours. Son bilan: «Télé 7 Jours encourage la soumission aux supérieurs et le conformisme social en présentant sous un jour positif non pas les détenteurs de l’autorité auxquels il faut obéir, mais plutôt l’attitude recommandée au lecteur de garder leur profil bas.»

[...]

Elle étudie la rubrique mot à mot et démontre comment on y déconseille aux lectrices l’impulsivité («Vous risquez de vous enflammer.»), la franchise («Apprenez à ne pas dire trop franchement ce que vous pensez.»), l’esprit critique («Modérez votre esprit critique en société»), alors qu’on y encourage la réserve («Soyez conciliante»), la diplomatie («Soyez plus souple en famille», «N’imposez pas trop votre personnalité»), ou la prudence («Contrôlez-vous»). Laurent Puech en conclut qu’«astrologues et magazines féminins enferment les femmes dans un rapport de soumission et jouent ainsi contre leur public.» »

Via http://sebsauvage.net/links/?BrbJyQ

« On 17 December 2011, Kim Jong Un became the leader of North Korea. Two days later, on 19 December 2011, I started my first scan of North Korean Internet space. I was curious to see if their new leader would result in change on their Internet. That was three years ago. I've been keeping an eye on that network now and again. »

En complément de : http://bluetouff.com/tags/coree-du-nord/

Via http://reflets.info/piratage-de-sony-pourquoi-est-il-tres-peu-probable-que-la-coree-du-nord-soit-a-lorigine-de-lattaque/

« Au milieu des années 1990, Le Grand Secret, le livre de Claude Gubler – docteur de François Mitterrand – dans lequel il expose l'état de santé de l'ancien président, est diffusé sur Internet malgré son interdiction en France. En réaction, le mythe d'un « Internet zone de non-droit » (par exemple l'Expansion, 8 février 1996, ou l'Humanité 25 janvier 1996) apparaît comme élément de langage dans les discours médiatique et politique pour ne plus jamais le quitter, de « l'amendement Fillon » de 1996 (Libération 13 septembre 1996), qui tentait – en vain – d'imposer un filtrage administratif des contenus, à la loi « terrorisme » de Bernard Cazeneuve fraîchement adoptée qui valide leur blocage extra-judiciaire, en passant par « l'Internet civilisé » cher à Nicolas Sarkozy.

[...]

Malheureusement, le mythe s'est progressivement réalisé. L'accumulation de mesures législatives et pseudo-contractuelles imposées par le pouvoir politique pour les premières et par des entreprises privées pour les secondes a réussi à transformer Internet en « zone de non-droit ». Non pas que le citoyen y court un risque accru d'être victime de diffamation, de propos haineux ou de n'importe quel autre crime perpétué en toute impunité par des anonymes, mais que sa capacité à opposer ses droits à des atteintes à ses libertés diminue de manière progressive et persistante.

[...]

Sur le terrain de la liberté d'expression, les mécanismes de censure reposant sur des intermédiaires techniques plutôt que sur des juges ne cessent d'être élargis à des catégories de contenus toujours plus nombreuses. Depuis 2004, elles ont ainsi été étendues des crimes considérés comme les plus graves (apologie de crime contre l'humanité, pédo-pornographie, incitation à la haine raciale…) à des infractions secondaires (homophobie, sexisme, handiphobie…), provoquant la censure arbitraire de toujours plus de contenus [2]. En parallèle, les mesures de blocage et de filtrage administratifs se sont elles aussi développées – sans faire l'objet d'application réelle à ce jour, faute de publication des décrets – permettant théoriquement au pouvoir exécutif de censurer des contenus, là aussi sans contrôle du juge malgré la gravité de ces décisions.

[...]

Alors que, par essence, Internet pourrait être le lieu privilégié et concret de l'application réelle de nos droits fondamentaux, nous assistons peu à peu à leur émiettement et à l'apparition de la « zone de non-droit ». Ironiquement, alors que cette menace était agitée par une puissance publique prétendant défendre l'intérêt général pour justifier ses tentatives de reprise de contrôle sur un outil lui échappant, c'est finalement sous la forme d'un recul de la capacité des citoyens à faire valoir leurs droits face à l'exercice arbitraire du pouvoir qu'elle se réalise. Si ces évolutions vers le contournement systématique du pouvoir judiciaire et la privation de libertés imposées par le pouvoir législatif ou par des acteurs privés n'empêchent pas la création et la diffusion grandissantes d'outils permettant l'émancipation de tous (des licences libres aux outils de chiffrement, en passant par les monnaies virtuelles), elles les ralentissent, sont facteurs d'incertitudes, et pourraient à terme soit les étouffer, soit finir de briser l'idée que la loi est au service de l'intérêt public.

[...]

Les récentes mobilisations en Europe et aux États-Unis en réaction à de tels projets politiques et législatifs (ACTA, SOPA, PIPA, neutralité du Net, etc.) démontrent le niveau d'appropriation et de consensus citoyen autour de ces questions. Il est urgent de réduire le fossé qui sépare les gouvernants des gouvernés, particulièrement palpable sur ces questions, afin de permettre un développement des cadres juridiques favorables à tous. Nous ne pouvons plus nous contenter de ne repousser que les plus dangereux de ces projets tout en assistant à la disparition progressive de nos droits fondamentaux : nous nous devons d'agir pour leur application réelle dans les pratiques numériques, d'une part à travers leur consécration législative, mais surtout par le maintien du pouvoir judiciaire au centre de ces dispositifs.

[...]

Ensemble, faisons comprendre à nos élus que nous ne laisserons pas le contrôle de la loi nous échapper d'avantage, et qu'Internet doit redevenir une « zone de droit », avec ou sans eux. »

« On va fermer boutique. Pas dans un an, dans 2 semaines. S’il n’y a pas au minimum 45.000 € de dons supplémentaires d’ici au 4 janvier 2015, il serait irresponsable pour nous de continuer à faire des dépenses. Et à vrai dire, comme indiqué sur notre jauge, c’est 85.000 € de dons supplémentaires qu’il faut pour qu’on puisse raisonnablement continuer en 2015 et 150.000 € pour qu’on opère dans des conditions vaguement normales. En tant que président de l’association, je n’ai qu’une responsabilité par rapport aux autres membres du collège d’orientation stratégique, c’est de savoir dire « non, là on arrête » quand c’est nécessaire.

[...]

Là, c’est simplement l’annonce d’un fait. Apparemment, à part les 2000 personnes qui ont déjà fait des dons à La Quadrature cette année, quel que soit leur montant, les autres ne sont pas au courant ou bien s’en foutent. Pourtant on a fait des efforts bien plus importants pour que vous le sachiez cette année. »

Via http://korben.info/la-quadrature-du-net-cest-termine.html

ÉDIT DU 24/12/2014 à 9h25 : appel au don réussi : http://shaarli.guiguishow.info/?GexXhw FIN DE L'ÉDIT.

« L'idée est ancienne (on la trouve par exemple dans le système T/TCP du RFC 1644, et dans les autres systèmes résumés en section 8) mais le problème est plus difficile à résoudre qu'il n'en a l'air, notamment si on veut garder un bon niveau de sécurité (le problème qui a tué T/TCP). L'idée est ancienne, car devoir attendre trois voyages avant de pouvoir envoyer les données contribue sérieusement à la latence d'applications comme le Web. Si le serveur est à 100 ms de distance, on attendra au moins 300 ms avant que des données ne commencent le voyage. Et, contrairement à la capacité, la latence ne s'améliore pas avec le temps et les progrès de l'électronique. Des mesures faites sur Chrome montre que la triple poignée de mains de TCP est responsable de 25 % de la latence moyenne des requêtes HTTP.

[...]

Et la sécurité ? Le TCP normal présente une vulnérabilité : les paquets SYN n'ayant aucune forme d'authentification, un attaquant peut, en trichant sur son adresse IP, envoyer des paquets SYN sans révéler son identité et ces paquets, s'ils sont assez abondants, peuvent remplir la file d'attente du serveur (attaque dite « SYN flood »). C'est encore pire avec Fast Open puisque ces requêtes en attente comprennent des données, et peuvent déclencher l'exécution de commandes complexes (GET /horrible-page-dont-la-génération-nécessite-10000-lignes-de-Java-ou-de-PHP HTTP/1.1...) Les techniques du RFC 4987 ne sont en général pas appliquables à Fast Open. C'est pour cela que Fast Open ajoute un composant essentiel : un petit gâteau (cookie) généré par le serveur et que le client devra transmettre pour bénéficier du Fast Open.

[...]

La section 3 décrit en termes généraux le protocole. À la première connexion Fast Open d'une machine vers une autre, le client envoie l'option TCP (pour les options TCP, voir la section 3.1 du RFC 793) 34 TCP Fast Open Cookie (désormais dans le registre IANA) avec un contenu vide. Si le serveur gère Fast Open, il répondra (dans le SYN + ACK) avec un gâteau (cookie), généré par lui et imprévisible. Dans les connexions TCP ultérieures, le client renverra l'option Fast Open Cookie avec le même gâteau. Le serveur le reconnaitra alors. Les requêtes SYN comportant ce gâteau pourront inclure des données, elles seront transmises tout de suite aux applications qui le demandent (et on aura alors du beau TCP Fast Open) et le premier paquet de réponse pourra inclure des données (dans les limites données par le RFC 5681). On voit donc que la première connexion entre deux machines ne bénéficiera pas de Fast Open.

[...]

La section 4 de notre RFC plonge ensuite dans les détails compliqués de TCP Fast Open. Le gâteau est un MAC généré par le serveur et est donc opaque au client. Ce dernier ne fait que le stocker et le renvoyer.

[...]

Autre point important lorsqu'on met en œuvre Fast Open : le serveur doit garder une trace en mémoire du nombre de connexions qui ont demandé Fast Open mais n'ont pas encore terminé la triple poignée de mains. Et, au delà d'une certaine limite, le serveur doit refuser de nouvelles connexions Fast Open (en ne renvoyant pas d'option Fast Open dans le SYN + ACK), n'acceptant que le TCP traditionnel. Cette précaution permet de résister à certaines attaques par déni de service.

[...]

D'abord, il peut tenter d'épuiser les ressources du serveur en utilisant des gâteaux valides. Où les obtient-il ? Cela peut être en utilisant plein de machines (un botnet). Bien sûr, vous allez me dire, on peut faire des tas d'attaques par déni de service avec un botnet mais, avec Fast Open, les zombies peuvent faire plus de dégâts pour moins cher (ils ne sont pas obligés d'écouter les réponses ni même de les attendre). [...] On ne peut pas normalement voler des gâteaux à une machine et les utiliser ensuite soi-même puisque le gâteau est (si le serveur a bien fait son boulot) lié à l'adresse IP. Mais ce vol reste possible si plusieurs machines partagent une adresse IP publique (cas du CGN par exemple). Une solution possible serait d'inclure dans le calcul du gâteau, non seulement l'adresse IP mais aussi la valeur d'une option TCP Timestamp.

[...]

Fast Open peut aussi en théorie être utilisé dans des attaques par réflexion. Par exemple (mais le RFC indique aussi d'autres méthodes), si l'attaquant contrôle une machine dans le réseau de sa victime, il peut obtenir des gâteaux valables et ensuite, lancer depuis un botnet des tas de connexions Fast Open en usurpant l'adresse IP source de sa victime. Les serveurs Fast Open vont alors renvoyer des données (potentiellement plus grosses que les requêtes, donc fournissant une amplification, chose bien utile pour une attaque par déni de service) à la victime. C'est idiot de la part de l'attaquant de s'en prendre à une machine qu'il contrôle déjà ? Non, car sa vraie victime peut être le réseau qui héberge la machine compromise. Les réponses des serveurs Fast Open arriveront peut-être à saturer la liaison utilisée par ce réseau, et cela en contrôlant juste une machine (soit par piratage, soit par location normale d'une machine chez l'hébergeur qu'on veut attaquer).

[...]

Dans le doute, une application qui ne pourrait pas gérer le cas de données dupliquées ne doit donc pas activer Fast Open (rappelez-vous qu'il ne doit pas non plus l'être par défaut). [...] Ensuite, même s'il n'a pas de conséquences néfastes, TCP Fast Open n'a pas non plus d'avantages si le temps d'établissement de la connexion est négligeable devant la durée totale de la connexion. Une requête HTTP pour un fichier de petite taille peut sans doute profiter de Fast Open, mais pas le transfert d'une énorme vidéo.

TCP Fast Open est-il utile lorsqu'on a ces connexions persistentes ? Oui, répond notre RFC. [...] Les montrent que le nombre moyens de transactions HTTP par connexion TCP n'est que de 2 à 4, alors même que ces connexions restent ouvertes plusieurs minutes, ce qui dépasse normalement le temps de réflexion d'un être humain. Les mesures effectuées sur Chrome (qui garde les connexions de 5 à 10 minutes) ne voyaient que 3,3 requêtes TCP par connexion.

Qu'est-ce qu'on doit encore étudier et mesurer pour être sûr que Fast Open marche bien ? D'abord, quel est le pourcentage exact de chemins sur l'Internet où les paquets TCP ayant des options inconnues sont jetés ? Pas mal de middleboxes stoppent stupidement tout ce qu'elles ne comprennent pas. [...] Des mesures semblent indiquer que 6 % des chemins Internet seraient dans ce cas. [...] TCP Fast Open réagit à ce problème en réessayant sans l'option (comme le font les résolveurs DNS quand ils n'optiennent pas de réponse lorsque les requêtes sont envoyées avec EDNS). »

« What I did was execute OS level commands on one of Facebook's acquisition's servers.

[...]

I also started to look at Facebook's acquisitions. Doing the same, port scanning common ports, probing services that looked interesting.

[...]

I decided to do a full port scan with nmap. The results showed another Jenkins service running on a less common port. Accessing it over this less common port it did not prompt me for authentication. Bingo!

For those of you that do not know, Jenkins is a 'continuous integration server'. Once authenticated it allows you to run 'Groovy script' through the 'Jenkins Script Console'.

By using Groovy script and the Jenkins Script Console I was able to execute commands on the server under the 'jenkins' user.

[...]

I reported this issue to Facebook and they patched it very fast. I was awarded $7,500 through their bug bounty program. The payment took a few months to come through and lots of emails back and forth. But it came through in the end.

What's the takeaway? Don't forget the basics. I was able to find a pretty risky bug in one of Facebook's acquisitions from within my bed by just using Nmap. »

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