La gestion des connexions RDP sur une EC2 Amazon

mercredi, décembre 12, 2018
By Emmanuel RAMI in AWS (erami@capdata-osmozium.com) [3 article(s)]

 

Cet article va décrire les différentes actions liées aux accès RDP sur une VM Amazon EC2.


Dans une première partie, nous verrons comment réinitialiser le port RDP d’une EC2 Amazon si jamais le port 3389 a été changé et n’est plus accessible

Puis nous verrons comment changer le numéro de port RDP via l’interface Amazon.
Les différentes actions pourront être effectuées via la console Amazon AWS, ou bien via le programme AWS CLI interpréteur de commandes.

 

 

Reinitialiser une connexion RDP

 

Prenons un exemple concret, vous souhaitez changer le numéro du port RDP, par mesure de sécurité, afin d’éviter de passer par le 3389.

Premier réflexe, vous irez directement dans la base de registre afin de changer l’entrée et choisir un nouveau port (exemple 3007) : 

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp

En revanche, une fois la modification validée, et si par malheur vous n’avez pas changer les règles Firewall … vous tenterez une reconnexion RDP avec ce nouveau port, et la, c’est le drame ….



Comme vous n’avez pas changer les règles Firewall, celui ci vous empêchera de communiquer via ce nouveau port, et il vous sera impossible de rentrer sur la VM (c’est un oubli qui arrive, y compris chez les meilleurs !)

Afin de résoudre ce problème, Amazon a prévu une solution qui passe par un service AWS appelé Service System Manager (SSM).
Par défaut, chaque AMI généré via Amazon possède un agent SSM sur sa template AMI.
En revanche, il ne faudra surtout pas oublier de l’installer sur une nouvelle VM issue d’une migration ESX par exemple.

Cet agent va nous permettre d’agir en mode ‘console’ sur notre EC2, et nous permettra de lancer certaines fonctionnalités intéressantes.
Ici, on s’appliquera à réinitialiser le port RDP 3389. On pourrait tout aussi bien désactiver le Firewall via l’agent également.

Prérequis

Afin de pouvoir gérer cette instance via la System Manager, il faudra la déclarer comme ‘instance gérée’.

Pour cela, il sera primordial de créer un rôle pour utiliser SSM. Cette première phase pourra se faire via la console AWS , service IAM :

On créera un nouveau rôle auquel on affectera la stratégie :
AmazonEC2RoleforSSM

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ssm:DescribeAssociation",
                "ssm:GetDeployablePatchSnapshotForInstance",
                "ssm:GetDocument",
                "ssm:GetManifest",
                "ssm:GetParameters",
                "ssm:ListAssociations",
                "ssm:ListInstanceAssociations",
                "ssm:PutInventory",
                "ssm:PutComplianceItems",
                "ssm:PutConfigurePackageResult",
                "ssm:UpdateAssociationStatus",
                "ssm:UpdateInstanceAssociationStatus",
                "ssm:UpdateInstanceInformation"
            ],
            "Resource": "*"
        },

 

ce rôle ainsi créé sera alors à attribué aux VM EC2 que l’on souhaite faire gérer par SSM. A noter que depuis peu, nous pouvons attacher ce rôle dans les paramètres de l’instance, y compris lorsque l’instance est déjà créée.

Nous pouvons également choisir ce rôle lors de la création de l’instance EC2 à la seconde page lors du choix de la couche réseau.

On selectionne notre VM, puis Actions, Paramètres de l’instance et Attacher le rôle IAM
Une liste déroulante nous permettra de choisir notre rôle RoleSSM que l’on prendra.

Notre EC2 est maintenant prise en charge par Service System Manager.

Attention, sur AWS, je n’ai pas réussi à configurer ce service pour une instance sur un subnet privé. Seules les instances d’un subnet publique, comportant une IP publique, semblent fonctionner.

Il faudra donc, temporairement, changer les règles Security Groups  de l’instance, ou bien la copier dans un subnet publique (créer un image -> regénérer une instance EC2 dans un subnet publique).

 

Réinitialisation


On ira vérifier en navigant dans les services AWS afin de choisir SSM :


Entrer dans le menu “Instances gérées”

Notre instance est alors reconnue. A noter que l’instanceId est référencée:

En cliquant sur le bouton Actions, un menu déroulant apparaît dans lequel nous pourrons effectuer diverses actions, comme ouvrir une session CMD, lancer une commande via un invite. Ce qui nous intéresse est “Exécuter l’automatisation” :

Un choix de documents json sera alors présenté afin de valider l’action que nous pourrons mener sur cette instance. Naviguer dans les différentes pages afin de choisir le document ‘TroubleshootRDP”

On cliquera sur ce document qui nous sera alors décrit, puis on laissera la version par défaut afin de revenir au paramètre initial.

L’étape suivante consiste à choisir notre instanceId sur laquelle sera exécuté ce document d’automatisation.

Choisir l’option souhaitée, dans notre cas nous pourrons soit désactiver le Firewall :

Ou bien reprendre le port 3389 par défaut pour RDP

Une fois le choix effectué, on cliquera sur Execute



L’exécution sera gérée via l’ordonnanceur

Vérifier que tout s’est correctement passé

A la prochaine connexion, via RDP, sur notre serveur, si le port 3389 a été remis par défaut et/ou si le Firewall a été désactivé :


Enjoy !!

 

Commande via AWS CLI

On pourra tout aussi bien utiliser l’utilitaire AWS CLI pour effectuer cette opération. A noter que la configuration d’un compte avec les droits adequats devra être effectué. 

Pour désactiver le FireWall :

"aws ssm start-automation-execution --document-name "AWSSupport-TroubleshootRDP" --parameters "InstanceId=INSTANCEID,Firewall=Disable" --region REGION"

Exemple pour notre instance, à Paris (code région eu-west-3)

"aws ssm start-automation-execution --document-name "AWSSupport-TroubleshootRDP" --parameters "InstanceId=i-00e36ea8009dffb61,
Firewall=Disable" --region eu-west-3"

Pour changer le port RDP et remettre le 3389:

"aws ssm start-automation-execution --document-name "AWSSupport-TroubleshootRDP" --parameters "InstanceId=INSTANCEID,RDPPortAction=Modify" --region REGION"

Soit 

"aws ssm start-automation-execution --document-name "AWSSupport-TroubleshootRDP" --parameters "InstanceId=i-00e36ea8009dffb61, RDPPortAction=Modify" --region eu-west-3"

 

 

 

Changer le port RDP de connexion

Nous allons voir dans ce paragraphe comment changer le port RDP de notre connexion sur notre instance EC2.

Prérequis

/!\ /!\ Il est évident qu’il faudra avant tout, gérer la problématique du FireWall avant de changer ce port. Nous choisirons, soit de le désactiver, le temps de faire l’opération, et ajouter une règle sur ce nouveau port à la fin, soit de déclarer ce port dès le début.
On déclare une nouvelle entrée, sur le FireWall, pour le port 3007 par exemple :

L’ajout de ce port se fera dans les options avancés

Créer une nouvelle règle basée sur un port

Par exemple le port TCP 3007



Appliquer pour tous les domaines



Vérifier que cette règle est bien active 

A partir de la, nous avons donc ouvert le port 3007 pour cette instance EC2 depuis l’extérieur.

La suite de la procédure se déroulera via Service System Manager. Comme pour le paragraphe précédent, les actions seront à mener sur SSM en prenant en considération les prérequis en terme de rôle SSM, afin de définir notre instance comme instance gérée.

Le document à choisir dans SSM est 
AWSSupport-ManageRDPSettings

Comme pour le 1er paragraphe, nous passerons par l’étape du choix de l’instanceID, Actions et Exécuter l’automatisation :

L’étape suivante nous permettra de définir le nouveau port RDP, soit le 3007, que nous appliquerons à cette instance:

On vérifie également la bonne exécution de cette opération :




Il est également possible d’utiliser AWS CLI pour cette opération, s’il l’on prend exemple sur notre instanceId ci dessus :

"aws ssm start-automation-execution --document-name "AWSSupport-ManageRDPSettings" --parameters "InstanceId=i-00e36ea8009dffb61, RDPPortAction=Modify, RDPPort=3007" --region eu-west-3"

 

Il nous restera à valider la modification :

N’hésitez pas à laisser vos commentaires 

Emmanuel RAMI

Continuez votre lecture sur le blog :




Cliquer pour partager cet article sur Viadeo
Cliquer sur "CAPTURER" pour sauvegarder cet article dans Evernote Clip to Evernote

Tags:

Leave a Reply