Getting Started With AWS Networking Services – Part 2

Getting Started With AWS Networking Services – Part 2

Network

Here are some more networking components to add to your AWS infrastructure.

The previous post of this series is here. In this post, let’s look at those important components of VPC which are critical for secure and successful network data flow.

You may also enjoy:   Introduction to Kubernetes Pod Networking, Part 1

1. Route Tables

In simple terms, a route table is a lookup table, which defines where to route incoming network traffic. This traffic can be originated from a subnet (within AWS) or the internet. Wait, doesn’t this sound like a Router? You’d be correct in that observation. Please note AWS has a magic router for a VPC but it’s hidden from users and of course, won’t show or give access to their router (which makes perfect sense for a cloud provider). As a user, we can define the routing, using a “route table” for our VPCs and Subnets. An important point here – AWS does not share the physical or virtual interfaces where packets were received (ingress) and from where packets are sent (egress).

When a VPC is created, AWS creates a default route table which has an entry ensuring all local traffic is matched and forwarded appropriately. Any subnet created within a VPC is by default associated with a “main route table.” If you haven’t guessed already, the default route table is your “main route table” unless you explicitly create a new “route table” and make it the main one.

Image title

Route Table

Though out of scope for this post, when you work on VPC Peering, VPN or AWS PrivateLink then route table plays an important role and must be updated for correct routing. Please refer to this link for detailed documentation.

2. Network Access Control Lists (NACLs)

The name is self-explanatory as a set of rules which governs the allowed and denies traffic into your subnets. This is a security feature that works above the subnet level and can be thought of as a hidden firewall sitting behind the hidden router. Default NACL (created by AWS) allows all inbound and outbound IPv4 traffic but any NACL created by users denies all inbound and outbound traffic until you add rules to allow it.

There are three parts of NACLs which are important to developers:

  • Inbound Rules
  • Outbound Rules
  • Subnet associations

Rules for both inbound and outbound rules function independently and must be configured as a pair for bi-direction traffic. In simple terms, if you add an inbound rule to allow HTTP traffic but forgot to add an outbound rule for the same then AWS will allow incoming HTTP requests but deny HTTP response, causing your application will experience HTTP time-out exception.

Let us look at the default NACL (from AWS doc). The following is an example default network ACL for a VPC that supports IPv4 only.

Inbound

Rule #

Type

Protocol

Port Range

Source

Allow/Deny

100

All IPv4 traffic

All

All

0.0.0.0/0

ALLOW

*

All IPv4 traffic

All

All

0.0.0.0/0

DENY

Outbound

Rule #

Type

Protocol

Port Range

Destination

Allow/Deny

100

All IPv4 traffic

All

All

0.0.0.0/0

ALLOW

*

All IPv4 traffic

All

All

0.0.0.0/0

DENY


Rules
are evaluated starting with the lowest numbered rule. As soon as a rule matches traffic, it’s applied regardless of any higher-numbered rule that may contradict it. This is a first-match policy from the lowest rule number to highest. A rule number “*” matches all traffic, is of lowest priority, and should DENY.

One of the most common mistakes I have seen in NACLs is to assume the ports for both ingress and egress traffic will be the same. Often the client application uses an ephemeral port. Servers use standard or documented port numbers.

So, if you are hosting a web application and allow port 80 for inbound traffic then for outgoing, you should allow all port or the traffic will not reach the client. Remember inbound needs a source port and outbound needs a destination port.

3. Security Groups (SG)

A security group is the next level of security feature provided by AWS. Very important to understand that SG is associated with network interfaces and not with a subnet. When you create EC2 instances, AWS creates a network interface (eth0) for your EC2 and the security group is associated with this eth0 and not with subnet or EC2. Tomorrow, if you associate this interface to a different EC2 instance then the associated SG rules will apply to the new EC2.

As an analogy, this is a virtual firewall for your compute instances that reside behind the NACL. It is not mandatory for users to configure and maintain both NACLs and SGs; in fact, you will be working with SG more often that NACL because of the default NACL all-allow policy. As with both inbound and outbound rules, AWS creates a default SG when you create VPC.

Security Groups are different from NACL in following ways:

  • All rules are evaluated to decide whether to allow or reject
  • There are no “deny” rules, you simply state what you want to be allowed
  • For all allowed incoming traffic, SG automatically allows outgoing (stateful firewall) traffic
  • If there is more than one rule for the same port then AWS considers the most permissive rule. According to the documentation: “… if you have a rule that allows access to TCP port 22 (SSH) from IP address 203.0.113.1 and another rule that allows access to TCP port 22 from everyone, everyone has access to TCP port 22.”
  • As a best practice, except for public subnets, be specific in the rules and follow the principle of least privilege.

4. Internet Gateway (IGW)

The Internet Gateway allows internet access between instances in VPC and the internet. IGW provides bi-directional or duplex communication and is fully managed service (horizontally scaled, redundant, and highly available). AWS creates a default IGW and attaches it to your default VPC. This allows users to start accessing their instances created in default VPC from the internet is without much configuration. Please note that IGW is associated with a VPC and not subnets and has 1-to-1 mapping with VPC.

If you observe the route table of default VPC then you will see at least two entries, out of which one will contain “igw-<alphanumeric-id>” as the target for all traffic (0.0.0.0/0). This is the route that lets the internet traffic flow through IGW.

Points to Remember

  • Every VPC (custom or default) has a default route table, a default NACL, and a default SG.
  • These are “main route table” and “main NACL” unless you make a different one under a new “main.”
  • Every subnet by default gets associated with “main route table” and “main NACL.”
  • You can edit the association and map the subnet to different ones.
  • NACL needs two rules for each direction with explicit allow/deny (stateless)
  • SG is stateful — responses to allowed inbound traffic are allowed to flow out, regardless of outbound rules.
  • A default VPC is associated with an IGW but not a custom VPC.
  • You need IGW for any traffic between compute instances in VPC and the internet. (there is a special gateway called NAT Gateway which I will cover in part-3)
  • Traffic flow can be thought as follows
    •  Internet -> IGW -> Router (route tables) -> NACL -> Subnet -> Security Groups -> Network Interfaces (EC2 instances) 
      • **This flow is not all-inclusive but only represents what I have shared so far. In practice, AWS deployments include a load balancer, Route53, CloudFront, WAF, Shield, etc.)

Ok, so now let us put all this in a simple architecture and try some rules.

Simple web server architecture

Simple web server architecture

You can use the AWS Console to provision components of this architecture. If you wish, then use CloudFormation templates: first, create a base stack using base-vpc and then create a referenced stack using ec2. These templates are, however, defaulted for the Mumbai region and need further edit to work in other regions (I will share in detail on this template in another blog).

The above architecture has AZ names from the Mumbai (ap-south) region and is an extension of the architecture which was shared in part-1 of this series. You can follow the below steps and create them in your region of choice.

  1. VPC with CIDR 10.0.0.0/16
  2. IGW attached to the VPC
  3. Route Table with an entry for IGW
  4. NACL which allows both inbound and outbound TCP (protocol # 6) traffic on all ports (0 – 65535)
  5. Two subnets in two different availability zones with CIDR as 10.0.1.0/24 and 10.0.2.0/24
  6. Two security groups
    • First SG that allows TCP traffic on port 80 and port 22 from anywhere 0.0.0.0/0
    • Second SG that allows TCP traffic only on port 22 from anywhere 0.0.0.0/0
  7. Two EC2 instances (t2.micro), each associated with an individual SG created in the above step.
  8. While provisioning, you need to provide or create a new keypair. This will be used to ssh into EC2.

Ok, now that we have infrastructure provisioned in an AWS region, let’s install a simple web server.

SSH into the EC2 in whichever way you prefer and execute the following command:

# In EC 1A
sudo yum -y install httpd 
cd /var/www/html
sudo nano index.html
<h1> Hello World From EC2 Instance 1A </h1>
sudo service httpd start 
# In EC 1B
sudo yum -y install httpd 
cd /var/www/html
sudo nano index.html
<h1> Hello World From EC2 Instance 1B </h1>
sudo service httpd start 

Now, if you try to open the webpage of EC2 1A, it will work, but EC2 1B will time out. The reason being the Security Group of EC2 1B which has no rule for HTTP traffic on port 80.

Once done, please remember to delete all components to avoid any cost.

Further Reading

How to Become an AWS Expert

My Mental Model of AWS

from DZone Cloud Zone

Sharing is caring!

Comments are closed.