Archives de catégorie : Architecture

Sécuriser son exposition RDP Internet Azure

Voilà un problème que je rencontre souvent chez mes clients, les Vm Azure accessible librement sur Internet. Il faut comprendre une chose, les adresses IP Azure sont connues (référence fichier XML mis à jour chaque semaine : https://www.microsoft.com/en-us/download/details.aspx?id=41653), donc scanner les ports RDP, c’est tout ce qu’il y a de plus simple.

Généralement, on en trouve la trace dans Azure Log Analytics. La première piste, c’est la présence de nombreux events 4625 avec la requête suivante :

SecurityEvent | Where (EventID == 4625) | Summarize Count() By TargetAccount

Nous en avons un exemple ci-dessous. A une période donnée, une machine virtuelle a été exposée directement sur Internet.

clip_image001

 

De ce qu’on constate dans l’illustration ci-dessous, il y a eu beaucoup de tentatives infructueuses pour le seul compte Administrator. Presque 10 000 tentatives en moins d’une semaine. Voilà le premier effet kiss-cool d’une machine virtuelle librement exposée sur Internet. Le second et il est moins drôle, c’est qu’on constate aussi d’autres tentatives en ciblant des comptes plus génériques. Avec un compte comme Helpdesk, un attaquant aurait certainement moins de privilège que « Administrator » mais il a plus de chance que ce compte soit partagé par un plus grand nombre d’utilisateurs qui d’un commun accord auront choisi un mot de passe beaucoup moins stricte, pire ne pas imposer une politique de renouvellement.

Pas encore convaincu ? OK, disons maintenant que vous avez mis en œuvre l’Azure Security Center en plus de Log Analytics pour cette machine virtuelle, comment considère t’il la chose avec la requête suivante : SecurityDetection | Where (AlertTitle == « Failed Brute Force Attack »)

clip_image002

 

Du point de vue de Security Center, cette accumulation d’event 4625 n’est rien d’autre qu’une attaque de type brute force RDP. Heureusement pour le cas illustré ci-dessus, ce n’est qu’une attaque qui a échouée, … Si elle a échoué, n’y aurait-il pas des attaques qui ont-elles réussies ? Posons la question: SecurityDetection| where ( AlertTitle == « Successful RDP brute force attack » )

clip_image003

 

Houston, we have a fucking problem. C’est le cas de le dire. Cependant, ce qu’il faut comprendre avec cet évènement, c’est qu’au milieu du flot de tentatives d’authentifications infructueuses, il y a aussi les accès légitimes. Le problème, c’est comment ne pas considérer la chose suspecte, si un compte est compromis, l’accès à la machine virtuelle devient possible.

 

Problème, comment identifier un compte qui aurait une activité suspicieuse ? Dès lors qu’un attaquant dispose d’un accès dans un système d’information, la première tâche après avoir validé la persistance de l’accès, c’est de passer en mode de recherche de cibles à haut potentiel. Ici encore, l’Azure Security Center est capable d’identifier des comportements douteux. Imaginons qu’après de multiples tentatives, un attaquant ait réussi par un moyen ou un autre à découvrir le mot de passe de mon compte utilisateur.

SecurityDetection | Where (AlertTittle == « Suspicious Process Execution Activity Detected »)

clip_image005

 

Que je me logge sur un serveur, normal. Que j’utilise ce type de commande aussi vieilles que Windows for Workgroup 3.11, c’est douteux (PowerShell & VBScript fan Boy). Voilà de bonnes raisons pour ne pas exposer ses machines virtuelles Windows directement sur Internet. Sans Log Analytics couplé à Security Center, difficile de savoir qu’on est dans ce type de situation. Avec l’arrivée cette année de la GDPR, voilà comment je justifie l’investissement dans ces deux produits :

  • Voir vos données compromises est un risque pour l’entreprise
  • Chaque incident de sécurité avéré coutera jusqu’à 4% du CA de l’entreprise

Azure Security Center et Log Analytics ne sont pas des solutions magiques (compliance GDPR) mais au plus tôt on est capable d’identifier une situation à risque, au plus tôt l’équipe sécurité est capable de réagir. Azure Security Center est capable de vous avertir que vous avez une machine virtuelle Windows / Linux qui est exposée en direct sur Internet avec RDP / SSH en Open Bar. Après, il vous faut un peu de process (s’il n’y a personne pour lire les recommandations d’Azure Security Center, je ne peux rien pour vous)

Alternatives

Exposer une machine virtuelle Windows ou Linux sur Internet n’est clairement pas une bonne idée. Si vraiment, vous en avez besoin, voilà quelques idées pour remédier au problème.

  • Changer le port RDP
  • Azure Load Balancer
  • Tunnel IPSEC
  • Un peu de bricolage
  • Just in time Access (Preview)
  • Bastion (RDS)

 

Changer le port RDP

Autant le dire tout de suite, c’est une solution « Low-cost ». Elle va effectivement réduire le volume d’attaque. Le problème, c’est qu’on a tendance à utiliser des noms « parlants » pour désigner nos machines virtuelles. Donc si on a une réponse pour l’host bastion ou dmz, en scannant les ports pour l’IP, l’attaquant trouvera assez facilement le nouveau port RDP d’exposition. Si le sujet vous intéresse, je vous conseille la lecture du billet suivant : Change the default RDP port (3389) on a Azure Windows ARM VM to a high range port. Après, faudra aussi adapter votre règle au niveau des Network Security Groups.

 

Azure Load Balancer

Disons que c’est un peu moins « Low cost » mais pas top quand même. Avec cette solution on masque plusieurs expositions RDP (ou même SSH) derrière un Azure Load Balancer. Pour chaque exposition, nous devons créer une règle de NAT comme illustré ci-dessous :

Le premier problème de RDP/SSH, c’est que le port est connu. La première approche est donc de changer ce port. C’est ce que nous propose Azure Load Balancer. Avantage, une seule adresse IP publique permet d’exposer un grand nombre de machines virtuelles, aussi bien RDP que SSL.

clip_image006

 

De mon point de vue, on ne fait que masquer le problème.

 

Tunnel IPSEC

La on commence à traiter le problème. On impose l’établissement d’un tunnel IPSEC entre le client RDP et la machine virtuelle dans Azure. Le bon établissement du tunnel IPSEC nous garantit que le client à l’autre bout est bien celui qu’il prétend puis qu’il dispose d’un mécanisme d’authentification. De mon point de vue, on commence à traiter le problème. Pourtant cette solution a aussi sa faiblesse. Une implémentation bâclée d’IPSEC utiliserait une clé pré-partagée. Or si tous les utilisateurs partagent la même clé, cela devient difficile d’en isoler un pour le bloquer. Cela implique donc une clé d’authentification propre à chaque utilisateur (certificat client par exemple).

 

Un peu de bricolage

C’est une trouvaille un peu par hasard : Good news everyone! We are under brute force attack!. Si votre machine virtuelle doit nécessairement être exposée sur Internet, il faut au moins pouvoir se défendre en bloquant les adresses IP. Sa solution est intéressante et propose même le reporting dans Log Analytics et la visualisation dans PowerBI. Bref, je like.

clip_image007

 

Just in Time Access (Preview)

Si le besoin d’exposer le RDP est avéré, il n’est peut-être nécessaire que l’exposition soit permanente. Une approche serait de procéder à l’ouverture uniquement lorsque le besoin est nécessaire. Voilà une approche intéressante. C’est la solution proposée dans Azure Security Center avec l’option Just-in time Access.

Attention, cela impliquera un pricing standard et non free (donc un coût par machine virtuelle). Pour chaque machine virtuelle, nous pouvons configurer la liste des ports qui seront ouverts. Pour une machine virtuelle Windows, c’est donc du RDP en TCP et UDP (oui oui, il n’y a pas d’erreur) qui sera mis en œuvre « à la demande ». Ce qui est intéressant, c’est que l’ouverture demandée ne sera réalisée que pour l’adresse IP « source » et pendant une durée de vie limitée.

clip_image008

 

Une fois la configuration en place, on peut demander notre ouverture des flux avec le bouton « Request Access ».

clip_image009

 

Dans le cas ci-dessous je demande l’ouverture du flux RDP pour mon adresse IP pour une durée de vie d’une heure seulement.

clip_image010

 

De retour, nous pouvons constater qu’une requête d’ouverture de flux est bien en cours pour un utilisateur donné.

clip_image011

La fonctionnalité semble plus qu’intéressante, reste à voir comment serait proposé des mécanismes comme l’approbation des requêtes par des administrateurs. Au moment d’écrire ce billet, la fonctionnalité Just in time Access est encore en Preview.

 

Bastion (RDS)

Cette approche implique l’utilisation d’un point d’accès unique qui sera utilisé comme référence IP pour les machines exposées. Ce qui est bien, c’est que Windows embarque cette technologie depuis Windows 2008 : RDS Gateway. Donc on a juste besoin de licences CAL RDS. La on commence réellement à adresser le risque :

A ce jour, c’est l’approche la plus complète. Encore pour cela qu’on s’attarde un peu sur le hardening de la RDS Gateway. La mise en place d’un équipement d’analyse de flux (IDS) est plus que recommandée.

 

Conclusion

Voilà, vous n’avez plus d’excuse pour continuer à laisser vos RDP exposés librement sur Internet. Pour finir, faites attention à ne plus provisionner inutilement d’adresse IP publique pour vos machines virtuelles déployées via le portail. Juste une case à cocher.

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