GuiGui's Show

Un bon tuto pour débuter et installer Postfix, Dovecot (avec prise en charge de Sieve), SquirrelMail et SpamAssasin pour un usage personnel (auto-hébergement).

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

Wow !

(via http://lehollandaisvolant.net/?id=20140519201456)

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.

«  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

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).

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.

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. »

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.

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