Archives mensuelles : juillet 2016

DirectAccess now supported in Azure virtual machines

Note : This post was updated on 11 of november 2016 due to recent change : DirectAccess No Longer Supported in Microsoft Azure

I was expecting this news for a while. Until a few days, DirectAccess was considered as unsupported scenario in Azure according to KB2721672. On the 14th of July this year, this KB was updated. The Remote Access feature is not longer listed as unsupported and appear in the supported features list But the DirectAccess Feature remain an unsupported scenario.

clip_image001

 

Hosting a DirectAccess infrastructure in Azure introduce a new way to build IT. Everyday that pass, the need to a local IT infrastructure is reducing. Soon, we could consider building a complete IT infrastructure hosted in Azure and connect computers to it using DirectAccess.

Dear, I have other wishes about DirectAccess :

  • ARM template to build a DirectAccess infrastructure in Azure (using a certificate located in Azure Keyvault of course)
  • Having DirectAccess as a VPN gateway scenario choice

 

Thank you for the news Richard and for the update.

­

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

C’est l’heure de la chasse au SHA1

La prochaine mise à jour de Windows 10 arrive à grand pas. C’est prévu à partir du 2 Aout 2016, tout le monde est au courant. C’est un process d’upgrade bien maîtrisé (on est tous passé par le programme Windows Insiders, …). Le problème, c’est qu’avec cette nouvelle Build, Microsoft a changé les règles pour les certificats. En même temps, ça devenait urgent. D’autres éditeurs comme Google ont déjà franchi le pas. SHA1 n’est plus considéré comme un algorithme de signature fiable. Le problème, c’est que cela ne concerne pas que Windows 10. Microsoft a mis le temps pour communiquer sur le sujet mais maintenant, c’est clair : An update to our SHA-1 deprecation roadmap. Le paragraphe ci-dessous est on ne peut plus clair :

This update will be delivered to Microsoft Edge on Windows 10 and Internet Explorer 11 on Windows 7, Windows 8.1 and Windows 10, and will only impact certificates that chain to a CA in the Microsoft Trusted Root Certificate program. Both Microsoft Edge and Internet Explorer 11 will provide additional details in the F12 Developer Tools console to assist site administrators and developers.

 

Une lecture de l’article Windows Enforcement of Authenticode Code Signing and Timestamping à la section Enforcement in general sera tout aussi claire :

clip_image001

 

Le véritable problème, ce seront Edge et Internet Explorer (pour toutes les versions de Windows supportées ) qui n’accepteront plus de reconnaître de certificats utilisant SHA1 comme sécurisés. Conclusion, je recommande vivement de partir à la chasse au SHA1. Le problème, c’est de les localiser le plus efficacement possible.

Pour vérifier si on a ce type de certificats, on va passer par PowerShell, c’est très simple. On commence par créer un objet contenant la liste des certificats contenus dans le magasin personnel de notre poste de travail de la manière suivante :

$Certs = Get-ChildItem cert:\LocalMachine\My

clip_image002

 

OK, on a quatre certificats dans le magasin personnel. Le problème, c’est que brut de fonderie, cela ne nous parle pas beaucoup.

clip_image003

 

Pour que cela nous parle, on a besoin de plus d’informations. Commençons par voir de quoi est composé un objet certificat dans PowerShell :

clip_image004

 

La liste contient des méthodes mais aussi des propriétés et il y en a deux qui nous intéressent.

clip_image005

 

La propriété « Subject » est ce qu’il y a de plus parlant pour désigner un certificat. Par contre brut de fonderie, le « SignatureAlgorithm » ne nous parlera pas beaucoup, à moins de savoir lire entre les lignes. Avec son « FriendlyName », c’est tout de suite plus compréhensible. Maintenant, on sait qu’on a un mauvais SHA à chasser.

clip_image006

 

Ne reste plus qu’à voir à quel certificat cela correspond.

clip_image007

 

C’est un auto-signé. Maintenant, avec un peu plus de détails on retrouvera peut être l’application concernée :

clip_image008

 

Le plus moche dans mon cas, c’est que ce certificat a été généré sur mon poste pour installer Visual Studio 2015. Donc même avec les dernières versions des outils Microsoft, on n’est pas à l’abris de ce type de surprise.

Si on est capable de réaliser l’opération localement, on doit pouvoir faire de même en PowerShell Remoting si on a pensé à activer et sécuriser correctement le protocole.

OK, donc avant de procéder à la mise à niveau vers Windows 10 update anniversary 2016, faudra commencer par traiter les applications qui utilisent toujours des certificats SHA1. Pour une approche plus industrielle de la recherche, je vous recommande ce script publié sur le Script Center : SHA1 Certificate Signature Check (Updated)

Si le certificat incriminé a été délivré par votre autorité de certification interne, c’est qu’il faudra envisager une migration vers SHA2. Je conseille alors la lecture d’un ancien billet : ADCS, quick and dirty et conséquences.

­

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

A quoi ça sert de locker ses ressources dans Azure?

La notion de Lock existe depuis un certain temps, pourtant, c’est en voyant sa disponibilité dans le portail Azure que je me suis dit que ce serait intéressant d’écrire un billet sur le sujet. Globalement, l’idée est de pouvoir verrouiller des ressources, un ensemble de ressources (groupe de ressources) ou même carrément une souscription de manière à ce qu’aucune opération de modification ne puisse être réalisée tant que le lock est présent. Pendant un déploiement, cela a du sens (éviter les conflits entre plusieurs opérations menées en parallèle). Pour moi, cela permet aussi d’éviter les erreurs fatales ou le scénario « Dédé fait du Cloud Computing ».

Imaginons un scénario dans lequel notre système d’information a basculé dans le cloud, que nous sommes capables de travailler en déploiement continu, un monde presque parfait. Avec les templates ARM, on est sur une approche d’intégration continue, on modifie son template, on teste son déploiement pour valider qu’il fonctionne puis on recommence. Pour cela, on a pris l’habitude de supprimer le groupe de ressources contenant nos ressources. C’est bien mais le problème, c’est qu’avec le temps se créé des dépendances invisibles. Dans l’organisation de notre souscription, il y a des ressources qui seront liées à la sécurité ou au réseau. Ce sont des ressources communes qui seront consommées dans d’autres groupes de ressources (quelle machine virtuelle n’a pas besoin de connectivité réseau ?). Supprimer et redéployer une machine virtuelle n’est pas risqué. Par contre si on supprime le groupe de ressources dédié aux ressources réseau, c’est beaucoup moins marrant. Imaginez qu’on réponde oui à la question suivante, juste par habitude de ne plus lire le message d’avertissement ?

clip_image001

C’est pour éviter ce type de scénario qu’on a inventé la fonctionnalité de verrouillage de ressources dans Azure. Si on a utilisé la fonctionnalité Lock, on aura la réponse suivante :

clip_image002

Si on clique sur le message, on sera amené à l’interface de gestion des locks. On découvre que même si j’ai tous les privilèges sur mon groupe de ressources (genre je suis le propriétaire), ben j’ai quand même un garde-fou qui va me rappeler que je vais peut-être faire une connerie.

clip_image003

Là, normalement « Dédé » (nous l’appelons Dédé pour ne pas dévoiler son identité) devrait se dire qu’il vient d’éviter de faire une superbe connerie. Des machines virtuelles sans connectivité réseau, ça perd quand même beaucoup de son intérêt. Si Dédé décide de s’acharner, et de passer en PowerShell, il y passera un peu de temps avant de comprendre la nature de son problème.

clip_image004

La fonctionnalité a quand même une limite. Si Dédé a les permissions suffisantes sur la ressource, le groupe de ressources ou la souscription, il peut supprimer le lock. Par contre, dans les logs, on aura la trace qu’il a délibérément décidé de se tirer une balle dans le pied. Le scénario « Dédé fait de l’Azure » est pour moi le meilleur cas d’usage du verrouillage de ressources.

Maintenant, voyons comment cela fonctionne et ce que propose le module PowerShell AzureRMresources :

Get-command -Module AzureRM.Resources -Name « *azurermresourcelock »

clip_image005

C’est donc assez simple. Vu que je viens de tenter de supprimer un groupe de ressources RGNetwork, on devrait trouver la trace de notre Lock avec Get-AzureRMResourceLock

clip_image006

Globalement, il est indiqué qu’il est interdit de supprimer le groupe de ressources. Le seul moyen de le supprimer, c’est de supprimer le verrouillage avant. Maintenant, voyons comment on a pu en arriver là en créant le lock avec la commande New-AzureRmResourceLock.

New-AzureRMResourceLock -ResourceGroupName « RGNetwork » -LockName « NetworkTeam » -LockNotes « Pense y deux fois avant de continuer, … » -Locklevel CanNotDelete -Force

clip_image007

Remarque : Aujourd’hui, on ne dispose que de deux types de Lock : Read-Only, CanNotDelete.

Après, on peut être plus fin et de verrouiller qu’une ressource particulière. D’un point de vue sécurité, la disparition de mon coffre-fort numérique contenant toutes mes clés et secrets serait plus que préjudiciable à notre ami Dédé.

 

Conclusion

Le Resource Locking est un bon moyen pour éviter les erreurs. Pour moi, une équipe qui ne verrouille aucune de ses ressources peut signifier plusieurs choses :

  • Elle n’a peur de rien, tout du moins jusqu’à ce que le pire survienne
  • Elle a évalué les risques et ce type de scénario ne surviendra jamais (jusqu’à ce que le facteur Dédé survienne)

Bref, pensez à Locker vos ressources, ça peut vous sauver la vie et le job de Dédé

­

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)