Create a Security Group
Objective
To create a new EC2 security group (or groups) to use with servers added to a deployment.
Table of Contents
Prerequisites
- Requires "security_manager" user role privileges
Overview
A security group defines which ports are open to allow incoming connections to a server. Security groups act as firewalls in the cloud. They are designed to control who can communicate (i.e., initiate communication) with a server. With the exception of Amazon Virtual Private Cloud (VPC) security groups, discussed under VPCs, EC2 security groups only affect ingress (incoming) communications and do not prevent a server from initiating outbound communications.
The default security group in each AWS region (automatically created for your account by Amazon) does not allow any incoming connections. Therefore, you will need to create a new security group to use with your production servers. Security groups give you flexible options for restricting access to servers. For example, you can limit server access to a specific IP address and port (though you cannot block a specific IP address). To learn about different ways to use security groups for various architectural scenarios, see EC2 Security Groups.
Amazon security groups are also AWS region specific; for example, you cannot use a security group that you created in "US-East" to secure a server in "US-West." You can assign multiple security groups to a server. Permissions defined in a security group are additive in nature; so, if a server has two security groups where one group has port 80 open and the other group has port 80 closed, port 80 will be open (not closed) on the server.
Warning: Although you cannot change which security groups are used by a server after launching that server, you can modify the server's associated security groups. This immediately affects all running servers using those security groups. For example, if you launched a server with a security group which initially only had port 22 open, and later opened port 80 for this same security group, the running server inherits those changes immediately, meaning that port 80 is now open on that server. To prevent unexpected changes to a server's ingress communication permissions, you should only grant trusted users the "security_manager" role, and consider creating separate security groups for each project or deployment in your cloud architecture.
The following tutorial assumes you are creating a security group for use in the Amazon US-East region. However, the functionality is identical for other AWS regions.
Steps
The following steps explain how to create a generic security group to be used by all servers in a typical three-tier deployment.
For information about more advanced configurations, see EC2 Security Groups. To build a more robust deployment architecture that utilizes multiple security groups, see Configure Multiple Security Groups for a Multi-Tiered Deployment.
Create a Security Group
1. In the RightScale Dashboard, go to Clouds > AWS Region > Security Groups. There is already an initial default user group listed. In the following steps, you will create an additional, customized security group for your production deployment.
2. Click New.
3. Name the group "production" and add a brief description.
Note: You cannot change a security group's description after creating it.
4. Click Create.
Add IP-Address-Based Permissions
After completing the steps in the previous section, you now have a security group with no open ports. Next, you must open up the necessary ports to allow communication among servers in your deployment and define who can initiate communication with those servers.
To open a single port for all servers in a security group, you must select an IP protocol (i.e., TCP, UDP, or ICMP) and a port or range of ports, and use CIDR notation to define the permissions.
For your generic example security group, open the following protocols and ports:
-
TCP: 80 (see graphic above)
- To allow HTTP access to servers in the security group, enter 80 in both port fields, since you are only opening up a single port and not a range of ports.
- Ensure that the "IPs" option is selected from the drop-down list, and that the corresponding address value is set to 0.0.0.0/0 (the default). The 0.0.0.0/0 value allows access to the specified port from any IP address, whereas '0.0.0.0/32' denies access to all IP addresses (which is equivalent to not opening the port at all).
-
TCP: 22
- Enable SSH access to servers in the security group by entering 22 in both port fields.
- Enter 0.0.0.0/0 in the IPs field, to enable access from all IP addresses.
-
TCP: 443 (optional)
- Port 443 is required for SSL communications (i.e., "https"). To allow HTTPS access to the server, enter 443 in both port fields.
- Enter 0.0.0.0/0 in the IPs field, to enable access from all IP addresses.
-
ICMP:-1..-1 (optional, see graphic above)
- To "ping" the servers in the security group, you must allow ICMP access.
- Choose "ICMP" from the protocols list, enter -1 in the "Type" and "Code" fields, and enter 0.0.0.0/0 for the IPs field.
Warning: If you will use your security group with Microsoft Windows servers, ensure that you open port 3389 for Windows Remote Desktop Connection sessions as well.
Add Group-Based Permissions
Since you will use the same generic security group for all servers in your deployment in this sample exercise, you must explicitly add the security group to itself, so each server in the group can communicate with all other servers in the group, across any port, via any protocol, over their private IP addresses. Do this by selecting the "group" option from the drop-down list in your new permission definition, as shown below.
You must add security-group permissions for each protocol (TCP, UDP, and ICMP) separately. Use a port range of 0 to 65535 for TCP (shown above) and UDP to allow protocol access over all ports. Use a "Type" and "Code" value of -1 for ICMP to enable all ICMP types and code values.
The "Owner" field automatically defaults to the AWS account ID associated with your RightScale Dashboard account; however, you must manually enter the security group name in the "Group" field as shown above.
Warning: While it is useful to allow internal communications among all servers in a security group via any port during the testing and development phases, in a production environment, you will probably want to restrict communications to specific, select ports only.
Review Security Group Permissions
Assuming you followed all the previous steps, you should now have the below permissions defined for your "production" security group.
Troubleshoot Security Groups
When experiencing communications issues with servers in a deployment, you may need to troubleshoot your security group settings. The following is a list of common issues often associated with the setup and configuration of security groups.
- Ports not opened correctly
- No website access? Port 80 may be closed.
- SSH sessions fail? You may be using a server launched with a RightImage that uses RightLink Version 4 or earlier, and port 22 is not open. (For Version 5 RightImages that are RightLink-enabled, incorrect or absent SSH keys can affect operational and decommissioning RightScripts also.)
- No SSL support? Port 443 may be closed.
- Accidental use of /32 in CIDR IP address notation, instead of a less restrictive /0.
- If too many ports are open on your server, you may have specified a range of ports when trying to specify a single port in your security group (e.g., ports 80 through 8000 instead of only ports 80 and 8000).
- If servers within a security group are not communicating correctly, you may need to either explicitly open the communications ports to all IP addresses, or add the security group to itself, which allows all servers in the security group to communicate with each other.
See Also
- © Copyright 2015 RightScale Technical Support