Concatenating IP Ranges And Other Firewall Rule Tricks

Tips for fewer firewall rules when you’re trying to block traffic from a network

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

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

🔒 Related Stories: Network Security | AWS Security | Cloud Architecture

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

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

This is the next in a series of blog posts about inspecting network traffic and creating firewall rules to limit your risk. The series started here:

The last post covered logs you need to spot C2 traffic:

This is a quick post to help you decipher certain IP Registry records and reduce the number of rules you have to add in your firewall ruleset potentially.

As I look up IP addresses, I often find creative (shall we say) entries for CIDR block ranges. Also some companies may slice and dice their network traffic up so you’ll have multiple records for a single contiguous IP range.

I’m not to go into all the details for defining IP ranges in CIDR block notation, but let’s just say that these two IP ranges:

10.0.0.0–10.0.0.255 and 10.0.1.0–10.0.1.255

can be expressed as:

10.0.0.0/24 and 10.0.1.0/24

OR

10.0.0.0/23

So if you can concatenate IP ranges, then you will be able to create less firewall rules. The more rules your firewall has to process, the more it has to work (and the more you have to type and manage).

Let’s look at an interesting entry on ARIN for this IP address which happened to be in my logs today: 203.76.110.234.

That entry currently comes up like this:

The owner is someone in Bangladesh, apparently.

So do you have to create all those firewall rules if you want to block that network? Here’s the interesting thing. Take a look at the handle that has the IP range:

That’s strange. One IP short of the last IP for a single CIDR bock: 203.76.110.255. I wonder who owns that CIDR bock. Let’s check.

Well what do you know:

Yes, it’s the same owner.

What if we change the first IP in the range to:

203.76.108.0

Yep. Look it up in ARIN. Same owner.

So instead of entering all those CIDR blocks in our firewall rules, change the first and last IP in the range:

203.76.108.0–203.76.110.255

And now you get the following CIDRS:

203.76.108.0/23
203.76.110.0/24

Now you can reduce the number of firewall rules you need to create.

Tip: A well-architected network will consider firewall rules when allocating CIDR block ranges and IP addresses. When you are in the cloud you can use various network constructs to deal with changing IP addresses. That's something I cover in my cloud security classes.

Here’s another one. Zenworks has been frequenting my logs. The IP addresses hitting my network tend to resolve to a /24 CIDR like this:

23.251.102.0/24

That’s a fairly small range. They show up a lot and the IPs are sometimes nearly contiguous. I wonder who owns the next 24 block:

23.251.103.0/24

Well, look at that. Also Zenworks.

I went through looking at all the different /24 blocks and I could nearly block the whole /8 range. There were just a few other networks sprinkled in between. What I noticed is that the owners breaking up this contiguous IP range were always the same ones: Speedyhost and UCloud. In this case you can take a look at these other companies and what they do and see if you need any of them connecting to your network or vice versa. You might just opt to block the full /8 range altogether and be done with it. Make a note of what you did in the rule description.

What about a network that doesn’t fall neatly into a contiguous set of IP ranges. They are hitting your network from a lot of disparate IPs. Let’s say you found this IP address scanning your network. I don’t know if this IP is involved in network scanning this is just an example.

138.197.0.0

You look it up and see that it belongs to Digital Ocean. IPs on their network ranges are often in my network logs. Scroll down in the record to the “Entity” portion and click on the link next to the handle (DO-13 in the example below).

Scroll down and you can see 57 related networks. If you wanted to, you could block all those networks. If you block all of IPV6 already, you could skip those and only enter the IPV4 ranges. I’m not necessarily saying you should do that. But you could….if you want block all the scanning from that network. As mentioned in a past post, this will also block some legitimate websites. How many depends on your particular Internet access needs.

This last tip won’t create less firewall rules but you’ll spend less time investigating IP addresses from networks that only send you scanning traffic by simply blocking the whole network range all at once if you don’t need access to or from it.

I know, too much fun with IP addresses.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2021

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