Showing posts with label BASE. Show all posts
Showing posts with label BASE. Show all posts

Thursday, April 14, 2011

BASE and Snorby: packet captures

Noticed that someone on the interwebz stated that Snorby captures full payload while BASE doesn't.  I read this as a comment on the Snorby pages.  Unless I'm totally off-base here, that's not the case, unless they're taking about something like netflows or something akin to it.  I believe one of the dev guys stated that only Snorby and Sguil offer full packet capturing.  That does NOT sound right and I believe he should clarify.

I'll dig up the link later, but it should be very apparent on their pages (it was to me, when I was perusing).

So, I pulled up my BASE console and looked at a sample packet.  To look at payload/packets within BASE, you go to a line item then click on the "ID", which would look akin to "2-278900". 

BASE capture view:


Snorby capture view:

Now, I don't see either lacking in that regard.  This is enough for the analyst to determine a false positive vs. a real attack/concern.

Now, if I wanted to further investigate, I can (in BASE), go to a listing, then click the offending IP (or the other IP...doesn't matter).  Then I click "Unique alerts" or "Unique IP links" under "Summary Statistics":

 
Unique alerts
This is basic stuff here.  It shows the history of that particular IP...it shows everything that was ever recorded from that IP, and you can dig down from there.  Source/Destination would show bidirectional traffic between the offending IP and whatever it was communicating with.  I'll get payload every time, IF (BIG IF HERE) the Snort signature is designed to capture payload and if the traffic even has payload.

I don't understand the argument of saying that BASE doesn't capture full payload.  Of course, BASE won't.  It's just a SEM.  Snort would actually do the capturing.  It would also totally depend on who sets up Snort and their requirements.  The admin that configures Snort may not even have all the sigs enabled.  But, BASE will show any payload that Snort does capture.

At this point, Snorby's search and analytical functionality is lacking.  I've said this before and got ridiculed by one of the Snorby developers.  We all know Snorby is relatively new when comparing it to BASE, but until the Snorby dev team enables better query functionality and better ways to quickly track activity, I'm going to stick to my guns.  A pretty (and even simplified) interface is one thing, but when it comes to the meat and potatoes, candy apples doesn't cut it.  As an analyst, I'd not want to lose any type of query features, as this will make a sometimes frustrating job all the more frustrating (been there, done that).

Lastly, I will NOT HAVE A PISSING MATCH over this.  I've been doing such comparisons for YEARS and am fully capable of judging what is acceptable and what is not regarding most security tools (that's why I get paid the big bucks), although I'm always objective in my opinions.  I definitely know what "best of breed" entails.  I'm going to put it out there:  Snorby is NOT best of breed.  I'd love it to be, but right now, it is NOT.  It has to help me sort/organize/filter information that helps me catch malware and such...much more that what it currently offers.  Right now, with Snorby, there's no such thing as digging down or simplifying the search through thousands of potentially bad security events.  "Packet capture options/Customer" isn't going to cut it.  It is good for the small investigation but not for the bigger tasks.  Let's be grown-ups about this topic and offer objective opinions.  If you can't do that, don't even try to leave some nasty comment on this blog.  Comments moderation is enabled.  Yes, I do require clarification on what is considered "full payload analysis", as I feel that's not enough of a description and could actually be relating to something else entirely different that the above (I doubt it, though).

Tuesday, March 10, 2009

tcpdump, Dell Mini, and BASE

So, I'm wondering why tcpdump is missing from the default install of my Dell's Ubuntu...doesn't make sense. I was having issues with getting my wifi card associated with my WAP and wanted to see the packets leaving the wireless interface, so I tried to bring up tcpdump, but it wasn't available. I actually had to hook a cat5 cable to the Mini to get this package, just to troubelshoot. I noticed the same thing with Suse about a year ago.

Apparently, tcpdump was created on the permissive free software license, per Wikipedia. I don't know if this is actually GPL or a derivative of GPL. The manpage doesn't mention what license tcpdump falls under and I'm sometimes wary of Wikipedia, as I like to find the facts on my own to validate (or invalidate) internet claims.

I'll research this and post my findings here.

On another note, I found a very cool bag for my Dell Mini, at Dell's website. I'll try to post pics and a link soon (from my Macbook, as the Mini's keyboard slows me down a bit).

Lastly, I somehow broke access to my MySQL database, so now my snort sensors won't report to it. It's been down for about 2 weeks and I don't have the time to fix it. I'm going on vacation for my birthday and hope to have some personal (ie, QUIET) time to myself to fix this. I'll be visiting my parents for my birthday this weekend and will see about shelling in to fix it remotely.

Monday, October 08, 2007

Snort/BASE and Analytics

This post is not related to Slackware, but will cover a method of utilizing BASE to conduct analysis. I'm including screenshots of my BASE setup when conducting analysis to describe how I utilize BASE and correlate logged activity. The below is NOT the only methods of conducting analytics with BASE. This method works for me and offers me quick results. In fact, if you've other methods, please post or e-mail me so that I can know different ways of using this SEM.

If you're not familiar with BASE, please visit the project's site. BASE is a browser-based console that presents intrusion detection logs in various readable formats.

Here is a screenshot of the root page:



Within the upper left-hand corner (within the blue field), there are what I call "canned queries", that will allow you to see certain subsets of data. The ones that I focus on the most are

- Today's alerts
- Last 24 Hours alerts
- Last 72 Hours alerts
- Most recent 15 Alerts
- Most recent 15 Unique Alerts
- Most frequent 5 Unique Alerts

Out of those, I focus on "Last 72 Hours alerts" most frequently.

Let us delve into the last 72 hours' events. Note in the image that I've circled this link. Please either follow along if you've BASE installed, or follow this diatribe and its image links. Either click the circled link or open it in a new tab or browser. I tend to open BASE links in a new browser instance, as it gives me a separate area to dig into a new investigation. This way, if I've several concerns, I've a browser window for each.

After clicking the 72-hour link, you should see something similar to below:



I've split the browser window into two pages, since the alerts scroll down the page. For this exercise, we're going to focus on the second image, specifically the "WEB-PHP remote include path" events (toward the bottom). I chose these events because I wanted a good example of how to correlate events per IP. Click on this link (circled in RED) or open the link in a new browser/tab. You may see something similar to the following browser window:



In this example, 37 alerts are showing, with various source IPs (or what I call SIPs) and, in this case, one destination IP (what I call a DIP). Note that there could be more than one DIP, such as when you've two web servers or two IPs that are sharing a NIC. In the above browser window, I've a few IPs apparently attacking my web server. How do I make it so I see one line per SIP yet get enough situational awareness that I have an idea of which SIP generated what number of alerts on a DIP? The "Unique IP Links" in the upper right corner (circled in RED). Click on that link and you should see something similar to the following:



What's changed? The traffic is now matched based on unique traffic. Let's focus on "90-179-94.adsl.cust.tie.cl/200.90.179.94". This IP shows as a source and destination IP. Why? Because the IDS sensor logged both the web server's sending and receiving traffic (bi-directional). Note that this only happens when a response signature triggers (we'll see this in the next screenshot). If the web server response does not trigger a signature, the IDS won't log an alert. This is where signature tuning comes in handy...you really don't want to see legitimate HTTP 202 (OK) traffic being logged unless absolutely necessary. You only want concerning traffic to be logged. Now, note the brackets (sloppy) in RED in the above right screenshot. I'm going to click the 200.90.179.94 IP because I want to know what's going on there. I also observed this IP in the lower half of the screen (not screenshotted for brevity) alerting on my other IP (the NIC is dual-homed). Click on the IP and you'll see something similar:



You can study this page for a moment, but its just a page to gain a further understanding of who owns the IP. The real resources on this page are circled in RED. We'll click on both, starting with "Source/Destination", then "Unique Alerts". Open them in separate windows so you can compare. While both may show similar alerts, each is valuable:



The view on the left shows every unique attack and attack response regarding the attacking IP. The view on the right shows a summary of the attacks, with a description of "4 unique alerts detected among 16 alerts on 200.90.179.94/32". The right view also shows that you can dig down into each category of alert, if you chose.

Which view do I rely on? For a quick view, I usually use the right screenshot, but I also use the left screenshot method for when I want to see everything the attacking IP did (and how my server responded). Note that I didn't obfuscate the whole of my server's IP. I wanted to show an example of this method of analysis showing EVERYTHING the attacker did, including reaching out to both of my IPs.

I'm not going to go further. I just wanted to highlight how BASE can be used efficiently. Anything further would get into payload analysis, which is beyond the scope of today's post.

Stay tuned for a possible swf2vnc movie capture of using BASE. This will happen as soon as I can figure out how to mask my public IPs. This task may get me to delve into using my Macs to edit the SWF movies (we'll see if that is possible, with free- or shareware).