Amazon Web Services: Security Groups

Security is one of the elements of infrastructure configuration, which is very often overlooked. Often administrators focus on delivering functionality and fulfilling requirements, while not caring about securing the infrastructure against attacks, believing that it's probably going to be fine. We in Droptica often build corporate websites on Drupal for banks and other institutions which care about security, therefore we do not have the luxury to not think about security.

 However, you do not need very sophisticated mechanisms and solutions are needed to ensure basic security... Let's see.

Filtering network traffic

One of the ways to protect networks and systems against intruders are firewalls - tools for blocking unwanted incoming and outgoing connections, and thus denying requests for access to the network or services which are considered to be dangerous.

The simplest type of firewall is a packet filter that checks network addresses and ports of packets to determine whether they should be denied or allowed to reach the target machine. In such a solution, the firewall has a set of rules that determine the fate of the packet depending on the direction of the connection (in particular, from which address and to which address it is directed), the network port number and its type (for example TCP, UDP or ICMP).

AWS: Security Groups

Security Groups policies function exactly the same way as a packet filtering firewall and are used to control traffic in the AWS network. Amazon allows you to define rules for most of their products that are exposed to external networks.

When a new EC2 instance is spin up, the administrator assigns at least one policy to it. Each of them can be modified at any time - all changes are applied automatically and immediately.

Amazon enables you to configure both incoming and outgoing traffic policies. The example - rules for our test server - can be seen below.

Security Groups configuration

The main aim of Security Groups policies is to make services that require it available to the outside world. Running additional software on servers (for example solr, redis, memcached) is a common practice, but these should not be made available to users. This is why it is important to start by considering what should be visible to others.

In the case of a web server, the open ports policy might look as follows:

• SSH (22) - if you want to manage the server remotely (you can allow only traffic from internal network),
• HTTP (80) - for unsecured traffic;
• HTTPS (443) - for secured traffic.

Of course, these are not the only services. Sometimes it is necessary to set up a mail server (SMTP, IMAP) or a dedicated API (port 8080 and others). However, this is the basic recommended configuration.

Example using Terraform

It is also good practice to follow the idea of keeping infrastructure as code - it facilitates and streamlines the management of your servers, which is why we use this approach at Droptica. Below you can find an example of Terraform code, which is used to manage Security Groups.

resource "aws_security_group" "web-sg" {
  name        = "web-sg"
  vpc_id      = "${aws_vpc.vpc.id}"
  description = "Allow incoming WEB connections"

  tags {
    Name = "web-sg"
  }

  # Allow incoming SSH
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # Allow incoming HTTP
  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # Allow incoming HTTPS
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # Allow incoming ICMP
  ingress {
    from_port   = -1
    to_port     = -1
    protocol    = "icmp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # Allow all outgoing traffic
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

At the beginning, we define the basic information only - the name, description and network identifier, to which the given policy will be assigned. Next, we define the filters (we used the filters described in the previous section).

Values from_port and to_port enable you to define ranges - you can, for example, open all ports from 8000 to 9000. The ingress sections refer to incoming traffic and the egress refers to outgoing traffic.

Summary

Security Groups are hardly an ultimate solution that will turn your servers into impenetrable fortresses, but they allow you to limit the visibility of what should not be available to the public. Assigning default policies to all services is a common mistake made by novice administrators, which leads to opening all the services to the public. This is why it is worth learning more and understanding this topic.