Thursday, February 08, 2007

IP Tagging

I just read Godfadda's blog entry about a prototype system for tagging IP addresses in Splunk. His system analyzes IP addresses as they're about to be inserted into his log/event tracking system and cross references them with several databases in order to generate additional tags to provide additional context to the event.

Right now, his system deals with geography ("which branch office is this in?") and system role ("Is this an admin's workstation, a server or a public PC?"). I really like this idea, as it provides valuable context when evaluating events.

In fact, I've done a lot of thinking recently about how to add more context to NSM information, but it wasn't until I read this article that I realized that what I was looking for would probably best be implemented as a tagging system. What if Sguil were to incorporate tagging? Well, we'd first have to figure out what to tag. I'd like to be able to tag several types of objects:

  1. IP addresses
  2. Ports
  3. Events
  4. Session records
  5. Packet data for specific flows (probably would treat the pcap file and any generated transcript as a single taggable object)

As for the tags themselves, the system should automatically generate tags based on some criteria, just as in Godfadda's system. Maybe it would automatically tag everything in my exposed web server network as internet,webserver, for example, or maybe it could correlate my own IPs to an asset tracking system to identify their function and/or location.

But here's the part I think would be even more useful: I'd like to have the analyst be able to tag things on-the-fly, and later search on those tags to find related information. For example, if someone has broken into my web server, I could tag the original IDS alert(s) with an incident or case number (e.g., "#287973"). Perhaps this would also automatically tag the attacker's IP with the same number. As I continue to research the incident, I will probably perform SANCP searches, examine the full packet data and generate transcripts. I could tag each of the interesting events with the same ID. At the end of the investigation, I could just do a search for all objects tagged with #287973, order them by date & time, and presto! The technical portion of my report is almost written for me! This is quite similar to other forensic analysis tools (EnCase, for example) that allow you to "bookmark" interesting pieces of information and generate the report from the bookmark list.

To go a bit further, what if the same attacking IP came back six months after the above incident, this time with an FTP buffer overflow exploit? You might not remember the address as the origin of a previous incident, especially if you have a large operation and the original incident was logged by a different analyst. However, if the console says that the address was tagged as being part of a specific incident, you'll know right away to treat it with more suspicion that you might otherwise have done.

To be honest, these are just some of my first ideas on the power of tags; the real power could come as we consider more elaborate scenarios. What if you could tag any item more than once? Well, by associating multiple incident tags with an item, you just might uncover relationships that you didn't realize existed. It doesn't take much to imagine a scenario where you can build a chain of related tags that could imply association between two very different things, perhaps by creating a series of Kevin Bacon links between addresses and or events.

So, will any of this show up in Sguil? Probably not any time soon. Maybe if I can convince Bamm that I'm not insane, maybe it'll find its way onto a feature wish list. Or maybe another project or product will beat us to the punch (it is the era of Web 2.0 after all, and tagging is like breathing to some folks nowdays). But I do fantasize about it, and I live in hope.

NSMWiki update

I spent some time this morning reconfiguring the NSMWiki to provide secure login and password management pages. So first off, now you know that.

The real point of this post, though, is that I had a hard time finding good examples that applied to my specific situation, so I'm documenting the process here. I hope this will make things easier for the next person.

Here's what I started with:

  • A shared webhost (Linux, Apache & mod_rewrite)
  • An SSL and a non-SSL server serving identical content
  • MediaWiki 1.9.0

I wanted to let mod_rewrite do the hard work, so I did some web searches on the topic. Unfortunately, I always came up with pages that had the same two problems:

  1. They assumed that I had control of the server-wide configuration files for Apache, but I use a shared web host, so I needed to use a .htaccess file to set the rewrite settings on a per-directory basis.
  2. The examples only provided protection for the login page, but none of the other pages that dealt with password information .

The first problem is that mod_rewrite sees different URLs when it's configured on a per-directory basis than when it's configured for the entire server. The change is small, but important. In a server wide configuration, URLs begin with the "/" character. When run per-directory, they don't. As I initially started by using some online examples, this tripped me up until I figured it out.

The second problem is that none of the examples cared about the other MediaWiki password management options, just the login page. Oops!

Fortunately, the solution to both problems was easy, with a little tinkering. Here's a .htaccess file that will do the right thing. Drop it in your MediaWiki directory, edit the RewriteRules to reflect the correct path in your wiki URLs, and you should be good to go.

RewriteEngine on
# Any Wiki page that uses the Special:Userlogin page (account login, creation),
# the Special:Resetpass (password reset) or Special:Preferences (where normal
# password changes operations are done, among other things) should get
# redirected to the SSL server. Note check to make sure we're not ALREADY
# using the SSL server, to avoid an infinite redirection loop
RewriteCond %{QUERY_STRING} ^title=Special:Userlogin [OR]
RewriteCond %{QUERY_STRING} ^title=Special:Resetpass [OR]
RewriteCond %{QUERY_STRING} ^title=Special:Preferences
RewriteCond %{SERVER_PORT} !443
RewriteRule nsmwiki/index.php https://%{SERVER_NAME}/nsmwiki/index.php?%{QUERY_STRING} [L,R]

# Any Wiki page that's NOT one of the specific SSL pages should not be using
# the SSL server. This rule redirects everything else on the SSL server
# back to the non-SSL server.
RewriteCond %{QUERY_STRING} !^title=Special:Userlogin
RewriteCond %{QUERY_STRING} !^title=Special:Resetpass
RewriteCond %{QUERY_STRING} !^title=Special:Preferences
RewriteCond %{SERVER_PORT} 443
RewriteRule nsmwiki/index.php http://%{SERVER_NAME}/nsmwiki/index.php?%{QUERY_STRING} [L,R]

As I said, this was my first foray into mod_rewrite, and I'm pretty happy with the functionality it gives me. I know there are some gurus out there who are much more familiar with mod_rewrite and/or MediaWiki, though, so if you can suggest any improvements, please leave a comment.

Update 2007-06-17 17:25: I upgraded the wiki software to 1.10.0 the other day and today I got an email to tell me that no one could log in. I did a little poking around, and sure enough, they couldn't. It turns out that you should also set the following line in your ''LocalSettings.php'' file:

$wgCookieSecure = false;

Because the login page was using the SSL server, MediaWiki was issuing "secure" cookies (i.e., cookies that can only be sent via SSL). Only the login and a few other pages use SSL, though, so most of the rest of the wiki session simply wasn't seeing the cookies. The setting existing in the old software, but I guess it wasn't being used.