AWS security groups are often compared to a traditional firewall. While there are similarities, security groups...
are more capable than a traditional firewall. This tip compares security groups to a traditional firewall and describes best practices for developing a security group policy.
Security groups vs. firewalls
The first distinction is that a traditional firewall is deployed between subnets, while a security group is applied to a specific server. The traditional firewall only filters traffic that is exiting or entering a subnet. It does nothing to filter communications between servers in the same subnet. A security group, on the other hand, filters all traffic entering or exiting a specific server. As a result, the security group can protect the server from attacks that originate from within the same subnet.
This can be a confusing change for new AWS users. An engineer knowledgeable in traditional network design may assume that the two servers in the same subnet can communicate on any protocol or port. He or she may not realize that he or she needs to add a new security group rule to allow this communication. Luckily AWS includes a default policy that makes the transition easier for new users. But, this policy introduces a potential security hole. I'll explain how in a minute, but first, let's look at how security group policies work.
A traditional firewall defines rules based on IP addresses or blocks of IP addresses. Each rule allows traffic from a source IP address to a destination IP address. When a new server is added to an application, the rules must be updated to account for the IP address of the new server. This can be tedious and error-prone and it is difficult to comb through all the rules that accumulate over time.
Security groups support IP-based rules, just like traditional firewalls, but they also support policy-based rules. A policy-based rule allows one security group to refer to another security group. For example, the database security group might allow connections from the Web server security group. In other words, any server added to the Web server security group automatically gets access to the servers in the database group without updating the rules to account for new IP addresses.
When adding a new Web server to the application, simply add it to the Web server security group and the database security group automatically recognizes it. There no need to update the rules of either security group with the IP address of the new server. A security engineer can define the security policy before the first server is ever launched. The chief information security officer will love this.
Let's return to the default policy discussed above. The default (it is literally named "default") security group includes a policy that allows any server in the group unrestricted communication with any other server in the group. For a new user, this policy allows servers the ability to communicate like they are on the same subnet in a traditional network. Keep in mind that the servers in the default group can communicate even if they are in different subnets. In general, you should create custom security groups with application-specific rules rather than relying on the default security group. Below are a few examples.
Example: Basic Web application
Let's begin with a basic Web application running on Microsoft Windows. This application has an elastic load balancer, a few Web servers and a SQL Server database. Users should begin by defining a security group for each tier of the application. First, the load balancer security group allows HTTPS requests from anywhere in the world using a traditional IP-based rule. The Web server security group allows HTTP traffic (assuming encryption was terminated on the load balancer) from the load balancer group using a policy-based rule. Finally, the database security group allows SQL traffic from the Web server group.
Now simply add the individual servers to the appropriate security group when they are launched. If the application grows over time, simply add additional servers. There is no need to update the security group rules. In fact, all of the security rules were defined without needing the IP addresses of the individual servers.
Example: Windows Active Directory
Another great feature of security groups is that an individual server can be a member of more than one security group. This allows a server to be added to multiple security groups to arrive at an aggregate security policy. For example, assume the servers described in the Web application above are joined to a Windows Active Directory domain.
To account for the change, define two new security groups; one for domain controllers and one for domain members. The Web servers can now be added to both the Web server group and the domain member group. The Web server group allows communication with the database and load balancer, and the domain member group allows communication with the domain controller.
While security groups are often compared to a firewall, they offer advantages over a traditional firewall. A well-thought-out policy will be easier to set up and maintain than IP-based rules on a traditional firewall.
About the author:
Brian Beach is an enterprise architect with more than 15 years of experience in software engineering and information technology management. Brian is an Amazon Certified Solution Architect, Microsoft Certified Solution Developer (MCSD) and Certified Information Systems Security Professional (CISSP). He holds a BS in Computer Engineering from NYU Poly and an MBA from Rutgers Business School and is a member of American Mensa. Brian is an advocate for cloud computing on the AWS platform and currently manages a team of cloud engineers at a Big Four accounting firm. He can be contacted through his blog at http://blog.brianbeach.com or LinkedIn at http://www.linkedin.com/in/brianjbeach.