Category Archives: Infos

Comment bloquer les spams téléphoniques

On reçoit tous des appels téléphoniques inopportuns en tous genres, au point qu’on en arrive à généraliser un accueil téléphonique glacial même à ses proches.

La solution la plus évidente est le recours à la liste noire.  Pour faciliter cela, numerunique partageait gratuitement un système de blocage en deux clics. Hélas, même avec 1044 numéros en liste noire, on est encore dérangé.

Une autre solution s’avère plus efficace : elle consiste à configurer un SVI (Serveur Vocal Interactif) minimaliste :

  • Message d’accueil : “Si vous êtes de la famille ou de nos amis, faites le 1 ; sinon faites le 2.”
  • 1 : ça sonne.
  • 2 : ça raccroche.

Enfin tranquille !

En pratique, ce sont des robots qui lancent les appels, automatiquement, à la place des employés des plateforme d’appels. Dès qu’une cible décroche, le robot fait sonner le poste d’un esclave disponible qui peut alors débiter son baratin en suivant les directives du discours commercial imposé. Les robots actuels sont incapables de comprendre l’annonce d’un SVI ni de taper 1. En bonus, cela épargne aux malheureux qui sont exploités sur les plateforme d’appels d’avoir leurs taux de conversion dégradés par un appel qui n’aboutira à rien.

Meltdown et Spectre, faut-il vraiment s’affoler ?

Noms judicieux, logos, timing (juste après les fêtes de fin d’année), site Internet dédié, matraquage médiatique, GIF montrant une démo de keylogger : le traitement marketing des dernières “failles” de sécurité informatiques est vraiment spectaculaire !

Ce qui l’est beaucoup moins c’est ce qui ressort de l’analyse du risque réel de ces menaces, avec les informations actuellement publiées.

Certes, le “risque” est confirmé par Intel ” software analysis methods that, when used for malicious purposes, have the potential to improperly gather sensitive data” mais juste comme potentiel. A la base, le risque serait induit par l’optimisation de traitement d’un processeur qui profite des temps d’accès à la mémoire pour tenter sa chance en exécutant un code probable sans dispositif de protection d’accès à la mémoire pour cette exécution spéculative.

Cependant les deux articles de référence qui décrivent Meltdown et Spectre indiquent clairement que ces failles nécessitent l’exécution d’un programme sur la machine cible.

Et là, il n’y a rien de nouveau, on sait depuis toujours qu’on a presque perdu la partie contre un pirate dès lors qu’il est capable d’exécuter ses programmes sur la machine que l’on défend. La première préoccupation d’un administrateur système est la fiabilité des utilisateurs de ses machines.

C’est donc logique que les hébergeurs tels qu’OVH ou Online mettent autant d’énergie à appliquer des correctifs, tout en précisant qu’à ce jour il n’ont aucune preuve que ces attaques pourraient se réaliser en vrai ” To date, OVH has not received any information demonstrating that the concerned vulnerabilities have been exploited outside of a research laboratory setting.” Les hébergeurs savent que parmi leurs centaines de milliers de clients qui ont accès à leur machines, il y a certainement plus d’une crapule.

Dans le papier “universitaire” qui décrit Spectre, sur lequel pas moins de 10 auteurs se sont agglutinés, l’assemblage des techniques utilisées pour exploiter la faille hardware est impressionnante au point qu’on peut se demander si la somme des conditions favorables à l’exploit ne le rendrait finalement très peu probable. Il y a au moins un aspect décisif facile à comprendre qui n’est pas clair : le succès de la technique dépend-il de la présence de certaines instructions particulières dans un programme cible dont on veut dérober les informations détenues en mémoire ? On y donne un exemple de code hallucinant qui peut être exploité :

if (x < array1_size) y = array2[array1[x] * 256];

C’est bien de vérifier si l’index x est dans les limites du tableau array1 mais alors pourquoi ne pas aussi vérifier que l’index (array1[x]*256) est aussi dans les limites de array2 ? Si ce code est celui écrit par le pirate, il fait ce qu’il veut mais a priori il n’aura accès qu’au contexte de son propre programme comme l’article le précise “The completed attack allows the reading of memory from the victim process.“. Si ce code doit figurer dans celui d’un autre programme exécuté sur la machine alors la probabilité qu’un tel code existe parait plus que très faible.

Il y a de nombreuses autres conditions ou réserves évoquées ou exprimées dans cet article telles que “Kernel mode testing has not been performed, but the combination of address truncation/hashing in the history matching and trainability via jumps to illegal destinations suggest that attacks against kernel mode may be possible.

Tout cela change complètement la réalité de la menace.

Malheureusement cela n’enlève rien aux conséquences qu’elle a déjà engendrées et qui sont irréversibles : un tsunami de mises à jour, une version plus qu’améliorée de l’obsolescence programmée 🙁

Meltdown and Spectre: the juiciest bug of 2018?

2018 starts wonderfully: a new kind of vulnerability has been disclosed, an hardware bug!

Documentation about this is available from sources with considerable authority, from university researcher or google official blog.

However, a closer analysis of the threats raises doubts about their seriousness. The risk to be affected by them seems rather low.

“...Meltdown allows an adversary who can run code on the vulnerable processor…” [https://meltdownattack.com/meltdown.pdf]. Thus for dedicated server, the vulnerability implies a logged attacker. Of course for VM or VPS, you don’t control who runs code on the physical host you share. But servers administrator core preoccupation is to keep attacker from logging on their systems.

As for “Spectre” [https://spectreattack.com/spectre.pdf], the so called proof of vulnerability – among other prerequisites unlikely to happen – relies on the “victim” code to have an instruction such as “if (x < array1_size) y = array2[array1[x] * 256];“! Who would write such a code and what for?

These two quoted papers remind of academic context where such unpractical conditions hidden behind well handled complexity are often observed. The underlying techniques are too complex to be easily understood but the presentation is convincing.

Even google (https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html) admits that “To take advantage of this vulnerability, an attacker first must be able to run malicious code on the targeted system.

Anyway, even if the risk is much lower that it is presented, the inevitable result will be a massive update frenzy: an ideal opportunity to deploy other vulnerabilities, spywares or backdoors and to motive hardware replacement…

First, the software fix will decrease performance: a motivation to invest in faster – and more expensive – systems. Eventually the hardware fix will require new computers. Thus it is not surprising that all CPU vendors happily admit that their products are affected.

Whatever dangerous Meltdown and Spectre may be, they are certainly a huge opportunity of profit.

Well done.

 

L’EURL Barme change de nom commercial…

… et s’appelle désormais numerunique :

En fait une société a trois identifiants :

  1. sa dénomination ou raison sociale,
  2. son nom commercial,
  3. son enseigne commerciale.

Ce nouveau nom commercial reflète davantage l’activité de numerunique. C’est la contraction de numérique et unique et justement, lorsque on fait le bilan de son activité depuis bientôt 10 ans, numerunique fourni des services numériques si personnalisés qu’il sont en fait uniques.

Ce changement – dans la continuité, car c’est toujours la même entité et elle conserve sa raison sociale – est renforcé par un nouveau logo, produit par numerunique.art, plus conforme lui aussi à l’activité de numerunique :

A gauche le 0 symbolise le numérique, à droite, le 1 symbolise l’unique et, au centre, les deux fusionnent dans un objet binaire en 3 dimensions qui symbolise la concrétisation des services numériques uniques de numerunique.

Comparaison de quelques types d’accès à Internet

Quelques tests de différents type d’accès à Internet donnent :

Type d’accès IP Réception max Envoi max Latence min gigue
Wi-Fi distant fixe 0.241 0.657 0.36 0.514 186.1 39 1060
Ethernet via CPL fixe 5.523 5.758 0.708 0.788 42.17 39.8 7.4
Wi-Fi Orange 3G variable 8.194 11.28 0.417 0.542 268.2 91.58 332.3
Wi-Fi proche fixe 11.89 12.28 0.791 0.84 80.91 38.91 171.2
Ethernet direct fixe 11.95 12.12 0.639 0.708 41.05 37.54 8.39
Wi-Fi Free 4G variable 70.87 77.5 7.28 8.988 129.5 54.17 158.2

Les débits de réception et d’envoi sont en Mb/s, la latence et la gigue en ms.

Pour la meilleure réception :

  1. Wi-Fi Free 4G
  2. Ethernet direct
  3. Wi-Fi proche
  4. Wi-Fi Orange 3G
  5. Ethernet via CPL
  6. Wi-Fi distant

Pour l’envoi le plus rapide :

  1. Wi-Fi Free 4G
  2. Wi-Fi proche
  3. Ethernet via CPL
  4. Ethernet direct
  5. Wi-Fi Orange 3G
  6. Wi-Fi distant

Pour la meilleure réactivité :

  1. Ethernet direct
  2. Ethernet via CPL
  3. Wi-Fi proche
  4. Wi-Fi Free 4G
  5. Wi-Fi distant
  6. Wi-Fi Orange 3G

Pour la meilleure stabilité :

  1. Ethernet via CPL
  2. Ethernet direct
  3. Wi-Fi Free 4G
  4. Wi-Fi proche
  5. Wi-Fi Orange 3G
  6. Wi-Fi distant

Synthèse (tous critères) :

  1. Ethernet direct
  2. Wi-Fi Free 4G
  3. Ethernet via CPL
  4. Wi-Fi proche
  5. Wi-Fi Orange 3G
  6. Wi-Fi distant

En bref :

  • La 4G est vraiment rapide à défaut d’être stable.
  • L’Ethernet direct et le wifi proche se valent.
  • Le pire est le Wi-Fi trop distant.

Ces conclusions sont juste indicatives : en pratique, les résultats des tests sont spécifiques à un lieu et un moment donnés.

Le plus petit SaaS ?

C’est “L’adpresse IP publique” : lip.ovh !

A voir tous les sites qui propose de vous révéler votre adresse IP publique, c’est un service très demandé. Mais lip.ovh se distingue de ses analogues à plus d’un titre :

  1. son nom est le plus court
  2. c’est le service le plus concis,
  3. il n’a aucune pub,
  4. c’est le moins cher.

On accède à lip.ovh en 7 caractères seulement ; on pourrait faire plus court sur un TLD de 2 lettres qui accepte des noms de domaine à moins de 3 lettres mais se serait plus cher.

Ce SaaS (Software as a Service) affiche uniquement l’adresse IP publique de celui qui l’utilise, et rien d’autre. Difficile d’en faire moins.

lip.ovh est hébergé sur un hébergement mutualisé gratuit ; son prix de revient est donc de 0.0825 € HT par mois. Qui dit mieux ?

A ce prix là, ce service est royalement offert par l’EURL Barme qui en profite pour illustrer l’approche minimaliste et économique qu’elle propose à ses clients.

L’EURL Barme entame sont 10ème exercice

Depuis le 1er juin 2017 l’EURL Barme est entrée dans sa 10ème année. Et 10 est un chiffre exceptionnel qu’il est courant de célébrer. C’est encore plus opportun pour un informaticien.

Un informaticien jongle forcément avec les bases binaire, décimale et hexadécimale. La base 2 est celle des ordinateurs et des circuits logiques. Elle utilise 2 chiffres, le 0 et le 1. 10, qui vaut 2 en binaire est donc un nombre particulier à plus d’un titre puisque les bases binaires et décimales y convergent.

A cette occasion, l’EURL Barme lance une nouvelle activité :
numerunique.art.

Au premier abord c’est une activité dont le modèle économique cumule les handicaps : les charges considérables de conception et l’absence d’économie d’échelle qu’apporte la production en masse.

Pourtant, c’est justement ce qui est au cœur de l’activité principale de l’EURL Barme : l’application de l’outil informatique pour un usage spécifique. C’est donc une niche à l’écart de laquelle se tiennent les sociétés dont l’objectif exclusif est la rentabilité mais c’est l’écosystème dans lequel l’EURL Barme d’épanoui depuis bientôt 10 ans, pour la plus grande satisfactions de ses clients.

Comment perdre 2 ans de confiance en 2 heures

Les faits

08:44

Un client de l’EURL Barme signale l’indisponibilité d’un service.

08:55 Création d’un ticket incident :

Bonjour,

Que ce soit depuis l’extérieur (ping barme.fr 195.154.60.32) ou par le RPN (ping 10.x.x.x), le serveur ne répond pas.

Est-ce un problème réseau ?

Merci.

08:58 réponse du support :

Bonjour,

Je fais quelque vérifications et reviens vers vous dans les plus brefs délais.

Cordialement,

09:01 (support) :

Bonjour,

Je vois des logs sur le kvm qui peuvent indiquer une Kernel Panic.

M’autorisez-vous à passer le serveur en mode secours afin de faire quelques tests? Je reviendrai vers vous dès les tests finis.

Cordialement,

09:08 (EURL Barme) :

Oui, passez en mode rescue.

A noter, j’ai basculé mon IP failover sur mon serveur de secours.

09:36 (support) :

Bonjour,

Après les tests que j’ai effectué, il apparaît que le serveur est fonctionnel et n’a pas de souci matériel.

Je vous invite à regarder du côté Software/OS et installation ou configuration.

Je reste à votre disposition pour toute autre demande.

Cordialement,

09:40 (EURL Barme) :

ping x.x.x.x: 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
^C

Vous appelez ça fonctionnel ?

09:43 (support) :

Bonjour,

J’ai fait les tests en mode secours et cela n’utilise pas la configuration du serveur(celle que vous avez installée) mais démarre bien sur un OS qui se trouve sur un serveur de stockage à nous donc je vous invite à revoir la configuration de l’OS que vous avez installé et les réglages que vous avez fait.

Je reste à votre disposition pour toute autre demande.

Cordialement,

09:45 (EURL Barme) :

Merci, je sais ce que c’est le mode secours.

Ne touchez donc plus à rien ; je vais investiguer par moi-même.

09:47 (EURL Barme) :

A noter le “Monitoring” :

Monitoring

Service Statut

Ping du serveur Disponible il y a 1 année historique

!!

09:54 (support) :

Bonjour,

Très bien.

Cordialement,

10:00 (EURL Barme) :

Mon serveur sd-x est à nouveau opérationnel, directement sans _aucune_ modification de sa configuration…

Un simple reboot aura donc suffit à le remettre en service ; c’est habituel de mettre en cause la configuration du client mais comment pouvez-vous le justifier ?

10:16 (support) :

Bonjour,

Je vois que le souci sur ce serveur est résolu après un simple reboot.

Je vous invite à clore le ticket et à le noter en laissant un commentaire.

Bonne journée,

10:20 (EURL Barme) :

Dans syslog, j’ai :

Apr 11 21:17:01 ol1 /USR/SBIN/CRON[46128]: (root) CMD ( cd / && run-parts –report /etc/cron.hourly)
Apr 12 09:40:42 ol1 kernel: imklog 5.8.11, log source = /proc/kmsg started.

Donc mon serveur est down depuis hier 21:17:01 et à nouveau opérationnel depuis 09:40:42 ce matin.

Et pourtant votre monitoring ne m’a pas alerté et prétend qu’il est disponible depuis 30/09/2015 09:52:18 ! ?

N’y aurait-il pas un problème de votre coté ?

10:44 (support) :

Bonjour,

Je transmet votre demande au service concerné et nous reviendrons vers vous dans les plus brefs délais.

Cordialement,

10:53 (EURL Barme) :

Cela vous amuse de passez mon serveur en mode rescue sans prévenir ?

11:03 (EURL Barme) :

Vos techniciens mettent mon site HS alors que je leur ai demandé de ne plus y toucher à 12/04/2017 09:45:53.

C’est pourtant pas un jouet ce serveur !

11:09 (support) :

J’ai prévenu mes collègues en charge

— —

Cordialement,

11:30 (support) :

Bonjour,

je reprends la suite du ticket au vu du signalement de celui-ci.

Un quiproquo et un échange trop rapide lors de la remonté a en effet entraîné un autre passage en secours.

Je confirme que le serveur est bien opérationnel de mon côté

Il ping bien en mode normal.

J’ai remis à jour le monitoring sur le serveur en espérant que vous soyez allertez la prochaine fois.

Rien ne vous empêche de mettre en place votre propre monitoring.

Cordialement – Technicien Premium

Commentaires

C’est toujours dans un contexte défavorable qu’un incident survient, en l’occurrence lors d’un déplacement, avec un contexte technique d’intervention et une disponibilité réduits.

Evidemment, c’est un client qui découvre et indique le problème ; en temps normal il aurait été découvert bien plus tôt et l’investigation de l’EURL Barme aurait été faite directement par une connexion sur la console du serveur, avant de faire intervenir le support.

Le support a été très réactif : réponse au ticket en 3 minutes. Son diagnostique initial (Kernel Panic) a été confirmé par le technicien Premium intervenu après escalade du problème.

Erreur du support : retour sans vérifier que le serveur est opérationnel après sortie du mode rescue. Il aurait été préférable d’attendre la fin du redémarrage.

Dérapage du support : mise en cause arbitraire du client (“J’ai fait les tests en mode secours et cela n’utilise pas la configuration du serveur(celle que vous avez installée) mais démarre bien sur un OS qui se trouve sur un serveur de stockage à nous donc je vous invite à revoir la configuration de l’OS que vous avez installé et les réglages que vous avez fait.”)

C’est un grand classique de tous les supports de mettre systématiquement le client en cause. C’est évident que la plupart des remontées faites aux supports le sont par des personnes aux compétences informatiques modestes et de surcroît sans doute agressives car le problème pour lequel elles appellent est mal vécu. Mais ce n’est pas une raison pour mettre tout le monde dans le même panier et considérer, a priori, que l’origine du problème est du coté du client. La bonne approche devrait être de vérifier en premier s’il n’y a pas un souci du coté du prestataire et rien n’empêche, ensuite, de mettre le client face à ses responsabilités.

Erreur gravissime du support : passer un serveur de production (qui fonctionne !) en mode rescue sans autorisation du client. Là c’est le summum de l’inconséquence et totalement inadmissible de la part d’un service professionnel.

Ensuite c’est l’escalade et le problème atterri sur le dos d’un technicien “Premium” qui n’y est pour rien et ne peut plus rien y faire. Le terme “Premium” fait sourire avec sa connotation de “compétence supérieure”. Techniquement c’est sans doute vrai mais dans le contexte, ce sont davantage des compétences en communication qui sont requises.

Ce technicien “Premium” prendra la peine d’appeler pour signaler le retour au mode normal du serveur, ce qui est très bien et courageux de sa part mais son ton condescendant face à un interlocuteur avec 36 années d’expériences en informatique dans un tel contexte sera la cerise sur le gâteaux… Une formation de base à la communication lui serait bien utile.

Et pour la suite…

Les serveurs sous linux sont très fiables mais pas infaillibles. C’est justement la raison pour laquelle un serveur dédié utilisé pour un service critique  ou non doit être doublé par un clone synchronisé automatiquement et en permanence avec le serveur en fonction. Un kernel panic isolé est un aléa potentiel qui ne remet pas en cause le serveur ni sa configuration.

De même un incident isolé mal géré ne remet pas en cause un prestataire ni son professionnalisme.

L’EURL Barme ne changera donc pas ses serveurs impliqués dans cet incident et ne souhaite finalement qu’une chose : que cesse cette habitude des supports de mettre systématiquement en cause le client.

Epilogue

A l’occasion d’un autre souci technique (mineur celui-là) sur mes serveurs chez Online, j’ai eu affaire à un service de qualité, tant en compétences techniques qu’en communication.
Comme quoi cela dépend beaucoup des interlocuteurs ; il y en a des décevant mais aussi des très bons.
Ouf, mes serveurs sont décidément bien gérés et mes fournisseurs bien choisis 🙂

Comptage d’impulsion – vue d’ensemble

Que ce soit pour la visualisation de la consommation d’eau en temps réel ou celle de la puissance électrique instantanée, le principe de base est le même :

archi

  1. Il y a d’abord un capteur qui fournit l’information recherchée sous forme d’impulsions électroniques.
  2. Un processus activé par interruption logicielle relève ces impulsions aussi vite que possible.
  3. Un autre processus stock tranquillement ces relevés d’impulsion dans une base de données.
  4. Un serveur web anime un mini site internet qui récupère les données et les transforme en informations présentées dans un navigateur.

Les impulsions sont fugitives ; il est important de ne pas les rater et de pouvoir mémoriser l’instant de leur occurrence aussi précisément que possible.

Naturellement, comme dans l’exemple indiquée dans un commentaire sur l’exemple de code pour l’étape 2, une solution simpliste consiste à enregistrer dans un fichier le nombre total d’impulsions comptées et la date et l’ heure de la dernière impulsion.

Cependant, c’est long, relativement à la brièveté d’une impulsion. Il faut en effet : ouvrir le fichier, lire la dernière valeur du compteur, recréer une nouvelle version du fichier avec la nouvelle valeur du compteur et la date et l’heure de la dernière impulsion. Si les impulsions sont trop rapprochées, on pourrait en rater. Par ailleurs, un décalage, d’une valeur plus ou moins aléatoire, s’introduit entre l’impulsion qui déclenche le traitement et le moment où l’heure est relevée.

En plus c’est pauvre : on ne conserve que le nombre total d’impulsions et la date de la dernière occurrence.

C’est pour cela qu’il est préférable de faire le traitement des impulsions en deux étapes : une lecture aussi rapide que possible (étape 2) puis, indépendamment et  sans contrainte de temps d’exécution, le stockage de chaque impulsion dans une base de données (étape 3). Ce traitement est fait à l’initiative de l’étape 4 et, en parallèle, il est aussi fait à intervalles réguliers. Ce qui permet d’avoir l’information la plus récente possible à afficher et éviter qu’un trop grand nombre d’impulsions ne s’accumulent avant d’être stockées en base de données si l’affichage n’est pas sollicité suffisamment souvent.

De plus, le stockage de toutes les impulsions dans une base de données ouvre la voie à de nombreux traitements et analyses.

Une histoire de bonne année !

Créée en 2008, l’EURL Barme a souhaité ses premier vœux de bonne année en 2009 :

BA2009A part le jeu de mot sur le siège social de l’EURL Barme qui avait bien plu, la photo paraît naïve vu de 2016. Le bureau est le même mais le local et le matériel ont bien évolués depuis.

En 2010, c’est la même photo mis à part le fond :

BA2010Ce projet d’aménagement a eu un beau succès (mais n’a pu être réalisé, hélas…).

En 2011, les vœux prennent une dimension plus technique avec une animation flash :

BA2011En 2016, le flash est en voie de disparition, officiellement pour des questions de sécurité, sans doute davantage pour écarter une potentielle concurrence avec les applications que l’on doit acheter en ligne.

En 2012, les vœux sont présentés par un mini site internet avec un lien cliquable sur une image “mystérieuse” :

BA2012Très peu de personne ont cliqué sur le lien : un bel exemple d’ergonomie perfectible !

En 2013, c’est à nouveau une animation, mais en HTML 5 :

BA2013Non seulement c’est toujours d’actualité mais c’est une technique d’avenir.

En 2014, les vœux sont intégrés dans le site Internet de l’EURL Barme :

BA2014La photo qui sert de fond est exceptionnelle : un arc en ciel depuis le phare du Jardin jusque sur le fort de la Conchée, aux approches de l’estuaire de la Rance. Elle est authentique en plus. Il est possible que l’originalité de cette photo ait échappé à quelques visiteurs.

En 2015 : rien ! Une très forte charge de travail a motivé une expérience intéressante : que se passe-t-il si on ne souhaite pas les traditionnels vœux de bonne année ? Et bien rien… tout va très bien.

En ce début d’année 2016, la charge de travail de l’EURL Barme est encore plus importante que l’année précédente. Mais les vœux de fin d’année sont une tradition alors la question est résolue une fois pour toutes avec le concept de vœux pour l’année en cours c’est à dire mis automatiquement à jour chaque année (le 2016 est dynamique) :

BA2016