Extra networking Lab 2

Security Controls
Prerequisites for this Lab:

Section 1 of Lab 1 is completed, with

● 3 VPCs with 2 Subnets in two AZs
● 3 EC2 instances, one each in VPC A-AZ1, VPC B-AZ1 and VPC C-AZ1
Section 2 of Lab 1 is also completed, with
● VPC A and VPC B peering connection
● VPC A and VPC C peering connection

The environment is depicted as below.

Network ACLs
11 Modifying default Network ACLs to block, allow subnets

Network ACLs are stateless access controls you configure at a subnet level, to allow or block a CIDR block on a
particular port or range of ports. Network ACL rules are numbered list and evaluated top down, with a DENY ALL at
the end. If a rule is matched, subsequent rules are not evaluated.
Both inbound and outbound traffic can be controlled with these rules. By default when you have created the
above subnets, the default Network ACL attached to them will have an ALLOW ALL rule for both inbound and
outbound traffic.
In this lab, we will modify Network ACL on VPC A-AZ1 to allow only VPC B’s CIDR; and test connectivity on port 22
from VPC B to VPC A, and test other connectivity from VPC C to VPC A as well

1.1 Navigate to VPC Dashboard and click on ‘Subnets’

To get started, navigate to VPC Dashboard Services: https://console.aws.amazon.com/vpc

1.2 Navigate to Subnets

1.3 Filter AZ1 subnets and open Network ACL for VPC A
1.3.1 Type ‘AZ1’ in the search box to filter only subnets in AZ1. The console should now show only the 3 subnets
in AZ1 as below, along with Network ACL IDs.

1.3.2 Click on the Network ACL ID of VPCA

1.3.3 In the Network ACL screen, click on ‘Inbound Rules’ to view existing inbound rules
 The default inbound rules in the Network ACL can be seen above. All traffic get evaluated for Protocol,
Port and Source IP match. In this default Network ACL, all traffic are allowed into VPC A – AZ1 Subnet by
the first rule. The second rule which is a DENY ALL is not evaluated.

1.3.4 We will now modify the first rule (100) to allow only ICMP traffic from VPC B’s CIDR. Click on ‘Edit inbound
rules’ button in the above screen.

In the above screen, enter the following and save the rule. (Note that the catch all rule for DENY ALL cannot be
edited)
● Select ‘ALL ICMP – Ipv4’ for Type
● Enter VPC B’s CIDR 10.1.0.0/16 for Source
● Click on Save

1.3.5 The screen should return to the Network ACL page and the updated rule will display like below. Verify the
rule for Type, Protocol, Port and Source for the ‘ALLOW’ rule 100.
We have now completed modifying Network ACL of VPC A’s AZ1 Subnet to allow ONLY ICMP traffic from VPC
B’s CIDR and all other traffic will be denied by the catch-all DENY rule. Let us now test this from VPC B AZ1
Subnet for ALLOW, and VPC C AZ1 Subnet for DENY.
Note that we have not modified outbound rules, and the default outbound rule allows ALL traffic to flow out
of the subnet.

1.4 Testing connectivity from EC2 VPC B AZ1 to EC2 VPC A - AZ1
Here, we will login to EC2 VPC B – AZ1 using EC2 instance connect, and verify reachability to EC2 VPC A –
AZ1 over ICMP (ping)

1.5 Navigate to EC2 Dashboard and select ‘EC2 VPC A – AZ1’, and note down its Private IP4 address, here it is
10.0.0.5

1.6 Now select ‘EC2 VPC B – AZ1’, and click ‘Connect’ button on the top
1.7 In the ‘Connect to your instance’ dialog, select the option ‘EC2 Instance Connect (browser-based SSH
connection) and click ‘Connect’ button as below

1.8 A new browser window opens with SSH connection to EC2 VPC B – AZ1 established and showing the
command line prompt as below:

1.9 Type this following command in the prompt: “ping 10.0.0.5” (substitute with your EC2 VPC A – AZ1
instance’s private IPv4 address). The ICMP traffic should flow through and return as shown below:
We have now verified that the Network ACL on VPC A – AZ1 subnet is allowing ICMP traffic to flow in and out,
from EC1 VPC B – AZ1.

1.10 Testing connectivity from EC2 VPC C AZ1 to EC2 VPC A - AZ1

Similarly, connect to EC2 VPC C – AZ1 from EC2 console, and ping EC2 VPC A – AZ1 as we did from VPC B above.
The ping command will freeze without progress because the Network ACL in VPC A – AZ1 subnet is DENYING all
traffic from VPC C. Like below.

Conclusion: We modified the default Network ACL in VPC A to allow ICMP traffic only from VPC B; the only other
rule is a DENY ALL. We verified that ICMP traffic flows through from EC2 VPC B – AZ1 to EC2 VPC A – AZ1 and DID
NOT flow through from EC2 in VPC C – AZ1.
Security Groups
2 Modifying Security Group to ALLOW only ICMP traffic from VPC C to VPC A

Security Groups are virtual, stateful firewalls attached to an instance or network interface. Both inbound and
outbound rules can be defined to allow specific protocols, ports and source/destination CIDR. A DENY is not
possible with security groups.

With Security Groups, all rules are evaluated before a network packet is allowed or blocked, unlike Network ACLs
where the rules are evaluated in order of rule number and once a rule matches subsequent rules are not
evaluated.

In this exercise, we will modify the security group attached to EC2 VPC A – AZ1 to allow only ICMP traffic inbound
from VPC C’s CIDR only. We will verify that EC2 VPC C – AZ1 is able to ping EC2 in VPC A – AZ1, and EC2 in VPC B –
AZ1 is not able to ping EC2 in VPC A – AZ1.

Prerequisite: As shown in Section 1.3 above, edit the Network ACL in VPC A – AZ1 subnet to revert the change to
Rule 100, and set it to allow ALL TRAFFIC from all sources (0.0.0.0/0), because we want all traffic to flow past the
Network ACL to the instance in VPC A to test the Security Group at the instance level.
After reverting the change, the Network ACL rules should look as below:

2.1 Navigate to EC2 Dashboard

To get started, navigate to EC2 Dashboard: https://console.aws.amazon.com/vpc

2.2 In EC2 Console, navigate to Running Instances

2.3 In the EC2 instance list, select ‘EC2 VPC A – AZ1’, and click on the Security Group in the bottom section

2.4 In the Security Group page, click on ‘Inbound Rules’ tab, and then click on ‘Edit inbound rules’ button
 2.5 In the Edit inbound rules page, in the second rule that is currently allowing ICMP from any source,
change it to allow only from VPC C’s CIDR 10.2.0.0/16 and click ‘Save rules’

Now we have modified the Security Group on EC2 VPC A – AZ1 to allow ICMP traffic (ping traffic) only from
instances in VPC C, and from nowhere else. We will now test to verify that we are NOT able to ping this instance
from EC2 VPC B - AZ1, and we are ABLE to ping from EC2 VPC C – AZ1.

2.6 Navigate to EC2 Dashboard and to Running Instances page by following instructions in 2.1 and 2.2
above
 2.7 Select ‘EC2 VPC B – AZ1’ from the list of instances, and click ‘Connect’ button

2.8 Follow instructions in 1.7 to use EC2 connect to open command line prompt on EC2 VPC B – AZ1

2.9 In the command line of EC2 VPC B – AZ1, try pinging the private IPv4 address of EC2 VPC A – AZ1. It
will freeze and make no progress. This is because the Security Group on EC2 VPC A – AZ1 has only
ICMP inbound rules to allow VPC C. There are no rules for allowing VPC B, and an implicit DENY occurs

Similarly connect to EC2 VPC C – AZ1 and try to ping EC2 VPC A – AZ1. The ping will succeed and traffic will
flow through. This is because the SG on EC2 VPC A – AZ1 is allowing ICMP traffic from VPC C’s CIDR range.
 Conclusion: We modified the Security Group on EC2 VPC A – AZ1 to allow only ICMP traffic from VPC C. We
tested and verified that we cannot ping this instance from VPC B, but we are able to ping it from VPC C
confirming the behavior of the Security Group.

VPC Endpoint Policies

3 Limiting access to AWS service API calls with VPC Endpoint Policies

VPC Endpoints are private link to supported AWS services from a VPC, instead of reaching the service’s public
endpoints through the internet. Two types of VPC endpoints exist, Gateway endpoints and Interface endpoints.
Gateway endpoints support only S3 and DynamoDB, and reach these services through a gateway from the VPC.
Interface endpoints create a network interface in the VPC’s subnets, and all traffic to the service flows through this
interface to the service.

Endpoint policies are IAM policies attached to VPC endpoints to restrict/grant permission to the service’s API calls.
For example, with an S3 endpoint, a policy can be attached to limit only read access to one or more S3 buckets
from the VPC.

In this lab, we will create an S3 bucket, remove the Internet Gateway route in VPC A’s route table, and check if we
can reach the S3 bucket from EC2 VPC A – AZ1. Then, we will create a VPC Endpoint for S3, attach it to VPC A with
a policy allowing only read access to the S3 bucket and verify the read access.

3.1 Navigate to the S3 console as below

3.2 Click on ‘Create Bucket’ in the S3 console

3.3 Enter a unique name for the bucket, select US East (N.Virginia) for region and click ‘Create Bucket’ as
below. Leave other settings to default.

3.4 The bucket should get created and a success message displayed to confirm bucket creation
3.5 Navigate to VPC Dashboard and click on ‘Endpoints’, then click on ‘Create Endpoint’ to start creating a
VPC Endpoint

3.6 In the Create Endpoint screen,

1. Search for ‘S3’ by service name and select it

2. Select VPC A for VPC
3. Select the checkbox for route table entry to be added automatically
4. Enter the below IAM policy for VPC Endpoint policy. This policy restricts access to only reading S3
buckets and no write or API calls to modify the bucket
{
"Statement": [
{
"Sid": "ReadOnlyAccess",
"Principal": "*",
"Action": [
"s3:Get*",
"s3:List*"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
5. Click on ‘Create endpoint’ button to create the VPC Endpoint for S3 attached to VPC A
3.7 Verify the route entry to the route table by navigating to the VPC console, click on Routes, and select
the Route for VPC A and click ‘Routes’ tab in the bottom. It should show an entry pointing to the VPC
Endpoint ID for destinations in the prefix list (This could take a minute or two)

3.8 Here, even though we have a default route using the internet gateway, we have a more specific route
to S3 using the prefix list and VPC Endpoint. So traffic to S3 from VPC A will take the VPC Endpoint
route to S3.

3.9 Let us now verify access to S3 and what actions are permitted from EC2 VPC A – AZ1. Follow
instructions in 2.6-2.8 to connect to EC2 VPC A – AZ1.

3.10 Issue the command ‘aws s3 ls s3://a-5112020’ (replace with name of bucket you created) to check
if we can list the bucket
Note that the command was successful and no errors returned. The bucket is empty and hence it did not
return any listing.

3.11 Let us try to create a test file and upload to the S3 bucket. Issue the commands ‘touch test.txt’ to
create an empty test file, and then ‘aws s3 cp test.txt s3://a-5122020/’

Note that the command returned an ‘Access Denied’ error message when trying to upload a file to the S3
bucket. This is because the Endpoint policy allows only Get* and List* actions, effectively making the
S3 bucket read only, and all other actions are denied.

3.12 Let us now add permissions to the VPC Endpoint policy document to allow creating objects in the
S3 bucket, and test it by uploading the same test.txt file to the bucket and verifying successful upload.

Navigate to VPC console, and click on ‘Endpoints’ on the left menu, and select the VPC Endpoint we
created in above steps. In the bottom frame, click on ‘Policy’ tab, then click on the Edit Policy button,
as below:

In the policy editing screen, enter the below policy document and click save.

{
 "Version": "2008-10-17",
"Statement": [
{
"Sid": "ReadWriteAccess",
"Effect": "Allow",
"Principal": "*",
"Action": [
"s3:Get*",
"s3:List*",
"s3:Put*"
],
"Resource": "*"
}
]
}

This policy adds allowing s3:Put* (highlighted) permissions to the VPC Endpoint, effectively allowing
instances from VPC-A to upload objects to S3 buckets in the account.

Let us now try uploading the file test.txt again. If your SSH session in the EC2-Connect browser window
has expired, follow instructions in 2.6-2.8 to connect to EC2 VPC A – AZ1 again.

Issue the command ‘aws s3 cp test.txt s3://a-5112020’ (replace with name of bucket you created) to
upload the file to the S3 bucket.

You will see that the command succeeds and the file is uploaded to the S3 bucket. You can also verify the
upload by listing the s3 bucket with this command: “aws s3 ls s3://<your-bucket-name>/”. S3 will list
the uploaded file in the output, as shown in above screenshot.

Conclusion: We tested access to an S3 bucket through Gateway VPC Endpoint to S3; we set the endpoint
policy to allow only read actions; we tested that we can only list and get objects from the S3 bucket,
and verified that put objects are denied by the endpoint policy.

And we also modified the policy to allow writing objects to the bucket, and verified the same, effectively
displaying that the VPC Endpoint policy is an effective control mechanism to control allow/deny to
service API calls from the VPC.