8,90 € TTC
p. 06 Le code est mort, vive le code !
p. 08 Scikit-image, une alternative à OpenCV pour la reconnaissance d’images
p. 22 Mesure fine de déplacement par RADAR interférométrique à synthèse d’ouverture (InSAR) par radio logicielle
p. 34 Accélérez vos traitements en développant votre propre solution de parallélisation
p. 50 L’édition des liens démystifiée
p. 68 Des usages de l’astérisque en Python
p. 72 Distribuez vos traitements Python avec Celery et Docker Swarm
Un passage en production, ça se planifie. Je ne vais pas vous parler dans cet édito des développeurs pour qui la production n’existe pas vraiment puisque leurs environnements de développement et de production ne font qu’un : leur cas est désespéré. Non, je vais vous parler des développeurs consciencieux qui travaillent normalement en développant et testant sur leur environnement de développement avant de passer en production. Il peut arriver, au moment de la bascule, que surviennent encore des erreurs. Cela peut être anticipé de manière à s’assurer que l’impact soit le plus faible possible pour les utilisateurs. Avec les bugs c’est comme avec les virus : au plus on teste au plus on a de chances statistiquement parlant d’en trouver un ! Mais que se passe-t-il lorsqu’il n’y a pas de synchronisation avec le service commercial, que le logiciel ou le site est passé en production alors qu’aucun test n’a été effectué, mais que la campagne marketing est lancée ? Un beau raté !
Quelques minutes avant d’écrire cet édito, j’ai reçu un mail m’informant qu’un site (dont je préfère taire le nom) avait mis à jour ses C.G.U. (Conditions Générales d’Utilisation) et que pour pouvoir continuer à utiliser les services proposés, je devrai les accepter. Pour cela, on me proposait même d’accéder directement à mon compte via un bouton. Plutôt que d’attendre d’avoir besoin d’un quelconque document via ce service, j’ai décidé d’accepter les C.G.U. immédiatement. Je clique donc sur le bouton, la page se charge dans mon navigateur et là s’affiche l’image d’un ourson mal en point qui m’annonce : « Oups… votre compte xxxxx est momentanément indisponible. Il sera de retour en pleine forme très bientôt ». Ça, c’est ce qu’on appelle une synchronisation parfaite ! On propose quelque chose aux utilisateurs, les faisant venir sur le site, mais la page cible ne fonctionne pas ! Chapeau bas !
On ne s’en rend pas toujours compte, mais dans la mise à disposition d’un logiciel ou d’un service, il n’y a pas que les aspects techniques qui comptent. Comment ne pas s’assurer qu’un service est disponible avant d’en faire la promotion ? Il n’y a pas besoin d’être développeur pour ça ! Il suffit d’un minimum de communication entre deux services qui sont censés œuvrer dans la même entreprise avec des objectifs communs.
En tout cas je peux vous annoncer la sortie de GNU/Linux Magazine n°244 sans risque, tous les articles sont à votre disposition !
Tristan Colombo
GNU/Linux Magazine s'adresse aux professionnels et aux particuliers désireux de mieux maîtriser les techniques et problématiques liées à la programmation et à l’utilisation de solutions open source. Tous les deux mois avec ses articles techniques, la publication couvre les thématiques suivantes : programmation système, algo, bas niveau, sécurité du code, développement web...

Les dénis de service sont un sujet récurrent. Cependant peu nombreux sont ceux qui y croient réellement.
Le Domain Name System (ou DNS, système de noms de domaine) est un système permettant d'établir une correspondance entre une adresse IP et un nom de domaine et, plus généralement, de trouver une information à partir d'un nom de domaine (cf. Wikipédia).
Bien que l'attaque la plus intéressante contre une plate-forme de VoIP soit celle où l'on intercepte une communication, ce n'est généralement pas l'attaque la plus simple à réaliser (à moins bien sûr d'être sur le chemin ou de pouvoir facilement contrôler une des parties). Le risque qui engendre le plus de cheveux gris pour une équipe sécurité est de rendre la plate-forme résistante face aux dénis de service. Au cours de cet article, nous allons décrire quels sont les challenges pour sécuriser une telle plate-forme, et tout particulièrement comment l'optimisation de la disponibilité de la plate-forme la rend plus vulnérable. Les éléments-clés d'un déploiement qui sont les plus exposés sont bien évidemment le SoftSwitch (ou P-CSCF en terminologie IMS) qui va gérer les communications, le SBC (Session Border Controller) qui gère et régule l'accès au SoftSwitch depuis l'extérieur (les clients), ainsi que les MGW (Media Gateway) qui connectent le nuage VoIP avec le réseau téléphonique traditionnel (RTC). Nous allons étudier quelles attaques sont les plus courantes à l'encontre de ces équipements et quel est leur rôle côté protection.