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.
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 :
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 :
- Export d’une VM d’un ESX vers une EC2 AWS (Emmanuel RAMI) [AWS]
- AWS RDS : les extensions PostgreSQL (Emmanuel RAMI) [AWSPostgreSQL]
- AWS : Backup Restore SQL Server RDS vers une EC2 ou On-Premise et vice versa ! (Emmanuel RAMI) [AWSSQL Server]
- AWS Oracle RDS Read Replicas : un Active Dataguard en mode PaaS ? (Emmanuel RAMI) [AWSNon classéOracle]
- AWS : Configurer un cluster PostgreSQL HD avec Corosync/Pacemaker sur des EC2 Amazon (Emmanuel RAMI) [AWSPostgreSQL]