Tips to Reduce Network Noise via AWS Subnet NACL

ACM.309 Have you looked at all the traffic reflecting off your public facing systems?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Check out my series on Automating Cybersecurity Metrics | Code.

🔒 Related Stories: Network Security | AWS Security | Application Security

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In the last post I explained how to troubleshoot problems with Lambda networking on AWS, or any networking really. It’s just that with Lambda you need to know where to find the ENIs and IP addresses associated with a Lambda function.

While going through those steps it became apparent that there’s a lot of unwanted traffic reflecting off our NAT, or worse. This pointless noise is slowing down systems and making it hard to pinpoint malicious activity on networks (traffic that passes but is unwanted).

What you will notice about all the traffic above is that it is for most use cases, anomalous. It sends and receives traffic on two high ports. Most traffic sends traffic out on a low port under 1024 and return traffic comes back on 1024–65535. Yes, there are exceptions. But you could choose to design systems that operate as I just described and make your life easier.

• Request to a port < 1024
• Response to a port => 1024

If you could do this you could create very nice network rules. Yes, I know a lot of systems use high ports. Maybe you can segregate them a bit and simplify the rules you can.

Can’t block traffic on two high ports in Security Groups or NACLs

For some systems, it will be difficult to use the tip I’m showing you, because some systems need to accept all traffic from the Internet. If there was a way to implement the rule I showed you in this blog post using a home network and pfSense, it would be easier to block:

Unfortunately that doesn’t work in AWS NACLs or security groups due to the way they work. You might be able to do it with an AWS Network Firewall (I haven’t tried) but those are incredibly expensive to run for a small business. WAFs can also be expensive and slow down systems compared to blocking the traffic at a lower layer protocol.

It might be possible to set up a pfSense on AWS if you don’t have a lot of traffic. But then you’re really trusting the importance of pfSense if it’s something sensitive. You also need a scalable solution if you process a lot of traffic. Other firewall solutions can probably implement this as well. Using third-party firewall solutions with clouds can get complicated, but if you have high security needs a network firewall beyond NACLs and Security Groups may help.

A simple solution for limited traffic needs

If you have something that only needs to allow traffic out to specific resources, here’s a little trick you can use.

In my example in the last post, I need to allow private hosts to access GitHub in my NAT subnet. Then I need to allow the destination host to return traffic through my NACL rules.

Now remember how NACL and Security Group rules get processed:

• NACL rules work in order from top to bottom where the top is the lowest numbered rule and the bottom is the highest numbered rule. As soon as a rule matches, the rule is applied and rule checking stops.
• Security Groups where rules are applied as a set. Only what is allowed after all the rules have been applied is allowed to pass.

Using these two networking features together is a powerful combination that allows you to create very specific networking rules.

The other nice factor which no other cloud offers is that NACLs are stateless and Security Groups are stateful. The stateless rules allow you to drop traffic really quickly to reduce the load on networking devices for known bad IP ranges because they operate on the IP address, protocol and port alone without tracking connection state.

We can’t use security groups with a NAT and we also want to drop any noise we can as quickly as possible, so let’s take a look at what we can do with the NACL rules to weed out the noisy traffic.

How can we block all that noisy unwanted traffic on two high ports from the last post?

Well, first of all, we need to make sure we allow the private traffic. Let’s say our private IP addresses fall into the range of 10.0.0.0/8. Obviously you can be more specific.

Create the Inbound rule on the NAT subnet to allow requests from your private IP addresses destined to the Internet. The private host is going to send traffic to the nat on port 443 using the TCP protocol so your rule will look like this:

• Ingress
• Allow
• Protocol TCP
• Port 443
• IP Range: 10.0.0.0/8

Create an outbound rule to send the traffic back to the private range. I wrote about ephemeral IPs somewhere in another post. The response traffic for an HTTPS request is going to come back in some range specific to your operating system. The lowest common denominator is 1024–65535. Here’s the rule to allow traffic from the NAT back to the private host.

• Egress
• Allow
• Protocol: TCP
• Port 1024–65535
• IP Range: 10.0.0.0/8

Now let’s say you only want to allow internal hosts to reach GitHub on port 443 and let’s say GitHub is in the range 140.0.0.0/8. Add an outbound rule to allow traffic to reach GitHub with an HTTP request.

• Egress
• Allow
• Protocol: TCP
• Port: 443
• IP Range 140.0.0.0/8

Add a rule to allow the return traffic:

• Ingress
• Allow
• Protocol: TCP
• Port: 1024–65535
• IP Range: 140.0.0.0/8

Blocking Large IP Ranges

That’s great if you have a very specific network range that you want to allow. But what if you need to allow a large variety of IP ranges but you know you want to block various regions or countries?

Unfortunately this is not so clear cut. You can’t just block all of Europe by blocking all IP ranges managed by RIPE. More on internet registries here:

For example, I see a ton of traffic from Russia in this range:

45.0.0.0/8

You know what else is in that range?

Netflix.

Good luck if your significant other has a Netflix subscription.

I’m not going to get into why that is but let’s just say you wanted to block the entire Internet. Well most you might already know that is 0.0.0.0/0 but what is the CIDR range?

Head over to the ARIN calculator and you can figure that out (pretending we don’t already know for a minute if you do):

Now we can do the opposite at the top of the calculator — convert an IP range to a CIDR block.

Now, I’m telling you this because in the past I’d block IPs in ranges of 8 like this:

45.0.0.0/8
77.0.0.0/8

But let’s say you know you want to block a whole bunch of IPs from other countries up to the range 140.0.0.0/8. That’s going to be 139 rule entries. Instead, you can calculate the least number of rules you need to add like this:

Three rules. That’s it. Three rules block all the traffic from that huge IP range. So if you know you have a big range of IPs you want to block that only ever sends you invalid traffic, you can block them with those rules.

Then I can calculate all the ranges after 140.0.0.0/8.

But then how do you allow the valid traffic?

Once you’ve added all your blocking rules, then add one allow rule for the entire Internet on the ports you want to allow.

Then the default deny rule will apply for the rest of the ports.

Here’s what it looks like:

After making that change you can search for what is actually getting through your NAT more easily. I showed you how to look at VPC Flow Logs in the last post. After making that change, you can search on a time range and search on the word ACCEPT:

If you see anything you aren’t expecting…time to do some digging and figure out what is going on because you either have:

1. A data breach or security incident
2. A misconfiguration

In my case, I noticed a bunch of NTP traffic to and from the Internet — which was odd because my EC2 instance was previously configured to only use the AWS internal NTP servers. Hmm. I fixed that. NTP can be a source of data exfiltration or could potentially be used as a command and control channel.

Check your logs — and use this tip to make it easier to find what you are looking for, if you can. Also, it might help with performance in some cases.

Not going to put that all in CloudFormation just yet. The networking rules will really be specific to each organization’s environment.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2023

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab