ACM.61 Adding custom route tables with names to our AWS VPCs
This is a continuation of my series of posts on Automating Cybersecurity Metrics.
We created a basic VPC in the last post in this series.
If you tried to deploy an EC2 instance in that VPC we created you wouldn’t be able to connect to it using SSH or RDP even if opened the correct ports (22 and 3389 respectively and an upcoming topic if you’re not familiar). That fact is something that often trips new AWS users up. That’s why this is one of the first topics I cover in my AWS cloud security class and I added that concept to class labs for another company.
The reason you wouldn’t be able to connect to your VPC is that currently the VPC we deployed in the last post has no route to the Internet. In order to provide a route to and from the Internet for resources in our VPC we need to create a route table with a route pointing to an Internet Gateway.
Routes Tables and Routes
Without that route, traffic destined to the Internet from your VPC can’t get there, and anything trying to send traffic to the IP addresses of resources in your VPC can’t get there either. Routes define allowed destinations between networks. If no route exists to get to a particular destination, the traffic can’t get there.
A route table is a collection of routes. Route tables are generally found in network devices that help your connect to other networks, like when you connect from your home network to your ISP. You might be using a network device that has a route table.
We can define a route table on AWS using CloudFormation:
I’ve created a separate route table template because although I’m going to have my subnets use the VPC route table for now, I forsee needing to override subnet route tables in the future. The route table for the VPC controls the routing for subnets unless overridden.
I’m also going to give my route table name via tags like we did for our VPC.
Internet Gateways
When you try to connect to an EC2 instance in AWS, your network traffic is going to travel on a path on the Internet (in most cases) to get there. As the packets you send to your VM traverse this path they will get sent to various devices that understand what to do with the packets and forward them to the next device until finally they reach your host.
An Internet Gateway is one of those devices. If a route to an Internet Gateway (IGW) exists in your VPC route table, the traffic can get to the Internet Gateway and it knows how to handle packets from the Internet and get them to the correct endpoint or host in your VPC. When you send outbound traffic to the Internet, the Internet gateway knows how to forward the traffic to the Internet to get it to the correct destination. Without one, your Internet traffic isn’t getting to your VPC or going anywhere from your VPC.
Route
Finally, we need a route in our route table that sends traffic to the Internet Gateway if we want to allow traffic to and from the Internet.
If you look at the options for a route table you’ll see quite a few:
There are a lot of different ways to restrict traffic with route tables. When you’re troubleshooting network connectivity on AWS, don’t forget to check route tables. Additionally, be aware of broad access that can have unintended side-effects. I like to say, if a path exists, traffic will flow there.
Once on AWS my QA engineer was sending traffic to the production VPC for some reason. When I asked him why he was doing that he was very surprised and said, “I’m not doing that!” The problem was that a route table will send traffic where it can and prioritizes by the most restrictive route. All things being equal, the traffic might end up going to the wrong place. You may need a combination of route tables and traffic rules to keep traffic where you want it to be. Traffic rules will be covered in a later post.
Explaining all of the above options is beyond this blog post series for the moment. I definitely cover them in classes but we don’t need all those options for what we’re doing right now. In a large organization, you’d probably be setting up some things differently than I’m going to do here.
Here’s what we need to create our route:
RouteTableID: Our route table where we are going to add the route.
GatewayID: The route destination which is our IGW.
DestinationCidrBlock: 0.0.0.0/0 which specifies we are allowing traffic to any IPv4 address on the Internet.
Note that this error message that you get if you fail to specify either a DestinationCidrBlock or a DestinationIpv6CidrBlock is incorrect.
Exactly one of DestinationCidrBlock and DestinationIpv6CidrBlock must be specified and not empty.
You can specify only a DestinationCidrBlock if you don’t want to allow IPv6 traffic. I recommend that you only enable IPv6 if you understand how to correctly secure and monitor it because it works quite differently than IPv4. Large organizations may need IPv6 most likely to avoid IP exhaustion. Smaller organizations may not. The whole reason IPv6 came about was to overcome a limited number of IPv4 addresses. If you are not facing that problem and no one is forcing you to use IPv6 you do not need it.
I also recently read about how someone performing a penetration test in a Windows environment got domain administrator access using a flaws IPv6 configuration. It was the only problem he could find to gain additional access. Every time I post something about how to disable or disallow IPv6 on Twitter I get attacked by IPv6 zealots. I’m not saying you should not use IPv6. I’m saying you should know how to secure and monitor it properly before you do and how to quickly update devices if an IPv6 vulnerability is discovered as it has been in use a much shorter time than IPv4.
VPC Gateway Attachment
Now if you tried to run our CloudFormation template we’ve created up to this point you’ll get the following error:
route table rtb-xxxxx and network gateway igw-xxxxx belong to different networks (Service: AmazonEC2; Status Code: 400; Error Code: InvalidParameterValue; Request ID: xxxx; Proxy: null)
That’s because in we need to associate or “attach” the IGW to the VPC. We can do that in CloudFormation using the VPCGatewayAttachment resource.
This resource allows us to attach different types of gateways to a VPC, as the name suggests, namely Internet gateways an a VPN Gateway, which I might cover later if time allows.
Here’s what we need to add to our template:
Now there’s one other interesting thing about these resources. Normally when you use CloudFormation it sorts out all the dependencies for you and it won’t deploy a resource until all its dependencies are met. However, after adding the VPC Attachment to my template I got the same route table error. We can fix that with the CloudFormation DependsOn attribute:
We simply add a line that indicates that our Route resource depends on our VPCAttachment resource:
After making that change the template deploys successfully.
Always Check Your Work
So I forgot something about route tables and at this point I presumed what I did was correct but went to double check. When I went to my VPC and clicked on the route table there was no route for the Internet Gateway. Hmm. Oh yeah. I went to the route tables list and My route table was there, with the proper routes, associated with the IGW. When you add a route table with CloudFormation and associate it with a VPC it doesn’t add the route table as the primary route table. This will still work but now we’ve got a route table with no name in our route table list and that’s kind of annoying. I’ll fix that in a separate post.
Public and Private VPCs and Networking
You may have heard the terms public VPC, private VPC, public subnet, or private subnet in the past. The fact that a VPC is named a private cloud means that you can put restrictions on it so no one else can access it but you or your organization. It is only opened up to the Internet if you choose to configure it that way.
A public network resource is exposed to the Internet.A private network resource is not.You primarily control whether a resource is public or private via the route table by either giving the network a route to the Internet or not.
Modifying our template to create public and private VPCs
Our VPC above was created for developers that need to access VMs on AWS from the Internet. We also need another type of VPC for our private resources on AWS that we don’t want exposed to the Internet. We could simply create a new template but then we’re creating extra work for ourselves and more potential bugs. Basically we either deploy the route and IGW if we want a public VPC and we don’t if we want a private VPC.
In order to achieve this objective, we can use a CloudFormation condition, not to be confused with IAM Policy conditions we discussed in prior posts.
The way we are going to use a condition in our template:
Pass in a parameter that indicates whether we are deploying a public or private VPC. Create a Condition that resolves to IsPublic (true/false)Only deploy the IGW, VPCAttachment, and Route if we are deploying a public VPC.
Note that I anticipate more VPC types so I’m not using a true or false parameter which would allow us to skip the condition. I only want to allow assignment of one type so we need one parameter to maintain integrity.
Add a condition that resolves IsPublic to true or false.
Add the condition to the IGW, VPCAttachment, and Route:
Note that I left the route table alone so we have route tables associated with VPCs with explicit names via the tags. Also, you can make this template more flexible if you need using similar constructs.
A function to enforce a VPC Naming convention
Next we’re going to create a function that enforces a consistent naming convention. We want the VPC name to end with PublicVPC or PrivateVPC.
Create a new network_functions.sh file in the same folder as deploy.sh and add this function:
Now use the above to deploy one public and one private VPC.
Now go to the VPC console and verify that your two new VPCs exist. Verify that two new route tables exist. The Remote Access VPC route table will have a route for the IGW making and the route table for the BatchJobs will not have an Internet route.
Teri Radichel
If you liked this story please clap and follow:
Medium: Teri Radichel or Email List: Teri Radichel
Twitter: @teriradichel or @2ndSightLab
Requests services via LinkedIn: Teri Radichel or IANS Research
© 2nd Sight Lab 2022
All the posts in this series:
____________________________________________
Author:
Cybersecurity for Executives in the Age of Cloud on Amazon
Need Cloud Security Training? 2nd Sight Lab Cloud Security Training
Is your cloud secure? Hire 2nd Sight Lab for a penetration test or security assessment.
Have a Cybersecurity or Cloud Security Question? Ask Teri Radichel by scheduling a call with IANS Research.
Cybersecurity & Cloud Security Resources by Teri Radichel: Cybersecurity and Cloud security classes, articles, white papers, presentations, and podcasts
