Soit une machine, deux disques durs, des volumes RAID 1, pas d'usage de LVM (c'est pour les faibles/chiens, il faut croire :/ ). On veut redimensionner à la baisse (réduire la taille quoi) un volume RAID afin de récupérer de l'espace pour créer une nouvelle partition. Évidemment, on ne veut subir aucune perte de données. Pour ce faire, il faut bien évidemment que la taille finale de la partition redimensionnée soit supérieure à la taille totale des données qui y sont stockées. L'opération se fait à chaud, avec le système GNU/Linux installé sur la machine en cours d'exécution, pas de live.

Voilà ce que donne un cfdisk sur l'un des disques (le deuxième est identique) :
Nom       Ind.         Partition      S. Fic.               [Étiq.]              Taille (Mo)
-------------------------------------------------------------------------------------------------------------------
                                              Inutilisable                                        1,05    *
  sda1    Amorce     Primaire     ext4                  [boot]                   999,30    *
  sda2                    Primaire     linux_raid_m      [mdresize:0]      10000,27    *
  sda3                    Primaire     linux_raid_m      [mdresize:1]        8998,46    *
  sda4                    Primaire     swap                                           1475,77    *

« Inutilisable » est de l'espace libre mais on a le droit à 4 partitions primaires avec une table des partition MBR ; Deuxième partition (sda2) : système ; Troisième : données.

Ici, c'est la partition sda3 (qui forme, avec sdb3 la grappe RAID 1 md1) que nous voulons redimensionner pour la passer d'environ 9G à environ 7G.
/dev/md1  8,3G  147M  7,7G  2% /home


Voici les différentes étapes pour y parvenir :
1) umount /dev/md1

2) e2fsck -f /dev/md1

3) On réduit la taille du système de fichiers : resize2fs /dev/md1 7G

4) On réduit la taille du conteneur, c'est-à-dire le volume RAID : mdadm --grow /dev/md1 --size=7G


5a) On sort la première partition de la grappe RAID : mdadm /dev/md1 --fail /dev/sda3 --remove /dev/sda3

6a) On redimensionne la partition (ici : sda3) avec fdisk ou (mon préféré) cfdisk : d (supprimer) - [ 3 -] n (nouvelle) - p (primaire) - 7500M - debut - type : DA (ou FD, "l'ancien" « linux raid autodetect ») - w (écrire). Oui, 7500M est supérieur aux 7G désirés mais c'est volontaire : être sûr que la partition ne soit pas plus petite que le conteneur RAID qu'elle va recevoir. Si vous avez une table des partitions GPT, il suffit d'utiliser gdisk pour cette étape, ça marche tout pareil : d - 3 - n - 3 - +7500M - DA - w . Les autres étapes restent inchangées

7a) On reintègre la partition à la grappe RAID : mdadm -a /dev/md1 /dev/sda3

8a) On attend le resync RAID. Pour voir la progression : watch cat /proc/mdstat

On recommence les étapes 5 à 8 avec la deuxième partition qui constitue md1) :
5b) mdadm /dev/md1 --fail /dev/sdb3 --remove /dev/sdb3

6b) cfdisk - d - [ 3 -] n - p - 7500 - debut - type : DA - écrire

7b) mdadm -a /dev/md1 /dev/sdb3

8b) Attente resync RAID

Note : oui, on pourrait être plus bourrin c'est-à-dire stopper le RAID et modifier directement la taille des deux partitions, sans resync.


9) On démonte le RAID sinon la prochaine étape ne peut pas fonctionner (ressource occupée) : mdadm --stop /dev/md1

10) On informe le noyau que les tables des partitions ont changées, sans rebooter bien sûr (cette commande fait partie du package parted chez Debian) : partprobe . La commande « blockdev --rereadpt » (package util-linux) fait le job tout aussi bien.

11) Si on tente de monter le RAID, mdadm nous informera que les superblocks sont endommagés et qu'il ne peut donc pas assembler la grappe. Nous allons réécrire les headers : mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sda3 /dev/sdb3
mdadm nous informe que : « /dev/sda3 appears to be part of a raid array ; /dev/sdb3 appears to be part of a raid array ;  /dev/sda3 appears to contain an ext2fs file system ;  /dev/sdb3 appears to contain an ext2fs file system », ce qui est une bonne chose.

12) On actualise mdadm.conf pour que tout fonctionne au prochain reboot : mdadm --detail --scan >> /etc/mdadm/mdadm.conf
Attention : penser à effacer le(s) doublon(s) à la mano dans mdadm.conf. Penser également à mettre à jour fstab ou crypttab s'ils utilisent l'UUID de la grappe RAID comme identifier (ls -lh /dev/disk/by-uuid pour trouver le nouvel UUID de la grappe RAID). Évidemment, si la grappe RAID redimensionnée héberge le système GNU/Linux, il faut reconstruire l'initramfs : update-initramfs -u

13) e2fsck -f /dev/md1
Si jamais le message suivant s'affiche :
« La taille du système de fichiers (selon le superbloc) est de 1835008 blocs
La taille physique du périphérique est de 1830368 blocs
Le superbloc ou la table des partitions est peut-être corrompue !
abort ? » -> répondre : n

14) resize2fs /dev/md1

15) N'est pas utile mais par sécurité : e2fsck -f /dev/md1


On ajuste la taille du conteneur ainsi que la taille du système de fichiers à celle de la partition :
16) mdadm --grow /dev/md1 -z max

17) resize2fs /dev/md1


Résultat :
Nom       Ind.          Partition      S. Fic.           [Étiq.]                Taille (Mo)
------------------------------------------------------------------------------------------------------------------
                                              Inutilisable                                       1,05    *
  sda1    Amorce     Primaire     ext4                  [boot]                  999,30    *
  sda2                    Primaire     linux_raid_m      [mdresize:0]     10000,27    *
  sda3                    Primaire     linux_raid_m      [mdresize:1]       7501,46    *
                                              Inutilisable                                  1497,01    *
  sda4                    Primaire     swap                                          1475,77    *

/dev/md1  6,9G  142M  6,4G  3% /home


Autre ressource intéressante : http://www.howtoforge.com/how-to-resize-raid-partitions-shrink-and-grow-software-raid

« Starting at 08:33 UTC we detected  that hundreds of new prefixes were being announced by primarily AS 29386. The new BGP announcements by STE (AS29386) were for prefixes that are not owned or operates by the Syrian Telco and as a result triggered ‘hijack / origin AS’ alerts for numerous BGPmon users. The announcements lasted for a few minutes only and we saw paths changing back to the original origin AS at about 08:37 UTC.

[...]

STE buys upstream connectivity to the rest of the Internet via three providers, AS3491 (PCCW Global), AS3320 (Deutsche Telekom AG) and AS6762 (Telecom Italia Sparkle). The ‘bad’ BGP updates from this morning were only seen via Telecom Italia. This is either because STE only announced it to Telecom Italia, or because the other two providers filtered correctly. It’s clear that in this case Telecom Italia failed to filter correctly as it should have never accepted the prefixes from AS 29386 (STE).

[...]

In total we detected 1481 prefixes that were affected by this hijack which last for a few minutes. Most of these events were seen globally so it’s likely that connectivity to these prefixes was affected for that brief period. The 1481 prefixes belong to 306 unique Autonomous Systems (organizations) from around the globe.

[...]

It’s unclear what the cause of this incident is, but typically large scale and short-lived hijacks like these are due to configuration mistakes as compared to intentional hijacks with a malicious purpose. »

Après les attaques par réflexion+amplification sur DNS, NTP, SNMP, CHARGEN, récupération du statut sur Call of Duty, voici venu ... le service "découverte" de Microsoft SQL Server ...

« so when SQL Server 2000 introduced support for multiple instances of SQL Server, SQL Server Resolution Protocol (SSRP) was developed to listen on UDP port 1434. This listener service responded to client requests with the names of the installed instances, and the ports or named pipes used by the instance. To resolve limitations of the SSRP system, SQL Server 2005 introduced the SQL Server Browser service as a replacement for SSRP. »

« By default, the SQL Server Browser service starts automatically: When upgrading an installation. [...] When installing on a cluster. [...] »

Bon, le facteur d'amplification est faible (~10x) mais quand même...

« Documents published on November 25, 2014 by Süddeutsche Zeitung revealed more specific details about submarine cables currently tapped by GCHQ. Previous reporting had made it clear that GCHQ had submarine cable taps created in collusion with companies like Vodafone and BT Cable, but not which specific cables.

[...]

Some caution

Initial methods are very, very messy here. There's a lot of data cleanup that is probably going to need to happen. Reasons for the messiness:
    - The PDF list of cables was hella dirty and it OCR-ed poorly, there's the possibility of manual cleanup errors.

    - Names of cables in the GCHQ doc are not always exactly matched up to cables in the Telegeography data. I did a really sloppy table join and caught a few manual ones, but here are some cables listed in the GCHQ document that I haven't found a match for: [...]

What I'm saying is don't just run with this dataset, it really needs some thorough double-checking.  »

Via http://shaarli.cafai.fr/?zXFZFA

« Un chercheur en sécurité a repéré un dysfonctionnement dans OS X Yosemite qui entraîne la création de fichiers logs contenant toutes les frappes enregistrées dans Firefox et Thundebird. C'est plus précisément un bug du framework CoreGraphics qui génère ces historiques stockés dans le dossier /tmp.

[...]

D'OS X 10.6 à 10.9, la fonction d'enregistrement du clavier de CoreGraphics était désactivée par défaut. Dans Yosemite, un bug d'initialisation fait qu'elle est active pour certaines applications utilisant un allocateur personnalisé de mémoire. »

Une merde de plus pour censurer et surbloquer tout et n'importe quoi ... pfff ... Si seulement ça restait dans le cadre des entreprises, ça serait presque acceptable : l'employé est sur le réseau de l'entreprise, l'entreprise n'est pas FAI donc elle fait bien ce qu'elle veut chez elle y compris appliquer des règles, usages, morale, charte àlacon.

C'est mignon :') J'adore surtout le British Board of Film Classification (CSA-like) : alors oui telle pratique sexuelle est autorisée mais selon telle intensité, telle manière de faire mais pas celle-ci, chorégraphie au millimètre près, ... juste -L-O-L. Consentement mutuel, il n'y a besoin de rien de plus, c'est tout (et dans le cas DVD/VOD : consentement du visionneur. La protection des mineurs est hors sujet quand on en vient à réguler aussi précisement le désir).

Notons que le mal est déjà fait depuis longtemps : les pratiques énoncées étaient déjà interdite au format DVD depuis longtemps, la seule nouveauté du 1er décembre 2014 est leur application au monde de la VOD : http://legislation.data.gov.uk/cy/uksi/2014/2916/made/data.htm?wrap=true . Tenter d'appliquer la pudibonderie locale à un marché mondialisé et dématérialisé (youporn > *) : check. :)

Prudence tout de même : certaines des pratiques listées sont bien dans la liste des contenus inacceptables de la BBFC, d'autres proviennent uniquement de Myles Jackman, un avocat spécialisé en matière de « pornographie extrême et obscenité » (O_O) et d'autres encore proviennent du même avocat mais confirmé par la BBFC au journal Vice.

Lecture complémentaire : http://bigbrowser.blog.lemonde.fr/2014/12/03/fessee-fouet-fist-le-porno-britannique-online-doit-revoir-ses-pratiques/

Via : http://sebsauvage.net/links/?tLCldw et https://twitter.com/FradiFrad/status/540432021710200832

À lire absolumment : sanction des intermédiaires au lieu des délinquants, inégalité devant la loi, couplage fort mais absurde entre FAI et FSI récursif DNS, ... Tout ça tout bien expliqué.

Mon conseil sera de garder la tête froide et de ne pas s'emballer en mettant en place à tout va et à la va-vite des récursifs DNS ouverts. Quand c'est mal conçu/mis en place, le résultat est catastrophique et fait très mal (DDoS, nuissances sur autrui, surfacturation, ...), pas tant pour la personne qui mettra en place ce service, mais surtout pour les victimes qui seront attaquées via ces récursifs DNS ouverts (attaques par réflexion+amplification). TL;DR : ouvrir des récursifs DNS ouverts = un gros oui mais pas n'importe comment et pas dans la précipitation, c'est un projet qui se réfléchit et se construit sur des bases saines ! À ce sujet, lire : http://www.guiguishow.info/2014/08/23/comment-mettre-en-place-un-serveur-dns-recursif-cache-ouvert-dans-de-bonnes-conditions/

« Le sujet du jour c'est que quand les ayants droit veulent faire interdire une activité illégale, ils font un procès... à quelqu'un d'autre. Ce n'est pas que les ayants droit soient fous, c'est que nous vivons au temps de la justice de père Ubu. En effet, ce que veulent obtenir les ayants droit, c'est que les fournisseurs d'accès empêchent l'accès au site de The Pirate Bay. Or pour forcer les FAIs à faire quelque chose, il faut les condamner. Pour les condamner, il faut qu'ils soient délinquants.

L'affaire qui nous intéresse oppose donc, d'une part, des gens qui défendent leurs droits patrimoniaux sur des œuvres, et d'autre part des gens qui ne sont pas les délinquants, mais qui vont quand même être condamnés. De manière particulièrement amusante, ils seront payés pour mettre en œuvre la décision de justice. Ils sont donc condamnés à se faire payer par les ayants droit pour mettre en œuvre une décision de justice.

Mais, et le délinquant alors ? Fastoche. Il n'est pas concerné. Pas cité dans la procédure. Pas invité à se défendre. On a donc d'une part, des ayants droit qui exposent leurs griefs. D'autre part des FAIs qui sont transformés par la force de la justice en exécuteurs des sentences. Et personne pour représenter les intérêts de l'accusé/condamné, puisqu'il n'est même pas cité au procès. Père Ubu inventerait la justice qu'il ne ferait pas mieux. Ou pire, c'est selon.

Cette approche du droit pose des questions, en dehors du fait qu'elle est ridicule. Par exemple, le site The Pirate Bay n'est pas condamné. Il n'y a pas de décision d'un tribunal en France disant que son activité est illégale et qu'il doit fermer. Du coup, pour un FAI qui n'est pas condamné à le filtrer, il serait totalement illégal de le faire (atteinte au secret des correspondances privées, atteinte au droit d'accès à l'information, atteinte aux obligations définies par le code des postes et communications électroniques).

On a donc cette situation ubuesque où celui qui est annoncé comme le méchant n'est pas condamné, où ceux qui sont condamnés sont en fait les exécuteurs de la décision de justice, et où les autres FAIs ont l'obligation de continuer à permettre l'accès au site. Et bien entendu, celui qu'on annonce dans toute la presse comme délinquant, et dont on essaye d'empêcher l'activité, n'a pas pu se défendre.

[...]

Cette approche expose un problème de fond. Tous ces braves gens, FAIs, justice, ministres et ministères, moines copistes de DVDs, disent qu'ils font filtrer par les opérateurs du réseau, alors qu'ils font filtrer par le fournisseur de service DNS. Ils sont en train, dans ces décisions de justice, de graver l'idée que le résolveur DNS utilisé par l'internaute est, forcément, toujours, celui de son FAI. Que le service de résolution DNS est une composante totalement centrale du réseau. Ce qui est parfaitement faux.

Ce couplage fort entre l'opérateur du réseau et le fournisseur de DNS est exactement aussi faux que celui entre l'opérateur et le fournisseur de mail. Il y a 15 ans, les mêmes pensaient qu'il était de toute évidence, et de toute éternité, qu'un abonné de Club Internet a une adresse e-mail qui se termine en @club-internet.fr. Le fait de graver ce genre d'idioties dans des décisions de justice, dans des décrets, dans des lois, c'est suivre la pente savonneuse qui rendra illégal le fait d’utiliser un service de résolution DNS autre que celui fourni par son opérateur.

Ce serait en effet la conséquence logique. Pour faire fermer un site, au lieu de condamner le site, on condamne le FAI. Pour filtrer, il n'utilise pas son activité de FAI, mais une activité annexe de fourniture de service de résolution de nom. Pour rendre ce filtrage plus solide, il faudrait interdire à l'internaute d'utiliser un autre service que celui de son opérateur. Sur le principe, c'est contraire à toutes les directives européennes, car c'est rendre obligatoire un abus de position dominante, une entrave absolue à la concurrence.

Or choisir son service de résolution DNS, c'est choisir la façon dont on voit Internet. C'est choisir la racine du système de nommage qu'on utilise. Bien qu'étant sur le même Internet que tout le monde, quand on change de DNS, on voit le réseau différemment, et pour le moment on le fait par choix. Peu de gens utilisent cette faculté, mais elle existe. »

Haha, tellement vrai : qui n'a jamais gigoté dans tous les sens en attente d'un signal WiFi qui marchait juste 5 secs plus tôt ? :D

Gogol, gogolplex, les puissances itérées de Knuth, le nombre de Graham, nombres inaccessibles (la plus grande partie, l'infini étant long, surtout vers la fin ;) ) ...

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

« Ainsi, Jean-Ludovic Silicani a affirmé que "sur l'Internet général, le principe de la neutralité du net doit s'appliquer de façon absolue", en n'évoquant qu'une seule exception possible, "s'il y a un encombrement pour une raison conjoncturelle, comme par exemple un événement mondial très suivi, pour faire de la gestion de trafic". Il doit s'agir d'une exception "purement technique", et surtout temporaire. "Aucune discrimination ne doit exister sur le service général d'accès à internet", a insisté le président de l'Arcep.
[ Ni vu ni connu, j'embrouille les parlementaires avec le bon vieux gag des services spécialisés ... La neutralité des réseaux, tout le monde est pour mais chacun s'en fait sa définition. Attention à l'argument de la congestion : àmha, cette exception doit être fermement encadrée pour éviter les dérives comme le refus d'investir pour augmenter la capacité des réseaux. Content néanmoins que le président de l'ARCEP indique qu'une congestion ou une opération de maintenance doit être technique et temporaire, c'est un bon début, il ne manque plus que « ciblée et proportionnée ». ]

[...]

"Est-ce qu'il faut que nous soyons naïfs, que nous oublions de derrière internet il y a les plus grandes entreprises du monde ?", a demandé Jean-Ludovic Silicani. "Pourquoi ce qui est devenu un secteur marchand serait-il le seul secteur marchand du monde où certains services ne seraient pas payants ? Il faut revenir à des choses fondamentales."
[ Parce que tout doit forcément être payant ? Même un échange de bon procédé ? Même quand les deux opérateurs et le bien commun sont gagnants ? ]

En matière de peering, l'Arcep prévient qu'elle est dans une position d'observation et de surveillance. "Si l'on constatait des dérapages susceptibles de faire disjoncter le système, nous pourrions aller plus loin, jusqu'à une régulation, à condition de trouver une base légale", a prévenu M. Silicani.
[ Sous-titres : comme d'habitude, l'ARCEP doit composer avec le corpus législatif existant et a donc une puissance de feu limitée ... :( Joli appel renouvellé du président de l'ARCEP en direction des parlementaires, sera-t-il écouté ? ] »

C'est mignon :') Une sorte de modèle de péréquation (financement des zones non rentables par les zones rentables, service universel quoi)  ... Bordel, pourquoi l'idée leur vient *après*, quand ils sont dans l'opposition (plan THD, cf ci-dessous) et pourquoi sous forme de taxe ?! Par ailleurs, à qui iront les revenus de cette taxe au bout du bout ? Cela constituera-t-il un finacement déguisé d'Orange ?

Un modèle de péréquation, c'est pile poil le modèle qui n'a pas été retenu dans le plan THD (fibrage de la France) puisque, pour rappel, les zones jugées rentables sont les zones dites AMII sur lesquelles la puissance publique s'interdit d'investir si des opérateurs privés s'engagent à monter au moins une boucle locale fibre et les zones jugées (subtiles car le taux de pénétration de la fibre dans les foyers ruraux sera supérieur car un besoin existe alors que les zones rentables fibre sont les villes déjà bien équipées ...) non-rentables sur lesquelles les opérateurs privés ne veulent pas intervenir seront fibrées par la puissance publique sans définir le financement, sans profiter des revenus générés par les zones rentables donc levée d'impôts quasi obligée  ... Alors certes, il y a les directives européennes qui fixent le cadre comme la nécessaire concurrence et l'auto-régulation par le saint marché tout-puissant, m'enfin bon, la responsabilité du déploiement merdique actuel n'incombe pas qu'à l'UE, faut pas charrier.

Supervisor, codé en Python, est un système de contrôle de processus orienté utilisateur (pas comme launchd ou runinit qui remplacent init pour fonctionner) qui juste marche (pas comme systemd).

Il prend en charge la relance des processus s'ils sont interrompus en cours d'exécution, un mécanisme minimaliste d'évenements permet de surveiller un minimum le programme lancé comme sa conso RAM par exemple et de relancer le programme si elle devient excessive, on peut sortir stdout et stderr dans des fichiers de log, faire en sorte que ces journaux soient "rotatés" (archivés selon une périodicité donnée quoi), ...

Très pratique pour des scripts/programmes persos : plus besoin d'écrire un pseudo script d'init et on ajoute de la fiabilité (processus relancé automatiquement en cas de crash).

« Ce coquetier en plastique vous permettra de faire cuire des oeufs au micro-ondes en un temps record. Avec le Micro Egg, il vous suffit de casser l'oeuf délicatement dans le récipient en plastique, de refermer le couvercle et de poser le tout dans le four micro-ondes... 35 secondes plus tard, il ne vous reste plus qu'à saler à votre goût et profiter des joies de l'oeuf à la coque sans coquille... Il s'entretient au lave-vaisselle et est fabriqué en France. »

Je pose ça ici pour diffuser l'idée car j'ai constaté qu'elle est plutôt méconnue. :) Je précise quand même qu'il n'y a pas de miracles : oui des bulles d'air et autres se prennent dedans et forcément ça claque pendant la cuisson et donc oui, il arrive que le couvercle soit éjecté et que ça repeigne l'intérieur de votre micro-ondes. C'est là qu'on se dit que ce produit ne fait pas mieux qu'un bol ou autre récipient…

Rien de neuf : du sur-filtrage (effets collatéraux) était déjà visible aux alentours de 2008. C'était du même acabit, aussi violent et injustifié et ça nuisait aux recherches documentaires (je me souviens de cas en socio et philo).

« Ars Technica s’est procuré en effet plusieurs documents montrant que des enquêtes en cours concernent deux smartphones verrouillés, pour lesquels l’All Writs Act est utilisé. Dans le premier cas, la demande est réalisée par le bureau du procureur de New York sur un modèle inconnu et impliqué dans une fraude à la carte bancaire. Dans le second, il s’agit d’un iPhone 5s dans une enquête criminelle, avec une demande faite par le bureau du procureur d’Oakland, en Californie.

Dans le second cas, l’exposé des faits est direct : un iPhone 5s présente un écran de verrouillage qui empêche les enquêteurs d’acquérir les données nécessaires dans le cadre d’une enquête criminelle. Le procureur demande donc à la Cour l’utilisation de l’All Writs Act afin d’obtenir une ordonnance qui forcerait Apple à assister les enquêteurs dans le déverrouillage de l’appareil.

[...]

La demande du procureur est d’autant plus intéressante qu’elle précise que ce n’est pas la première fois que la loi de 1789 est utilisée avec Apple. Et non seulement la situation ne serait pas nouvelle, mais elle aurait également prouvé son efficacité, la firme ayant déjà accepté par le passé de remplir ses obligations. On peut lire également (à la fin) que si les enquêteurs devaient se passer de l’aide d’Apple, la recherche prendrait plus de temps, réclamerait des ressources plus importantes et pourrait même endommager l’appareil.

Et la cour a accepté ces arguments. La juge Kandis Westmore a ainsi ordonné à Apple « de fournir une assistance technique raisonnable pour permettre aux agents des forces de l’ordre d’obtenir l’accès aux données déchiffrées ». Cette ordonnance présente cependant une précision cruciale : «  Il est également ordonné, dans la mesure où les données sur l’appareil iOS sont chiffrées, qu’Apple fournisse une copie de ces données aux forces de l’ordre, mais Apple n’est pas tenue de tenter de déchiffrer les données ou d’aider agents en la matière ».

Il est donc important de constater que l’All Writs Act est utilisé dans ce cas pour déverrouiller le téléphone, mais le travail de déchiffrement des données reste l’apanage des forces de l’ordre. Apple doit ainsi fournir une « assistance technique raisonnable » mais il ne lui est pas réclamé une méthode pour obtenir les données en clair. Les proclamations d’Apple et Google semblent donc valides en l’état.

Mais quelle est exactement la différence entre le déverrouillage d’un smartphone et les données elles-mêmes ? Comme le note Jonathan Mayer, maître de conférence à l’université de Stanford, les informations couvertes par l’Electronic Communications Privacy Act ne peuvent pas être obtenues via l’All Writs Act. Or, les données personnelles sont protégées par l’ECPA, mais pas le déverrouillage du téléphone, ce qui ouvre donc la porte à la vieille loi.

[...]

La situation dans l'Hexagone est à la fois plus claire et plus dure qu’aux États-Unis depuis que la loi sur le terrorisme a été adoptée. L’article 230-1 dispose en effet que « le procureur de la République, la juridiction d'instruction, l'officier de police judiciaire […] peut désigner toute personne physique ou morale qualifiée, en vue d'effectuer les opérations techniques permettant d'obtenir l'accès à ces informations, leur version en clair ainsi que, dans le cas où un moyen de cryptologie a été utilisé, la convention secrète de déchiffrement ».

En d’autres termes, si la justice estime que la « mise au clair des données chiffrées nécessaires à la manifestation de la vérité » lui permet de réclamer l’aide de quiconque aura compétence en la matière. De plus, pour les infractions pénales les plus graves, elle peut faire appel aux compétences du CTA. Le centre technique d'assistance est géré par la direction centrale du renseignement intérieur et peut à ce titre mettre à disposition des enquêteurs ses capacités de déchiffrement de contenus chiffrés. »

« 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 [...] »

« C'est dans ce contexte que Axelle Lemaire a annoncé2 que le projet de loi « numérique », prévu pour le premier trimestre 2015, contiendrait un volet sur la neutralité du Net, alors que cette option semblait avoir été écartée3. Mais la position défendue par la France lors du vote au Parlement européen d'avril dernier et les récents débats au Conseil européen soulève de graves inquiétudes. De plus, l'apparition dans le discours de la Secrétaire d'État chargée du Numérique d'éléments de langage habituellement portés par les opérateurs4, laisse craindre que ce projet de loi soit davantage orienté vers la protection des intérêts des opérateurs plutôt que de ceux des citoyens.

À cet égard, les positions sur la neutralité du Net exprimées par le récent rapport du Conseil d'État sont également source d'inquiétudes : elles semblent elles aussi conforter les affirmations infondées des opérateurs selon lesquelles il serait nécessaire de porter atteinte à la neutralité pour encourager l'investissement.

[...]

« Il est plus que temps pour les pouvoirs publics français de clarifier leur position au sujet de la neutralité du Net, tant au niveau européen qu'au niveau national à l'approche du projet de loi annoncé sur le "numérique". L'importante mobilisation citoyenne du printemps dernier et le vote historique des eurodéputés en faveur d'une vraie protection d'un Internet libre ne peuvent être balayées d'un revers de la main par le gouvernement français. [...] »

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

« I'm the CEO and co-founder of La Maison du Bitcoin (a Bitcoin center in Paris), and Ledger (a secure hardware wallet). Our company was in business relation with HSBC since 2011, and everything was fine until we pivoted to Bitcoin in 2013. A few months ago, HSBC notified us of termination of all our accounts, including our subsidiaries' which are not at all related to Bitcoin. They never wrote the real reason, but discussions with our bank managers revealed it was of course related to the fact we were dealing with crypto-currencies.

We had another bank account (in another bank), which we "unfroze" following the HSBC's notification. As soon as they discovered that we where the company behind "La Maison du Bitcoin", we received a registed letter closing also all accounts. I have met with the president of the bank, who stated he didn't have the choice, that he had "to chose his battles". The French regulator put huge pressure on him to close all businesses related to Bitcoin, even if there is nothing illegal in it.

We are now trying to operate under the radar by opening accounts in unsuspecting banks. But it is not easy when you are running a Bitcoin center with huge "B" on the street windows.

All this give us even more legitimacy and motivation in our efforts to build an alternative of the banking system, based on digital identities, full decentralization and power of the open & distributed consensus security systems. »

Intéressant mais ce n'est pas un scoop, ni réservé au bitcoin : http://blog.fdn.fr/?post/2014/06/08/FDNN-change-de-banque . Il reste le droit au compte tant que la législation ne bannit pas le bitcoin.

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