Thursday, February 25, 2010

Hogging the Snort Host Attribute Table

Hogger is a new Snort supportive tool written in Perl, by Parker Crook, that allows you to create a Host Attribute Table from an nmap scan. But first, a little primer; A feature within Snort that has received some traction lately is that of the --enable-targetbased configuration option. This allows you to specify a Host Attribute Table that contains critical information about what your network host topology is (i.e. OS, services etc..). Using this information, snort can then properly reassemble fragments, track streams and a number of other things. All of these items are covered in Joel Esler's recent CSO article that can be found at This URL. This is an excellent article that covers what Host Attribute Tables are and how to use them, so please read the article for a better understanding!

Now that you know all about the Host Attribute Table, let's jump into the purpose and use of hogger. As mentioned previously, hogger was written by Parker Crook to create a Host Attribute Table using the resulting output of an nmap scan. Without further adieu, let's walk through the usage of hogger!

Requirements:
Steps:
  1. Install XML::Writer
  2. Get hogger
  3. Install Nmap
  4. Run Nmap with correct options
  5. Run hogger against Nmap output file
  6. Start your snorting!
1: Installing XML::Writer
$perl -MCPAN -e shell
cpan[1]> install XML::Writer
2: Get Hogger
$wget http://hogger.googlecode.com/files/hogger.tar.gz
$tar xvfz hogger.tar.gz
3: Install Nmap
Use whatever tool that your distribution / OS uses to install Nmap, or get the source from nmap.org and build it yourself!
4: Run Nmap
$mkdir ~/hogger/nmap
$cd ~/hogger/nmap
$nmap -sV -T4 -oN scan.nmap 192.168.1.0/24
Starting Nmap 5.21 ( http://nmap.org ) at 2010-02-25 18:46 UTC
..output suppressed...
5: Run hogger (against scan.nmap)
$cd ~/hogger
$./hogger.pl -c nmap/hostmap.csv -n nmap/scan.nmap -x nmap/host_attrib_table.xml
6: Start your snorting - At this point you can take the newly created host_attrib_table.xml file and place the path to it in your snort.conf, assuming your built snort with the correct option:
attribute_table filename /path/to/host_attrib_table.xml
Now that we have all of this running, let's examine some of the options that are currently available in hogger and dissect our hogger run: "./hogger.pl -c nmap/hostmap.csv -n nmap/scan.nmap -x nmap/host_attrib_table.xml".

Hogger help output:
Usage: ./hogger.pl [-r? -help] -n -c -x

Options:
-c Where the human-readable/modifiable csv file containing host information lives.
-n Where the nmap file containing host information lives.
-r Process the csv file and output to xml for snort, but do not read an nmap file.
-x Where you want to create the host_attribute table.xml (Overwrites existing files)
-help/? Print this information

Starting with the -c flag, this is a file that will be created by hogger if it does not exist, and is simply a csv file that you can modify (for those hosts that nmap either misses or is not as accurate as you would like). A few sample entries in the file (hostmap.csv) that we created in the above test run:
192.168.1.1, Linux, 23|tcp|telnet 53|tcp|domain 443|tcp|ssl/http
192.168.1.2, Linux, 23|tcp|telnet 53|tcp|domain 443|tcp|ssl/http
192.168.1.7, FreeBSD, 22|tcp|ssh 53|tcp|domain 80|tcp|http 3000|tcp|http 3128|tcp|http-proxy 3306|tcp|mysql 5000|tcp|http-proxy 8443|tcp|http
Next we see the -n flag, this is the flag that specifies where the nmap output file (that we previously created using the nmap -oN scan.nmap option). This is the file that hogger reads to create entries in the -c .

The -r flag is fairly straightforward and specifies that you ONLY want to read the csv file specified with the -c flag value.

The final flag that we will discuss is the -x flag, this is a required flag and tells hogger where you want the resulting output (the Host Attribute Table) to be placed. Examples from the output, matching those noted in the -c flag information above:
<SNORT_ATTRIBUTES>
<ATTRIBUTE_TABLE>
<HOST IP="192.168.1.1">
<OPERATING_SYSTEM>
<NAME ATTRIBUTE_VALUE="Linux" CONFIDENCE="90"></NAME>
<FRAG_POLICY>Linux</FRAG_POLICY>
<STREAM_POLICY>linux</STREAM_POLICY>
</OPERATING_SYSTEM>
<SERVICES>
<SERVICE>
<PORT ATTRIBUTE_VALUE=" 23" CONFIDENCE="100"></PORT>
<IPPROTO ATTRIBUTE_VALUE="tcp" CONFIDENCE="100"></IPPROTO>
<PROTOCOL ATTRIBUTE_VALUE="telnet 53" CONFIDENCE="95"></PROTOCOL>
</SERVICE>
</SERVICES>
</HOST>
<HOST IP="192.168.1.2">
<OPERATING_SYSTEM>
<NAME ATTRIBUTE_VALUE="Linux" CONFIDENCE="90"></NAME>
<FRAG_POLICY>Linux</FRAG_POLICY>
<STREAM_POLICY>linux</STREAM_POLICY>
</OPERATING_SYSTEM>
<SERVICES>
<SERVICE>
<PORT ATTRIBUTE_VALUE=" 23" CONFIDENCE="100"></PORT>
<IPPROTO ATTRIBUTE_VALUE="tcp" CONFIDENCE="100"></IPPROTO>
<PROTOCOL ATTRIBUTE_VALUE="telnet 53" CONFIDENCE="95"></PROTOCOL>
</SERVICE>
</SERVICES>
</HOST>
<HOST IP="192.168.1.7">
<OPERATING_SYSTEM>
<NAME ATTRIBUTE_VALUE="FreeBSD" CONFIDENCE="90"></NAME>
<FRAG_POLICY>BSD</FRAG_POLICY>
<STREAM_POLICY>bsd</STREAM_POLICY>
</OPERATING_SYSTEM>
<SERVICES>
<SERVICE>
<PORT ATTRIBUTE_VALUE=" 22" CONFIDENCE="100"></PORT>
<IPPROTO ATTRIBUTE_VALUE="tcp" CONFIDENCE="100"></IPPROTO>
<PROTOCOL ATTRIBUTE_VALUE="ssh 53" CONFIDENCE="95"></PROTOCOL>
</SERVICE>
</SERVICES>
</HOST>
Having said all of this, I am not going to go into detail about the flags used during the Nmap scan, suffice it to say that those are the suggested flags and that the -oN is required to produce the output file for hogger to read.

Overall I think that the concept behind hogger is excellent and that it should provide useful aide to all you snort heads out there! This tool gets a thumbs up from me and should be one that you put into your snort bag of tricks and is also one that I am planning on contributing to.

Cheers,
JJC




Tuesday, February 23, 2010

Writing Snort Rules Correctly (via Joel Esler)

Joel Esler recently published an article entitled "Writing Snort Rules Correctly". I certainly suggest having a read through of this ,as it discusses a number of the finer points (including PCRE) when writing a snort rule using a previously published example rule. Joel dissects the rule, pointing out the good and bad while making note of better methods.

Just a short post, but I thought it worth posting to bring more attention to the aforementioned article by Joel Esler.

JJC