GuiGui's Show

Un rappel de la difficulté (stupidité ?) d'envisager de la QoS à l'échelle de l'Internet.

« L'Internet a toujours fonctionné sur le principe du « fais au mieux » (best effort), c'est-à-dire que les applications qui l'utilisent n'ont aucune garantie sur les caractéristiques quantitatives du réseau qui sera à leur disposition.


[...] intserv (RFC 1633) ou bien diffserv (RFC 2475). En pratique, ces mécanismes ont été très peu déployés, ce qui relativise la soi-disant demande de QoS. [et ils n'ont jamais atteint la granumarité que certains souhaitaient, NDLR]


La section 2 expose les propriétés de ce service simple best effort. En 2.1, les auteurs listent les forces de ce service :

    - Il ne demande pas trop d'efforts de la part de l'infrastructure réseau : les routeurs, par exemple, ont ainsi le minimum de travail. Ce service libère ainsi des ressources pour, par exemple, augmenter la capacité (les réseaux télécoms traditionnels passaient tellement de temps à gérer la QoS que leur débit total était sérieusement réduit).

    - Il ne demande pas trop de mécanismes économiques entre les opérateurs. Une des principales raisons du très faible déploiement de diffserv est qu'il nécessite des mécanismes de compensation entre opérateurs. Autrement, tout le monde enverrait ses paquets avec la classe la plus favorisée ! Ces compensations sont complexes et nécessitent des accords entre opérateurs qui vont plus loin que les mécanismes actuels entre opérateurs, ou entre un opérateur et son client.

    - Et, surtout, ce service « fais au mieux » est utile dans le monde réel. Il marche, pour une grande variété d'applications, et il propulse l'Internet depuis trente ans, malgré les affirmations (qu'on trouve par exemple dans la quasi-totalité des ouvrages universitaires sur les réseaux informatiques publiés en France) comme quoi un réseau sans QoS ne servait à rien.


Évidemment, tout n'est jamais uniformément rose. Le service « fais au mieux » a aussi des limites, que détaille la section 2.2.

    -  Ensuite, les services avec QoS peuvent interférer avec la « transparence du réseau ». En effet, il n'est pas difficile d'imaginer des cas où, pour certaines applications, celui qui ne paierait pas le surcoût de la QoS serait, en pratique, exclu du réseau. Mais le débat est loin d'être clos sur la question de savoir quel niveau de QoS reste compatible avec cette transparence du réseau.

    -  Une autre faiblesse du « fais au mieux » est sa sensibilité aux incivilités (section 2.2.2). Si un certain nombre d'utilisateurs ne jouent pas le jeu, le réseau peut s'effondrer puisqu'il n'y a pas de limites à l'allocation de ressources. Dans cette optique, les services différenciés ne seraient pas tant un moyen de « donner plus à ceux qui paient plus » qu'un mécanisme de contrôle de la congestion, même en présence d'implémentations « agressives » de TCP/IP, qui ne respecteraient pas les règles énoncées dans le RFC 2914.

    - Enfin, la dernière faiblesse (section 2.2.3) est le cas de « pics » de trafic brutaux (suite à une DoS ou tout simplement en cas de grand succès d'un site Web), pour lesquels le mécanisme « fais au mieux » mène en général à ce que personne ne soit servi...

[...]

Une deuxième question est qu'il n'existe pas de définition claire et consensuelle de ce qu'est l'équité entre les flux. Tout le monde est pour l'équité, c'est lorsqu'on essaie de la définir que les ennuis commencent (section 3.2.2). D'abord, « flux » (flow) n'est pas bien défini (cf. RFC 2309, RFC 2914, RFC 3124 et bien d'autres). Est-ce par connexion ? (Un concept qui n'existe pas pour tous les protocoles, par exemple UDP.) Ou bien pour tout trafic entre deux machines ? Ou bien, à une granularité intermédiaire, faut-il mettre toutes les connexions TCP démarrées par le même navigateur Web ou bien le même client BitTorrent dans le même flux ? Et l'équité doit-elle se mesurer en nombre de paquets ou en octets/seconde ? (Les protocoles interactifs comme SSH préféreraient certainement la première solution.) Et que faire avec les protocoles où le trafic tend à être très irrégulier ? Faut-il une équité « en moyenne » ? Si oui, sur quelle période ? Bref, si l'objectif politique est clair, le traduire en chiffres précis semble très difficile. »

Il se trouve que la mise à jour du paquet sympa dans Debian stable du 27/04/2014 (oui oui, monitoring incomplet spotted) a refait buguer sympa/wwsympa ...

Dans les logs d'erreur d'Apache :
(104)Connection reset by peer: mod_fcgid: error reading data from FastCGI server
Premature end of script headers: wwsympa-wrapper.fcgi

Déjà vécu lors de la migration Squeeze -> Wheezy ... Voir : http://www.guiguishow.info/2013/05/19/de-debian-gnulinux-squeeze-a-wheezy/#toc-3696-sympa-plus-prcisment-wwwsympa-linterface-web

La solution est toujours la même : si vous utilisez mod-fcgid, alors il faut avoir « use_fast_cgi  1 » dans /etc/sympa/wwsympa.conf . Mais attention ! C'était mon cas. Mais il semble que la mise à jour ait ajouté « use_fast_cgi  0 » à la fin du fichier et que la dernière occurrence d'un paramètre gagne ... Oui, il faut le voir ...

Mais ce n'est pas fini ... En effet, cette mise à jour a aussi reset les paramètres « domain » et « listmaster » dans /etc/sympa/sympa.conf ... Remettez les bonnes valeurs ...

On peut enfin service sympa restart.

De mon côté, cette nouvelle expérience vaudra un apt-mark hold sympa (on fige la version). Pour avoir vu du mailman en action depuis, je déconseille désormais sympa ...

Des rappels salvateurs sur TLS.

Rien d'innovant, juste des rappels essentiels de choses trop souvent oubliées :
  - Écouter les communications qui passent sur un réseau, c'est facile, quelles que soient les technos utilisées à tous les niveaux (physique, logique, logiciels, ...) ;

  - Attaques passives/actives ;

  - Confidentialité implique authentification *surtout* si l'attaquant est actif ;

  - TLS protège en transit mais ne protège pas contre des extrémités corrompues. Exemples : malwares, PRISM ;
 
  - Le modèle de sécurité x509 est vaseux. Exemples : n'importe quelle AC peut signer n'importe quelle clé publique qui revendique tel nom ; Vague de piratages en 2011 ;

  - Fonctions des librairies standards de certains langages mal conçues qui débrayent la sécurité (authentification) par défaut. Exemples : python, php/curl ;

- API complexes, documentation mal fichue. Les premières aides qu'on trouve (sur SO par exemple) expliquent systématiquement comment débrayer la sécurité sans l'indiquer clairement. Comment le dev' dont la sécurité n'est pas le domaine de compétence peut-il s'en rendre compte ?

  - Mauvaises pratiques côté développeurs :
    - Les tests valident uniquement les cas normaux donc la sécurité fonctionne forcément. Il faut tester des scénarios d'attaque et vérifier que la sécurité fonctionne toujours. C'est pas simple à mon avis : quels cas teste-t-on ? Quels sont ceux qui se produisent le plus en situation réelle ? Comment intégrer ça dans les délais de coding/intégration déjà serrés au maximum ?

    - Débrayer la sécurité en phase de développement pour ne pas se prendre la tête ... et oublier de réactiver ladite sécurité dans la version finale livrée.

   - Plutôt que de chercher à protéger des énormes volumes de données, pourquoi ne pas plutôt collecter que le strict minimum nécessaire à la fourniture de la prestation ?

Renesys produit de bon rapports post-incident. J'espère que ça va pas changer avec les nouveaux proprios ... Dommage de voir où Renesys va atterrir. :'(

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.