Have you ever spent a day picking through firewall logs, looking for the useful bits to help diagnose a reported issue? Firewall logs provide a rich data set, but in and of themselves, they’re a bit hard to read and understand, which makes them even harder to get insights from. Not to mention they are one of the chattiest sources of logs – in fact, one of our customers recently told us their firewall logs increased by more than 200% since the start of the pandemic because of remote employees all accessing resources within the corporate network! If only there was a way to take these obscure and verbose logs and make them immediately useful…

Take this example of a Palo Alto Network firewall Traffic log entry:

Clearly, just from looking at this log entry, you understand where each IP address is geographically, and whether it’s an internal or an external address, and whether the external address is on a list of bad actors. Wait, it’s not that clear? Exactly. I look at that line, my eyes glaze over, and I start thinking about what I’m going to make for dinner instead of the potential problem in front of me.

What do YOU want to do with your data?

I used to run an infrastructure team responsible for, among other things, the global network of a Fortune 1000 company. As a pointy-haired boss, I was generally not all that interested in specific IP addresses, but I was very interested in our geographic traffic patterns. So we had GeoIP lookups set up in our Splunk environment, allowing me to build dashboards around that. But the same data was not available in our SIEM environment, nor in our applications logging environment (which was largely Elasticsearch-based). 

Sure, I probably could have hacked all of those systems to do their own GeoIP lookups, but then I’ve got multiple places to maintain the GeoIP database. My security team was interested in checking the data against threat feeds, but they did that in a separate, bespoke, system. It would have been nice to be able to enrich the firewall data (or any other IP address–rich log source) with GeoIP data and any threat feed data *before* it got to the logging system. By doing that, I could ensure that no system’s data would look “different” just because the local “enrichment” worked a little bit differently than on the other systems. 

When I was introduced to Cribl LogStream, a light went off in my head, because it allowed me to do EXACTLY that. Allow me to show you how…

Enriching Data with Cribl LogStream

LogStream has a general Lookup function that will be well covered in a future blog post, but here, we can also make use of a few other options:

1.  The GeoIP function – this is a function that requires a GeoIP database (e.g., MaxMind’s GeoIP-Lite), and does IP lookups within that DB to generate GeoIP information. This function takes one or more source fields, and tries to look up the IP address in each source field. If it finds it, creates a destination JSON object, which contains all the GeoIP information from the DB that matches that IP address. 

This will potentially create two new JSON objects, src_geoip and dest_geoip, which will contain the GeoIP data for each source field.

2.  The C.Lookup() JavaScript function, used within a LogStream Eval function to check whether a specified source field contains an IP address that is present in a provided list. It returns true if the IP address in the field is in the list, or false if it isn’t.

This will create a new field called compromised that will be true if the IP address is present in the compromised-ips.csv file, or false if not. In this case, I used the compromised-ips.txt file from the ProofPoint Emerging Threats feed, but this could be done with any text file.

3.  Also within an Eval function, we can use the C.Net.cidrMatch() JavaScript function to check if an IP address source field matches an internal address. The form of this will be different from org to org, but the example here checks if the source field is an RFC1918 (a/k/a non-routeable) address.

Since the value expression is too long to see in total on the screenshot, the expressions are:

This will create two new fields, src_type and dest_type, which will be set to “Internal” if the IP address is an RFC1918 address, or “External” if not.

Try it Out For Yourself

These are just a couple options for enhancing your firewall data, but the possibilities are endless. I suggest you take a look at Cribl LogStream by taking one of our sandbox courses. If you are not familiar with our sandboxes, they are a great way to learn Cribl LogStream. Each sandbox is a fully functional version of the LogStream product, with instructions to help you implement the specific use case for the sandbox scenario. There is a sandbox course for GeoIP and Threat Feed Lookups at https://sandbox.cribl.io/course/enrichment