Skip navigation
Product & Engineering

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:

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:

Good Demo Environment 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.

Demo - All Exposed 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 - Demo, All Exposed 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:

EC2 - Demo, All Exposed 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.

Demo - Soft Center 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.

Demo - Bad Failover 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.

Demo - Typo 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.