I was recently able to explore the Splunk software development kit with a customer. This helped me to implement another way to get username attribution within Plixer Scrutinizer. It’s a great addition to past methods such as Active Directory, Cisco ISE, and CounterACT because in many cases user information will already be logged in Splunk, which saves duplicate work with multiple systems.Read more
Competition generally ends up being good for the consumer. It keeps prices down and forces innovation as vendors compete for market share. A great example of this has been the explosion of vendors and features in the SD-WAN market—and from my perspective, one of the best things to come out of this has been the visibility offered from the enhanced metadata exports of the key players.Read more
With the dramatic shift to work from home, Plixer has been working with people all over the globe to visualize VPN traffic in a variety of different ways. I wanted to take some time to capture what the top five most common use cases I have been asked for are along with some examples of what the reports look like.Read more
The big boss had a conference call over the weekend. She sent a message to your boss’s boss, which trickled downhill, and eventually made its way to you in the form of a text message.Read more
The cloud-first movement is taking over every facet of information technology, and DNS is not excluded. There are tons of vendors that provide solutions around DNS security. The use case this blog will cover can apply to many of them, but I’m choosing to focus on Cisco Umbrella because recently there have been a flood of questions with the same major theme:Read more
Companies today seem to be screaming for easy access to time series data, and there are a few rising stars in the space—notably Grafana and Elastic. Both of these companies can collect metrics; Grafana with its close ties to Prometheus and their new Loki project, and Elastic touting Logstash as the leading alternative to Splunk.Read more
Do you wanna build a NetFlow? Doesn’t have to be a NetFlow…
Network metadata (NetFlow, IPFIX, sFlow, etc.) provides a wealth of information about the transactions that are happening on a network. Typically, if something happens on the network, NetFlow will see it.
Traditional flow records, however, can leave a lot of the puzzle unsolved during an investigation.
If you are ever out to dinner with friends talking about which network devices have the strangest exports, the Cisco ASA will certainly be near the top of the list. The ASA is truly unlike any other firewall in what it can export in its NetFlow Secure Event Logging (NSEL) format. When gathering ASA flows, you will get most of what you are used to with standard version 5 or 9 of NetFlow (minus DSCP Marking and TCP Flags). The interesting bit is its unique elements:
Elements Unique to Cisco ASA NSEL Data
- Firewall Event:
- ID 1 – Flow Created: Flow added to cache (conversation starts)
- ID 2 – Flow Deleted: Flow deleted from cache (conversation ends)
- ID 3 – Flow Denied: (conversation was blocked)
- ID 5 – Flow Updated: In the cache as an active flow (conversation is ongoing)
- Firewall Extended Events:
- Flow Denied:
- ID 1001: Flow was denied by an ingress ACL
- ID 1002: Flow was denied by an egress ACL
- ID 1003: Typically, ICMP to the ASA being denied, but could be other reasons.
- ID 1004: The first packet on the TCP connection wasn’t a SYN packet
- Flow Deleted: These IDs will be somewhere in the 2000s
- Flow Denied:
- Ingress Access List: What ingress ACL was in play during a flow
- Egress Access list: What egress ACL was in play during a flow
- Username: Interestingly, the Cisco ASA includes VPN Username in the flow records. So if your ASA is a VPN appliance, you can gain some valuable insight into what users are doing during VPN sessions. I have worked with customers to set up custom alerts to let them know if VPN connections are being established from outside of the USA or other approved regions.
- NAT Information: ASA keeps track of and exports information regarding how IPs and ports are translated by the firewall. Useful for gaining visibility into internal users when investigating traffic entering the firewall.
As you can see, there is a wide variety of elements that are specific to the ASA. By harnessing these data elements, you can get historical reports on all of the ACL activity the firewall has seen.
For example, let’s say there is an overly permissive policy that allows any host to communicate to a disaster recovery provider off prem. A firewall admin may want to lock this policy down to the IP addresses he believes should be making this communication. But prior to making this change on the firewall, we could look back over a couple months of data and make sure we aren’t going to be inadvertently blocking any IP addresses we didn’t think of. Furthermore, we could check to see if any hosts are communicating with the disaster recovery site that we wouldn’t expect.
Taking a look at an example from Scrutinizer, we can see some peculiar activity from our marketing team. As a firewall administrator, I could investigate who from marketing was attempting to connect to the AWS Backup Servers and what time of day it’s occurring. Then I can determine if this communication should be allowed or investigated further.
These type of reports nicely complement companies’ compliance initiatives. Being able to prove that ACLs are doing their job over extended periods of time tells a great story during an audit. That said, when considering where to store this NSEL data, if compliance is a priority, make sure the solution you choose has customizable data retention settings to ensure the data is there when you need it.
When it comes to reporting on ACLs within a flow collection system, powerful filtering mechanics will be crucial to this endeavor. To get started collecting these, you can either use ASDM or the CLI to configure the Cisco ASA. Once the data is flowing into Scrutinizer, you would simply be running reports specific to those events.
Contact our support team if you want to learn more about these integrations, or need help with configurations.
When it comes to filtering network traffic, a scenario that appears simple in nature can be hard to accomplish at scale. Understanding top talker information or bandwidth trends isn’t really a problem for most traffic analysis solutions—the challenges I encounter revolve around:
- Proactive network monitoring
- Sifting through large amounts of data