En v6, l'espace d'adressage est énorme donc les scans naïfs comme en v4 ne sont plus possibles car ils prennent un temps démesuré.

Sur le même L2 : ping6 ff02::1 ... Adresse multicast sur laquelle toutes les machines qui ne font pas office de routeur doivent écouter (les routeurs écoutant en ff02::2). Mais comme c'est spécifique à un lien, il faut préciser sur quelle interface on souhaite émettre : ping6 -I eth0 ff02::1 ou ping6 ff02::1%eth0

Sans être sur le même L2 : scan intelligent sur des adresses significatives donc souvent utilisées :
  - première/dernière du range/contiguë, ::42

  - ::53 pour un serveur DNS, ::80 pour un serveur web

  - adresses qui forment des mots marrants (cafe, dead, boob, babe, ...)

  - constructeur. Les IPv6 étant dérivées des adresses MAC (hors extensions permettant de préverser la vie privée) et les entreprises/administrations étant souvent sous contrat groupé avec le même équipementier, on obtient un parc homogène et donc un espace d'adressage réduit sur lequel se concentrer.

« Un programme qui copie le contenu de toute clé USB insérée. »

Je me doutais bien qu'un tel programme existe mais je n'avais pas creusé le sujet.

C'est le truc auquel je pense quand j'imprime des PDF depuis un cybercafé (non, avoir une imprimante chez soi pour imprimer/photocopier 2 documents administratifs par an, ça ne vaut pas la peine) : et si le proprio de la boutique dumpe toute ma clé USB ... Alors bien sûr, ma clé contient uniquement les documents que je souhaite imprimer donc ça limite le périmètre, mais quand même ...

ÉDIT DU 01/05/2015 : https://codingteam.net/project/usb-dumper/browse/ FIN DE L'ÉDIT

«  Pour être honnête, j’hésite entre “cyber” et “souverain”. Je ne sais pas laquelle de ces deux tartes à la crème a été la plus entendue en 2013. Mais qu’en est-il sur le terrain ? Y a-t-il une réalité derrière ces termes ?

Pour le savoir, menons une expérience assez simple: si j’écris à n’importe quel collègue travaillant dans une entreprise du CAC 40, où va arriver mon email ?

[...]

La conclusion est la suivante: dans seulement 12 cas sur 40, il est certain que le message arrivera sur un serveur hébergé en France. Dans les autres cas, le message est susceptible d’arriver à l’étranger. Il ne s’agit pas de détournement BGP ou d’intrusion sur des câbles sous-marin: l’entreprise du CAC 40 paie effectivement pour recevoir son mail à l’étranger. »

Je ne suis pas surpris ... Quand t'as vu de grands labos français qui ont un rayonnement mondial et donc des budgets publics ET privés monstrueux qui songent très sérieusement à migrer vers office365, tu ne peux plus être étonné. Pareil quand tu vois « LE magazine mensuel de l'administration et du développement sur systèmes open source et embarqués » qui propose de se « débarrasser » de son serveur mail pour aller chez Google. Il n'y a pas toujours besoin de faire des empoisonnements DNS et des détournements BGP et autres trucs compliqués pour faire de l'espionnage (économique, scientifique, diplomatique, ...) efficace. La rationalité c'est bien mais pas à n'importe quel prix. C'est ça PRISM : tout con, aucune sophistication mais efficace.

Je concède que gérer un serveur mail avec de l'envergure, ce n'est pas simple, entre le traitement du spam (nonnon, c'est plus difficile que d'installer quelques softs, faut affiner ensuite) et du support utilisateur (domaine destinataire en panne, problème annexe, il n'y a qu'à lire FRsAG/FRnOG pour avoir des exemples) ... Mais rien d'inaccessible en terme humain. Mais paraît que Google/MS/autres font moins cher à côté ... C'est que ça doit être vrai.

ÉDIT du 20/05/2014 à 12h42 : dans le même genre : http://www.lesechos.fr/journal20140519/lec2_high_tech_et_medias/0203503288156-le-cac-40-s-entiche-du-cloud-a-la-sauce-amazon-671744.php

+1

L'affirmation du titre me semble à moitié fausse (verbe conjugué au présent) :
« Le trafic de communications vocales, fixes et mobiles, augmente de 1,2% ce trimestre par rapport au quatrième trimestre 2012 et de 2,7% pour l'ensemble de l'année 2013, grâce à la progression toujours vive de la consommation des clients équipés de mobiles (36,3 milliards de minutes au quatrième trimestre 2013, soit +3,7 milliards de minutes par rapport au quatrième trimestre 2012) : au cours du dernier trimestre 2013, les clients disposant d'un mobile ont téléphoné en moyenne plus de trois heures par mois, soit 15 minutes de plus qu'un an auparavant. A l'inverse, la consommation au départ des téléphones fixes diminue (-10,3% en un an au quatrième trimestre 2013), y compris au départ des box. »

(Source : observatoire des marchés des communications électroniques en France au quatrième trimestre 2013 - http://www.arcep.fr/index.php?id=8571&tx_gsactualite_pi1[uid]=1657&tx_gsactualite_pi1[backID]=26&cHash=8c93a0a21bc19c94235b5b8b4580a8a7)

Moi ce que je comprends, c'est que les gens téléphonent moins depuis chez eux (fixe) car, c'est un moment où on a envie de faire autre chose (le téléphone étant synchrone) mais ils téléphonent plus (certainement dans les moments de creux comme les transports) donc on ne peut pas dire que le téléphone est totalement dépassé. Juste il y a eu un déplacement temporel de ce que l'on considère comme étant le "bon moment" pour téléphoner.

Notons que l'ARCEP parle exclusivement du départ de la communication donc on ne sais pas si les appels mobiles->fixes ont diminués. ;) Donc le côté "appel téléphonique vécu comme une intrusion" n'est pas vraiment vérifiable objectivement.

Je ne sais pas si le téléphone (et les autres moyens de communication vocaux comme Skype, c'est bien pareil hein) vont disparaître. Ça suppose une adaptation aux nouvelles manières de communication par une frange plus large de la population. Ça suppose une mutation profonde de comment on envisage nos interactions pour faire société et donc du tissu social (on a un très lourd passif de communications vocales alors que l'écrit *pour tous* commence tout juste). Ça suppose que les gens apprennent à lire (beaucoup ne lisent pas les gros pavés alors qu'ils écoutent le même correspondant parler du même sujet pendant des heures) et à écrire (pas pour plaire au prof mais pour être efficace dans la transmission de l'information).

« Netflix se justifie dans un mail envoyé à ses abonnés, en précisant vouloir « ajouter plus de films et de séries » à son offre. »

Hum ... Je suis perplexe ... Plus de sous pour convaincre les majors ? Je crois que Netflix est bien implanté aux USA et a un poids dans l'écosystème. Besoin de matos ? Peut-être, je n'ai sais rien mais je doute. Et si c'était pour "compenser" avec les sommes d'argent que Netflix verse aux FAI américains mais sûrement pas qu'à eux vu qu'ils ont ouvert la boîte de Pandore (cf http://shaarli.guiguishow.info/?hYtm8A) ... Je pose juste une hypothèse.

Et si c'était le cas, ça veut dire que le coût a finalement été reporté sur le client. Donc sortir du 29,99€ (oui, je passe des USA à la France) pour se rapprocher de ce que coûte réellement x abonnés à y megas quand leur conso au 95e centile augmente car les usages changent, ça ne serait pas plus idiot ni plus coûteux pour le client final (au contraire, au moins ça ne serait pas un surplus pour une seule destination donnée) et au moins, la neutralité des réseaux serait respectée.

Pour se faire un serveur de mail secondaire simpliste (en cas de panne du primaire, il ne fait que mettre en file d'attente les mails et la consultation se fera uniquement directement dans cette file d'attente avec postcat, guère pratique ...) avec Postfix, on met les domaines voulus dans « relay_domains » et on augmente la valeur de « maximal_queue_lifetime » (5 jours par défaut), histoire de garder les mails plus longtemps en cas d'une panne prolongée du primaire.

Ce type de secondaire permet de se prémunir d'une panne du primaire tout en étant sûr que les mails seront bien mis en file d'attente. En effet, certains administrateurs de serveurs mails peu consciencieux (le mail n'a pas été conçu pour être instantané) réduisent le « maximal_queue_lifetime » à 24h ou 48h, ce qui s'avère insuffisant pour réparer une bonne panne. Au moins, avec un tel secondaire, c'est vous qui fixez la durée de rétention.

On se demande ensuite comment le secondaire peut vérifier qu'une boîte aux lettres ou un alias existe bel et bien sur le primaire ? En effet, les spammeurs s'attaquent bien souvent au MX de plus basse priorité espérant qu'il sera moins bien protégé. En fonctionnement normal, le secondaire va donc se retrouver à mettre en queue des mails que le primaire va lui refuser sans cesse ... jusqu'à l'atteinte du « maximal_queue_lifetime ». Le secondaire tentera alors d'avertir l'expéditeur de la non-livraison ... quand il le peut ... donc le bounce peut se retrouver en file d'attente pendant « bounce_queue_lifetime ». Tout ce travail pour rien, c'est dommage.

Pour éviter cela, Postfix peut interroger le primaire et vérifier que la boîte ou l'alias existe juste après l'étape « RCPT TO » et donc avant le transfert du message par l'expéditeur et sa prise en charge. Cela se fait avec l'option « reject_unverified_recipient » de la directive de configuration « smtpd_recipient_restrictions ».

Cette vérification se fait simplement en simulant l'envoi d'un mail : EHLO - MAIL FROM - RCPT - QUIT. Si le primaire ne répond pas assez vite, le secondaire demandera à l'expéditeur de revenir plus tard (code 450, comme pour le greylisting) donc aucun risque de perte. Évidemment, le secondaire met en cache la réponse du primaire, qu'elle soit négative ou positive pendant le délai défini par « address_verify_cache_cleanup_interval » (0 pour persistant, 12h par défaut).

Lors d'une panne importante et durable sur le primaire, il faudra désactiver cette option (« reject_unverified_recipient »). Dans le cas contraire, le secondaire n'arrivera jamais à interroger le primaire et les mails seront donc sans cesse refusés temporairement à l'entrée ... et donc vous dépendez à nouveau de la bonne configuration du serveur de mail expéditeur en ce qui concerne le délai maximal de mise en file d'attente en cas de non livraison.

Astuce en plus : un tel secondaire n'a que deux buts :
  1) transmettre les mails pour certains domaines à un (ou plusieurs) serveur primaire.
  2) accepter et délivrer les mails pour lui-même, en tant que machine (mamachine.mondomaine.example).
On connaît donc toutes les destinations de sortie autorisées : soit les relay_domains, soit le serveur lui-même est la destination finale. Donc on élimine les indésirables avec l'option « reject_unauth_destination » de la directive « smtpd_recipient_restrictions ».

L'astuce consiste à positionner l'option  « reject_unauth_destination » avant l'option « reject_unverified_recipient ». Dans le cas contraire, le secondaire va contacter inutilement la destination indiquée dans le RCPT TO avant de rejeter le mail pour cause de relai interdit !

Comme l'indique cette page du manuel de Postfix, il est aussi possible de vérifier l'existence de l'adresse mail d'expédition mais le manuel ne le recommande pas, surtout sur des gros volumes de mails : des checks trop fréquents provoqués par des mails forgés pourraient vous valoir un ban de votre serveur de la part de ces serveurs indiqués comme expéditeurs.

La fonctionnalité MUC (Multi-User Chat) c'est simplement reproduire IRC sur Jabber : discussion à plusieurs (> 2 personnes).


Avec ejabberd, il faut :
  - une entrée A/AAAA/CNAME dans le DNS (par défaut c'est conference.<virtualhost_actuel> mais ça se change dans le fichier de config). D'après mes tests, ça ne peut pas être le nom de l'hôte lui même (erreur : le nombre max d'utilisateurs est atteint) ...

  - Le module MUC est activé par défaut mais il faut ajuster les ACL (qui peut être admin ? qui peut créer un salon ?, ... ?) selon vos envies : http://www.process-one.net/docs/ejabberd/guide_en.html#sec69


Mes observations de n00b découvrant le truc :
  - Le serveur devient un point central pour les salons et pour les discussions privées. J'imaginais un mode P2P. Du full-mesh entre tous les participants, le serveur ne servant qu'à mettre en relation "tels JID sont connectés à ce chan". Le serveur d'un participant envoie le message à tous les participants, de manière directe. Oui, ça ne passerait pas à l'échelle et oui, ça montrerait les JID à tout le monde alors qu'ils sont masqués aux utilisateurs (visibles des modo/admins), par défaut). Donc Jabber+MUC c'est vraiment comme IRC d'un point de vue de l'architecture.

  - On peut inviter des personnes de sa liste de contacts sur un salon hébergé sur un serveur qui n'est pas le sien. Ce qui signifie que, dans un groupe de connaissance, tout le monde n'a pas besoin de faire le petit bout de conf qu'il faut pour pouvoir discuter à plusieurs. Comme IRC quoi.

  - C'est un pseudo par salon, pas par serveur contrairement à IRC.

  - Les admins/modos ne peuvent pas s'entre-kicker/ban, contrairement à IRC (ce comportement dépend peut-être du logiciel serveur IRC utilisé). Un admin/modo ne peut pas non plus s'auto kick/ban.

  - Un salon peut se caractériser par un nom, un sujet et une description. Sur IRC c'est nom (avec un # obligatoire) et un sujet.

  - Quand on rejoint un salon, on a un historique de ce qui s'est dit sur le salon avant notre arrivée.

  - Pour chaque personne, on peut définir une affiliation (outcast (banni), none (simple participant), member, admin et owner) et un rôle (none (kick), visitor (sans voix), participant (normal), moderator).

  - Il y a une fonctionnalité d'auto-reconnexion au serveur/salon en cas de coupure réseau, en tout cas par défaut avec Gajim ... tout comme c'est possible de config irssi pour faire ça.

Carte intéressante, tout comme la fin de l'article. À croiser avec ce que publie Reflets depuis longtemps.

Excellente tribune de Laurent Chemla et d'Éric Walter.

« Si nous avons une question à nous poser aujourd’hui, ce n’est certainement pas celle de savoir comment sont morts nos espoirs déchus. Ils ne le sont pas. C’est, bien au contraire, de chercher comment faire pour que ce bouillonnement créatif qu’Internet a fait naître soit mieux appuyé, accompagné, pour se lancer plus vite dans la conquête de l’infini. Selon que l’on écoute les Cassandre, ou non, que l’on surrégule, ou non, c’est aujourd’hui qu’on bascule dans le futur, ou dans le tiers-monde numérique.

L’histoire récente n’a pas manqué de législations nationales sur Internet. Beaucoup pour protéger, peu pour en préserver les principes (tels que la neutralité), et encore moins pour y garantir les droits fondamentaux. C’est pourtant par là qu’il est urgent de commencer. Il ne s’agit pas d’adapter le nouveau monde à l’ancien, mais bien le contraire.

C’est pourquoi, citoyens, forts de nos expériences respectives, nous appelons le législateur à la plus grande prudence dans l’accumulation législative sur Internet. Il est temps d’inventer. Nous avons besoin d’innovation institutionnelle face à l’innovation sociale et économique qui se répand grâce à Internet. Parce que, même si elle est née aux Etats-Unis, l’utopie internet ne se résumera jamais mieux que par la devise républicaine française : liberté, égalité, fraternité. Voilà ce qu’il faut préserver avec force et vigueur, sauf à risquer de la transformer en dormeur du val. »

La nouvelle super méga giga grosse faille dans le DNS qui va tout casser l'Internet ... ou pas. Que les récursifs, que BIND et avec un impact bien faible. En cela, ça me rappelle l'épisode des noms de domaine fantômes (https://kb.isc.org/article/AA-00691/0/CVE-2012-1033%3A-Ghost-Domain-Names%3A-Revoked-Yet-Still-Resolvable.html) ...  

En tout cas, le bad buzz est parti, à voir combien de temps il va tenir ...

Voir aussi : https://kb.isc.org/article/AA-01030

Bien que le bugreport a été clôturé après le freeze de wheezy (30/06/2012), le support SNI a été ajouté dans la version 1.13.4 de wget que l'on a dans stable lors de l'update Debian 7.4 (https://www.debian.org/News/2014/20140208 - « wget Add support for SNI »). Il n'y a donc plus aucun problème lié à SNI.

Le cas rencontré ici est un serveur web qui envoie son certificat, signé par le certificat intermédiaire de StartCom ... Or, ce certificat n'est pas disponible dans le magasin (/etc/ssl/certs), seul le certificat racine de StartCom l'est. Donc chaîne de certificats x509 invalide donc foirage de wget. Le serveur web devrait envoyer une chaîne comprenant son certificat + le certificat intermédiaire. Dans ce cas, la validation x509 fonctionnerait.

Les navigateurs ont l'air plus coulants. Chromium n'avait pas le certificat intermédiaire, « StartCom Class 1 Primary Intermediate Server CA », dans son magasin mais seulement le certificat racine (« StartCom Certification Authority ») et m'a laissé passé. Dans Firefox, le certificat intermédiaire était présent en « Sécurité personnelle », pas en « Builtin Object Token ». Après suppression et redémarrage manuel de Firefox, il m'a affiché une erreur (« Le certificat n'est pas sûr car aucune chaîne d'émetteurs de confiance n'est fournie. ») pour le site en question mais quand j'ai voulu ajouter une exception, il m'a indiqué que « Ce site fournit une authentification valide et certifiée. Il n'est pas nécessaire d'ajouter une exception. » et le bouton « Confirmer l'exception de sécurité. » était grisé ... Après vérification, le certificat intermédiaire de StartCom était de nouveau présent dans le magasin. Après une nouvelle expérience, je peux dire qu'il n'est pas nécessaire de cliquer sur « Ajouter une exception de sécurité » : voir l'erreur et juste faire F5 et le site apparaît et le certificat intermédiaire est remis dans le magasin de certificats.

« Because dig is not so self-explanatory, here’s something more useful. Since bind 9.10rc1, the ISC team introduced a new team to help with the debug of DNSSEC eventual problems. Initially called delve, but changed to delv. »

ÉDIT du 26/07/2014 à 17h58 : http://www.bortzmeyer.org/delv.html

« Les auteurs de SF sont pour moi, les personnes les plus créatives qui soient quand il s'agit d'imaginer le futur de l'Humanité. D'ailleurs, de nombreux délires d'écrivains se sont concrétisés au fil des années et c'est ce que montre cette infographie. »

Je me garde ça sous le coude.

(via http://seenthis.net/messages/253874)

Bravo à Cambrai ... Pffffff

Intéressant.

Lorsqu'on est hébergeur DNS, on est souvent amené à ajouter/supprimer une zone et/ou à modifier le contenu desdites zones "automatiquement" via une interface web mise à la disposition du client/membre/...

C'est dans ce cas d'usage qu'un logiciel de contrôle pour le serveur de nom aide en permettant l'ajout, le retrait de zones et la prise en compte des modifications dans un fichier de zone, à la volée, à partir d'une simple ligne de commande.

Parmi les logiciels qui permettent de monter un serveur qui fait autorité les plus connus :
BIND est équipé de rndc
NSD est équipé de nsd-control *à partir de sa version 4*
knot est équipé de knotc ...

Quel serveur de nom choisir ? Voici quelques pistes :
- BIND est un fourre-tout monolithique qui mélange les rôles (serveur récursif-cache et serveur qui fait autorité) ce qui n'est pas sain. Knot est pour l'instant exclusivement un serveur qui fait autorité. Mais ajouter la fonctionnalité récursif-cache est en projet. Donc NSD est à considérer.

- rndc (BIND) est complet : on ajoute une zone, on la supprime, des commandes sont prévues pour tout ça. nsd-control aussi. knotc impose de modifier manuellement le fichier de configuration pour ajouter/supprimer la prise en charge d'une zone puis de faire relire la conf' (knotc reload), ce qui s'avère dommage : l'ajout est facile, la suppression plus difficile (chercher la zone concernée dans un fichier texte et la supprimer quand elle est en plein milieu) ou crade (regénérer tout le fichier de conf' à chaque suppression). BIND et NSD ont un avantage.

NSD et knot sont légers au niveau des dépendances à la compilation.


C'est aussi dans ce cas d'usage que l'on regrette qu'il n'y ait pas de protocole normalisé à l'IETF d'échange de la configuration entre serveurs DNS (comme un transfert de zones mais pour la configuration). C'est une plaie de modifier les maîtres puis ensuite les esclaves en utilisant les logiciels de contrôle propre à chaque logiciel ... Cette normalisation est un vieux projet : 2006 - Nameserver Communication Protocol - voir http://www.bortzmeyer.org/ncp-first-draft.html jugé trop prématuré (pas assez discuté des problèmes que l'on cherche à résoudre) donc renvoyé à une design team puis 2011 - RFC 6168 - voir http://www.bortzmeyer.org/6168.html qui pose enfin le cahier des charges ... À voir si ça va aboutir un jour ...

Encore une commande qui me semble méconnue donc je la partage.

Si, pour X raisons, vous changez le propriétaire/groupe et/ou les permissions d'un fichier/dossier qui fait partie d'un package, cette commande est très pratique pour vous assurer qu'une mise à jour dudit paquet ne viendra pas écraser vos modifications.