AWS Security Groups strategy

How to use AWS Security Groups

How to use AWS Security Groups in large enviroment


What can we do with SG
1. You can only allow traffic. There is no deny action. Last rule is "implicit deny"
2. You can create inbound and outbound rules
3. You can allow traffic based on port and source IP (inbound) or destination IP (outbound)
4. Destination (inbound)/ Source (outbound) is always "me" - interface where SG is assigned
5. SG is statefull firewall on instance (host) level
6. There is no "session helper" know from enterprise firewalls. If applications use dynamic ports those ports have to be open manualy
7. You can have up to 50 rules inside SG (soft limit, can be increased)
8. You can have up to 5 SG assinged to network interface (soft limit, can be increased)
9. When mulitple SG are assign, result ruleset will be sum of all rules


Suggestions
1. Focus on inbound rules rather than outbound. It's easier to manage access to resource in one inbound SG rather in multiple outbound SG. When you create new SG you will always have default action: outbound allow all. It will be easy to destroy your work if will manage outboud rules
2. Use instance tags and automate SG assignment
3. Try to avoid assigning elastic ip to instance. Access from internet should be through load balancer
4. Control outgoing traffic using NAT instance. But do not use AWS built in instance. It is allowing whole traffic without restriction. Use enterprise class firewall to control traffic to internet
5. If you use vpn to your office, control office <-> AWS traffic on office firewall
6. Try not to nest SG to often
7. Use AWS trusted advisor to audit your rules. Dome9 has similar function
8. Use NACL only when necessary. ACL are stateless. When you will want to block high ports (destination port) you can accidentally block legitimate traffic based on source port. NACL work on subnet level so rules will affect all instances in subnet. You can also block traffic from ELB that teoretically is in same subnet but in fact its not


Security group nesting
Nesting behavior is not obvious. First lets look how they do not work:

We have following SG:

SG_Web_Servers:
ALL from 10.0.0.1
ALL from 10.0.0.2
ALL from 10.0.0.3
ALL from 10.0.0.4


SG_Database
1433 from SG_Web_Servers


Everybody expects following ruleset as result:
1433 from 10.0.0.1
1433 from 10.0.0.2
1433 from 10.0.0.3
1433 from 10.0.0.4

Unfortunately this is not how it works. You can't use SG as static IP list to use it in different security group. You have to consider SG nesting as instance tagging or dynamic list.
For following example:

SG_Web_Servers:
ANY from SG_Web_Servers

SG_Database
1433 from SG_Web_Servers


And follwoing instance with SG assigned:
WEB1 :SG_Web_Servers
WEB2 :SG_Web_Servers
WEB3 :SG_Web_Servers
WEB4 :SG_Internal_Web_Server

DB1 :SG_Database

Web servers (WEB1, WEB2, WEB3) will have full access between each other. Web servers (WEB1, WEB2, WEB3) will have access to DB1 on port 1433. WEB4 has different SG assinged. It will not be able to communicate with DB1 and other Web servers. You can use group nesting only for instances inside AWS. You can nest SG from other AWS account but you can't use it to allow access from servers not located in AWS.


Strategy 1: Security group nesting
1. In this scenario you don't need to use subnets. You can have one subnet that contains all instances
2. Group all your servers based on function: Live-Server, Live-DB, Mail-Server, File-Servers
3. As all instances will be in one subnet you will have to recognize them base on instance name or tags
4. If you enviroment is complex, split then and use multiple AWS accounts
5. If you don't assing correct SG, instance will not be able to communicate (on function level)
6. Numerous role will complicate management


Strategy 2: Subnet based
1. Group all your servers based on function: Live-Server, Live-DB, Mail-Server, File-Servers
2. Create subnet for every role
3. Allow unlimited communication inside subnet. This will simulate "standard" network behavior
4. Create rules from subnet to subnet. If machine will change IP it will not loose connectivity
5. You will easily identify instances by IP
6. Keep internal LB inside functional subnet
7. Create one subnet for external load balancers. It will be easier to identify what instances have access from internet