The default route 0.0.0.0/0 is treated as evil by many organizations; most security scanning tools will flag any security group containing a default route as insecure. The default route is often improperly used when troubleshooting connectivity issues and frequently used by lazy developers as a shortcut. However, there are many legitimate uses of the default route.
Given that the deployment of public facing websites, web apps and open APIs are increasing in number (even for large enterprises), it makes sense to find more nuanced ways of providing governance for these accounts and the security groups within them.
This post focuses on how to write governance controls for public facing security groups. We will use AWS as an example, but the same principals and process will work for Azure and GCP as well.
Traditional Workflow
Many large organizations have historically outsourced public facing websites and web applications to 3rd parties to reduce the liability of having public endpoints into their data centers. In the world of cloud-based systems, this makes little sense, but the phobia of the default route continues to persist. We see organizations struggle with how to manage exceptions for these types of applications. Groups that leave the false positive alarms in place suffer from alert fatigue and teams that turn them off expose themselves to real vulnerabilities.
Get it done with Turbot Guardrails
Turbot Guardrails Object Constraint Language (OCL) gives you great flexibility and control over security group rules. OCL works using simple REJECT and APPROVE filters. It executes from top to bottom and the first matching filter wins. Cleverly constructing the order of the filter statements allows for a wide variety of policy implementations. We can implement these rules individually for ingress and egress rules using policies like AWS > VPC > Security Group > Ingress Rules > Approved > Rules:
In the simple rule above, we reject any ingress rule that uses the IPV4 default route (0.0.0.0/0) or the IPV6 default route (::/0). For our public facing web application let's create a rule that allows http/https traffic (ports 80 and 443) with a default route source, but denies other usage of it:
In this example the first check looks for a security group rule matching ports 80 or 443 with ingress from the default route. If it matches, the APPROVE rule is applied and processing stops on that rule (each rule in a security group is evaluated independently). If the first rule does not match, then the next check would reject any other port with default route ingress.
Like all policies, these can also be set via Turbot Guardrails Terraform Provider. Here is an example of creating a Smart Folder named "public_web_sg_check" with the same rules. Using a smart folder allows you to attach the same policies to multiple accounts.
After setting this policy, Turbot Guardrails will identify all security group rules that match REJECT statements as alarms, allowing you to request remediation of the improper security groups from the app team.
If you are ready to enforce automated remediation, you can change the policy setting from Check: Approved to Enforce: Delete unapproved and the automation will delete all security group rules that match a REJECT statement.
Make it happen!
See for yourself how easy it is to manage your network ingress and egress rules across all your cloud services. A ready-to-run Terraform template is available to enable this configuration from the Turbot Development Kit (TDK). If you need any assistance, let us know in our Slack community #guardrails channel. If you are new to Turbot, connect with us to learn more!