Et ça continue pour Orange ! Après qu’une intrusion informatique avait permis de dérober les informations personnelles de 800 000 clients, fin janvier, c’est désormais une nouvelle attaque qui touche 1,3 millions de clients.

L’opérateur vient d’annoncer que le 18 avril dernier, sa plateforme technique d’envoi d’e-mail et de SMS, utilisée par l’opérateur pour l’envoi de messages commerciaux a été attaquée.

Ainsi, les adresses mail, numéros de mobile et de téléphone fixe et les dates de naissance des clients ont été récupérés. Cependant et fort heureusement, les coordonnées bancaires sont restées en sécurité.

En fait, il ne s’agit pas uniquement de clients Orange puisque cette base de données contient des coordonnées de personnes auprès desquelles l’opérateur souhaite prospecter, pour proposer de nouveaux services, afin d’obtenir de nouveaux clients justement.

Orange a contacté les personnes touchées par le problème et promet que les actions nécessaires ont été mises en oeuvre pour boucher les trous de sécurité.

I. Présentation

Cela est intéressant de pouvoir installer l’hyperviseur de Microsoft en VM pour effectuer des tests. Ce procédé s’appelle de la nested virtualization : de la virtualisation dans la virtualisation, dans notre cas on parlera plus précisément de nesting Hyper-V.

Pour ma part, j’utilise un PC sous Windows 8.1 avec VMware Workstation 10 installé, dans le but d’ajouter la fonctionnalité Hyper-V à une machine sous Windows Server 2012 R2.

Si vous tentez une installation sans effectuer de configuration adéquat de votre machine virtuelle, vous obtiendrez ce message :

II. Procédure

Après avoir fait face à ce message d’erreur, éteignez votre machine virtuelle proprement via le menu du système d’exploitation ou par le menu de VMware Workstation (clic droit sur la VM, Power, Shut Down Guest).

Nous devons modifier le fichier de configuration VMX de la machine virtuelle, ce dernier se trouve dans le répertoire de stockage de la VM. Vous devriez retrouver une arborescence comme ceci et le fichier .vmx :

Éditez ce fichier de configuration avec votre éditeur de texte préféré et ajoutez ceci à la fin du fichier :

hypervisor.cpuid.v0 = "FALSE"
mce.enable = "TRUE"
vhu.enable = "TRUE"

Le paramètre “hypervisor.cpuid.v0” lorsqu’il est actif indique à l’OS de la machine virtuelle qu’il est exécuté sur un environnement virtualisé. On le passe à FALSE pour que Windows Server ne se rende pas compte qu’il est virtualisé.

Le paramètre “mce.enable” permet de rendre actif le Machine Check Exception afin d’autoriser la machine virtuelle à rapporter des erreurs CPU. Enfin, “vhu.enable” permet d’activer le mode nested.

Une fois les modifications effectuées, sauvegardez le fichier de configuration. Ensuite, accédez aux paramètres de votre VM en effectuant un clic droit sur son nom dans VMware Workstation puis “Settings“. Accédez à la section “Processors” et cochez les deux options suivantes utiles pour le mode nested :

- Virtualize Intel VT-x/EPT or AMD-V/RVI

- Virtualize CPU performance counters

Validez. Votre VM est fin prête, il ne reste plus qu’à démarrer votre machine virtuelle et à effectuer l’installation d’Hyper-V !

J’en ai profité pour faire une procédure en vidéo :

Après la découverte du bug Heartbleed qui a fait beaucoup de bruit, c’est au tour du protocole DNS d’être ciblé et plus précisément du logiciel BIND. Pour rappel, il s’agit de la solution la plus utilisée pour la mise en place d’un DNS, tout en étant sous Linux.

Deux étudiants Israéliens, Roee Hay et Jonathan Kalechstein, qui travaillent sur un projet  à la faculté de Science informatique à Technion, ont découvert cette vulnérabilité.

Cependant, les étudiants n’ont pas fournit une explication détaillée à propos de la vulnérabilité. Ils ont quand même indiqué que l’exploitation du protocole DNS permet à un attaquant de rediriger les utilisateurs qui tentent d’accéder à un site légitime vers un site falsifié, contrôlé par les hackers. Bien sûr, le site falsifié est semblable au site légitime et porte le même nom.

Kalechstein précise “Nous sommes très surpris d’avoir trouvé une faille dans ce protocole“. Et il ajoute “Nous l’avons reporté aux autorités responsable de son implémentation, ils ont répondu ne pas être au courant de ce problème, et ajouté qu’ils remplaceront l’algorithme concerné dans la prochaine version de l’application“.

Les informations concernant cette faille n’ayant pas étaient divulguée, cela permet que la faille soit exploitée par de nombreuses personnes et de créer un second phénomène comme heartbleed.

Source

Je ne cesse de le répéter : mieux vaut empiler et déployer des choses simples plutôt que déployer une “usine à gaz” !

Pire : Mieux vaut utiliser et maîtriser un outil simple plutôt que d’essayer d’apprivoiser un “mammouth” !

De prime abord, ces deux affirmations paraissent un peu “bateau” et pourtant… Un projet “compliqué” est, par définition :

- long à spécifier,
- long a développer,
- long a tester,
- long à documenter,
- long à déployer,
- long à fiabiliser.

Et c’est pas fini… : Un projet compliqué consiste trop souvent à apporter 30 fonctionnalités aux utilisateurs finaux, alors que 10 seulement seront utilisées et quand il faudra en utiliser une parmi les 20 autres, bien évidement elle ne fonctionnera pas ! Croyez-moi ce ne sont pas les “gros” projets qui font avancer les entreprises car quand ils sortent enfin, ils sont déjà dépassés !

La faute à qui ?

La faute au DSI qui sur estime la capacité de l’entreprise a entreprendre de trop “gros” projets et qui se défausse trop souvent en disant : Eh, vous avez souhaité une Ferrari, je l’ai faite, cela a d’ailleurs coûté très cher, et ce n’est pas de ma faute si vous ne savez pas la piloter…

La faute au “métier” qui sur estime bien souvent sa capacité à s’approprier un projet de trop grande taille ou trop complexe et qui ne tardera pas à dire : Certes on voulait une Ferrari mais pour passer les dos d’âne et pour faire le marché ce n’est pas très pratique…et, bon dieu, qu’est ce que cela coûte cher à maintenir !

Mais au final, qu’est-ce qui compte pour le DSI d’aujourd’hui : Acheter du Windows 8.1, de l’Office 365, du Exchange (voire du Gmail…), du Sharepoint, du SAP, développer des usines à gaz, puis bien remuer et mettre le tout dans le cloud externe et rentrer chez soi en pensant : Eh ben si avec ça ils ne s’en sortent pas, j’aurai fait le maximum non ?

Euh…c’est ça le boulot du DSI ? Alors Zut ! Ce n’est pas vraiment ce que je fais…c’est même à l’opposé…du coup, je m’interroge et je me dit qu’ils ont peut-être raison ceux qui disent que le DSI est mort…

Mais alors, mon métier à moi, c’est quoi ?

Pour ceux qui utilisent le DHCP sous Windows Server, j’ai trouvé une page très intéressante pour vous ! Microsoft, sur son site Technet a publié une page qui référence tous les icônes d’états possible pour le rôle DHCP et la signification pour chacun d’entre eux.

Cette page évitera de rester face à un problème sans information à disposition alors que l’icône vous donnes déjà des informations primordiales dans le débogage d’un serveur DHCP.

Des informations sur différents icônes s’y trouvent : ceux du serveur, des étendues, des options, de bail mais aussi des icônes concernant la console de manière générale.

Lire l’article : Référence des icônes serveur DHCP