A few weeks ago a client asked me: "Hey, can you please create a dev machine on our POC account, we want an internet-facing server with RDP opened on port 3389 for a small test and an RDS Database connected to it, just go simple, ClickOps to test out something"

I immediately said: Careful RDP is typically a target port, and you should use AWS SSM (AWS Systems Manager) to access the machine, you can even enable RDP through session manager by configuring a proxy on the localhost if needed.

No no, that's too complicated, this is just for a few days, then we kill the machine.

Long story short, the machine stayed running and they assumed this was already production ready... Clients...

A few days in, this message came out of the blue, thanks GuardDuty once again saving the day.

Hello.

We recieved the following GuardDuty Alarm.

94.232.42.99 is performing RDP brute force attacks against i-XXXXXXXXXX.","description":"94.232.42.99 is performing RDP brute force attacks against i-XXXXXXXXXX. Brute force attacks are used to gain unauthorized access to your instance by guessing the RDP password.
UnauthorizedAccess:EC2/RDPBruteForce
Resource affected
Resource role TARGET
Resource type Instance
Port 3389
Port name RDP

Instance details
Instance ID i-XXXXXXXXXX (XXXXXXXXXX_dev)
Instance type t3.medium
Instance state running
Availability zone eu-west-1a

If we check the Security Rules for this Instance, it showsthat Port 3389 is open for the world.
This Alarm reocures every few days.
Is it necesary for this port to be open? Can we regulate Acces with a Whitelist (IP based) or can it be closed?
If nothing of the suggested solutions is aplicable, can we block this kind of alarm to minimized unnesecary communikation?

A malicious IP was brute forcing the RDP port of the machine and it was a matter of time until they eventually got access to the machine. If it was not for GuardDuty we could not have noticed the issue until it was too late and someone gained access to the infrastructure and did all the possible damage.

Thanks to GuardDuty I immediately called the client, hey this is happening, do you wanna try SSM now?

The answer was... ah not really, what's the other options?

Well, don't whitelist this port to the world (0.0.0.0/0) at least have a single public IP able to target the port and restrict the security group on this port to a /32.

Ok, but this is an external consultant company, we want them to update the IP when they access it, but not touch the rest of the infrastructure.

No problem, AWS IAM Policy to the resque.

Create a user, create, create a prefix list, associate the prefix list to the security group, and create a policy to allow the user to update only its prefix list and nothing else.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "ec2:GetManagedPrefixListAssociations",
                "ec2:GetManagedPrefixListEntries",
                "ec2:ModifyManagedPrefixList",
                "ec2:RestoreManagedPrefixListVersion"
            ],
            "Resource": [
                "arn:aws:ec2:eu-west-1:ACCOUNT_ID:prefix-list/pl-XXXXXXXXX"
            ]
        },
        {
            "Effect": "Allow",
            "Action": "ec2:DescribeManagedPrefixLists",
            "Resource": "*"
        }
    ]
}

15 minutes later, the RDP port was at least closed to a single IP and reduced the security vector to a minimal target. I still believe that the best way is just to not open ports to the internet and use AWS SSM, but I'm not scared this machine will be a target anymore.

I also sleep well knowing that AWS GuardDutty has my back covered 24 hours per day and will probably email me in case something is about to go wrong. Thanks, AWS for making my life on the internet much easier.