Quantcast
Channel: sysforensics.org
Viewing all articles
Browse latest Browse all 57

AWS Security Overview - Part III - VPC Security Groups

$
0
0

Overview

I discussed AWS Security Overview - Part I - Networking Terminology in part one. Now that we have the terminology out of the way for the most part I wanted to discuss Security Groups.

The next few AWS Security Overview Parts will be focused on security and logging.

Security Groups

Security Groups (SGs) are a virtual firewall for instances that are used to control ingress and egress traffic. SGs operate at the instance level, not the subnet level. It's also worth noting that each instance within a subnet can have a unique SG and you can assign up to 5 SGs to an instance. SGs are associated with the networking interface (ENI) of the instance.

Security Groups are used to create allow rules, not deny rules. With SGs you're able to configure; Type (port), Protocol, Port Range, Source (CIDR, SG) and a 255 character limit for a Description.

When you create a SG, there are no inbound rules by default. There is; however, an allow for All Traffic, All Protocols, and All Port Range to destination 0.0.0.0/0, which is a route to your Internet Gateway. If you create an SG via the launch wizard it will allow SSH for Linux and RDP for Windows systems inbound and a default source of, 0.0.0.0/0.

Security Groups are Stateful. This means if you send a request from your instance, the response traffic is allowed to flow in regardless of inbound SG rules. It's also worth mentioning that you can only filter on the destination port when creating a rule.

For example, on a test instance I have the following inbound rules. As you can see I have, 80, 443, and 22.

1

If I kick off a ping against google.com from within my instance. You will see that even though I do not have ICMP allowed inbound, it still returns.

ping -c 3 google.com

And here is the reply.

PING google.com (172.217.7.206) 56(84) bytes of data.
64 bytes <snip>: icmp_seq=1 ttl=48 time=1.40 ms
64 bytes <snip>: icmp_seq=2 ttl=48 time=1.50 ms
64 bytes <snip>: icmp_seq=3 ttl=48 time=1.43 ms

Instances that are associated with SGs cannot talk to each other unless you add rules allowing it. There is one exception to this, which is the default SG, which will assign the SG group id (Ex. sg-b9<snip>) as the source, and allow ALL Traffic, All Protocols, and All Port Range.

When the SG is set as the source within a SG rule, it will allow those instances associated with the source SG to access instances within the SG.

Discovery Security Group Information

The AWS command line is a great place to start. You don't want to be stuck using the AWS Console GUI. If you're a SysAdmin and you're using the GUI after a few months you are not using the cloud the way it was intended to be used.

In either case, you can view information about your SGs by running some of the following command(s).

This will give you a JSON blob of your instance settings/information.

aws ec2 describe-security-groups

If you want to take a look at a single security group you can specify the security group, group id and it will return that single SG.

aws ec2 describe-security-groups --group-id sg-8c<snip>

If you wanted to see which security groups allow a particular port you could do something like this, which will return the instances in JSON format that allow SSH.

aws ec2 describe-security-groups --filters "Name=ip-permission.to-port,Values=22"

These CLI options can be very useful. You should review the entire list of them here. When you start adding on filters, queries, etc. they can become long and "complex".

Once you start building "complex" CLI queries I would recommend building them programmatically. It's good coding practice as well.

Let's say you want to return the following information for your instances within your AWS account.

  • VPC Id
  • Instance Id
  • Security Groups
    • Group Name
    • Group Id

I wrote the below Python by leveraging the Boto3 AWS SDK to accomplish this. I'm not a good coder so this if for demonstration purposes. Also, it's only looking at my default region, which is us-east-1.

import boto3
import json
from Utils.HelperFunctions import DateTimeEncoder

client = boto3.client('ec2')

# Build a dictionary of the instances
def buildDict(response):
    instanceDict = {}

    for instances in json.loads(response)['Reservations']:
        for item in instances['Instances']:
            instance_id = item['InstanceId']
            vpc_id = item['VpcId']
            # There can be up to 5 SGs
            security_group = item['SecurityGroups']
            subnet_id = item['SubnetId']
            image_id = item['ImageId']

            instanceDict[instance_id] = security_group, vpc_id, subnet_id, image_id

    return(instanceDict)

# Iterate through the Dictionaries
def parseSGs(instance_dicts):
    results = []
    for key, value in instance_dicts.iteritems():
        for sg in value[0]:
            results.append([key, ' '.join(['{0}'.format(v) for v in dict.itervalues(sg)]), \
                            value[1], value[2], value[3]])

    return(results)

# Return the JSON blog of describe_instance)
response = json.dumps((client.describe_instances()), cls=DateTimeEncoder, indent=4)

# There is a limit of 5 per network interface
instance_dicts = buildDict(response)
results = parseSGs(instance_dicts)

for result in results:
    print ' '.join(result)

Which would return the following information as it relates to a particular EC2 instance.

i-0580369426b44468b default sg-b9ddc1cb vpc-61a61e19 subnet-8369eec8 ami-da05a4a0

i-09bf2137c5e446732 default sg-4493dd3a vpc-0cb37675 subnet-d592159d ami-772aa961

You could obviously build on this code and incorporate other use cases. It wouldn't be difficult to construct a plugin based architecture. A buddy of mine showed me an auditing tool by NCC Group, which seems nice called, Scout2.

Security Group Limits

There are some limits with Security Groups.

  • 500 SGs per VPC
  • 50 rules to an SG
  • 5 SGs per EIN

You can ask AWS for some exceptions to this; however, it's best not to rely on the kindness of an organization. If you reach these limits, it's likely that you have made some poor architecture choices along the way that should be fixed first.

Visual Network Diagram

So building upon what we had already drafted our in the AWS Security Overview - Part I - Networking Terminology post.

I made some updates to reflect our security group. You will see our security group is inside our VPC, surrounding our EC2 instance. I will continue building upon this diagram as I discuss and add technologies.

2

Summary

So this should provide you with a good overview of what Security Groups are.

In Part IV, I discuss Network Access Control Lists (NACL).

Also, all of the posts in this series are kept here at the table of contents.

Enjoy!

References
Amazon Virtual Private Cloud User Guide
Amazon EC2 Security Groups for Linux Instances


Viewing all articles
Browse latest Browse all 57

Trending Articles