AWS RDP Scanning
I came across a great post from Joseph Wood at HP last week, on the recent dramatic increase in RDP scanning in AWS — specifically scanning of the RDP port. Down in the comments someone asked, “Why anyone would allow port 3389 from the Internet?” That seems to be a very salient question, no?
The first thing to know is that AWS leaves the RDP port open when configuring a new instance from the console (this issue is broader than just Amazon, as you’ll see below, but we’ll focus on AWS):
This is another example of a simple configuration mistake leading to potentially disastrous consequences, which will be followed by a chorus of security experts discussing how this should never happen. Yet in the real world it keeps happening. This highlights a point we make over and over again: securing small cloud infrastructure can be challenging, but as infrastructure grows the complexity and difficulty to secure it rises exponentially. And complexity leads to unintended exposures and other configuration mistakes, as Joseph points out.
Of course we are biased, but we think Guardrails are the answer here. Guardrails don’t hamper DevOps, but do continuously ensure security controls are properly configured and automatically correcting mistakes. This can be accomplished at scale with minimal human involvement, which is essential to cloud security success.
Of course we can help with RDP and ssh. DisruptOps detects open RDP ports across accounts and regions, and can react in a number of ways. You can choose a response ranging from notification, to manually executing an action (such as restricting the port to a trusted IP range or removing the security group), to a fully automated action, whenever the issue is detected.
This is just one of a number of configuration mistakes which are particularly problematic in AWS. We can put guardrails around many more. Check out the full library. Or better yet, give us 20 minutes and you can see the full functionality of the DisruptOps platform in your AWS accounts.