Switching to Sguil: A whole new meaning

Many of you may have wondered why I haven't yet blogged about the recent release of Sguil 0.7.0. Did I forget? No. Am I disappointed with it? Not at all! Am I just lazy? Yes, but that's not why.

The truth is, I've held off blogging about that because there's some even bigger news with the Sguil project!

You probably didn't know this, as we've tried hard to keep it under wraps until it could be formally announced, but the Sguil project has just received an extremely large vote of confidence, in the form of it being acquired lock, stock and barrel by Cisco!

Yes, you read that right! From the press release:

Under terms of the transaction, Cisco has acquired the Sguil™ project and related trademarks, as well as the copyrights held by the five principal members of the Sguil™ team, including project founder Robert "Bamm" Visscher. Cisco will assume control of the open source Sguil™ project including the Sguil.net domain, web site and web site content and the Sguil™ Sourceforge project page. In addition, the Sguil™ team will remain dedicated to the project as Cisco employees, continuing their management of the project on a day-to-day basis.

Really, I didn't blog about Sguil 0.7.0 yet because I didn't want to do say anything that could have interfered with this deal.

The great thing about this is that both Cisco and Sguil have made significant investments in Tcl, as it's already found in the OS on many Cisco products. Of course, Sguil is written almost entirely in Tcl, so this should provide for some great synergy going forward. You should start seeing Sguil being pushed out into the carrier-grade Cisco gear by 3Q08, with the rest of the Cisco-branded products following in phases through 4Q09. Linksys-branded gear will be supported too, though there's not an official timetable for that yet.

On a personal note, I would like to congraluate Bamm (AKA "qru"), Sguil's lead developer. He's put a lot of time into this project over the years, and is finally going to reap some rewards:

Although the financial details of the agreement have not been announced, Sguil™ developer Robert Visscher will become the new VP of Cisco Rapid Analysis Products for Security. “This deal means a lot to the Sguil™ project and to me personally,” Visscher explains. “Previously, we had to be content with simply being the best technical solution to enable intrusion analysts to collect and analyze large amounts of data in an extraordinarily efficient manner. But now, we’ll have the additional advantage of the world’s largest manufacturer of networking gear shoving it down their customers’ throats! We will no longer have to concern ourselves with mere technical excellence. Instead, I can worry more about which tropical island to visit next, and which flavor daiquiri to order. You know, the important things.”

I know that many of you will have questions about this major evolution in the Sguil project and our continuing roles as Cisco employees, so please feel free to leave them here as comments, or ask in freenode IRC's #snort-gui channel.

Temporarily speed up SANCP insertions in Sguil

It's Monday morning, you're half asleep, you haven't finished your first diet soda yet, and -- oh no! Sguild has been down all weekend! Worse yet, SANCP inserts are backed up, to the tune of 17,000+ files in the queue!

As you know, the Sguil sensors are pretty much independent of the actual Sguil server. They'll happily continue collecting data, even when sguild has been down for a while. When the server comes back up, the sensors will automagically reconnect and send all the queued data. This is by design, of course. You don't want to lose all that data due to a failure of the central server.

Even after an extended outage, most of the data collected by the Sguil sensors poses no real problem. There are relatively few Snort alerts (maybe a few thousand), and probably even fewer PADS events, and these get added to the database in no time. Network session records collected by SANCP, however, can pose a bigger problem.

If you recall, SANCP works by keeping an in-memory list of active network "sessions" (including psuedo-sessions created from UDP and ICMP traffic). By default, it will dump these to a file every minute or so (or more often, on a busy network). The Sguil sensor contains a SANCP agent process that monitors the filesystem for these files, and sends them to Sguild as they are created, deleting them from the sensor.

Now here's the problem: there are just so many darned network sessions on a busy network that even a short outage can result in a few hundred files waiting to be queued, especially if you have multiple sensors. Longer outages, though, can be disastrous. Let's say that you have six sensors, and your Sguil server has been down for the weekend (48 hours). How many files is that?

60 * 48 * 6 = 17,280

Now, at an average rate of about 5 seconds to insert each file, how many hours would that take to catch up?

17,280 / (60 * 60) = 24

That's right! It'd take a full 24 hours to catch up! In the meantime, you're missing a few days of valuable network data (probably the few days you're most likely to want to query on Monday morning) and your MySQL database is spending all it's time inserting, which means not only that it's slower to respond to your analyst console, but also slower to process incoming events. In fact, it can easily get caught in a sharp downward spiral, where the incoming data gets even further backed up.

So what can you do about this? Actually, it's quite simple. If you find that you're getting behind while processing your backlock of SANCP records, you can dramatically speed things up by temporarily disabling the indices on your SANCP files.

First, figure out which days you have to catch up on. If you know your server crashed on Friday the 8th, and it's now Monday the 11th, you probably want to go through all SANCP tables from Friday - Monday.

Second, determine what the table names will be. Remember that Sguil creates one SANCP table per day, per sensor. These are all merged into a single virtual table, but for indexing purposes, ignore that one and concentrate on the individual tables. They will be named something like:

sancp_$SENSORNAME_$DATE

So for example, if you have two sensors named "external" and "internal", you'd have the following tables:

sancp_external_20080208
sancp_internal_20080208

sancp_external_20080209
sancp_internal_20080209

sancp_external_20080210
sancp_internal_20080210

sancp_external_20080211
sancp_internal_20080211

Next, you simply issue the SQL command to disable indexing for each table:

ALTER TABLE sancp_external_20080208 DISABLE KEYS;

MySQL will perform a quick table check before returning to the prompt. This may take a minute, and I personally find it annoying to wait after each table, so I usually just create a text file with all the commands in it, one per line, and run it batch mode:

mysql -u sguil -p sguildb < DISABLE-KEYS.txt

Based on my experience, I've seen the indexing speed go from 5 seconds per file to about 5 files per second, which is quite significant! At that rate, it would take less than an hour to insert everything!

17,280 / (5 * 60 * 60) = 0.96

Of course, you have to be extra careful to re-enable indices on all those tables. You can run a similar set of SQL commands to turn indices back on for a table:

ALTER TABLE sancp_external_20080208 ENABLE KEYS;

Again, I usually run this as a batch job.

The act of disabling and then later re-enabling indices does take a little while, but usually not more than a few minutes for each. Even given this overhead, it is still significantly faster to process a bunch of SANCP files without indices, then reindex them after you're all caught up.

Sure wish I didn't need to know this... 8-)

Update 2008-03-25 11:27: After you re-enable keys, you may need to also do a quick db check to make everything sane again:

mysqlcheck -o -a -u sguil -p sguildb

This will recheck all your tables and make sure they're still consistent. I've had a few situations where Sguil has been returning error messages like "ERROR 1030 (HY000): Got error 124 from storage engine" until I did this.

In which I attempt a metaphor

So I was explaining the poisoned search results threat to several people yesterday, and I hit upon a good metaphor to explain why this is particularly serious: it increases the attacker's "shots on goal".

If you know Hockey at all (which I don't, but I've been to a few games), you know that the scoreboard typically lists "Shots on Goal" right beside each team's score. Why? Because you can't score if you don't shoot!

The more times you get to try to score, the more likely it is that you will do so, and it's the same with security. Tracking the number of exploit attempts, even if they are unsuccessful, is just like reporting shots on goal.

It happens that poisoned search results are a great way to increase your shots on goal with very little effort, and if the analogy holds, that means this will prove to be an extremely effective strategy for the attackers. I believe current events are proving this to be true.

Of course, now that I have not only made metaphor linking digital security to real life, but a hockey metaphor, at that, I expect that I have invoked The Bejtlich, and he will no doubt be forced to appear shortly and leave an insightful comment.

New ZLob spreads through poisoned search results

You may have seen this technique before, but in the last few days, it seems that the creators of the ZLob trojan have found an effective way to spread their malware: poisoned search results.

In case you're wondering how this works, it goes something like this:

1. The attackers identify a set of "hot" search terms that users are most likely to be looking for. Popular products, current events, celebrities, scandals, you name it. I don't know for sure where they come up with these terms, but if it were me, I'd get them from Google Trends or some place like that. To really be effective, the attackers need to gather as many of these terms as possible, perhaps several thousand. They need to be updated frequently, too.
   
2. The attackers identify an otherwise legitimate website that happens to be vulnerable to some sort of file upload attack.
   
3. The attackers create a set of HTML files, one per search term they're targeting. The HTML is crafted to look highly relevant for that term, with what looks to me like snippets of text from other legitimate web pages on that subject. In addition, each of the files links to each of the other files, artificially inflating their number of incoming links in an attempt to fool the search engine into placing them nearer to the top of the result list.
   
4. When a user searches on one of the terms, they will see poisoned results interspersed with legitimate ones. If they click on the poisoned link, obfuscated Javascript in the page will redirect them to a site that claims to have a relevant video. It shows a static GIF that looks like the YouTube video interface, but then pops up a dialog telling the user they need a new CODEC to view the clip.
   
5. Of course, you know where this is going... The "CODEC" is an EXE file containing the ZLob trojan. SCORE!
   

It used to be that if you avoided browsing pr0n, gambling sites and similar shady sites, you were less likely to come into contact with this sort of thing. But now, legitimate users doing regular, every day searches are being exposed a lot more often. This is kinda scary.

So what can you do to protect your users against this type of attack? On a technical level, not that much. You can't really get much done on the Internet without a search engine, and it's going to be up to them to improve their ability to vet the pages they index. Individually, something like the NoScript Firefox plugin would be effective, but that's difficult to impose on an entire user community.

However, the most effective security is not technical. Get the message out to your users, "There are malicious web pages out there; you're likely to find some of them inside the search engine results; be careful what you click on, and never download things you weren't expecting to download."

Of course, I can't let this go by without at least some sort of NSM advice. Here's a quick Snort rule I wrote to detect these trojan CODEC downloads:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"WATCHLIST Possible ZLob Codec Download"; uricontent:".exe"; nocase; pcre:"/.*codec.*\.exe/smi"; flow:to_server,established; classtype:trojan-activity; sid:10000000; rev:1;)

This looks for HTTP downloads of files that machine "*codec*.exe" (case insensitive, of course). A simple file name change or something would evade this, but it's not too hard to see how to customize this to look for other things. And if your version of Snort is compiled with flexible response support, you can even add "resp: rst_all;" to try to block the download attempts by sending spoofed RST packets, which should provide some extra security.

NSM and VLANs

Sometimes I run across a pcap-aware utility that does something very cool, but just doesn't work right when it encounters 802.1Q VLAN tags in traffic. Most commonly, it fails to recognize these packets as IP.

To see why, take a look at this diagram of a sample Ethernet II frame. Most simple-minded code simply checks bytes 12 & 13 (the EtherType field) to see if they contain 0x08 0x00, which is the code for IPv4 traffic.

However, 802.1Q tags throw things off a bit. If present, the tag occupies an additional 4 bytes between the source address and the EtherType field. The first two bytes are a standard code for VLAN tags, 0x81 0x00. Then the following two bytes are an arbitrary numeric value identifying which VLAN the traffic belongs to.

The code is often something like:

if(etherframe[12] == 0x08 && etherframe[13] == 0x00) {
  /* Process an IP packet */
}

Adding VLAN support simply involves an extra check. For a quick and dirty solution, if the VLAN tag is present, I usually just adjust the pointer to the beginning of the frame's data (etherframe, in the above case) by 4 bytes, then proceed as usual.

In most cases, this has the desired effect, but it does mean that I'm throwing away all VLAN tag information. In my experience, this has only been a problem once, on Shmoocon's "hack or halo" network, where each participant's computers were on a unique VLAN but had identical IPs. In the real world, I have never seen this, but I'm certain it exists somewhere.

In the meantime, if you can live with this restriction, you can try out some VLAN patches I wrote for PADS, tcpflow and tcpxtract. You may also want to check out this wiki page which tracks VLAN support in various libpcap-based analysis tools.

The awesomest

This is the awesomest thing I've ever heard on the Internet. Some guy recorded a 10 minute phone call with a phisher. My favorites are the wife, the FBI and the 357.

This is SFW, though there are two or three things bleeped out.

Go ahead, get pwn3d, you've got Norton.

So I open my inbox today and find an e-newsletter from Symantec. Normally, they barely register with me, and I just delete them an move on. This one though, had a great subject line:

Go ahead, You've got Norton

Really? That's the idea you're going with? It's safe to open that attachement/click on that link/view that malicious site, just because you've got Norton AV?

I know this was probably written by a marketdroid, as I sincerely doubt that the Norton AV product engineers would encourage you to engage in risky Internet behavior no matter which AV product you've got installed. Still, you'd think that someone, somewhere, when planning their marketing strategy, would notice the fundamental disconnect between that slogan and any actual good security practice.


As Richard Bejtlich is fond of saying, prevention eventually fails. C'mon, Symantec. How can you expect customers to trust your product if your own marketing efforts display an ignorance of fundamental security principles?

Heading home for the holidays?

Take a look at PortableApps.com, a repository of free software that's modified to run directly from a USB stick. Not only will you find a nice anti-virus scanner to help you tune up your relatives' PCs (ClamAV), but you'll also get Firefox, Thunderbird, GAIM and other useful applications to help you keep connected.

Really, I just want everyone to run AV on their family computers. I just put that stuff about Firefox and Thunderbird in to tempt you into downloading the package. Heh.

Holy Grail Found

...or not. Who knows? This article published by the University of Wisconsin-Madison, claims that UWM's Paul Barford has developed technology (called "Nemean") to automatically identify botnet traffic. So far, so good. To be honest, the industry could really use this kind of solution.

Here's the part I have trouble with, though:

The Achilles’ heel of current commercial technology is the number of false positives they generate, Barford says. Hackers have become so adept at disguising malicious traffic to look benign that security systems now generate literally thousands of false positives, which Nemean virtually eliminates.

In a test comparing Nemean against a current technology on the market, both had a high detection rate of malicious signatures — 99.9 percent for Nemean and 99.7 for the comparison technology. However, Nemean had zero false positives, compared to 88,000 generated by the other technology.

I'm not even sure I know where to start here. These numbers sound quite impressive, but without knowing much more about how the tests were conducted, they really don't mean very much. First of all, how many unique types of botnets were tested, and what were they? Also, who chose the test cases? I can achieve a 99.9% detection with 0% false positives too, if I control both the software to be tested and the selection of the test cases.

Next, I wonder what specific technology they tested against, and whether or not they tuned it properly for their test environment. I suspect not, as 88,000 false positives is quite high. I doubt they had 88,000 unique botnet samples, either, so I'm sure there are multiple alerts for each, which can easily be tuned down.

Finally, and most importantly, even if you do achieve near perfect results on a selection of current botnets, this is likely to be only temporary. The Bad Guys are virtually guaranteed to step up their game too.

To be fair, this is addressed in the article:

While Barford has high hopes for Nemean, he says Internet security is a continuous process and there will never be a single cure-all to the problem.

“This is an arms race and we’re always one step behind,” he says. “We have to cover all the vulnerabilities. The bad guys only have to find one.”


At least it sounds as though Dr. Barford does have an idea of the scope of the challenge. Perhaps there is more to this project than was presented in this fluff article. I really would like to hope so, but I'm a bit skeptical based only on the information presented here.

File under: Things You Wish You Didn't Know

After reading this, I may never be able to attend a certain security convention ever again.

NSMWiki in print again

This month's ISSA Journal has another article by Russ McRee on NSM topics. You may remember that I've blogged about Russ' articles before. This time, he's writing about Argus, an excellent suite of tools for implementing distributed collection of network flow information. It also happens that he mentions NSMWiki, which I maintain for the Sguil project.

If you're not an ISSA member, you can read Russ' article here.

Sguil training: is there demand?

Ok, so I know that there are a fair amount of Sguil users out there now, and more coming every day. Some of us have kicked around the idea of providing some Sguil training, though we never seemed to have the critical mass of potential students. Maybe the time has come to consider this again?

What I'd like to know is this: if there were a one day class that covered Sguil administration (installation, troubleshooting and maintenance) offered in the Hampton Roads, VA area (Norfolk, VA Beach, Williamsburg), do you think you would be interested in attending?

If you would be interested in attending, how much would you be willing to pay for such a class?

Would your answer change at all if the class also taught you how to actually analyze events and research incidents with Sguil, possibly as a second day?

I'm not promising to run a class, but I've been interested in doing so for quite some time, and if I get enough interest, it's certainly a possibility.

Please email me or leave a comment here with your thoughts. Thanks!

Ok, there's something wrong here...

You may have seen this article about a survey McAfee conducted in conjuction with the National Cyber Security Alliance. In brief, they polled a few hundred random Americans and asked them about the security software they were using on their PCs, then followed up to see if the actual configuration matched what the user's thought. No surprise that they found only something like 50% of the people had up-to-date AV software, had turned on their firewall or were running any sort of anti-spyware software.

The numbers sounded reasonable in this article, but then I read the following sentence:

But when pollsters asked to remotely scan the respondents' 
computers, the story turned out to be very different.

Just who exactly would allow strangers to "remotely scan" their computers to verify their security settings? Hmm... Oh! I know! Perhaps the very people who are least likely to already practice good security measures!

Seriously, I'm no statistician or pollster, but this methodology sounds fishy to me. This sounds like a self-selected sample to me (the group of all people who lack enough basic security skills to properly secure their systems from strangers). I'd love to know if this was somehow accounted for in their methodology, but until then, I don't think these numbers are at all useful.

Update: 2007-10-02 13:34: BTW, I forgot to make my other point, and that is that the pollsters seem to have used exactly the same sort of techniques that we try to condition our users against, namely social engineering attacks. So that lends further credence to my belief that they probably ended up doing a survey of those who were already the worst at security.

Sguil covered in Information Security Magazine

Richard Bejtlich points out that the October issue of Information Security Magazine has an article by Russ McRee, entitled Putting Snort to Work. The article is about Knoppix-NSM, a Linux LiveCD designed for easy monitoring. Knoppix-NSM includes a preconfigured Sguil server and sensor, and Russ has a lot of nice things to say about it.

It's really good to see Sguil in some mainstream security press. VictorJ's modsec2sguil custom agent and our very own NSMWiki even get mentioned, so I know he's done some homework.

Snort 2.8 is out

Grab it from the Snort download page, and read my previous post about some of the new features.

I still haven't tried this myself yet, but soon. Honest.

I call shenanigans!

The Telegraph reported yesterday that aerospace giant EADS has developed "the world's first hacker-proof encryption technology for the internet" [sic].

Amazing! There are at least three separate errors in just that one 10 word sentence fragment. I tried to find some more info on the company's website, but all I could find was this year-old press release on a product called ECTOCRYP. I assume this to be the same product, because how many encryption protocols would this company develop? Let's take a look at some of the problems with this company's statement.

First off, as everyone reading this post probably already knows, there's no such thing as "hacker-proof". The definition of a hacker is someone who can change the rules of the game in his or her favor, so in order to be "hacker-proof" you've got to somehow deny them this opportunity. Most knowledgable attackers realize that attacking the encryption algorithm itself is usually unnecessary. For example, in order to be truly "hacker-proof", you must not only have a robust algorithm, but also perfect key management (both protocols and implementation) and secure endpoints on both sides of the communication. This last, by the way, also implies users and administrator who never make any mistakes in configuration or use of the system.

The second problem is that "world's first" thing. Probably the most commonly deployed encryption technology today is SSL, and let me tell you, it's pretty much "hacker-proof" if you are just trying to cryptanalyze a captured session, which, as I just mentioned, you probably wouldn't do.

Along the same lines, here's a quote from the article:

At the heart of the system is the lightning speed with which the "keys" needed to enter the computer systems can be scrambled and re-formatted. Just when a hacker thinks he or she has broken the code, the code changes. "There is nothing to compare with it," said Mr [Gordon] Duncan [the company's government sales manager].

So their big innovation is that they change the keys frequently? It's true, there's nothing like it... except for all the things that already do that! TKIP has been doing this for years ("T" is for "Temporal", and that's good enough for me). Even SSL can do this (via it's key renegotiation protocol), though this is admittedly rare since most SSL sessions are too short.

Finally, I'm impressed that they've developed an encryption technology "for the internet". IPv6 or IPSEC might be "for the internet" in the sense that they're tied directly to network protocols used to communicate over the Internet, but that doesn't seem to be the case with ECTOCRYP. It's probably just a stream or block cipher, which could be used equally well on, say, a dedicated serial line. I think what they mean to say is that it's a protocol used for protecting information in transit, as opposed to encrypting files at rest on the disk. That doesn't mean that it's designed "for the internet".

All of this is totally beside the main point, however, that I couldn't find any technical details on the encryption algorithm itself. I'm no professional cryptographer, so perhaps it has been published in a trade journal somewhere that I can't find in Google, but compared to other widely available encryption algorithms, I doubt it has undergone much peer review. This in itself makes the system suspect.

By the way, if you do Google "ECTOCRYP" you'll find this craptastic marketing video.

The embassy password thing

I wasn't going to comment on this, but we were discussing it a bit on #snort-gui today, and it made me wonder...

People everywhere are talking about how the embassies are foolish for using Tor to provide "secure" remote access to their systems. Ok, we can all agree that Tor isn't really suitable for that. But as someone on #snort-gui pointed out, how do we know it was an official embassy-supported application, and not just some power users who decided to start using Tor on their own? We don't! At least, I couldn't find any confirmation that the network admins were pushing Tor on their users.

But really, this got me thinking some more this afternoon. How do we know it was the embassy users who were using Tor? If I were a hacker who had somehow gained access to accounts in the embassies, I might use Tor to disguise my origin and wouldn't care if the passwords were exposed. I think there are any number of actors who could be behind this, so I don't want to name any names, but Certainly, Hacking Insecure Networks Around the world is a specialty of some...

Update 2007-09-11 16:02: giovani from #snort-gui reminded me that he was the one who brought up the idea of the power users. And he is unnervingly happy about being referenced here, even indirectly. Thanks, giovani!

Would you notice this?

Just a quick thought I had. If your organization is using virtualization to pack many VMs onto your existing server platforms (as many sites are trying to do these days), would you necessarily notice if an additional VM popped up?

It turns out that VMs can be very small (the smallest VMWare image I found with a quick google search was 10MB, which could fit in my /tmp partition). Many, perhaps all, of the VM packages provide command-line level access to manage the running guest systems. VMWare even provides a Perl API for this.

If I were an attacker who managed to get access to your VM system, could I insert my own VM image and make it run? If so, I could potentially have my own custom hacking environment, with root privileges and whatever software I needed, without creating too many files or new processes on the host OS. Unless you're looking carefully at every file on the system, or watching what VMs are running, would you notice?

Would anyone with real-world virtual server experience care to share their thoughts?

Find Storm with Sguil (and a little ingenuity)

My friend nr has started a new security blog. His first real post is about using Sguil to detect Storm worm infections. Welcome to the blog world, nr!

Cloaking your investigative activities in Sguil

I've written before on disguising your outbound DNS queries. In short, even looking up an IP to find the hostname might alert an attacker that you're on to them if they control their own DNS server. I briefly described how to create a simple proxy DNS server that could send all your queries through a third-party, like OpenDNS, which should make it harder for the bad guys to figure out just who is checking them out.

I'm happy to say the new Sguil 0.7.0 client now incorporates third-party DNS server support natively. In sguil.conf, you simply set the EXT_DNS, EXT_DNS_SERVER and HOME_NET variables, like so:

# Configure optional external DNS here. An external DNS can be used as a
# way to prevent data leakage. Some users would prefer to use anonymous
# DNS as a way to keep potential malicious sources from knowing who is
# interested in their activities.
#
# Enable Ext DNS
set EXT_DNS 1
# Define the external nameserver to use. OpenDNS list 208.67.222.222 and 208.67.220.220
set EXT_DNS_SERVER 208.67.222.222
# Define a list of space separated networks (xxx.xxx.xxx.xxx/yy) that you want
# to use the OS's resolution for.
set HOME_NET "192.168.1.0/24 10.0.0.0/8"

In this example, I've configued Sguil to use one of the OpenDNS name servers (208.67.222.222) to look up all hosts except those on my local LAN (addresses in either the 192.168.1.0/24 or the 10.0.0.0/8 range).

So that takes care of DNS, but what about WHOIS? Ok, so maybe it's a bit less likely that the attacker has also compromised a WHOIS server, but less likely doesn't mean that it hasn't happened. It probably has, and it probably will in the future. Therefore, it's prudent to also try to disguise the source of your WHOIS lookups.

Sguil has always had the ability to call a user-supplied command to perform WHOIS operations, so here is a simple script you can use to proxy all of Sguil's WHOIS lookups through a third party (Geek Tools, in this case). This should work on any version of Sguil.

#!/bin/sh
# 
# Simple script to proxy all whois requests through whois.geektools.com
# to help keep the bad guys from figuring out that we're onto them when
# Sguil looks up a record.
/usr/bin/whois -h whois.geektools.com $*

To use this, just set the WHOIS_PATH in your sguil.conf file, like so:

set WHOIS_PATH /home/sguil/bin/sguil-whois.sh

So now you have it. By implementing DNS and WHOIS proxies in Sguil, you can add an additional layer of protection against bad guys who may be monitoring their systems for signs that you have discovered their attacks.