The Network Logs You Might Not Need (GASP!)

Traffic you might not want to log in certain cases and why

This is one of my posts on Network Security.

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

In my last post I explained that there’s a single firewall rule that can identify a whole lot of useless noise on your network.

Now, I’m going to suggest a controversial idea in the world of cybersecurity where professionals want every single log — not logging a particular subset of network traffic. Before you start to shame me into oblivion (I know who you are…the same people that flipped out on me when I said maybe cloud could have some security benefits) read my next post also linked at the bottom.

This suggestion is not for production workloads hosting sensitive data. I’m talking about home networks and others where the risk of not logging this data is low because you don’t have full-time staff inspecting it and limited time to figure out what is going on in your logs. You also may benefit from improved network performance.

You’ll also want to be absolutely positive that your firewall rules are correct, your network appliances are not compromised, and doing what they are supposed to be doing. So test all that out before you take this action. Consider if you would ever, ever, ever need that traffic logged to prove what happened in a security incident before doing this.

I wrote previously about one network rule that can cause a lot of noise on your network. I explained how one single firewall rule can identify and block a massive amount of pure, useless noise.

This traffic creates extra work for your firewall:

It has to go through all your network firewall rules to determine if the traffic is acceptable or should be blocked.

Writing that information to your logs takes up firewall processing power and impacts how fast packets get through it.

If there is any vulnerability in the logging that a network packet could take advantage of, a maliciously crafted packet could attack your systems when the firewall writes the packet to the logs.

If you know a network is malicious and you never, ever have a reason to connect to it, why not block it, drop the packet and eliminate that noise from your logs? Your firewall won’t have to do as much work, which may speed up your network connection. If you later have a network problem and need to troubleshoot, you can turn that rule back on and inspect the logs.

What is the risk of dropping this information?

If you have a set of incorrectly defined firewall rules, then you could block the wrong traffic.

If there is a bug in your firewall software, it might fail to log traffic for other rules, not only this one.

If you need to know what sort of DDOS attack occurred prior to and around another security incident, you won’t have that DDOS attack information in your logs. Often attackers will generate a lot of noise to distract from another attack.

Let’s say you are on a home network. You have tested your firewall software and analyzed your network traffic, and you think it is working correctly. Take that rule I gave you in the last blog post. Start adding the IP addresses that hit that rule to an alias that you block with a second rule and do not log that traffic. These are “known bad networks.” Be careful that you are don’t block innocent traffic from good networks. Some traffic captured by this rule might be an inadvertent mistake due to a typo or an attacker abusing a network to which your devices need to connect.

Do you care about these logs?

If you know you are never going to connect to hosts in Russia or China — what about dropping and disregarding that traffic? No logging, no response, just dropped.

What about traffic coming to your residential networks from other residential networks? Is that ever legitimate? Occasionally I get traffic from Road Runner, Comcast, Charter Networks, and others. That type of traffic might be a compromised home router or laptop or a hacker in a basement.

Should traffic ever be coming directly from Hurricane Electric, a backbone company? I don’t think so. What about mobile and wireless networks?

Then there are just all the hacker-friendly cloud networks. So many hosting companies, virtual machine providers, and cloud-related networks are the source of noisy traffic. I’ve been seeing an uptick from Alibaba Cloud, and I always see Digital Ocean in my logs, for example. Some networks are just easy for attackers and scanners to use, for whatever reason.

When you drop the traffic for an IP, you can look up the IP address in ARIN and drop the entire range instead of adding rules for every single IP address. Let’s take a random sampling of this high port traffic from my logs right now.

OK, I’ve got multiple hits from that first address 103.92.28.102. I’ve become familiar with IP addresses over the years, so I know that’s somewhere in Asia unless, of course, someone in another part of the world registered addresses in APNIC. I can look up the address in APNIC. But I also know that ARIN will grab the information from any registry for me. So let’s go ahead and look it up at https://arin.net.

This network is in Vietnam:

What’s kind of strange about this particular record is that no parent network exists. Usually, that parent record is populated. That makes me wonder if there is something sketchy about this network. Also, make sure any security tools leveraging parent records work properly when none exists. It could also just be an oversight. Who knows. Typically I will create a rule for the parent network. But in this case, there isn’t one. So I’ll just grab the CIDR block: 103.92.28.0/22 and block that.

Let’s look at the next one: 164.52.24.175. I’m guessing this is in the US or North America somewhere based on the IP address. But as it turns out, it’s not. It’s in Hong Kong. I know this by the country code HK.

You can also scroll to the bottom two records, and typically you’ll find an address. Sometimes the records are missing information. That is often the case with suspect networks.

The 183 range is a Chinese network range. 183.136.225.14. Once again, no parent network exists in this record.

Let’s check out: 203.159.80.27. This record is a bit more normal-looking. It has a parent record. The only problem is that it’s not in the form of a CIDR block, which some firewall rules require. We can see the range of IP addresses for the parent is 203.159.80.0–203.159.95.255.

If you need a CIDR block, the easiest thing to do is use an online CIDR calculator. Be careful about putting your own IP ranges into any online tools, but we can use one for this purpose. ARIN has a CIDR calculator here: https://account.arin.net/public/cidrCalculator

You can calculate the CIDR block for the IP range to use in your firewall rules if needed.

Here’s another interesting one. I don’t think I had ever heard of Seychelles before I looked at my network logs. I see traffic from this part of the world and IP Volume, in particular, quite often.

My experience with reporting problems to abuse IP addresses has not been very beneficial in the past. Unless it’s a well-known company that I know will actually care about the abuse, I generally don’t bother reporting it, then I simply block it. The problem is that other countries don’t have the same interests or laws as one home network user in the United States might, so I suggest not wasting your time on that for the most part.

Until there is an actual attack that you can report to the Internet Crime Center, this traffic is simply noise and to be ignored. If you do face an attack that results in business impact or financial loss, you can report it here in the United States:

Once you start blocking and dropping all this traffic, you can begin to whittle down the noise and understand what is really going on in your network. At that point, you may grab a packet capture (pcap file or sniff live traffic) and dig deeper into the packets to see what they are doing. Just be very careful that you only drop things you are positive get denied by firewall rules. You might want a backup logging system like I mentioned in my last post on the topic on your host in case anything falls through the cracks.

I have ideas for alternative network solutions that capture all traffic but reduce the load on production systems and reduce the chances of a successful attack from one of these networks. Maybe I’ll write about that in a separate post or save it for my cloud security classes.

In related news, Yandex has been hit with the largest DDOS attack in history today, and I’m seeing a lot less traffic from Russia at the moment.

These strategies might help them. It would also help if networks all over the world started blocking this noisy and unrequested traffic. I wrote about this in a blog post on unrequested penetration tests.

Network traffic can be super interesting if you’re geeky about packets like me! Check it out. Especially if you want to get into cybersecurity.

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