The title of this blog could lead you to believe that this post is an advertisement for the newest doorbell camera. It isn’t. The front door I am referring to is the entrance to your network. As the Principle Network Engineer at DomainTools, I am often asked questions like:
- Do we know what traffic enters our network or at least have a way to see what it is?
- Do we have a “deny any” policy that only allows very specific known traffic prior to dropping all unknown/unexpected traffic?
- Are we analyzing the traffic that enters our network?
Although these questions may seem daunting, I have found that it is imperative to have answers to these questions in order to ensure I’m keeping my organization as safe as it possibly can be.
If you don’t know and/or can’t analyze/see what traffic enters your network, you’re blind to what bad or unexpected traffic is out there and is being directed at your network. Even if in most cases you are protected by a deny any policy, which in my experience isn’t usually the case, having the ability to look for traffic anomalies can be invaluable, both from blocked traffic as well as traffic from trusted sources. What happens if one of the trusted sources you’ve allowed to access a specific service is owned? Can they access anything else other than that specific service? Do you see attempts that the host is trying to access something other than what is allowed? If you can’t see/analyze the traffic, you will never even know those attempts were made.
This approach allowed me to unearth some very interesting traffic recently while analyzing some of our netflow data. Before we continue any further, I will say that all of this “interesting” traffic is blocked at our borders, but is still captured in our flows so it can be analyzed, monitored, sifted through, etc.
So, what is the definition of “interesting” you ask? In one case, I found a lot of TCP/UDP source port 0 traffic hitting our network. TCP/UDP source port 0 is a reserved port, so it isn’t traffic trying to hit any of our services. Instead, TCP/UDP source port 0, in some cases, is used by nefarious types to fingerprint operating systems and/or to bypass firewall and router access controls. When I say a lot, I’m talking close to 500,000 individual flows in a 24 hour period. I ran different days of flow captures and that number, while it varies, stays pretty close to that 500,000 mark. To me, that data was eye opening. Yes, we all know the bad guys are out there but when you see them knocking at the front door on that doorbell camera, it is a bit unsettling.
As I said before, in our case, this specific “interesting” traffic was blocked and didn’t hit any of our systems. But if we didn’t have any protections in place, it would have.
The source port 0 traffic is just one set of interesting traffic that I found at our front door that was unexpected. There were a half million telnet attempts (and we don’t use telnet), 100,000 ssh attempts from untrusted source IPs and over 100 BGP attempts from non-BGP neighbor IPs in a 24 hour period.
Most, if not all, network routers and firewalls support some type of flow export that will allow them to be analyzed. Versions, configuration options and naming (netflow, J-flow, cflowd) vary, but the data is valuable regardless of what it is named.
If you aren’t exporting flows today, you are missing a critical view of unexpected traffic that is trying to enter your network. I would recommend you start exporting flows and implement a netflow analyzer, that way you will know who is knocking on your front door.
Open Source Netflow Analyzers https://www.pcwdld.com/free-open-source-netflow-analyzers
Juniper J-Flow http://socpuppet.blogspot.com/2013/05/netflow-on-juniper-srx.html
Cisco Netflow https://www.plixer.com/blog/scrutinizer/what-is-netflow-how-does-it-work/
