
Automate Security: Lock Down Microsoft Windows Remote Access with AWS Systems Manager State Manager
This blog post explores how to use AWS Systems Manager State Manager to enforce remote access security policies on Microsoft Windows EC2 instances by automatically blocking RDP and SSH. It demonstrates how to create custom SSM Documents, configure State Manager associations, and leverage AWS resource tags for continuous policy enforcement.
- You might ask, 'Why don't we just block RDP using AWS Security Groups? Well, you should and can, but the idea here is that we are creating a declarative policy on the instance itself. If an administrator decided they wanted to RDP into the server, created a Security Policy that allowed 0.0.0.0/0, and also removed the Windows Firewall rule blocking RDP access, they could now log in to the instance.
- With State Manager in place, at the next scheduled association (default is every 20 minutes), a new Windows Firewall rule would be recreated to block RDP access. With this design in place, even if the security group with 0.0.0.0/0 was accidentally left open, external users or bad actors would not be able to RDP to the server.
- Custom SSM Document – Defines the automation logic to disable SSH/RDP via Windows
- Create a State Manager Association – Binds the document to targeted instances, executing on a defined schedule.
- Instance Targeting – Uses AWS tags or dynamic instance selection to apply policies selectively.
- If you want to be able to use Systems Manager and this blog with your on-premises or other no EC2 Windows Instances you will first need to set this up in Systems Manager.
- Ensure you have met the requirements to Manage EC2 Instances with Systems Manager
- Navigate to the SSM Console Page .
- Select Documents from the left-hand menu.
- Select Create Document, Command, or Session
- Give the document a unique name that you can reference later (I have used DisableRDPandSSH), Document Type can be left as Command.
- In the Content section, enter in your PowerShell script. I have used the following script, please check that this meets your requirements. Click Create new version.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
{
"schemaVersion": "2.2",
"description": "Block RDP (3389) and SSH (22) via Windows Firewall using AWS Systems Manager",
"mainSteps": [
{
"action": "aws:runPowerShellScript",
"name": "BlockRDPandSSH",
"inputs": {
"runCommand": [
"# Block RDP (port 3389) in Windows Firewall (Persistent)",
"New-NetFirewallRule -DisplayName 'Block RDP' -Direction Inbound -Protocol TCP -LocalPort 3389 -Action Block",
"# Block SSH (port 22) in Windows Firewall (Persistent)",
"New-NetFirewallRule -DisplayName 'Block SSH' -Direction Inbound -Protocol TCP -LocalPort 22 -Action Block"
]
}
}
]
}
- Navigate to the SSM Console Page .
- Select State Manager.
- Select Create Association.
- Give the Association a Name, I have used DisableRDPandSSH
- Select the Document that you created in the previous section, if you have created multiple versions of the document you can choose the version you would like to run, or just select the default.
- Select a Target Selection. I have selected an individual instance, but if you are using tags, resource groups, or want to apply this to all your instances, you can select the method that meets your requirements.
- Finally, set a schedule that meets your requirements. I have left the schedule as the default CRON schedule builder, which applies the association every 30 minutes. Select Create Association
- RDP to the Target Machine. As expected, this fails due to the State Manager configuration.
- Navigate back to the SSM Console Page .
- Select Fleet Manager from the menu
- Once in Fleet Manager, find and select an instance to which you have applied the State Manager association
- Select Node Actions > Connect > Connect with Remote Desktop
- Input your user credentials (this can be either local or domain credentials if the instance is part of a domain)
- Success! You should now be connected to your selected instance.
Any opinions in this post are those of the individual author and may not reflect the opinions of AWS.