Securing Splunk Free Version When Installed On Security Onion Server (or anywhere else)

This stroke of genius comes directly from the man behind Security Onion, @dougburks, and solves two problems, one serious the other functional. Splunk’s free version allows you to index up to 500 mb/day, but does limit some (even basic) capabilities, most important of which is disabling authentication. If you’re running Splunk free version on your Security Onion server and access the server remotely (from another workstation), I highly suggest you make this your standard access process. The instructions below work on Ubuntu distributions and if you followed Doug’s advice about using a Security Onion VM as your client, this should work perfectly as long as you haven’t configured the VM as a server.

The method can be used on a Windows or Linux client. The instructions below focus on Linux, but googling “windows ssh tunnel how to” should get you a good start. In the example below port 81 is the Splunk port. If you installed Splunk on a different port just replace 81 with it.

The approach uses an SSH tunnel and is really easy to setup. On your Security Onion/Splunk server you’ll want to make sure SSH is enabled in Uncomplicated Firewall (ufw).

sudo ufw status

You should see 22/tcp ALLOW in the results. If it says DENY, then enable it:

sudo ufw allow 22/tcp

Next configure ufw to block (yes I said block) Snorby, Squert and Splunk ports:

sudo ufw deny 81/tcp
sudo ufw deny 443/tcp
sudo ufw deny 3000/tcp

From a remote Linux host with openssh-client installed:

sudo ssh username@securityonion.example.com -L 81:localhost:81 -L
443:localhost:443 -L 3000:localhost:3000

Replace username with the Security Onion/Splunk server user and securityonion.example.com with the hostname or IP address of your Security Onion/Splunk server. This command essentially tells your client to pass anything destined to localhost ports 81, 443 or 3000 to your SO server on it’s localhost port 81, 443 or 3000 via the SSH tunnel. The command requires sudo due to accessing privileged ports, so you’ll be prompted for your local password then again for the remote SO server user’s password. After authentication, you’ll have an active SSH terminal session to the server.

Launch a web browser and browse to any of the following:

http://localhost:81 – Splunk
https://localhost:443 – SO Home/Squert
https://localhost:3000 – Snorby

It’s that simple.

If you recall I mentioned a “functional” advantage of using this approach. In the Security Onion for Splunk app, I provide links to Snorby and Squert, but unfortunately, the user must configure the urls to fit their environment if they access the tools remotely. The default config uses “localhost” as the server, so if you’re following, if you use the above method to access Splunk securely, the Snorby and Squert links work out of the box. =)

Thanks and hat tip to Doug for this little gem! I had to bite my lip whenever I recommended someone install the free version of Splunk due to the authentication limit, but now I don’t have to.

Announcing: Security Onion for Splunk Server/Sensor Add-on

I wanted to do a blog post on deploying the Security Onion for Splunk app in a distributed environment, where Splunk, Security Onion server and Security Onion sensor were all on separate hosts. I found it was easier to just build an add-on and let the README do the blogging. The add-on shouldn’t change or require updating nearly as much as the full app, only requiring updates when new logging is added at the server or sensor, as Bro is want to do at times (thank you very much). All the field extractions and transformations happen on the Splunk server. You can download the add-on here (once approved).

README

Overview:
Security Onion Sensor Add On eases the configuration of a multiple Security Onion sensor deployment. Install the Splunk Universal forwarder and untar this app to /opt/splunkforwarder/etc/apps. Edit /opt/splunkforwarder/etc/apps/securityonion_addon/local/inputs.conf to disable specific logs depending on whether you’re indexing from a
server or sensor that is remote to the Splunk indexer.

Installation:

Install Splunk Universalforwarder:

sudo dpkg -i <filename>

Start Splunk and accept the license

splunk start
splunk enable boot-start

Configure the universal forwarder to forward to a specific indexer:

splunk add forward-server <host>:<port> -auth <username>:<password>

Default receiver port is 9997. Username is a Splunk administrative user. Optionally, to enable secure Splunk communications the following command can be used to specify a certificate, root CA and password.

splunk add forward-server <host>:<port> -ssl-cert-path /path/ssl.crt -ssl-root-ca-path/path/ca.crt -ssl-password <password>

Download the Security Onion for Splunk Addon and extract the file to the Splunk forwarder apps folder:

sudo tar -C /opt/splunkforwarder/etc/apps -xvf securityonion_addon.tar.gz

Edit the local inputs.conf file depending on your deployment scenariot:

cd /opt/splunkforwarder/etc/apps/securityonion_addon/local/

Default config files for the following deployments are included:

inputs_server.conf
inputs_sensor.conf
inputs_server_and_sensor.conf

Just copy the appropriate file to replace the default inputs.conf (default deployment is server/sensor). For example, if you are installing on a sensor:

sudo cp inputs_sensor.conf inputs.conf

When you’re done, restart the Splunk forwarder:

sudo /opt/splunkforwarder/bin/splunk restart

As long as your indexer is receiving events you should be good to go.

Security Onion for Splunk 1.1.2 – Workflows and Event Views

Having spent the last few weeks working with the Security Onion for Splunk app and CIF (Collective Intelligence Framework) in addition to the recently released DShield for Splunk app, I found some of the workflows weren’t as easy to pivot from the dashboard panel to workflow queries as I liked. The latest release addresses this issue while expanding on the workflow capabilities already available.

Where you’ll notice the change the most is in the drilldowns from panels. I left the Overview dashboard alone, but you’ll notice on most all the others that when you drill down on an event in a panel, the results now show an event listing with key fields selected instead of the cleaner table views. I’m trading aesthetics for functionality. The event listing provides quick access to workflows, and that is where this update shines.

For example, the Monitors > Sguil Events panel screenshot below shows a drilldown on a Zeus alert. From the workflow dropdown menu on the left, you can now query DShield for Splunk app and Robtex, in addition to CIF, for source and destination IPs.

It gets better with Bro IDS when we look at HTTP Mining.

In addition to source and destination IPs, Bro results containing domain or md5 fields (typically Bro HTTP and SMTP entities logs) will now allow you to query those values directly against CIF. CIF and Robtex searches open conveniently in a new tab. DShhield queries will spawn a new window for now. There is some difference in how Splunk workflow generates links versus searches, where the former will open a new tab, the latter a new window that needs further exploring.

NOTE: You will likely have to reconfigure the CIF workflow server and API keys. For instructions reference my previous post on Querying CIF Data From Splunk.

If you haven’t checked out CIF but want to get a sense of what it’s all about, head over to josehelps.com who has generously stood up a public instance of CIF. You can fill out the form to request an API key and give it a spin.

I’m currently exploring other ways to integrate correlation against the DShield for Splunk data and am working on adding a DShield mining dashboard that will likely be a prototype for future CIF mining dashboards, so more goodness to come.

Happy Splunking!

Security Onion 1.1 for Splunk

README notes w/ bonus comments for Version 1.1

I’ve added an input for Bro’s capture_loss.log which now displays on the SOstat Security Onion monitor in a time chart paired with Snort packet loss. To enable this log in Bro edit:

/usr/local/share/bro/site/local.bro

and add the following:

@load misc/capture-loss

You’ll have to check and install Bro for the change to get loaded.

sudo broctl
check
install
exit

and you’re done. It takes a few before the first logged event will show so give it a bit before you worry if it’s working. (The main reason I added this aside from the value is it will likely be standard in SO down the road. It’s completely optional and if I didn’t tell you about it you’d be none the wiser unless you did have it turned up, in which case you’d be pleasantly surprised.)

I also tweaked the sguild inputs to exclude “{URL” events. This data is already being consumed via bro_http so it should cut down on the licensing volume. (This will save you a ton of indexing volume and alone is worthy of updating!)

Monitors Dashboard

  • Returned misc-activity to the Sguil panel. (I’d yanked it due to the volume of URL events, but since we’re leaving those to bro_http, it’s value returns.)
  • Added date/time and raw event to drill down display for the FTP Args panel.

GeoIP

  • A drop down list has been added to GeoIP allowing you to search GeoIP by sourcetype which should reduce query times for more targeted views. The map also now includes drill down capabilities with results appearing below the map when selected. (Neatest update. Much more efficient than relying on all connections and lets you get geo visibility into each sourcetype.)

Mining

  • Added drill down to the time chart panels for HTTP and SMTP mining

(The following additions bring a little asset and vulnerability management to the game via two dashboards: PADS [passive asset detection] and  Bro’s Known Knowns.)

  • Added a PADS dashboard (similar to HTTP and SMTP mining) searchable by Name, Classification, Source IP, Source Port, Destination IP, Destination Port, Protocol, and Severity.
  • Added a Known Knowns dashboard. Includes: Known Services; Known Software searchable by Name and Type; and Known Certs searchable by Country, Common Name, Certificate Issuer Subject, Location, Organization, Organizational Unit, Port Number, State, and Certificate Subject.

PADS

  • Created an event type for PADS in addition to the PADS Mining dashboard.

SOstat

  • Updated SOstat SO to include Bro capture loss in addition to Snort packet loss. (Also improved the packet/capture loss displays to be more “deployment friendly” tracking by host or sensor.)

Enjoy!

Few screenshots for @remor:

1.1 GeoIP1.1 Known Knowns

1.1 PADS

Security Onion 1.0 for Splunk

Today I give you version 1.0 of the Security Onion app for Splunk. While previous releases aimed at core functionality and essentially getting the data in with rather minimalistic views, version 1.0 brings a bit of a overhaul to several dashboards and welcomes Splunk Visualizations to the party.

For starters Overview now shows Sguil events by classification. The Overview dashboard is intended to be a quick pulse check of the environment and in this case I think leveraging classifications provides a cleaner heartbeat, so to speak.

Squil events by name has moved to the Monitors dashboard and in further effort to reduce clutter, I’ve excluded OSSEC and misc-activity classified events.

The Mining dashboards are where the major overhauls have occurred. The General Mining dashboard now contains a couple drop down lists to provide greater access with fewer concurrent searches. HTTP and SMTP filename searches have been consolidated as well.

But where things start to get cool is the Interesting URI Values panel:

The drop down list allows you to search Bro HTTP detected URI values for matching regex values. Due to the transitory nature of URI values in attacks, I’ve setup the drop down list to populate via an external lookup from a .csv file. The file is located at

/opt/splunk/etc/apps/securityonion/lookups/mining_uri_values.csv

and contains two fields: value and label, where value is a regex value that will be
searched for in URIs and label is the name you want to appear in the drop down.

The idea is to enable users to perform historical searching against newer active malicious URIs to identify potential victims retroactively or find similar patterns. I’ll likely be posting an updated copy of the file periodically as well, so suggestions for additions are welcome.

HTTP and SMTP Mining also get a lot cleaner in this release, going from a multiple panel view to a drop down list with table view of events and a time chart. HTTP Mining:

and SMTP Mining:

Last but not least, the previous incarnation of SOstat is now broken up into two views: SOstat Security Onion, for service status and Snort/Snorby details, and SOstat *nix, for details about the system (top, ifconfig, NSM log archive listing, etc). I’ve also added (as a proof of concept and because it’s really cool) a Security Onion Data Flow view that leverages the Splunk Visualizations app. I hope to do more with this in the future as I think it has a lot of potential, especially for visualizing replayed events or monitoring a host in real time.

For more details on the Splunk Visualization app and a video demo, check out http://metasplunk.com/projects/particle. It does require an Adobe Flash upgrade on a Security Onion build (achieved easily via Ubuntu Software Center) and can be browser intensive, so be warned.

I hope you enjoy the changes and wish you good luck finding evil!

Querying CIF Data From Splunk

Collective Intelligence Framework (CIF) is a feed parser that brings a vast wealth of collective threat intel to your fingertips. (Update: Kyle Maxwell has posted a great introduction to CIF at http://overhack.wordpress.com/2012/05/07/introduction-to-the-collective-intelligence-framework/.)  There’s a client app (perl or python, which is being rewritten presently) and browser plug-ins for Firefox and Chrome to make running queries simple. If you have access to a CIF server, it’s very easy to incorporate CIF queries into Splunk’s event and field menus. For Security Onion app users, this feature is coming, but you’ll need to edit the workflow to configure your CIF server and api key. Once configured you’ll see the item added to the event menu:

and/or the field menu:

The search results will open in a new window, and if there were any matches you’ll see something like this:

To add a workflow menu item in Splunk, go to Manager > Fields > Workflow actions and reference the screenshot below. If you’re a Security Onion user, you’ll need to enter the IP or hostname of your CIF server and a valid API key.

In the Security Onion app for Splunk the dest_ip and domain fields can be queried via the fields menu. If you prefer to edit/create via terminal:

CIF provides an enormous amount of intelligence for very little time, money or effort on the end users part and it’s future is looking very bright due to it’s flexibility in parsing content and the ease of interacting with data from other applications like Splunk. Once the python client is released I’ll look at building more correlation with CIF directly into the Security Onion dashboards.

 

Splunking the Onion

Five months brewing, I’m pleased and excited (and mostly ready to spend some time watching playoff hockey) to announce the initial release of Security Onion for Splunk has been submitted to Splunkbase (should appear here once approved). I’ve talked about Security Onion before, but in brief it’s an incredibly powerful compilation of open source network security monitoring tools that is so easy to configure and deploy it probably makes some commercial vendors blush. I started playing with Splunk about 6 months ago and it didn’t take long to realize what a powerful combination it could make with Security Onion.

Splunkbase, Splunk’s repository of community contributed apps, already had some apps relevant to Security Onion, but they were tool specific, like Splunk for OSSEC and Splunk for Snort. I wanted to create a broader canvas, pulling together events from as many layers of the onion as possible. I also wanted a better way to visualize Bro IDS logs for event correlation and mining events for incidents.

I want to emphasize this has been a learning process. The last 5 months have been spent learning Splunk and figuring out how I could improve access to the data from Security Onion tools I have spent the previous year learning. I have a lot to learn on both fronts and hope this app will ultimately reflect that as it matures. While some of the Splunk views have been tested with lots of data, the majority of testing has been done on my home install or with sample packet captures. So if you give it a spin, keep that in mind and please let me know if you run into any issues that need to be addressed for broader deployments.

So without further ado…splunking the onion.

Overview

The Overview provides visibility into the current status of your Security Onion (hereafter referred to as SO) deployment. The first panel displays recent Sguil events with total count of events and a sparkline to show the event trend over time, sortable by name or total number of events. The second panel leverages Splunk for OSSEC to show recent OSSEC events, followed by a timechart of Bro IDS notice events in panel three. From these three panels you can get incredible insight into what has been going on in your environment and the fourth panel pulls everything together to give you a timechart of all SO log activity.

Splunk provides some neat drilldown capabilities and I’ve included them on most of the panels throughout the app. Clicking on any result will provide a drilldown menu at the bottom of the panel showing specific event data. In the screenshot below, I’ve drilled down on SSL::Invalid_Server_Cert events from the Bro Notice panel and Bro SSL events in the Activity by Sourcetype panel. Additionally, the time range picker’s associated with each panel allow you to adjust your visibility over time on a panel by panel basis (notice the Sguil Events are displaying the last 4 hours of activity, while OSSEC is displaying the last 7 days).

Monitors

The Monitors view takes us a step deeper into the SO event data. Six panels give us quick access to Sguil Events by Priority, Bro Weird events, Bro SSL Validation Status Messages, Bro HTTP Status Messages, Bro Dynamic Protocol Detection events and FTP arguments monitored.

As with the Overview, drilldowns are in play. In the screenshot below you can see how easy it is to piece together the bits of an incident for targeting your investigation. In this case, I’d be heading over to the IR Search view and giving 192.168.10.128 a deeper look (which we’ll do momentarily).

GeoIP

The GeoIP view includes a geographical representation of events accompanied by an alphabetical listing of those events by destination country. As you can see from the screenshot, selecting a country from the list on the left will provide a drilldown listing of Bro Connection events to that country.

IR Search

Now let us go take a look at 192.168.10.128. The IR Search allows you to search by source IP, destination IP, source or destination ports and gives a holistic view of activity based on your search parameters.

For starters, we see Bro Notice and Sguil events specific to the IP address being investigated paired with a breakdown of all activity seen from our source IP by sourcetype in a timechart, followed by Bro Weird events, SSL Validation Status Messages and HTTP MIME Types associated with the host.

Continuing down the page, we see HTTP Filenames and FTP Arguments detected by Bro IDS, Bro Dynamic Protocol Detections and a grand finale of all events, line by line, of activity from our suspect IP.

Web Monitor

The Web Monitor view is an attempt at expanding the “reuse” potential of SO collected data, by providing a basic, high level view of HTTP related activity being monitored. Geared less towards investigative analysis, it can be used to supplement existing web filter capabilities, or for home or small office deployments it can provide great awareness of HTTP activity of monitored hosts. Two pie charts show activity by source and geoip, followed by the top source and destination IPs, and domains.

Mining

In using Bro IDS, I’ve noticed some events can be direct indicators of activity, while others more indirect leading you towards potential issues or activity that is otherwise suspicious. The Mining view attempts to ease the process of identifying items of interest with six table panels with drilldown capability: Bro Weird Events (anomolous activity), Bro Dynamic Protocol Detection Events, Bro HTTP Status Messages, Bro SSL Validation Status Messages, Bro HTTP Filenames Detected (exe, bat, cmd, pdf, jar, swf, doc, xls, sh) and FTP Arguments detected.

The Bro HTTP Filenames Detected can often be a dead giveaway of suspicious activity, but others can be more subtle. For example, deploying an SO sensor in front of critical web servers gives visibility into HTTP Status Messages, so you can quickly and easily monitor Forbidden or Not Authorized attempts to access web sites. Similarly, Bro SSL Validation Status Messages can help you monitor untrusted or expired certs.

OSSEC

The OSSEC menu leverages the Splunk for OSSEC app, which is a pre-requisite for Security Onion for Splunk. I won’t go into too many details on it. While I leverage Splunk for OSSEC for the data inputs and field extractions to tie into Bro IDS and Sguil, the OSSEC app itself is very well done and provides excellent visibility, via dashboards, reports and searches, all canned and ready to be consumed directly from the SO app menu.

Snorby/Squert

These menu items are designed to link directly to Snorby and Squert. Unfortunately, I’ve not figured out a way to dynamically generate the links based on the SO server hostname, so they point to http://localhost:<port> by default. I’ve included instructions in the README on how to modify those to fit your deployment.

Long term, I do not plan on trying to mature this app to replace the other tools included in SO. They all have unique value and use cases: Sguil is great for analysts; Snorby is great for Snort; Squert provides a good high level view. If anything I hope to improve the integration over time.

SOstat

SO includes a status monitoring script called “sostat” for verifying the status of agents, collecting disk and performance data, and stats related to Sguil and Snorby. I actually delayed the release of the app until I could get this piece integrated as the importance of monitoring your SO deployment is as significant as the data it’s collecting.

The Server/Service Status panel shows the last two status changes. The first service status listed is the status when SOstat last checked. If there is a second status listed for the same service you can see when it last changed. In the screenshot below you’ll see ossec_agent (sguil) with a status of FAIL on 4/13 @ 9:33. Towards the bottom of the list you’ll see it listed again with a status of OK on 4/11 @ 10:20.

SOstat also monitors Snort packet drop percent, disk status, interfaces, system info (via top), Snorby top 50 events and top events from the previous day, and directory listings for the NSM log archive.

What’s Next?

  • GeoIP – add tracking by event type, name and severity.
  • SOstat – implement Bro status monitoring; trending charts where applicable, like disk utilization.
  • Optimize searches and views for efficiency.
  • Suricata – incorporate and test.
  • Sideview Utils for Splunk – I’m going to start exploring where this add-on can benefit views and the interactivity of the Security Onion app.

If you find any bugs, have suggestions on how to improve the app or have ideas for correlation searches that could help improve the usability, effectiveness and efficiency of detecting and investigating events, please feel free to contact me at brad@eyeis.net or via Twitter: @bradshoop.

Clap…Be Amazed…Now Go Defend

What does it tell you when SC Magazine’s Best Security Company of the Year bases it’s business on helping organizations recover from all the failures of the layers of prevention and mitigation on which we focus so much of our time and money? The typical IT security environment today is focused on two things: prevention and vulnerability management. Problem is you can’t prevent what you don’t know is coming and with most preventative solutions in place today your best hope is that you’re not the first (or earliest) to see an attack and that whoever is can and will share that intel. Risk worth assuming? Are we better served with the Sisyphean task of continuous patch management than we would be were we to focus most of those resources (people and money) on early detection and response?

Whether you agree with these types of awards or not, Mandiant deserves the recognition. They’re a great company and group of people and are model givers to the Info Sec community which helps people like me do my job better. They’ve assembled some of the best talent in the business as well. All deserving reasons.

I’ll give you one more.

For all the money we spend in Info Sec trying to prevent attacks, and a lot is spent, what happens when an attack gets through? We know prevention is going to fail. Yes. Prevention WILL fail and regularly does. If you don’t have any level of network monitoring in place then you’re doing it wrong. And there’s no excuse for it. In fact, there’s no excuse for not leveraging the latest and greatest technologies available to mitigate attacks when the financial cost is moot and your security posture could be strengthened immensely. For larger organizations who already have commercial solutions in place, are you able to afford the extent of coverage required for maximum visibility? What if you could get that coverage without the lofty hardware and support costs?

How do you save money on network security monitoring? You open your eyes to the low cost potential of open source initiatives and brilliant minds eager to share, like a few of those that Mandiant has shepherded through the Info Sec world. Doug Burks (@DougBurks), of Mandiant, has provided one such solution with Security Onion, a network monitoring Linux distribution that is only limited by the hardware you have at your disposal on which to run it. And what’s even better? He’s made it so easy to setup and configure that even complete strangers to Linux can figure it out. If you know how to boot off of a DVD you’re in business. Need a deployed infrastructure? Setup one Security Onion host as a server and deploy others as sensors. Standalone works just as well. Heck, I run it in a virtual machine on my laptop and it’s the best host-based IPS money can buy…but doesn’t need to. I’m not kidding about how easy this is to deploy and if you take 20-30 minutes and watch one of Doug’s presentations (links available on the Security Onion site) demonstrating just how easy it is, you’ll thank me. Then you’ll show him thanks by downloading it.

When you look at the arsenal of monitoring tools that Security Onion brings to the table you’ll be even more amazed as you peel back the layers and get a handle on just how powerful the solution is.

You get Snort, the great open source intrusion detection/prevention system from Sourcefire (another incredible company; see my Razorback post then go download the new version). Maintaining Snort with Security Onion via PulledPork for signature management is a breeze and easily supports Snort (get thee an Oinkcode! ) and Emerging Threats signatures.

You get full packet capturing with Sourcefire’s Open Source Daemonlogger.

You get OSSEC, a host-based intrusion detection system, which helps you monitor your network security deployment out of the box and the capability to extend that detection to Windows, Linux, and MacOS via the OSSEC agents.

You get Bro IDS, an alternative approach to IDS that I’m just now learning myself and have been continually blown away by the visibility it provides. I hope to cover it more specifically in a future post, as educational resources for using Bro are a little scarce. It’s described as a network analysis framework and it comes preloaded with a few obvious examples that will give you an idea of what the framework can do. It collects basic connection data for every connection, http, ftp, syslog and SMTP data, SSL certificates (both known and the suspicious unknowns), SQL injection attacks, and more. It will continue to amaze you when when the framework reveals its capabilities with events like HTTP::Malware_Hash_Registry_Match, indicating a file has been downloaded, the file hashed and the hash matches a known malicious software hash in the Team Cymru Malware Hash Registry.

All that and more, packaged up nicely saving you all of the headaches of deploying a comprehensive network monitoring suite of Open Source solutions from scratch.

Once you start collecting data you’ll have the powers of Squil, Squert, and Snorby at your disposal for monitoring and analysis. If you prefer, you can also grab a copy of Splunk.which installs fairly painlessly on Security Onion. (Only issue I had was the default Splunk port was in use; I typically use port 81 without problems.)

Take a day. Install a Security Onion VM. Run some sample pcaps through it. See how easy it is to deploy and detect the activity. Now think how much better you might be able to defend with this kind of visibility at next to no cost (how many old servers are being retired and replaced with virtual machines? Reuse them!). Then with all the money you’ll be saving go hire some gifted local talent with dedication and passion to learning and an accepted understanding that they’ll always be a day behind. Do this and you’ve improved your overall security posture immensely and put yourself in a much better position to detect and respond to an incident. Even if you aren’t doing the responding! If the FBI shows up at your door, you’re going to need help. The data you would be collecting would be invaluable to resolving an incident efficiently and effectively.

Now do you start to see why I think Mandiant deserves Best Security Company recognition? And this is just one example. Have you looked at the free tools they offer? Have you ever heard of TaoSecurity Blog? Dustin Webber, the author of Snorby (although he’s with Tenable now I believe)? Their efforts with OpenIOC.org? Jamie Butler, who literally co-authered the book on rootkits? The latest is Michael Sikorski’s contributions with his new book Practical Malware Analysis accompanied by the release of FakeNet, a malware network analysis tool. The list goes on. They’re a company of talented people, providing tools and sharing knowledge to build stronger and more capable communities to build a safer Internet.

Any company like that deserves the title Best Security Company, especially when compared to companies who profit from you for solutions that you buy with the  expectation that they will fail you at some point. Mandiant profits when those companies fail you. And then they (Mandiant’s family) turn around and give, yes give as in free, you a way to do a lot if not more than what you’re paying good money for, or aren’t paying for at all because you can’t afford it. They’re doing something about enabling small/medium businesses and personal networks to adopt affordable security approaches. They’re providing security practitioners with tools and technologies to perform better, defend more wisely and “find evil” more efficiently with less technical skill than was required 2 years ago. They’re doing it in their 9-5 jobs. They’re doing it as hobbyists. They’re doing it as caring volunteer citizens.

They should be recognized and thanked…

And you should go download Security Onion and start protecting your personal and professional assets…like now.

Setup Razorback Release 0.3.0 in VirtualBox

If you’ve not yet heard of Razorback, start listening. Sourcefire, the company behind the incredibly popular and effective Snort IPS, are working on a new project to extend detection capabilities beyond their traditional IPS. The best part: much like Snort, Razorback is an open source project, which will likely be incorporated into Sourcefire commercial solutions at some point while still maintaining the free version. In the age of security budget cuts despite the so-called “Year of the Hack” free is a good thing.

So what is it? Razorback is an attempt to separate traffic capturing and detection. Traditional IPS solutions capture traffic and analyze it real time, which has limits in terms of exactly how much analysis and reconstruction it can perform. Razorback takes the approach of capturing data based on what type of data is being exchanged then submitting content for analysis to additional processes, such as ClamAV scans, dissecting PDFs, submitting file types to Virustotal, and more. Check out the Sourcefire team’s presentation at DefCon 18 if you want to learn more about it before diving in.

Razorback is young, but it’s growing up fast and the latest release overcomes one of the biggest obstacles in deploying the solution for testing: setup and configuration. Sourcefire has released a virtual machine appliance that can get you a Razorback installation up and running in less than 20 minutes. I’m going to walk you through doing just that with VirtualBox.

First you’ll need a PC with at least 8gb of RAM and two NICs. You’ll also need the ability to mirror the traffic you want to monitor via port span, hub or tap. You can download VirtualBox here and don’t forget the VirtualBox extensions here. The Razorback VM can be found here.

  1. Install VirtualBox then install the VirtualBox extensions. Defaults in both cases should be fine.
  2. Launch VirtualBox and click File > Import Appliance. Click the Choose button and browse to where you downloaded the Razorback virtual appliance file, Razorback-0.3.0-Release.ova, and click Open then Next. I’d suggest selecting the check box to re-initialize the MAC address of the appliance’s network card then click Import. It should only take a couple minutes to import the appliance.
  3. Once the appliance is imported, the first thing you’ll need to do is edit the VirtualBox network settings. Right-click the Razorback-0.3.0-Release machine name and select Settings. When the Settings window loads, select Network.Razorback VirtualBox Network SettingsFirst we want to make sure the first network adapter is set to Bridged Adapter. Make sure the “Name” field indicates the network card you want to be the management interface. Next click little triangle next to “Advanced.” You’ll need to change the “Adapter Type” to get it to work with FreeBSD so choose “PCnet-PCI II (Am79C970A).” Since this is only a management interface, don’t worry about Promiscuous Mode. Do NOT create or configure a second adapter for the monitor interface…yet. Choose OK when you’re done with the settings.
  4. Right-click the Razorback-0.3.0-Release VM and choose “Start” for your initial boot. It will take a couple minutes to boot and once it’s done you’ll see a command line menu and if you dither you’ll start to see some “razorback masterNugget” log events writing to the console. Click in the VM and press enter to see the menu again if it gets away from you. You should see a URL for the system management web interface.Razorback ConsolePort 8080 is the admin interface, port 80 is the user interface. If you don’t see the URL/IP address or if it’s not valid, reconfirm the network settings above.
  5. Open a web browser and browse to http://<Management IP>:8080/. Login as admin, password: razorback. Click Network > Interfaces > Add Interface. This is where you configure the Razorback management interface. The NIC should be le0. You can give it whatever interface name you like and setup DHCP or a static IP for the management interface. Scroll down and Click OK when you’re done.
  6. Shutdown the appliance. You can do so either from the command line menu or from the web UI.
  7. Once it’s shutdown, go back into VirtualBox Settings > Network (right-click the Razorback VM). Now we need to add a second adapter where your port mirror/span/tap should be. SaaC (Snort as a Collector) will monitor this interface. So click Adapter 2, enable it and set it to bridged. The “Name” should be the physical network card used for the port mirror. Click Advanced and set the “Adapter Type” to “PCnet-PCI II (Am79C970A).” This time we want to set “Promiscuous Mode” to “Allow All.” Click OK.
  8. Restart Razorback virtual appliance.
  9. This is where it gets tricky…if you don’t know vi. Basically, we need to edit /etc/rc.conf to configure Snort to monitor the proper interface. If you don’t know vi you can always learn the basics in 5 minutes here. From the Console Setup text menu on the Razorback VM, enter “9” to get Shell access. Type “vi /etc/rc.conf” and scroll to the bottom of the file. You’re looking for the lines following: “## TAP/Span interface on em1”.We need to change “em1” to the interface name “le1” on both the ifconfig_le1 and snort_interface lines as seen in the screen shot above. Save the file.
  10. Back to the browser, access the Administration web UI at http://<Management IP>:8080. This time, head to Services > Control Services and click the On/Off button next to Snort.Razorback Administration Control ServicesIf everything goes as planned the button should turn blue/on.
  11. Open up a new tab and browse to http://<Management IP>/ and login as admin, password razorback and watch for events and more importantly alerts.

That’s about all there is to it. Monitor performance as high bandwidth can really tax the system. If you have the resources, adding more RAM to the VM can help.

When you start to see events and alerts you’ll see something like this:Clicking on the Alert count will show you which inspector alerted and provide a little information as to why, in this case OfficeCat found an Office vulnerability. Drilling into the Metadata count can get you a good bit more detail. In this case the vulnerability was found in a downloaded file from Yahoo!Mail.And we can tell from the HTTP Response what file we need to be worried about. This type of data can be really handy for creating indicators of compromise (openioc.org).If you give it a go, please consider joining the Razorback mailing list and supporting the development with testing feedback.

Happy hunting!

Giving and Being Thankful – MIRcon 2011

MIRcon 2011 is fast approaching. I’ve been putting the finishing touches on my presentation and I hope it offers some ideas for dealing with infected hosts with Mandiant’s Intelligent Response and other tools you either already have deployed or can have for free. Well free to you. They’re really paid for with the blood, sweat and tears of some of the brightest, most giving and caring professionals you’ll ever encounter in any field…and Mandiant gives away a bunch of very useful ones. Which is why I decided to present.

I likely wouldn’t be attending MIRcon this year if I weren’t presenting. Budgets are tight and I prefer not to be away from my family anymore than I have to. I don’t have the technical ability or in depth knowledge to create some of the incredible tools freely available to anyone who cares, like Redline, Web Historian, and the “blows my mind/how cool is that” Heap Inspector from Mandiant or the LiveCD distributions like the SANS Investigate Forensic Toolkit (SIFT), Snorby/InstaSnorby, or Security Onion to name only a few.

It’s often lamented that we, the defenders, don’t share enough and to an extent it’s true. The attackers are sharing and trading tools and tactics in shady undergrounds, while the defenders are cloistered in their walls with minimal awareness of how surrounding castles fair. Look at all the breaches that have happened this year. How many have resulted in details of exactly what happened, how it happened, what was lost and why it can happen to anyone. The more we understand attacker methodologies the better we can prepare, detect and respond. We shouldn’t have to learn that lesson over and over again from company to company, living Madonna’s “Like a Virgin” each time it happens to an organization. Cybercrime is a war…it helps if allies actually talk and share.

But where the security community has proven to be a shining example of sharing is in the tools market. For most commercial detection and prevention tools there are freely available alternatives. They may not be for the weak or squeamish or be easy to find, but they’re effective, can do the job and are getting better and easier to use every year. These tools enable professionals like me. They allow me to go deeper and further than I may have without them. They make me better at security. They make me smarter than I am. They make me want to try to give something back. Like this blog. Like presenting at MIRcon.

I’m not a fan of public speaking, mostly due to nerves and not enough experience/comfort doing it. But my incredible wife constantly reminds me with her words and actions how important it is that we give back. That we share what we do have or know or create if it can help someone else through a struggle or to overcome a problem. So I’ll take the butterflies and try to overcome the awe and wonder of speaking at a conference where the likes of Richard A. Clarke and Michael Chertoff are keynoting. It’s more than worth it to try and give a something back, even if it’s just a little.

To anyone who has given something of themselves for the betterment of security, thank you. I’m looking forward to being able to thank some people in person for their efforts at MIRcon.