Security Onion for Splunk version 1.1.7 – README

1.1.7

  • Tweaked Sguil indexing to prevent Bro URL data from being duplicated into Splunk via sguild.log.
  • Monitors dashboard field name drop down selections added to all panels.
  • General Mining dashboard added panels for Bro SSH logs and Bro HTTP TLDs (top level domains). Also added drop down options for Bro FTP and IRC panels.
  • Squil Mining has been updated and improved.
  • Syslog Mining dashboard added for Bro Syslog.
  • An Event Workflow was added for searching Splunk for events by src_ip.
  • …and last but not least:
  • CIF Dashboards!

For the CIF integration to work you need access to a CIF (Collective Intelligence Framework – http://code.google.com/p/collective-intelligence-framework/) server in order to export query results to a .csv file for the external lookups.

The CIF integration leverages three files created by exporting CIF query results to .csv format. If you don’t have access to a CIF server but want a sense of how the app works, I’ve provided three sample files in the lookups folder. Visit http://testmyids.com via a browser and you should see results in the CIF dashboards.

IMPORTANT – By including these 3 sample files (that contain NO actual CIF data; just fields and a test/sample entry) we prevent Splunk from throwing lookup table errors for those who won’t use the CIF capability. The drawback is updating the Security Onion app will overwrite existing .csv files, so remember to backup the lookups/*.csv files prior to future updates or plan to recreate new CIF .csv files.

The three CIF queries used for development and testing were:

cif -q infrastructure -s medium -c 85 -p csv -O infrastructure.csv
cif -q url -s medium -c 85 -p csv -O url.csv
cif -q domain -s medium -c 65 -p csv -O domain.csv

Once you’ve created these files you have to do two things:

  1. Edit each file removing the “# ” (hash followed by space) from the first row of each file.
  2. Copy the files to /opt/splunk/etc/apps/securityonion_cif/lookups/

I highly recommend scripting the CIF export, file manipulation and copy/move process.

CIF Lookups:

In the first release there are two dashboards:

  • IP Correlation checks dest_ip addresses from the Bro Connection logs indexed against the CIF infrastructure.csv export.
  • Domain/MD5 Malware Correlation checks Bro HTTP domains and executable files downloaded MD5 hashes against CIF.

Both dashboards work the same in that you’ll first see a list of IP addresses with an event count. Clicking on an IP will provide CIF related details around the match as well as a list of all activity to the dest_ip address. From there you can use the Event workflow menu to splunk deeper.

=============================================

I’ll try to post some screenshots and more details soon!

Update:

Here are a couple screenshots of the CIF dashboards. When they load, the IP list in the top right shows all the IP matches in the CIF infrastructure.csv file that appeared in the Bro connection logs. A click will load some CIF details (impact, severity, confidence, etc) with the matching events below. From the events view, you can then use the Events Workflow menu (blue square with white arrow) to pivot to a search for activity from the the source IP, full CIF queries, Robtex and DShield lookups. OSINT at it’s finest!

The Domain/Malware MD5 dashboard works the same way. The only real difference is it’s matching Bro HTTP logs against both the domains.csv and url.csv. I wanted to match full urls from Bro against the url.csv, but I’ve run into a few technical difficulties. Bro logs domain and uri as separate fields. I can make Splunk index them as a single field for a direct match lookup against url.csv but that would equal more indexed data. So until I can figure out a better way to do that, we’re matching against the CIF malware_md5 field. Bro hashes executable files downloaded via HTTP by default and this allows us to limit the query to only bro_http fields that actually have an MD5 value.

The key distinction with the Domain/Malware MD5 dashboard is the presence of the cif_malware_md5 field in the CIF Details panel. If that field is populated with a hash value, then you have had a hit on a positive malicious executable download. If there is no hash value, then you have a domain name hit.

May the force be with you.

More (Advanced) Querying CIF Data With Splunk

My last post on querying Collective Intelligence Framework (CIF) data with Splunk showed you how to enable CIF as part of Splunk workflows for ad-hoc lookups, but what if you want to take it a step further and actually cross reference events against CIF? The easiest method I’ve found has been to perform periodic CIF queries saving the results to a comma delimited (.csv) file then using external file lookups in Splunk to cross reference events. It’s not very difficult to setup and you’ll quickly see the value. All you’ll need outside of Splunk is access to a CIF server to create the .csv files.

First we need to export the query results from CIF:

cif -q infrastructure -s medium -c 85 -p csv -O infrastructure.csv

This command queries CIF for any “infrastructure” results with a severity rating of medium or higher and a confidence rating of 85 or higher. Infrastructure results are IP based threats related to botnet command and control (CnC) and infection sources. You’ll then have an infrastructure.csv file that looks something like this:

We need to remove the “#” and following space from the first row fields so it looks like this:

If you don’t remove the “#<space>” from the first row, Splunk will not parse the field names. (In other words, it won’t work.)

Fire up Splunk and head to Manager > Lookups > Lookup table files and create a new lookup file. Specify which app you would like the lookup table associated with then browse to the file and specify what you want the file to be named when it gets copied up to the Splunk server. The Search app is probably the best default option. Once saved, you can change the permissions to make the lookup file available in other apps.

At this point you can already run some very handy queries, for example:

sourcetype=bro_conn [|inputlookup infrastructure.csv | rename address as dest_ip | fields + dest_ip]

This query searches our Bro IDS connection log but uses the “inputlookup” command against our infrastructure.csv file. The “rename address as dest_ip” tells Splunk to rename the address field as dest_ip and the “fields + dest_ip” specifies which fields to lookup.

If you want to just gauge what the number of connections from your network to IPs in CIF look like, add the stats command:

sourcetype=bro_conn [|inputlookup infrastructure.csv | rename address as dest_ip | fields + dest_ip] | stats count by dest_ip

This will show you all the dest_ip addresses in bro_conn that match CIF and provide a count of the number of those events for each IP. You can repeat this process for CIF domains and urls quite easily to perform the same types of queries against DNS or http logs (like Bro’s dns.log and http.log). We can, however, take it a step further with automated lookups.

If you revisit Splunk Manager > Lookups, let’s add a new Lookup definition. Specify the app, give it a name, make sure the “Type” is set to “File-based” and then specify infrastructure.csv in the “Lookup” file drop down. Save it and adjust the permissions accordingly. Then go back to Lookups but this time let’s add a new “Automatic lookup.”

Once again we choose the app, give it a name and choose the lookup table. We then specify which sourcetype we want to check against CIF. The “Lookup input fields” tell Splunk to check the address field in the infrastructure.csv file against the dest_ip for our bro_conn sourcetype. We then have to specify what fields we want to output from the lookup if there is a match. Here you can define every field in the infrastructure.csv file or just the one’s that you want to be able to reference in the events.

All we are doing is telling Splunk when you find “address” field in the .csv file display it in Splunk as cif_address. (I recommend you append a prefix to avoid potential field name conflicts). The fields defined in the above screenshot should give you plenty to get started. Save it and you’re ready to query.

Doing a simple search against the bro_conn sourectype won’t provide any CIF results on it’s own. In order to get the automatic lookup to kick in, we have to tell Splunk that we want one of our CIF output fields as a result.

sourcetype=bro_conn cif_impact=*

Running that query with the automatic lookup properly configured will now get you the CIF matches for any dest_ip addresses plus you’ll now see the output fields we defined in the field picker.

So now you can run queries like this:

sourcetype=bro_conn cif_impact=* | table src_ip dest_ip cif_confidence cif_severity cif_impact cif_portlist cif_cc

To get results like this:

If you want to turn it into a dashboard, you might end up with something like this:

You can automate the CIF query export to .csv, editing the results to remove the “#<space>” from the first row and copy the file to the Splunk lookup folder pretty easily. Once you’ve created the lookup file in Splunk, you can update it at any time without having to let Splunk know. The path to the file on your Splunk server would be something like /opt/splunk/etc/apps/<app name>/lookups/infrastructure.csv.

I plan to get some CIF dashboards built into the Security Onion for Splunk app over the next few months. (If you can’t tell I’ve already been working on them.) They’ll only benefit users who have access to a CIF server to perform the export queries for the file-based lookups, but it’s not that difficult to stand up your own CIF server and being able to correlate your network activity with current community based intelligence is more than worth the effort.