The 5 Biggest Mistakes Made With Cloud Firewalls

The 5 Biggest Mistakes Made With Cloud Firewalls

The greatest incentive to move to the cloud is to reduce cost. Organizations invest a lot to that end, but that investment is for not if your cloud isn’t protected. Most often, these mistakes are attributable to either a misinterpreted security policy or cluttered, nearly illegible security rules.

It’s a problem that affects not only large, enterprise organizations, but also small startups with only a few dozen instances – a rapidly growing group who’ve come to rely on the cloud because of it’s economical scale but whom often underestimate the complexity and importance of getting security right.

To help these and others, we’ve put together the following list of the five most common cloud server firewall mistakes to avoid:

#1: Too many rules = Trouble

In development, you typically start with just a few rules in your cloud firewall or Amazon Security Groups.  By the time you get into production, however, the list of rules and policy exceptions has grown considerably, creating a complicated mess that you’ll later be too scared to touch for fear of breaking your application or service.

Our suggestion: Limit the number of rules in any single firewall or security group to just ten.  This will significantly simplify your administration and prevent accidents down the road, and to re-architect your Security Groups and split complex policies to manageable functional sub-policies.


[Newvem scans and identifies the status of your security group configurations, continuously monitors their status, and alerts you of vulnerabilities. Get Started for Free!]


#2: Beware of the hidden 0.0.0.0/0

When a rule is set to open a port to 0.0.0.0/0, that service is exposed to the public Internet, and supersedes any other rules or limited scopes in the policy.  This mistake significantly compounds mistake #1 (too many firewall rules) because it’s difficult to detect amidst the tangled web of rules.  Unfortunately, this is a very common mistake, including in AWS VPC, so be sure to check your exceptions to make sure no ports are open to 0.0.0.0/0.

#3: Enforce authorization policy

Not every developer and administrator should be able to configure your security groups. Unfortunately, many organizations do not enforce a strict IAM policy to restrict who can configure their security policy. Be sure to implement IAM controls, and keep close track of who has these rights.

#4: If you use ELB, make it the only entrance

 If you use ELB as part of your AWS deployment, you can use it to shield your web servers. By configuring the web tier security group to allow HTTP & HTTPS only from the ELB, it limits the exposure level of your web server’s tier. We suggest you use ELB as the only trusted source for your web tier - no exceptions.

#5: Not all “private” 10.x networks are indeed private

Your cloud instances comes with internal and external IP addresses. Users tend to have 10.x internal network set as a trusted network. This gives the cloud providers more control (in comparison to the external network), but often organizations don’t invest to make their internal network ultra secure. What’s more, in contrast to traditional infrastructure, the cloud’s internal network is actually a semi-public environment, shared by many of its customers. Thus, to protect your environment from your internal network, we suggest using VPC to isolate your own private network in the public cloud.

Final Words

The greatest incentive to move to the cloud is to reduce cost, and organizations invest a lot to that end but that investment is for not if your cloud isn’t protected.  At Dome9, we believe that security must be a core component to your cloud adoption plan. In order to execute that plan effectively, without incurring significant risk, you must be able to create a strong, front-line perimeter with your cloud server firewall. We hope that, in sharing these five common mistakes, you’ll now be able to safely adopt the cloud.


Newvem analytics tracks your AWS cloud utilization:

  • Hourly Utilization Pattern Analysis 
  • Reserved Instances Decision Tool 
  • Resource Resizing Opportunities

Get Started with Newvem for free or learn more about Newvem’s features


About the Author

Zohar Alon, Founder and CEO at Dome9.  Alon is the Founder and CEO of Dome9 Security, and a veteran in networking security. He helped shape the early days of network security while at Check Point Software (NASDAQ:CHKP) where he built Provider-1, Check Point’s service provider’s management solution, which is still used today by the world’s largest MSPs and enterprises. Alon graduated from Tel Aviv University, and holds several leadership and advisory roles in venture-backed companies.

@zoharalon on Twitter

Contact Zohar

About Dome9

Dome9 makes cloud security elastic with automated cloud firewall management. Available for the enterprise and hosting providers, Dome9 centralizes firewall management across Clouds, Virtual Private Servers (VPS), dedicated servers, and Amazon’s EC2 Security Groups, covering all major operating systems and service providers. Secure Your Cloud™ with Dome9.

For more information on Dome9, Check out Dome9 SecOps for AWS service and visit www.dome9.com

Keywords:  Amazon web services, Amazon Cloud Services, Cloud Security, AWS ELB, Elastic Load Balancer, IAM policy, Cloud Firewall, Amazon Security Groups, Security Audit, Firewall Ports, VPN, VPC, HTTP, HTTPS, SSL, Security Policy, Cloud Adoption, Migration

There are 3 comments .

Tony O’Grady —

Hi,
Agreed on most of what you say with one exception:

‘#4: If you use ELB, make it the only entrance’
We sometimes need to target a specific web-server when troubleshooting an issue (yes, all servers should be identical but . . .). We add rules targeting the specific box, but tied to our source IP address, as and when required. Fairly straightforward via the Amazon portal.

Tony

    Zohar Alon —

    Thanks Tony - and this is why Dome9 was started: To get you on-demand access to your administrative services on your server, so in your case, with AWS SG and Dome9 you can define all the web servers to allow ELB for HTTP + On Demand access.

    This means that 99.9% of the time your web-servers would only allow the ELB and all your admins need to do is to login to their Dome9 account console and click “Get Access” on the specific Security Group on the HTTP or HTTPS. This fires a 1 to 24 hour lease authorizing the IP from which they are currently coming from, to access the web-servers. When this lease expires Dome9 automatically tells AWS to remove that bypass role. 

    Check us out!

    Zohar

You must be to post a comment.

* As a bonus, you'll receive our weekly newsletter!

Hitchhiker's Guide to The Cloud

Newvem's eBook for Cloud Operations