Spotting Misconfigurations With CloudMapper
In mid-February, we open-sourced CloudMapper for visualizing AWS environments and it has proven to not only be useful for us at Duo, but also across the broader community. In a matter of days, it had over a thousand stars on Github and a dozen outside contributors sending in pull requests.
Special thanks to the following for their contributions:
- Greg Dahlman for adding support for Python 3.
- Jules Denardou for converting the bash script for collecting AWS data to Python calls using boto3.
- ngerstle and Fernando Miguel for adding Docker support.
In our announcement post, we mentioned a number of ways this tool could be used. The initial post also showed a demo environment with a good architecture from what can be seen with CloudMapper, shown again here:
Initial demo configuration showing a well-architected network
I'll now make some modifications to this architecture to show potential misconfigurations you should watch out for that can be seen visually with this tool.
Misconfiguration 1: Unnecessary Service Exposure
In this example, services which are not user-facing applications have been made public despite an architecture that suggests an intention for a different model such as using a bastion host. You can see that the "internal" web servers and databases can all be reached from 0.0.0.0/0, which means the public internet or anywhere.
This means the bastion host really isn't providing much value here, because you can just connect directly to any of the systems. This type of setup can be okay if strong authorization protects access to the resources, but where this doesn't exist, often in front of databases, it can prove dangerous.
Environment where everything is public.
In order to simplify the visualization, external IP addresses such as 0.0.0.0/0 hide what some of the internal connectivity looks like. In reality, everything can talk to everything, so a more accurate representation of the graph would be:
Modified visualization to show a more accurate view of what it looks like when everything is public.
However, if we applied that same accuracy of representation to the initial graph, we would have:
Initial demo configuration with the display modified to show that all EC2s can connect to the ELBs which are public.
As you can see above, all of the EC2 instances can connect back to the ELBs. Although this is correct, it makes the graph appear needlessly complex.
Misconfiguration 2: Soft Center
In this configuration, I made a default security group that allows access from that same security group, and then applied this to all resources. The result is that only a few resources are public, which is good, but everything inside the network can talk to everything else.
All resources can communicate with each other
This network configuration can be bad because if an attacker gets inside the network they may be able to more easily move laterally to any other system. This rat's nest looking diagram can usually be spotted before the visualization is even generated because the "prepare" step of CloudMapper will show "n" nodes and roughly "2(n2)" connections.
Misconfiguration 3: Bad Failover
In this environment, an effort was made to have availability zone failover, but part of the architecture will not be resilient. Multiple ELBs and RDS instances were set up, one in each AZ, but the EC2 running the web server only exists in one AZ.
This isn't always bad, depending on the responsiveness needed in a failover situation, as you could have processes to spin up an EC2 in the another AZ, as is often the case with bastion hosts like the one in this and the other examples. However, an "unbalanced" architecture that straddles multiple AZs or regions can sometimes be more easily spotted visually.
Architecture that will not be resilient to AZ failover
Misconfiguration 4: Typo in Security Group
This next example looks almost identical to the original demo architecture, except instead of an external CIDR being labeled "SF Office", it has been labeled "1.1.1.1/2". The reason is that although the known CIDR for the SF Office was configured as "1.1.1.1/32", the Security Group has a typo that accidentally allows in anything in the whole "/2".
The result is that instead of 1 IP being granted access, roughly one billion IP addresses have been granted access.
Security Group is accidentally open to a /2 instead of a /32
Stay in Touch!
We hope this has been helpful to you in finding more ways CloudMapper can be useful to you in understanding your own AWS environments.
If you’re interested in the intersection between security and running a highly-available service on AWS, please contact Duo's Production Engineering team at prodeng-ext@duo.com.