#netflow

How Data Brokers Sell Access to the Backbone of the Internet - ISPs are quietly distributing "netflow" data that can, among other things, trace traffic through VPNs

 There's something of an open secret in the cybersecurity world: internet service providers quietly give away detailed information about which computer is communicating with another to private businesses, which then sells access to that data to a range of third parties, according to multiple sources in the threat intelligence industry.

 The information, known as netflow data, is a useful tool for digital investigators. They can use it to identify servers being used by hackers, or to follow data as it is stolen. But the sale of this information still makes some people nervous because they are concerned about whose hands it may fall into.

 At a high level, netflow data creates a picture of traffic flow and volume across a network. It can show which server communicated with another, information that may ordinarily only be available to the server owner or the ISP carrying the traffic. Crucially, this data can be used for, among other things, tracking traffic through virtual private networks, which are used to mask where someone is connecting to a server from, and by extension, their approximate physical location.

 See https://www.vice.com/en/article/jg84yy/data-brokers-netflow-data-team-cymru

 #technology #privacy #VPN #netflow

vRealize Network Insight v4.x now supports external sources for NetFlow and sFlows. This means you can perform micro segmentation planning on physical servers (before you migrate them to virtual) and create deep insight into what network traffic is going through your entire network (and not just limited to what’s happening in your virtual network).

Currently, NetFlow versions 5, 7, 9 and IPFIX are supported. Getting started with NetFlow in vRNI is pretty easy, but it is slightly more complicated than regular data sources.

Getting Started

I say it’s slightly more complicated, because you have to have a dedicated Collector VM (previously known as Proxy VM) for NetFlow only. The deployment process of this Collector is a bit different, I’ll guide you through the steps below.

First, get the regular Collector VM OVA file, the same one you used to deploy the Collector that collects data from your vCenter, NSX, etc. Get ready to deploy it via vCenter, but first follow these steps to get a shared secret:

Login to vRNI

Go to the settings (either type “settings” in the search bar or use the menu on the top right)

Select Accounts and Data Sources

Click the Add Source button

Choose Netflow Collector as the data source type (on the bottom)

Click the Add Collector VM button. This will display the following popup:

Deploying the Collector VM

After you’ve generated the shared secret for the Collector VM, you can go ahead and deploy that OVA via vCenter. I’m not going to go through all steps, assuming you know how to deploy an OVA. Remember to select Thin Provisioning. You will get a couple of template customisation options, mostly around network settings, but the last option is the most important one; the shared secret. Here you want to input the shared secret you just generated in the vRNI UI.

If everything looks good, deploy the Collector and go get some coffee. It takes a couple of minutes to deploy the OVA and the boot sequence needs to be completed before you can continue. It takes 10 to 15 minutes total. Don’t be like Fred, don’t stare at the progress bars. Anyway, when it’s done with all that it needs to do, it will show up in the vRNI UI automagically. When it does, give it a nickname and optionally some notes about the Collector. Click the Submit button when you’re done.

You can check if you’re successful by looking at your data source overview and the NetFlow data source turns up and there’s a timestamp on the Last Collection value.

And that’s it, vRealize Network Insight is ready for NetFlow ingestion. Point your NetFlow streams to the IP address of the newly created Collector VM.

Verification

Alright, so now you have the NetFlow Collector running and it’s supposed to gather flow data to present back to you. If you’ve already configured your switch to send NetFlow to your NetFlow Collector VM though. If you haven’t, there are a couple examples at the bottom here.

There’s a search query to test if your vRNI is actually collecting physical NetFlow:

flow where Flow Type = 'Source is Physical' and Flow Type = 'Destination is Internet'

I don’t think I have to explain what you’re looking at.

Creating More Context

Currently, vRNI does not resolve physical IP addresses to names (Also, who has their complete network correctly configured for forward DNS, let alone reverse DNS?). The functionality will be more automated in the future (like reading from a CMDB & IPAM, is my best hope/guess), but for now you can manually create more context for the physical flows you’ll be seeing in the UI.

There are two options to do this in the Settings page, under IP Properties and Subnets.

Physical IP and DNS Mappings

You can upload your Bind zones to vRNI so that it can use DNS names instead of IP addresses. If you don’t have Bind as your DNS server (have to admit, it’s pretty old), you can also upload a simple CSV file with your DNS records in it. Examples of this CSV file and the Bind zones can be found in a downloadable zip file.

Remember to zip up whichever format you use, even if it’s just 1 file.

Physical Subnets and VLANs

The other option to provide more feedback can be a bit more confusing. You can also manually map subnets to IP Subnets. I can hear what you’re thinking: “Isn’t vRNI supposed to do this automatically via its data sources?!?!?” – well, yes. If the NetFlow is coming from a supported data source, it will indeed automatically translate the IP Subnets to a VLAN. But here’s the thing; NetFlow is pretty universal and there’s a somewhat limited (although pretty large) list of supported switches and routers as a data source within vRNI. If you decide to send NetFlow from a switch or router that is not on the supported data source list, vRNI doesn’t know what IP Subnet belongs to what VLAN. That’s why you can configure them manually.

The process is pretty simply; on the Physical Subnets and VLANs settings page, click the Add button. Then enter a Subnet and VLAN ID and press Submit.

NetFlow Configuration

Here are a couple of examples on what configuration is needed on certain switch types. Replace $Collector_VM_IP with the IP address of your vRNI NetFlow Collector.

Disclaimer: Verify commands before you enter them into your equipment. I haven’t been able to test all of these, some are from documentation and theoretical.

flow-export destination inside $Collector_VM_IP 2055 flow-export template timeout-rate 1 flow-export delay flow-create 60 access-list netflow-export extended permit ip any any class-map netflow-export-class match access-list netflow-export policy-map global_policy class netflow-export-class flow-export event-type all destination $Collector_VM_IP service-policy global_policy global

More details and configurations will come soon.

Prime Infrastructure 3.3 – View traffic to off site networks

My last post talked about how to setup Prime Infrastructure (PI) 3.3 to correctly display “Site” data. You have to create “Device Groups”, then associate IP addresses in “End Point Association” for those groups. Here is the link to the post that I am referring to.

Because Cisco setup PI to have you create these Device Groups and associate the IPs per group, you can setup groups for IP ranges that…