Cloud Security
Published in

Cloud Security

Scanners lead to scammers

Sources of unrequested network traffic from the past few months

This is one of my posts on Network Security.

I’ve been sort of addicted to looking at network logs since I had my first data breach that incurred monetary losses. I wrote about that breach in How network traffic got me into cybersecurity. I know this is not for everyone, but it’s something I’ve been doing for years, and I’ve compiled a list of networks sending rogue traffic my way. It’s an ever-evolving list and iterative process, not a definitive answer to anyone’s problems. But you may find it interesting if you’re a network log geek like me. You may also want to check if one of your IP ranges is in the list.

Recently I’ve been tracking the different networks that scan some home networks and what they are doing at a NetFlow level (and occasionally at the packet level). I’ve posted the list of rogue IP address ranges scanning various networks to Github in the form of PFSense aliases if you want to use them. You can create firewall rules to block them. However, even as I post this, there are new IP ranges to add. It never ends. I know I can probably never deny all the bad networks, but why should I let the ones connect that I know are sending evil traffic and unnecessary?

Here’s the logic: Yes, it’s not going to block everything — stay tuned for an upcoming blog post related to that subject. But if I know the packets are bad, why wouldn’t I just drop them immediately? It could help improve my network performance, and I eliminate a few attack sources. That presumes I configured my network devices correctly, and my firewall doesn’t have a vulnerability, of course. I write more on this concept of blocking known bad and how you can protect networks in my book: Cybersecurity for Executives in the Age of Cloud.

My secret (not so secret anymore!) wish is this. If everyone would start blocking these bad networks, maybe those that facilitate this traffic because they make money from it would stop doing so and opt for making money in more ethical ways. If the traffic is all getting blocked from a particular network because many people worldwide start subscribing to the “Just say No!” mentality, perhaps these businesses would be less profitable. Maybe some of this noisy traffic would go away.

I’m sure that is a bit unrealistic, but here’s an example of the crowd punishing the cyber attackers that worked — until they threatened the business owner and his family. A company named Blue Frog set up a spam-fighting service back in the day when spam was much worse than it is now (at least the part that gets to most end-users’ inboxes). Each time a spam message hit the inbox of one of their customers, the company would overload the server that was sending the spam. That slowed down or eliminated the spam. It also annoyed the spammers to the point they fought back. You can read or listen to more about this story in Brian Krebs’ book Spam Nation.

In this day of all things distributed, the gig economy, and crowdsourcing, it would pretty cool if all the individual geeks of the world started looking at their logs, blocking these things, and individually banding together to fight this noise. Large organizations could participate, as well. Then the perpetrators of this unwanted traffic could not take out their wrath on any one individual. It’s just a crazy dream, I know. But if you feel like it, you could use these lists and create your own to block some evil traffic.

The lists won’t work for everyone, and there is some good mixed in with the bad in some cases, so you may have to remove a few entries. For example, my ISP in Seattle may be sending rogue traffic from Tuscon, and I block it. If you happen to use that ISP in Tuscon, you may need to remove that entry. Additionally, some cloud provider CIDR blocks appear in the ranges. All hosts in some of these ranges are not evil, but I don’t need AWS, Google, or Microsoft traffic from some of those IP ranges. If I ever do, I check my blocked traffic logs and open it up as needed. That might be too much for some people, but that’s what I do. I continuously monitor my logs and adjust as needed.

If you are an ISP or company and see your network range in the list, you may want to check out what is happening on your network. How did I come up with this list? It’s pretty obvious on home networks where the only traffic should be outbound for the most part when incoming traffic is unrequested and unnecessary. Here are some examples of the types of traffic I’ve spotted.

Countries where I don’t generally connect: Most of the unrequested traffic came from Russia, China, and Germany. Why Germany? Is the gang from the Cuckoo’s Egg still active? I have had some business in Germany. As for the other two, I don’t speak the language and none of them have a good reason to try to connect to my network. If I have a reason to connect it goes outbound.

Known ports: If I see a host connecting to telnet (port 23), MySQL (port 3306), SQL Server (1433), or a myriad of other ports you become familiar with after developing systems and managing networks, it’s very likely those remote IP ranges are scanning for vulnerabilities. Perhaps you have those particular ports blocked, but you have another one open and could be successful. A lot of traffic of this variety comes from Latin America.

Two high ports: Much of the noise in my logs consists of traffic hitting two high ports. That makes no sense. Is it traffic looking for an open ephemeral port? Are they looking for networks that block nothing? Are they reflecting traffic? Is it a long term noise-generating attack to slow down networks? Whatever it is, it is noise and unnecessary.

Security “researchers”: Some networks are associated with cybersecurity companies and security researchers, a term I use loosely when referring to some of this noise. We already have enough noise on the Internet. If you are scanning the entire Internet, please stop. It’s unauthorized. There are a few companies I’d be ok with continuing to do this because they provide truly useful services as a result, but not many. I block them all if I recognize the traffic on my network. It’s better to find your open ports yourself than let someone else find them and publish them in a public database.

Anything else inbound: On my particular network, I don’t allow ANY inbound traffic with a few minor exceptions. I wrote how QUIC complicates network rules previously. I don’t need that either. I can block all inbound network traffic except for the few ports I require in the direction I require, and then it becomes blatantly obvious which networks are sending rogue traffic.

When you block the traffic you know is malicious right away, you can ignore it in your network log analysis and focus on the traffic about which you’re not sure. Weeding out the noise helps you find needles in haystacks. Blocking traffic from known bad networks as quickly as possible — an immediate drop versus a complex evaluation of network rules — might improve your network performance. It could also prevent future attacks from networks that got blocked today but might get through tomorrow.

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 2021

____________________________________________

Want to learn more about Cloud Security?

Check out: Cybersecurity for Executives in the Age of Cloud.

Cloud Penetration Testing and Security Assessments

Are your cloud accounts and applications secure? Hire 2nd Sight Lab for a penetration test or security assessment.

Cloud Security Training

Virtual training available for a minimum of 10 students at a single organization. Curriculum: 2nd Sight Lab cloud Security Training

Have a Cybersecurity or Cloud Security Question?

Ask Teri Radichel by scheduling a call with IANS Research.

____________________________________

2020 Cybersecurity and Cloud Security Podcasts

Cybersecurity for Executives in the Age of Cloud with Teri Radichel

Teri Radichel on Bring Your Own Security Podcast

Understanding What Cloud Security Means with Teri Radichel on The Secure Developer Podcast

2020 Cybersecurity and Cloud Security Conference Presentations

DOM XSS Attacks and Prevention ~ IANS November 2020 Webinar

RSA 2020 ~ Serverless Attack Vectors

AWS Women in Tech Day 2020

Serverless Days Hamburg

Prior Podcasts and Presentations

RSA 2018 ~ Red Team vs. Blue Team on AWS with Kolby Allen

AWS re:Invent 2018 ~ RedTeam vs. Blue Team on AWS with Kolby Allen

Microsoft Build 2019 ~ DIY Security Assessment with SheHacksPurple

AWS re:Invent and AWS re:Inforce 2019 ~ Are you ready for a Cloud Pentest?

Masters of Data ~ Sumo Logic Podcast

Azure for Auditors ~ Presented to Seattle ISACA and IIA

OWASP AppSec Day 2019 — Melbourne, Australia

Bienvenue au congrès ISACA Québec 2019 KeynoteQuebec, Canada (October 7–9)

Cloud Security and Cybersecurity Presentations

White Papers and Research Reports

Securing Serverless: What’s Different? What’s Not?

Create a Simple Fuzzer for Rest APIs

Improve Detection and Prevention of DOM XSS

Balancing Security and Innovation with Event-Driven Automation

Critical Controls that Could have Prevented the Target Breach

Packet Capture on AWS

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Teri Radichel

Teri Radichel

1.1K Followers

Cloud Security Training and Penetration Testing | GSE, GSEC, GCIH, GCIA, GCPM, GCCC, GREM, GPEN, GXPN | AWS Hero | Infragard | IANS Faculty | 2ndSightLab.com