Time to own your rules - PulledPork 0.3.4 Released!

After what seems like forever since I have made a post about anything, I am pleased to announce the general availability of the latest version of PulledPork! This new version (v0.3.4) has a significant number of bugfixes for a variety of OS/distributions in addition to the numerous feature enhancements noted below.

I would like to thank all of the individuals that provided beta testing assistance and valuable feedback. I would also like to thank all of the users that have adopted PulledPork and sent in comments / feature requests. PulledPork certainly would not be where it is without your support and contributions!

Now that we are through the mushy stuff, on to the features!

VRT Rulesets! - Support metadata based VRT recommended rulesets - The short of it is that you can now specify a default pre-defined ruleset, yes.. this ruleset was designed by the VRT! The individual pre-defined rulesets that can be specified are fairly straightforward:

• Connectivity - You run a lot of real time applications (VOIP, financial transactions, etc), and don't want to run any rules that could affect the current performance of your sensor. The rules in this category make snort happy, additionally this category focuses on the high profile most likely to affect the largest number of people type of vulnerabilities.

• Balanced - You are normal, you run normal stuff and you want normal security protections. This is the best policy to start from if you are new, old, or just plain average. If you don't have any special requirements for super high speeds or super secure networks, start here.

• Security - You don't care about dropping your bosses email, everything in your environment is tightly regulated and you don't tolerate people stepping outside of your security policy. This policy hates on IM, P2P, vulnerabilities, malware, web apps that cause productivity loss, remote access, and just about anything not related to getting work done. If you run your network with an iron fist, start here!

Changelog - This feature allows you to specify that you want a changelog (any rule that has any change in it from your previous ruleset, i.e. disabled, enabled, modified etc..) maintained for any and all changes, in a specified log file.

Inline Drops - This feature allows you to specify what SIDs you want to be set to drop, for those running an inline setup!

Multiline Rules - Added full support for parsing of multiline rules.

Enhancements - Many minor enhancements made to the debugging output, speed enhancements, code cleanup, error handling etc...

There are quite a few runtime options and configuration options, please be sure to read through the README files thoroughly, also please be sure to use the latest pulledpork.conf that is included in the tarball! That's about it for now, please feel free to participate by asking questions on the mail list at http://groups.google.com/group/pulledpork-users/ or on freenode in #snort or #pulledpork

One final note, all of the release tarballs will now be named as pulledpork-X.X.X.tar.gz to help out with those maintaining packages and ports, thanks!

Download the tarball here pulledpork-0.3.4.tar.gz
MD5SUM = 034f90a2555c5f82e760b0ce68489ad2
SHA256 = 8b775e6476d653733f3d29ea9c962a76feaf148f3204a90fd47c646802448b80

Cheers,
JJC

Pulledpork v0.2.5 - Released

A new and updated version of pulledpork is out, this version adds functionality and also addresses a number of previously reported bugs, a few simple examples:

• Improved and cleaned up code for efficiency and speed
• Do not overwrite local.rules on run
• Do not attempt to copy . and .. as rules files
• Much more...

The primary feature that has been added allows for the capability to download rules from sites other than snort.org (VRT). Any url can be specified to download a rules tarball from, however md5 hash verification will only work when VRT or ET locations are specified. If a different location (i.e. a local redistribution point) is specified, please be sure to specify the -d (do not verify md5) option. Please see the README and pulledpork.conf files for more information on usage of new and existing options and features.

New option runtime flag:

• -u Where do you want me to pull the rules tarball from

(ET, Snort.org, see pulledpork config base_url option for value ideas)

A new tarball containing all of the new features will be published today at http://code.google.com/p/pulledpork/downloads/list

pulledpork 0.2.2 and new features

Get it while it's hot @here!

I have received a few requests to build support into pulledpork for the restarting of processes (i.e. snort after downloading new rules or modifying the ruleset using disablesid). In response to this, it is done ^-^. You will note in the pulledpork.conf file that there is a new option at the bottom called pid_path. Simply list the path to your pid files (/var/run/snort_intx.pid,/path/to/another/pid.pid) etc... and specify -H at runtime.. you will be magically pleased (assuming you run pulledpork under a context that has permissions to restart said PID).

I also added a second option "-n" that will allow you to make modifications to the disablesid.conf file and re-execute pulledpork without attempting to download the current ruleset or md5 again (ala tuning exercises...).

Please see the included README for additional info and general guidelines on usage... below is some sample output.

./pulledpork.pl -c ../pulledpork.conf -i disablesid.conf -THn
Prepping files for work....
Done!
Copying rules files....
Done!
Disabling your chosen SID's....
Disabled 1 rules in /usr/local/etc/snort/rules/web-iis.rules
Disabled 2 rules in /usr/local/etc/snort/rules/backdoor.rules
Disabled 1 rules in /usr/local/etc/snort/rules/rpc.rules
Disabled 1 rules in /usr/local/etc/snort/rules/exploit.rules
Done
HangUP Time....
Done!
Fly Piggy Fly!

That's all for now, enjoy!

JJC

Snorby for Snort, a Recipe with Barnyard2 and Unified2

Snorby, an all new frontend (yes, it's still Beta) for snort has recently emerged. As such I decided that I would take a look and give my thoughts as well as a quick recipe to get it running fairly quickly using barnyard2. During my testing of Snorby, I talked with the creator (mephux) about his plans for Snorby and also worked through a couple of bugs, that he jumped on right away.

Note: This posting details how to get Snorby working with apache and passenger, NOT Webrick.. if you want that please read the details of how to do so at the Snorby site.

Recipe Components:

• FreeBSD 8.0R
• apache22
• ruby-gems
• ruby-iconv
  
• prawn (gem)
  
• rake (gem)
  
• mysql (gem)
• rails (gem)
  
• passenger (formerly modrails)
• mysql
• snort
• barnyard2
• git

Ok, let's get the dependencies and such out of the way. I am making several assumptions in writing this... the least of which is that you know how to use google if you can't figure something out... also that you already have the base of some of these items installed (ala, FreeBSD, apache, snort). If not, I have previous posts that discuss the setup of said items, and I am again going to drop the google bomb!

We need ruby-gems to get passenger running and ultimately Snorby:

$ cd /usr/ports/devel/git/ && sudo make install clean
...I deselect all of the options, I just want regular old git for this exercise
...output suppressed
$ cd /usr/ports/devel/ruby-gems/ && sudo make install clean
...output suppressed
$ sudo gem install prawn --no-rdoc --no-ri
...output suppressed
$ sudo gem install rake --no-rdoc --no-ri
...output suppressed
$ sudo gem install rails --no-rdoc --no-ri
...output suppressed
$ sudo gem install mysql --no-rdoc --no-ri
...output suppressed
$ sudo gem install passenger --no-rdoc --no-ri
...output suppressed
$ sudo passenger-install-apache2-module
...run through the setup and perform the steps that are noted to activate the passenger capabilities with apache.. ala vi httpd.conf and add the 3 lines that you are told to.
$ cd /usr/local/www/ && sudo git clone git://github.com/mephux/Snorby.git
...output suppressed/usr/ports/converters/ruby-iconv
$ cd /usr/ports/converters/ruby-iconv && sudo make install clean

At this point you are ready to modify your database and email configuration for Snorby. If you have not done so, you should create a snort database (I have called mine snort and created a user "snorby" with password "snorby".. ok that's not really the password but for this writeup it is! This user has full access (not grant) to the snort database. I have also created the apt tables in this database using the create_mysql sql that is included in both Snorby and Snort!

$ sudo cp /usr/local/www/Snorby/config/database.yml.example /usr/local/www/Snorby/config/database.yml
$ sudo cp /usr/local/www/Snorby/config/email.yml.example /usr/local/www/Snorby/config/email.yml

Now choose your preferred editor and modify the /usr/local/www/Snorby/config/database.yml file.. we are only concerned with the production info... you can also modify the email.yml but don't have to for our current purposes.

Install additional gem requirements and setup Snorby to run!

$ cd /usr/local/www/Snorby && sudo rake gems:install
...output suppressed
$ cd /usr/local/www/Snorby && sudo rake snorby:setup RAILS_ENV=production
...output suppressed

At this point you are ready to tell apache all about Snorby, so lets modify our vhost or apache config again. Simply add the following under the vhost of your choice, you need to be sure that RewriteEngine On and RewriteOptions inherit are specified in this vhost (or in scope of your config):

DocumentRoot /usr/local/www/Snorby/public

RailsBaseURI /

<directory "/usr/local/www/Snorby/public">
AllowOverride All
Order deny,allow
Allow from all
</directory>

Once this is complete, restart apache and you will get the login for Snorby when you browse to that vhost. The default username is snorby and password is admin.

We are now ready to modify our snort config to output unified2, modify your snort.conf and comment out your old output plugins or simply replace them with the following:

output unified2: filename snortunified2.log, limit 128

Note that unified2 contains all log and alert data, so no longer do you need two files! And now it's time for barnyard2. Go ahead and fetch the latest version from securixlive.com, configure with "--with-mysql" option. Once that is done copy the barnyard.conf to /usr/local/etc/snort/ and let's go ahead and edit that file, putting in the mysql information that you used with Snorby earlier and making sure that we have our input specified as unified2. You should go through and make sure that all of the paths to the map and ref files are specified correctly. Once that's done, you are ready to fire it up!

sudo barnyard2 -c /usr/local/etc/snort/barnyard2.conf -d /var/log/snort -f snortunified2.log -w /var/log/snort/barnyard2.waldo -D

You should now be receiving events in the snort mysql database and seeing them in Snorby.

Please note that there are a number of security considerations that I did not take into account (ala running all this stuff under root) so please take that into consideration.

Overall, I give Snorby a good rating, it certainly has lots of eye candy at this point. Mephux promises that much of the functionality that everyone wants is coming shortly... I would say that Snorby has a good start and promises to be a decent usable frontend for viewing snort events. Is it a sguil, certainly not... but it does look like it will be a decent alternative to BASE.

Cheers,
JJC

BASE / ACID outdated reference links - a fix

Recently, with changes to the snort.org site, the Snort mailing lists have been quite inundated with questions about the link to the SID reference and how it is no more. As a partial means of compensating for this and to help the community, we have recently added an up-to-date tool at rootedyour.com that will allow for you to once again have a valid snort reference link.


In BASE, simply locate the following section of your base_conf.php:

/* Signature references */
$external_sig_link = array('bugtraq' => array('http://www.securityfocus.com/bid/', ''),
'snort' => array('http://www.snort.org/pub-bin/sigs.cgi?sid=', ''),
'cve' => array('http://cve.mitre.org/cgi-bin/cvename.cgi?name=', ''),
'arachnids' => array('http://www.whitehats.com/info/ids', ''),
'mcafee' => array('http://vil.nai.com/vil/content/v_', '.htm'),
'icat' => array('http://icat.nist.gov/icat.cfm?cvename=CAN-', ''),
'nessus' => array('http://www.nessus.org/plugins/index.php?view=single&id=', ''),
'url' => array('http://', ''),
'local' => array('signatures/', '.txt'));

and modify the 'snort' line to match:

'snort' => array('http://www.rootedyour.com/snortsid?sid=', ''),

Once this is done, you are all set, the snort documentation link will now take you to rootedyour.com and display the info for that SID.

Obviously if you want to do this in other applications, simply point them to http://www.rootedyour.com/snortsid?sid=xxxxx where xxxxx is the SID that you want to know about. ex: http://rootedyour.com/snortsid?sid=234

Cheers,
JJC

Pimping Tha All New Snort.org

The home of Snort, snort.org received a facelift last night! The site has been largely static and unchanged for some time now.

A shortlist of the new features on the new snort.org that should make life easier for all:



• New navigation
• Improved account management
• New user forums
• Persistent link panel
• Improved VRT subscription management

What this does NOT mean is that your tools that automatically fetch snort rules tarballs will be broken... everything is still 100% functional and up in that area.

Having said all of this, please check out the new snort.org for yourself!

I extend a hearty good job to the entire snort.org team for their efforts in this, it looks and functions excellently!

Cheers,
JJC

Snort 2.8.5 at snort.org... get it while it's hot!

A beta version of Snort 2.8.5 is now available on snort.org, at
http://www.snort.org/dl/

Snort 2.8.5 introduces:

- Ability to specify multiple configurations (snort.conf and everything
it includes), bound either by Vlan ID or IP Address. This allows you
to run one instance of Snort with multiple snort.conf, rather than
having separate processes.

- Continued inspection of traffic while reloading a configuration.
Add --enable-reload option to your configure script prior to building.

- Rate Based Attack prevention for Connection Attempts, Concurrent
Connections, and improved rule/event filtering. See README.filters
for details.

- SSH preprocessor (no longer experimental)

- Performance improvements in various places

Please see the Release Notes and ChangeLog for more details.

Please submit bugs, questions, and feedback to snort-beta@sourcefire.com.

Baconator - Shared Object Snort Rule Management!

Recently while taking a plane ride from one lovely airport to another and doing some snort shared object rule development, I realized that I did not have a clean and easy way of fetching the latest snort rule tarball.

Don't get me wrong and misinterpret this post, I love Oinkmaster and have been a user of it for many a year!

Now, having said that... Oinkmaster does have it's shortcomings (for me anyway); the least of which is certainly not the fact that it currently does NOT handle shared object rules. With the release of Snort 2.8.4 and it's awesome new dcerpc2 preprocessor... the use of so_rules will most likely be much more prevalent.. and as such, with threats like Conficker and it's varients out there, I needed a way to handle this.

I did consider modifying Oinkmaster to fit my needs, but when I started writing the code at 30,000 feet... I didn't have the Oinkmaster codebase with me.

As a direct result of this thought and the lack of codebase on the plane... I started Baconator. Baconator is a Snort rule management tool that also handles so_rules, the creation of stub files from said so_rules, complete file validation (via MD5) against current VRT releases. It also does much more... or, will anyway.

I'll be posting more about Baconator as I complete the code. For now, if you want to try it out (it's not yet complete) you can checkout the code from the svn repo at http://code.google.com/p/baconator/.

The current code will fetch the latest ruleset from snort.org (ultimately I'll probably build the functionality in to fetch from ET). If you have an existing copy of the rules tarball from snort.org it will fetch the latest rule tarball md5 from snort.org and compare so that it doesn't re-fetch the same tarball again. It then performs the various extraction routines as defined in the conf file or at runtime and puts the files where you tell it to.. the rules files that is!

More info can be found on the google code page for Baconator. I'll also be updating that site regularly with updates to the timeline, current svn etc...

Cheers,
JJC

Snort 3.0 Beta 3!

This last Thursday, Martin Roesch published a new blog entry discussing the Snort 3.0 architecture and some testing that has been conducted and has yet to be conducted. Definitely a good read and example of how software should be optimized and developed to work with current architectures and feature-sets!

Find this here: http://securitysauce.blogspot.com/2009/04/snort-30-beta-3-released.html

Cheers,
JJC

PHPIDS Phase 1.1

I have been reviewing PHPIDS for some time now, and have come to the conclusion that while a novel idea... it is simply overkill and extra rubbish to include in your php code. I also have some ideas surrounding evasion techniques.... Don't get me wrong, I think that in the right place (i.e. a server that you can not load a real IDS/IPS such as mod_security on) it is better than nothing. I will place one caveat on that though, I am not 100% sure what it does to load capacity (or increasing the load of) and existing site. I'll be conducting some extensive load testing on it over the next week or so and posting those results.

JJC

openpacket.org

I recently took over managing and maintaining OpenPacket.org from Richard Bejtlich of TaoSecurity. I would like to extend my thanks to Richard for his time and efforts in getting OpenPacket.org off the ground.

The mission of OpenPacket.org is to provide quality network traffic traces to researchers, analysts, and other members of the digital security community. One of the most difficult problems facing researchers, analysts, and others is understanding traffic carried by networks. At present there is no central repository of traces from which a student of network traffic could draw samples. OpenPacket.org provides one possible solution to this problem.

Analysts looking for network traffic of a particular type can visit OpenPacket.org, query the OpenPacket.org capture repo for matching traces, and download those packets in their original format (e.g., Libpcap, etc.). The analyst will be able to process and analyze that traffic using tools of their choice, like Tcpdump, Snort, Ethereal, and so on.

Analysts who collect their own traffic will be able to submit it to the OpenPacket.org database after they register.

Anonymous users can download any trace that's published. Only registered users can upload. This system provides a level of accountability for trace uploads.

Our moderators will review the trace to ensure it does not contain any sensitive information that should not be posted publicly. Besides appearing on the site, once a trace has been published you can receive notice of it via this published trace RSS feed.

If you have any doubt regarding the publication of a trace, do not try to submit it. When moderators are unsure of the nature of a trace, we will reject it. OpenPacket.org is not a vehicle for publishing enterprise data as contained in network traffic.

In the upcoming months you will see significant changes and improvements to the OpenPacket.org site. Many of these suggestions are the result of user feedback, so please keep it coming and stay tuned as updates are released!

JJC

New IDS/IPS technologies

Recently while parusing the intertubes I ran across a new IDS/IPS technology (PHPIDS) "http://www.php-ids.org". This is an interesting and simple concept that can add an additional layer of security to your web application(s). This being said, I am not sure that I would run it solely, but I will be testing it over the week and posting the results subsequently.

"Block the Bad" OSS IPS with Content Filtration and Transparent Proxy Acceleration pt 1.

In this two part series I will discuss and demonstrate the creation of an inline security and content filtration system built on FreeBSD 7.0R. What is a security and content filtration system you might ask? Simply put it is a system that has the capabilities of an IPS with the included benefit of advanced content filtration (things like blacklists, page content scoring "keywords etc", greylists, whitelists and so on...).

This first part, entitled "block the bad" will deal with the IPS aspect of the system that includes some new "or newly revisited" ways of utilizing snortsam with barnyard rather than directly patching snort. This is good for a variety of reasons that include the capability to keep your snort version updated without having to continually re-patch it for snortsam, and not having to load snort down with more work than what it was intended "SNIFFING J00r PAket F00".

Some things in the below documented barnyard snortsam plugin have been hacked together, and I am sure that more capable individuals "rotorhead, Obiwan..." will write a non-hacked-together plugin in the near future. But this will get you up and rolling for now.

A few assumptions are made before we get started... the first is that you have already built snort (2.8.1 is the latest as of the time I wrote this), and if not that you can follow the directions to do so on a previous posting of mine. The second assumes if you want to see output such as BASE, you read and followed that entire posting. The third assumption is that you know how to modify your kernel options and ultimately make and install a new kernel. The fourth and final assumption is that if any of the previous assumptions are not true, you know how to use google.

Now, to the heart of the subject at hand, we will be using the following for the remainder of the excercise:

1. Snort 2.8.1 (see above)
2. barnyard 0.20.0 (with a modified snortsam plugin)
3. snortsam 2.52
4. ipf
5. ipfw (this will come into play in the next part re: content filtering, but can also be used to block by entire source or destination *not protocol/port* hence ipf)

So, for our first step (since we have snort built/running) let's get our barnyard patched so that we have the snortsam plugin. If you previously built barnyard and still have all of the source, that's great... but remember to make clean before we do anything. For my purposes I'll be demonstrating with a freshly downloaded barnyard. You will need autotools "cd /usr/ports/devel/autotools/ && make install clean" to finish the patch work.

[jj@Azazel /usr/home/jj]$ wget http://www.snort.org/dl/barnyard/barnyard-0.2.0.tar.gz

2008-04-13 18:14:39 (537 KB/s) - `barnyard-0.2.0.tar.gz' saved [161543/161543]

[jj@Azazel /usr/home/jj]$ tar xvfz barnyard-0.2.0.tar.gz
x barnyard-0.2.0/

[jj@Azazel /usr/home/jj]$ wget http://www.snortsam.net/files/barnyard-plugin/barnyard-snortsam-patch.gz

2008-04-13 18:16:37 (148 KB/s) - `barnyard-snortsam-patch.gz' saved [27149/27149]

[jj@Azazel /usr/home/jj]$ gunzip barnyard-snortsam-patch.gz
[jj@Azazel /usr/home/jj]$ cd barnyard-0.2.0
[jj@Azazel /usr/home/jj/barnyard-0.2.0]$ patch -p1 < ../barnyard-snortsam-patch
Hmm... Looks like a unified diff to me...
...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 33.
Hunk #3 succeeded at 54.
...
done
[jj@Azazel /usr/home/jj/barnyard-0.2.0]$ ./autojunk.sh
configure.in:147: warning: underquoted definition of SN_CHECK_DECL
configure.in:147: run info '(automake)Extending aclocal'
configure.in:147: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
autoheader-2.61: WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot'
autoheader-2.61: WARNING: and `config.h.top', to define templates for `config.h.in'
autoheader-2.61: WARNING: is deprecated and discouraged.
autoheader-2.61:
autoheader-2.61: WARNING: Using the third argument of `AC_DEFINE' and
autoheader-2.61: WARNING: `AC_DEFINE_UNQUOTED' allows one to define a template without
autoheader-2.61: WARNING: `acconfig.h':
autoheader-2.61:
autoheader-2.61: WARNING: AC_DEFINE([NEED_FUNC_MAIN], 1,
autoheader-2.61: [Define if a function `main' is needed.])
autoheader-2.61:
autoheader-2.61: WARNING: More sophisticated templates can also be produced, see the
autoheader-2.61: WARNING: documentation.
[jj@Azazel /usr/home/jj/barnyard-0.2.0]$

Now that we have the main part of the patch completed we need to make a few quick modifications to "src/output-plugins/op_alert_fwsam.c" so that it handles the barnyard output properly and loads the sid-msg.map file via a hard coded path (line 191). I threw a patch out there so that you don't need to do this manually, located here: http://www.redsphereglobal.com/data/tools/security/patches/barnyard-snortsam-hack.gz.

[jj@Azazel /usr/home/jj]$ wget http://www.redsphereglobal.com/data/tools/security/patches/barnyard-snortsam-hack.gz

2008-04-13 18:52:54 (1.15 MB/s) - `barnyard-snortsam-hack.gz' saved [641/641]

[jj@Azazel /usr/home/jj]$ gunzip barnyard-snortsam-hack.gz
[jj@Azazel /usr/home/jj]$ cd barnyard-0.2.0
[jj@Azazel /usr/home/jj/barnyard-0.2.0]$ patch -p1 < ../barnyard-snortsam-hack Hmm... Looks like a unified diff to me... The text leading up to this was: ...
Patching file src/output-plugins/op_alert_fwsam.c using Plan A...
Hunk #1 succeeded at 188.
Hunk #2 succeeded at 815.
done
[jj@Azazel /usr/home/jj/barnyard-0.2.0]$

This patch or "hack" has assumed that the location of your sid-msg.map is at /usr/local/etc/snort/sid-msg.map if this is not the case, you will need to edit /src/output-plugins/op_alert_fwsam.c around line 191 and specify the correct path. At this point you can configure barnyard and build as you normally would.

[jj@Azazel /usr/home/jj/barnyard-0.2.0]$./configure --enable-mysql
[jj@Azazel /usr/home/jj/barnyard-0.2.0]$make
[jj@Azazel /usr/home/jj/barnyard-0.2.0]$sudo make install

Your barnyard is now ready and we will cover the config file and startup after we get ipf and snortsam up and running.

The next step is to add the following to our Kernel so that we have ipf and ipfw enabled and running by default at boot.

# IPFW support

options IPFIREWALL #Enable IPFW directly in the kernel
options IPFIREWALL_FORWARD #Enable the Ip Forwarding function of IPFW
options IPFIREWALL_VERBOSE
options IPFIREWALL_DEFAULT_TO_ACCEPT
options IPDIVERT #allow this host to divert packets to/through different ints and routes

# IPF Support - default is to accept
options IPFILTER
options IPFILTER_LOG

Once these have been added please build your kernel, install and reboot. At this point we are ready to fetch and make snortsam.

[jj@Azazel /usr/home/jj]$ wget http://www.snortsam.net/files/snortsam/snortsam-src-2.52.tar.gz

2008-04-13 19:17:28 (497 KB/s) - `snortsam-src-2.52.tar.gz' saved [1075606/1075606]

[jj@Azazel /usr/home/jj]$ tar xvfz snortsam-src-2.52.tar.gz
x snortsam
[jj@Azazel /usr/home/jj]$ cd snortsam
[jj@Azazel /usr/home/jj/snortsam]$ sh ./makesnortsam.sh
-------------------------------------------------------------------------------
Building SnortSam (release)
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Building SnortSam (debug)
-------------------------------------------------------------------------------
Done.
[jj@Azazel /usr/home/jj/snortsam]$sudo cp snortsam* /usr/local/bin/

That's it for the snortsam build, now we are ready to configure everything and fire it up for a test! The first thing that we will configure is our snortsam. There is a good amount of documentation under snortsam/docs/README.conf that covers basic configuration. For our purposes we will create the file /etc/snortsam.conf and place the following in it.

defaultkey secrets
port 6783
accept 192.168.1.0/24
keyinterval 30 minutes
ipf bge0

This configuration specifies a default key of "secrets" and that the snortsam daemon should listen on port 6783 for connectoins from the 192.168.1.0/24 network. The configuration also specifies that the connection between the client (barnyard) and snortsam daemon will be rekeyed every 30 minutes and that ipf will be used on bge0 locally.

On to the barnyard configuration, this file will be barnyard-snortsam.conf located at /usr/local/etc/. The only line that needs to be in this file is the one that calls the snortsam plugin for barnyard and specifies the host:port/password

output alert_fwsam: 192.168.1.7:6783/secrets

The barnyard snortsam plugin uses a sid-block.map file to define what sids will be blocked, how they will be blocked and for how long they will be blocked. The format is quite simple "sid: where[option],duration;" and to test we will put the file at /usr/local/etc/snort/sid-block.map with the following entry

9999999: src[conn], 15 seconds;

I chose sid 9999999 so that I could create a custom rule in my local.rules to test my configuration.

alert icmp any any -> 1.2.3.4 any (msg:"test"; sid:9999999;)

Assuming you were able to add that rule, we are now at the point to fire things up and give it a good old fashioned roll (all in debugging verbose mode of course)!

Restart your snort so that it sees the new SID if you have not done so... -HUP FTW!@!!
Start snortsam (must be as root right now to have access to ipf)

[jj@Azazel /usr/home/jj]$ sudo snortsam-debug

Start barnyard with the new config file (even if you have a previosly running barnyard from the previous security appliance article... this will run at the same time, we have specified a new waldo file and pid file). Note that the following is ALL ONE LINE... no line breaks or crs! Note that this uses the snort.alert and not the snort.log just like the syslog facility.

[jj@Azazel /usr/home/jj]$ sudo /usr/local/bin/barnyard -c /usr/local/etc/barnyard-snortsam.conf -g /usr/local/etc/snort/gen-msg.map -s /usr/local/etc/snort/sid-msg.map -d /var/log/snort/ -f snort.alert -w /var/log/snort/barnyard-snortsam.waldo -p /usr/local/etc/snort/classification.config -X /var/barnyard-snortsam.pid -vvv

After starting barnyard you should see the following debug output from your snortsam-debug:

Debug: Connection from: 192.168.1.7.
Debug: Received Packet: CHECKIN
Debug: Snort SeqNo: cbb9
Debug: Mgmt SeqNo : 7000
Debug: Status : 1
Debug: Version : 14

Now that everything is up and running we can test. The best way to test all aspects is to point a separate system at the IP of this box (default router/gateway) or on my system as evident by the above config "192.168.1.7" and ping 1.2.3.4 with that separate system. The ipfw options that we previously set in the kernel will allow this host to simply route the traffic to the proper destination. You should see debug output from your snortsam-debug as such:

Blocking host 192.168.1.43 in connection 192.168.1.43->1.2.3.4:0 (icmp) for 60 seconds (Sig_ID: 9999999).
Debug: [ipf][28201600] Plugin Blocking...
Debug: [ipf][28201600] command /bin/echo "@1 block in log level local7.info quick on bge0 proto 1 from 192.168.1.43/32 to 1.2.3.4/32"|/sbin/ipf -f -

We can see from the output that it is blocking the source address of 192.168.1.43 and proto 1 (ICMP) only. This means that this host can still browse the internet and do everything (other than send icmp to 1.2.3.4 for 60 seconds), this is a function of the [conn] option in the sid-block.map file.

Wonderful, we now have a functioning version of snortsam running off of the snort output and not snort directly. This means that we can upgrade / change our snort instance itself and not have to re-patch and mess with that... (this of course assumes that the version you use can output unified so that your patched version of barnyard can read it). The final step in this process is to add the sids that you want to block to the sid-msg.map file. I have modified the create-sidmap.pl file to create a sid-block.map compatible output by reading all of the .rules files in a directory and dumping "sid: src[conn], 30min;" output. This output blocks the service by source that the alert was generated from for 30 minutes. The file can be obtained at http://www.redsphereglobal.com/data/tools/security/patches/create-sidblock.pl.gz. Usage is simple and as follows (again, note that it's one line):

[root@Azazel /home/jj]# ./create-sidblock.pl /usr/local/etc/snort/rules/ > /usr/local/etc/snort/sid-block.map
[root@Azazel /home/jj]# tail -n 3 /usr/local/etc/snort/sid-block.map
2500000: src[conn],30min;
2510000: src[conn],30min;
9999999: src[conn],30min;

I suggest that you not put ALL sids in this file, but rather take a subset from rules files that you know are bad news. To do this simply copy the .rules files into a directory of your choice and run the script against that directory (note that the sid-block.map must always live in /usr/local/etc/snort at this time). Other suggestions include daemonizing your barnyard instance (-D) rather than -vvv. The rest you can figure out.

The next part of this series will cover adding content filtration and a transparent squid instance into the mix on this box.

Cheers,
JJC

How do I know if my Snort implementation is working?

How do I test Snort? How do I know if Snort is sniffing packets? How do I know if Snort is running properly? How do I generate a test alert with Snort? Recently, and over the years, I have regularly seen people join the #snort channel on freenode and post these very questions to the snort mailing lists. Perhaps this little article will index properly in the search engines and end their questions, this is of course assuming that they know how to use a search engine ;-).

There are really several ways of testing snort, some much more complex than others. Probably the most simple way is to define a custom rule that you can easily produce the traffic to trigger the alert. This can be done by creating a simple rule that looks for traffic of a certain type, to a certain address or many other ways but for the purposes of this article we will be looking for traffic to a certain address (as this tends to be the most easily produced). We begin by creating a custom rule either in a new rules file or by adding the rule into an existing rules file. To simplify this you can download the rule from the url below:

https://secure.redsphereglobal.com/data/tools/security/snort/rules/snort-test.rules

Once you have downloaded this rule file and added it to your snort.conf so that Snort has loaded it, simply generate traffic from the monitored network to one or more of the following hosts: 121.175.169.102,193.71.199.6,200.123.165.130. This traffic can be of almost any type. I will typically browse via browser or telnet to a standard IRC port (at the time that I wrote this, these hosts were on the known C&C list) such as 6666, 6667 ....

Once this is done you will see the alerts being generated by snort (assuming that everything is configured properly).

As a second method, you can attempt to generate traffic that an existing snort rule can detect and alert on. To do this, I suggest using a tool such as Metasploit to generate actual attack traffic. You will want to test it against a host that you own, I certainly am not advocating attacking someones network with Metasploit from your network, this host should either be intended to be a test host, and/ or be immune to the attack. A simple example would be to enable the web-iis.rules from snort.org and launch an attack against one of your patched webservers from metasploit in an attempt to exploit MS01-23 using the Metasploit Framework Exploit. This will in-turn generate the WEB-IIS ISAPI .printer access alert to fire.

Either of those two methods should allow you to test your Snort installation, there are some other tcpreplay type tools that you can generate traffic from some signatures with, but by and large they are not effective tests.

Regards,
JJC

managing snort rulesets cont...

I need to amend my previous posting about the usage of Oinkmaster to automate and manage your Snort rules. I had added in the simple script a command that updates the sid-msg.map in a fairly unclean way. There is, infact, included within the /contrib of Oinkmaster a nifty little script called create-sidmap.pl. This script reads all of the rules from the rules path that you specify and generates sid-msg.map output that can be redirected into a clean sid-msg.map file.

The location in my original posting that should be changed is highlighted here:

secure2# vi /usr/local/bin/autooinkall.sh
#! /bin/sh
#
# simple script to run oinkmaster and obtain bleeding threat updates
# in addition to the regular snort.org updates
#
/usr/local/bin/oinkmaster -o /usr/local/etc/snort/rules/
/usr/local/bin/oinkmaster -C /usr/local/etc/oinkmaster-bleeding.conf -o /usr/local/etc/snort/rules/
cat /usr/local/etc/snort/rules/bleeding-sid-msg.map >> /usr/local/etc/snort/rules/sid-msg.map
/bin/kill -HUP `cat /var/run/snort_em1.pid`
/bin/kill -HUP `cat /var/run/by.pid`

This should be changed to /path/to/your/create-sidmap.pl /path/to/rules/ > /usr/local/etc/snort/rules/sid-msg.map so that the whole thing looks like the following:

secure2# vi /usr/local/bin/autooinkall.sh
#! /bin/sh
#
# simple script to run oinkmaster and obtain bleeding threat updates
# in addition to the regular snort.org updates
#
/usr/local/bin/oinkmaster -o /usr/local/etc/snort/rules/
/usr/local/bin/oinkmaster -C /usr/local/etc/oinkmaster-bleeding.conf -o /usr/local/etc/snort/rules/
/usr/lobal/bin/create-sidmap.pl /usr/local/etc/snort/rules > /usr/local/etc/snort/rules/sid-msg.map
/bin/kill -HUP `cat /var/run/snort_em1.pid`
/bin/kill -HUP `cat /var/run/by.pid`

Regards,
JJC

HeX 1.0.1R LiveUSB Image

After receiving numerous requests to create a HeX Live USB Key Image, I have completed it. This image includes all of the standard tools that you will find on HeX and is writable; so you can update things (signatures etc), make changes and so on.

To use this tool, simply download it from the below location, decompress it and use dd to place it onto your USB Key. If you are not familiar with the dd syntax it's quite simple really; dd if=/path/to/extracted/hex-i386-1.0.1.usb.img of=/dev/da0 (your USB device). Note, that you should not dd this to a mounted partition, it will not work. You need to dd onto a USB Key that you don't mind losing the data on, because this will overwrite everything on that key. You can create a small partition after the dd (this of course assumes that you know how to do this, leaving the existing partition in-place) and have that to write data to etc...

This image does require a minimum 2G key (actually uses 1.75G), and has no minimum memory requirements (other than standard fbsd and X requirements).

https://secure.redsphereglobal.com/data/tools/security/live/hex-i386-1.0.1.usb.img.gz
http://secure.redsphereglobal.com:8080/data/tools/security/live/hex-i386-1.0.1.usb.img.gz
MD5 (hex-i386-1.0.1.usb.img.gz) = cd7489ba0a2a1fe824d286c72eee6842
SHA256 (hex-i386-1.0.1.usb.img.gz) = ffbb428145e0184d3848e45afee0d10ba41a4d9177688db10befc943dd4058f5

Please test this out and let me know how it works for you, or let the entire team at rawpacket.org know.

Regards,
JJC

MySpace accont pwnage!

As the title indicates and as I have wanted to write about for some time now, ever since I noticed that the MySpace login page is not protected by any type of encryption, this posting is about sniffing MySpace passwords off of your network...

To test this theory, and have a little fun, I used snort to sniff some packets off of a ToR (The Onion Router) system that I built specifically for this purpose. The results below are fairly self-evident, though the names, dates, and locations have been changed to protect the guilty ^_^. As we can see from the below highlighted output, the username is j00r_myspace_pwned@hotmail.com and their password is password12345. I am both surprised and not surprised to see this on the internet today.

POST /index.cfm?fuseaction=login.process HTTP/1.1
Host: secure.myspace.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.myspace.com/
Cookie: MSCulture=IP=10.10.10.10&IPCulture=en-US&PreferredCulture=en-US&Country=US&timeZone=0&ForcedExpiration=633298319485005304&USRLOC=QXJlYUNvZGU9MjA3JkNpdHk9Q2FtZGVuJkNvdW50cnlDb2RlPVVTJkNvdW50cnlOYW1lPVVuaXRlZCBTdGF0ZXMmRG1hQ29kZT01MDAmTGF0aXR1ZGU9NDQuMjI1MyZMb25naXR1ZGU9LTY5LjA5MjMmUG9zdGFsQ29kZT0mUmVnaW9uTmFtZT1NRQ%3D%3D; SessionDDF1=933aa40e14c3e8ee00fd99a3ab029eea43bb704eb259248a

Content-Type: application/x-www-form-urlencoded
Content-Length: 586

__VIEWSTATE=%2FwEPDwUKMTI3ODg2ODMzM2QYAQUeX19Db250cm9sc1JlcXV
pcmVQb3N0QmFja0tleV9fFgIFMGN0bDAwJE1haW4kU3BsYXNoRGlzcGxheSRjdGw
wMCRSZW1lbWJlcl9DaGVja2JveAUwY3RsMDAkTWFpbiRTcGxhc2hEaXNwbGF5JG
N0bDAwJExvZ2luX0ltYWdlQnV0dG9u&NextPage=&ctl00%24Main%24Splash
Display%24ctl00%24Email_Textbox=j00r_myspace_pwned%40hotmail.com
&ctl00%24Main%24SplashDisplay%24ctl00%24Password_Textbox=password12345&ctl00%24Main%24SplashDisplay
%24ctl00%24Login_ImageButton.x=26&ctl00%24Main%24SplashDisplay%24ctl00%24Login_ImageButton.y=14&ctl00%24
Main%24SplashDisplay%24ctl00%24nexturl=&ctl00%24Main%24SplashDisplay%24ctl00%24apikey=
HTTP/1.1 302 Found
Cache-Control: private
Content-Length: 214
Content-Type: text/html; charset=utf-8
Location: http://login.myspace.com/index.cfm?fuseaction=ad&MyToken=2d99f690-abae-4839-97dd-64b48d1edd52
Server: Microsoft-IIS/6.0
X-AspNet-Version: 2.0.50727
Set-Cookie: MYUSERINFO=; domain=.myspace.com; expires=Wed, 19-Jan-2005 08:28:17 GMT; path=/
Set-Cookie: MYUSERINFO=; domain=myspace.com; expires=Wed, 19-Jan-2005 08:28:17 GMT; path=/
Set-Cookie: USER=; domain=.myspace.com; expires=Wed, 19-Jan-2005 08:28:17 GMT; path=/
Set-Cookie: USER=; domain=myspace.com; expires=Wed, 19-Jan-2005 08:28:17 GMT; path=/
Set-Cookie: MYUSERINFO=MIICtQYKKwYBBAGCN1gDlqCCAqUwggKhBgorBgEEAYI3WAMBoIICkTCCAo0CAwIAAQICZgMCAgDABAjl8wldaxuF7AQQzm1U8TfL0hIgLZm%2f%2baYNBwSCAmDFTCkutM5yyyvSN8vTANn5kgTYOPD3DWWxRcRQEx2ehj0nYpz3kqS0jJaAnb1PD7auiaNq8XMaipcAFbJbzntSKmLEwK7H%2brQknmAbEpo4YP3ofM9GcZb5ZYWzN2hj%2bclZDsJ4M%2fEPlqDElkLW7cWbUGcP2KMMcd%2bxJDxL3tcHHNaZymfryqMHpEibZtUEs%2bvHjbbQ8pcVNm%2bFyfO8yfnIJ20BCwebS7ZiseN0D0I8yWuZRwULf
7HTAYB8jdhQyx49ULlkCUT4DL0iORqNL8Q3CvSdRwS7zT7cyBNC%2fg6%2b0Hy1D4NGHQcSzIXJ2tGg2%2bz5kCDPrARZVK5qgsSbI90ouN5LKu4kPLDd7w9%2fHtsFo%2ft%2bP4h4k%2fMq57s%2fuPPkM4J4h7ewHwEIVzv4lnk39l7QTthhroMwi9Qn196c%2fDNByifjkOAocz09n%2fB4t%2bzycg7B8VyIlY1P%2f29syvz%2ft5NbkbyYbAu6Sfz0%2biNM%2fjuqEFHAY1dGU6W%2btR8GD%2bGvsWttdb8kPXKL4x6HpIr1QyGIwk0SZEDr2oMzZjcQegezv3loAV9JivU8HmYaaibwLMJUVIPv6uvvr1slqJ%2f7dmG6hjFeEDjb4uEvrYfZrV0R75JQPd3W6MXjciL%2bRW3YDuK
XGghi9I70PnpFuWeEkzE11U2IkyX3jb6GP4uOAl4KEZtQoF8LSsezdXPjlBP%2f1Q0upnPXJTzy0RNTfZZ0bdOuqnC13%2fNXIL96aZKgo0KVILrKN7E2uJYGkavoYyeK7Efolb%2f%2fgLSrX%2bUoicGc2oLceCWhrVxXdZAVt%2b0c7YNUTQ%3d%3d; domain=.myspace.com; path=/; HttpOnly
Set-Cookie: MSCulture=IP=10.10.10.10&IPCulture=en-US&PreferredCulture=en-US&Country=US&timeZone=0&ForcedExpiration=633298319485005304&USRLOC=QXJlYUNvZGU9MjA3JkNpdHk9Q2FtZGVuJkNvdW50cnlDb2RlPVVTJkNvdW50cnlOYW1lPVVuaXRlZCBTdGF0ZXMmRG1hQ29kZT01MDAmTGF0aXR1ZGU9NDQuMjI1MyZMb25naXR1ZGU9LTY5LjA5MjMmUG9zdGFsQ29kZT0mUmVnaW9uTmFtZT1NRQ==; domain=.myspace.com; expires=Mon, 12-Nov-2007 12:00:36 GMT; path=/
Set-Cookie: LASTUSERCLICK=%7bts+'2007-11-05+04%3a00%3a36'%7d; domain=.myspace.com; path=/
Set-Cookie: GADC=EUD=0:0:YTVkMTA4OTQ5ZDg5ZWI0OekNaTFtgDI_S7P6H2jrQzkk4nPuDPBbmATsWT8Cbo-Vd3Hgs227A2MQcf3dzClR3nwSH5PPEg8uiygF6KzHRgPJYhvfCX0YsIcKZKOEwjO3; domain=.myspace.com; expires=Fri, 05-Nov-2027 11:00:36 GMT; path=/
Set-Cookie: SplashDisplayName=j00r_myspace_pwned; domain=.myspace.com; path=/
Set-Cookie: D
ERDB=ZG9tYWluPS5teXNwYWNlLmNvbSZ0bGQ9Y29tJnNtb2tlcj0yJnNleHByZWY9MSZ1dHlwZT0yJnJlbGlnaW9uaWQ9MCZyZWdpb249MjAmcG9zdGFsY29kZT0wNDU3MiZtYXJpdGFsc3RhdHVzPU0maW5jb21laWQ9MCZoZWlnaHQ9MTcxJmdlbmRlcj1NJmZyaWVuZHM9MSZldGhuaWNpZD04JmFnZT0zMCZib2R5dHlwZWlkPTYmY2hpbGRyZW5pZD00JmNvdW50cnk9VVMmZGF0aW5nPTAmZHJpbmtlcj0xJmVkdWNhdGlvbmlkPTEmcmVsYXRpb25zaGlwcz0wJm5ldHdvcmtpbmc9MCZkaXNwbGF5bmFtZT1KZXJlbXkmZnJpZW5kaWRfaW50PTE0MzE0MDkxNyZpcGFkZHJlc3M9JzY
5LjM5LjExMC4yNycmc2NobD0wJnNjaGw9MCZzY2hsPTAmZ3JwPTAmZ3JwPTAmZ3JwPTAmY3VsdHVzZXJwcmVmPTEwMzM=; domain=.myspace.com; path=/
Set-Cookie: MSCulture=IP=10.10.10.10&IPCulture=en-US&PreferredCulture=en-US&Country=US&timeZone=0&ForcedExpiration=633298319485005304&USRLOC=QXJlYUNvZGU9MjA3JkNpdHk9Q2FtZGVuJkNvdW50cnlDb2RlPVVTJkNvdW50cnlOYW1lPVVuaXRlZCBTdGF0ZXMmRG1hQ29kZT01MDAmTGF0aXR1ZGU9NDQuMjI1MyZMb25naXR1ZGU9LTY5LjA5MjMmUG9zdGFsQ29kZT0mUmVnaW9uTmFtZT1NRQ==; domain=.myspace.com; expires=Mon, 12-Nov-2007 12:00:36 GMT; path=/
Set-Cookie: Login=; domain=.myspace.com; path=/
X-Server: ce28ca171d6578a0dad1823b61ec8978cabea8d4955341dd
Date: Mon, 05 Nov 2007 12:00:36 GMT

I am surprised because I know that MySpace receives a large amount of traffic and has quite the large user base, I would therefore think that they would provide SSL/TLS transport as a minimum to protect the authentication information of their user base. But I am also not surprised by the fact that this is yet another blaring sign pointing to the fact that many organizations, engineers and so on do not take security seriously, nor do they develop with security as even so much as an afterthought.

I also find it quite humorous that they actually have "Safety Tips" on their site. Probably the most humerus of which is their sixth tip on that page: "Don’t get hooked by a phishing scam. Phishing is a method used by fraudsters to try to get your personal information, such as your username and password, by pretending to be a site you trust. Click here to learn more." I suppose that they are right though...I mean, why submit your information to a phishing site/scam when they can just sniff your traffic and own your account!

Of course gaining access to the users account is only the beginning, this opens up the door to a whole realm of possibilities, given the fact that *most* users will use the exact same password for all of their accounts. Or they will at least use a basic derrivation of that password, an example would be adding a different number to the end in each instance i.e. password1, password2, password3. Compromising the email account associated with the MySpace account also makes it extremely easy to gain additional information about an individual and ultimately be able to steal various types of sensitive information or even to further breach their resources (corporate accounts and the like).

With the use of ToR and various anonymizers growing every day, and the level of expertise / knowledge of the basic ToR user not being that of a security minded individual, it is surprisingly easy to grab a number of MySpace user accounts in short-order. During my testing period (roughly two weeks) of running a ToR server and sniffing for the magic MySpace packet, I was able to build a database of over 20 accounts and their associated passwords. Conceivably I could create a network of ToR servers and be able to easily own accounts at a fairly rapid rate.

All of this said, I strongly urge MySpace to purchase an SSL cert or two and use them, if nothing more than for the login process "This is what google does with gmail, a user browses to http://gmail.google.com and to logon is redirected to the https:// site, after authentication they are directed back to the http:// site".

For fun, I have included below a snort rule that should catch the magic MySpace packet ;-), this is from bleedingthreats.net.

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"BLEEDING-EDGE POLICY Myspace Login Attempt"; flow:established,to_server; content:"login.myspace.com"; uricontent:"/index.cfm?fuseaction=login"; classtype:policy-violation; sid:2002872; rev:2;)

I would like to thank Jeff for sending me some of his pcap data for analysis!

Cheers,
JJC

HeX Live 1.0 Release

After 6 months of heavy development and debugging I am pleased to announce the release of the HeX Live CD 1.0 Release. What is HeX Live? HeX Live is the worlds first and foremost Network Security Monitoring & Network Based Forensics liveCD. The intent is to provide a wide array of highly usable tools in a pre-packaged format that the analyst can use to investigate and monitor real-time network activity, whether security related or in the course of reviewing traffic to determine bandwidth over utilization sources and so on...

This will be the final major release of HeX LiveCD until the release of FreeBSD 7.0 Rel, this is of course pending no major bugs are located in HeX 1.0R. If there are any major bugs found, then a bug-fixed HeX will be released prior to FreeBSD 7.0 Rel.\\

For a detailed list of what applications can be found on HeX Live 1.0R check out the actual project at rawpacket.org.

I have also included in this posting the CD covers that were created by vickz, fantastic work man! You can download the HeX LiveCD 1.0R from the following locations:

1. US Server (East Coast) | MD5 | SHA256 | User Guide
   
2. Malaysia Server | MD5 | SHA256 | User Guide
   

I will try to get some decent screenshots posted soon so that everyone can see just how slick the HeX LiveCD 1.0R really is. I would also suggest that you download it and play with it. There are a good number of tools on here for packet monkeys of all ages and skill to have a good old time!

I'll leave it at that for now, and again would like to thank the community for their support and feedback throughout the development process of this tool.

Shout to Geek00l for organizing everything and kicking some a$$!
Shout to ch4flgs_ and zarul for everything!
Shout to all others involved in this project (esp for putting up with me)

Cheers,
JJC

HeX Live Pending Release

For all of you anxious packet monkeys out there, the HeX LiveCD 1.0R will soon be available. We are running through extensive tests and bug fixing excersizes right now, but anticipate releasing this new version within the next week. I'll post an update once released, as well as the standard US mirrors.

This project has also been gaining a good amount of momentum and continued community support. I would like to thank all involved, esp geek00l and chfl4gs_ (the core founders)!

If you want some additional information concerning this project, please check out www.rawpacket.org!

Cheers,
JJC

DHS Security Breach cont...

I believe that Richard summed up the consensus of the security community with his recent posting at http://taosecurity.blogspot.com/2007/09/dhs-debacle.html, therefore I will only stick to my comments. I would also like to note that I am not taking any sides here, simply commenting on what I read, Contractor Blamed in DHS Data Breaches:

Among the security devices Unisys had been hired to install and monitor were seven "intrusion-detection systems," which flag suspicious or unauthorized computer network activity that may indicate a break-in. The devices were purchased in 2004, but by June 2006 only three had been installed -- and in such a way that they could not provide real-time alerts, according to the committee. The rest were gathering dust in DHS storage closets and under desks in their original packaging, the aide said.

But who made the decision? I have personally seen "critical" equipment in the back of many a corporation and government agencies closet... Was this due to negligence by not being installed, or were DHS personnel involved in mucking up the works, so to speak.

In the 2006 attacks on the DHS systems, hackers often took over computers late at night or early in the morning, "exfiltrating" or copying and sending out data over hours -- in one case more than five hours, according to evidence collected by the committee.

A senior military technology officer warned last fall that China downloaded "10 to 20 terabytes of data" from the Pentagon's non-classified Internet Protocol router network. "They are looking for your identity so they can get into the network as you," Maj. Gen. William Lord, Director of Information Services and Integration in the Air Force Office of Warfighting Integration, said at an Air Force technology conference. "There is a nation-state threat by the Chinese."

I am curious if DHS or Unisys have the data or capability to review any detailed session data. Just another case for good exfiltration detection tools and techniques. They obviously got something with those "three" sensors that were in-place.

"Through October of that year, Thompson said, 150 DHS computers -- including one in the Office of Procurement Operations, which handles contract data -- were compromised by hackers, who sent an unknown quantity of information to a Chinese-language Web site that appeared to host hacking tools."

I guess not...

In closing, please be sure that your C&A / ST&E and so fourth and so on are conducted by personnel that are not connected to your operations. Further, be sure that you ensure adequate controls are in-place and not just hot air! Seems like I had more to add yesterday when I was worked up about this, but it has subsided. I hope that you find this useful as with my previous posts.

Cheers,
JJC