Friday, September 28, 2007

HeX Live Update

Excerpt from geek00l:
For all the HeX liveCD users out there, we have been developing this liveCD for quite sometimes and I have received some positive and negative comments and various inputs from the users, therefore instead of me receiving the email and redirect to other co-developers, I decide to create the mailing list for the HeX liveCD so that it will has life of its own ;P

There you go -

Since this is public group and mainly used for mailing list management, I decided to use google group as it is convenience and easy. Therefore feel free to join us!!!!!

On the other hand, you can visit us at Freenode #rawpacket. Most of us are slacking there.
I would also like to thank everyone for their feedback and support of this project, one small step at a time. As to some additional information, there has been some discussion surrounding the creation of a VM image / Virtual Appliance that would embody the HeX Live CD capabilities and give the network analyst a broad set of tools. I'll post updated about this as they are available.


NessusClient 3.0.0 Beta 4 Bug

In the process of testing and writing my previous post, I missed a bug that seems to exist in Linux and Win32 builds of the NessusClient 3.0.0 Beta 4 (atleast on Windows XP SP2 and FC6). I have it installed on Ubuntu Feisty Fawn but have not connected to a Nessus scanner yet, though I suspect the results will be the same.

This bug is in the Connection Manager, if you do not remove the default Nessus server and create a new one, it will crash the NessusClient.

Shout out to Bruce for the Winblows screenshot and the initial identification that there was a problem!

Conclusion....same as my last posting, the only difference in Beta 4 is that there are newly introduced bugs and the "support" for certificate based authentication to the Nessus server.

Bug opened at:


Thursday, September 27, 2007

NessusClient 3.0.0 Beta 4 - Nothing really new

Today, Tenable announced their NessusClient 3.0.0 Beta 4. Being the consummate security professional (geek) that I am, I had to download it and poke around. I must say that I am still disappointed that it lacks many of the capabilities of the nessus client itself (CLI).

The look and feel are the same as since Beta 3 (and earlier Linux / Mac releases).

Main Screen, add hosts, connect to scanner, define scanning policy / type and begin scan.

Add host(s) or subnetworks

Edit scan policy.

And finally...the results!

So, now that you have seen the results and a bit of the options I'll get into it. Overall this is a somewhat useful tool for ad-hoc or verification vulnerability scans. The primary drawbacks are that it will only export to html, nbe and nsr but not txt or xml (both supported by the CLI client). While all plugins have associated CVSS scores, A significant drawback of the NessusClient is that it does not sort or readily display the results based on CVSS scores. This makes it difficult to locate results by score and thereby prioritize.

All being said, this is a good support tool and I would suggest using it in conjunction with something like InProtect that will give you the history and maintain result sets in a manageable and queryable database.


Tuesday, September 25, 2007

DHS Security Breach cont...

I believe that Richard summed up the consensus of the security community with his recent posting at, 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.


Tuesday, September 18, 2007

bleeding and regular rules with Oinkmaster

As promised in a previous posting, here is the information about configuring oinkmaster to obtain both bleeding edge threat rules and standards snort rules.

first let's copy our /usr/local/etc/oinkmaster.conf file so that we can have a new config file for our bleeding rules.
secure2# cp /usr/local/etc/oinkmaster.conf /usr/local/etc/oinkmaster-bleeding.conf
secure2# vi /usr /local/etc/oinkmaster-bleeding.conf
#replace your url string w/ the following...
# Example for rules from the Bleeding Snort project
url =
#save the file
Now, let's retrieve the files and put all of the trash together....for simplicity sake let's just put this into a script...
secure2# vi /usr/local/bin/
#! /bin/sh
# simple script to run oinkmaster and obtain bleeding threat updates
# in addition to the regular 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/ >> /usr/local/etc/snort/rules/
/bin/kill -HUP `cat /var/run/`
/bin/kill -HUP `cat /var/run/`

That's it.. now run the script or crontab it... enjoy


Friday, September 14, 2007

InProtect Update, It Lives!

Just to give a quick update about the InProtect project, it is up and alive again and we now have 12 people actively working on the project!

We are in the process of developing a roadmap and evaluating several forks to determine what should be used or adopted into the upcoming version.

As of the time of this post, we have established the team and decided that we will be converting to sourceforge's SVN repo rather than the CVS and have started evaluating the forks...some screenshots are attached below.

It's also been nice to see people continuing to use this tool and support it. If you get a free moment or need some assistance, please feel free to swing by #inprotect on and say hi.

Customizable Dashboard (thx Heath!)

Anti-aliased graphs!

Added reports and report sorting functionality

There are certainly more features that are in the works or have been added, but I won't steal the teams thunder. Please check back here or at the InProtect site regularly for updates.


Tuesday, September 11, 2007

Network Security Toolkit Pt 1 (using snort with barnyard, apache, mysql, php and BASE)

So, as the title implies this is the first in a multi-part series discussing a network security toolkit built on Open Source. The system that I am using to create this is FreeBSD 6.2 RELEASE. We will be building tools mostly from the ports tree, but a few are not yet ported, so we will manually install those as needed.

  1. You have installed and somewhat adequately secured FreeBSD
  2. You have a basic knowledge of the FreeBSD OS and have network connectivity on this system
  3. If you don't know this / have your system setup, you know how to RTFM (Google)
  4. You have updated your ports tree prior to building this stuff

Ok, now that we have established the assumptions, let's go over the software that we are going to use for this implementation:

  1. Apache22 - Core webserver to serve up your base /usr/ports/www/apache22
  2. MySQL 50 - Database server to house your snort data /usr/ports/databases/mysql50-server/ (also -client and -scripts)
  3. php5 - php support for apache22 /usr/ports/lang/php5
  4. base - your snort alert and event viewing tool /usr/ports/security/base
  5. barnyard - the tool that takes the unified snort logs and puts them into your MySQL database /usr/ports/security/barnyard
  6. snort - your IDS engine /usr/ports/security/snort
  7. oinkmaster - snort rule updater /usr/ports/security/oinkmaster
  • phpmyadmin a GUI tool to help you manage your MySQL databases /usr/ports/databases/phpmyadmin


Apache22 - install and edit httpd.conf then start and test

secure2# cd /usr/ports/www/apache22 && make install clean
secure2# vi /usr/local/etc/apache22/httpd.conf
secure2# /usr/local/sbin/apachectl start
you should now be able to browse to http://ipofinstalledhost/ and receive the "It Works!" message.
MySQL 50 - install and set a password for root user
secure2# cd /usr/ports/databases/mysql50-server/ && make install clean
secure2# cd /usr/ports/databases/mysql50-scripts/ && make install clean
secure2# cd /usr/ports/databases/mysql50-client/ && make install clean
secure2# /usr/local/etc/rc.d/mysql-server start
secure2# mysqladmin -u root password "passwordwithouquoteshere"
secure2# mysqladmin -u root -h localhost password "passwordwithouquoteshere"
secure2# mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 88965
Server version: 5.0.45-log FreeBSD port: mysql-server-5.0.45

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)

php5 - php5 install be sure to select apache when asked for configuration options!
secure2# cd /usr/ports/lang/php5 && make install clean
secure2# vi /usr/local/etc/apache22/httpd.conf
.# insure that the following is in your httpd.conf
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps
secure2# apachectl restart
BASE - install and prepare base for use
secure2# cd /usr/ports/security/base && make install clean
.#be sure to select MySQL support...PDF is optional
. #configure apache22 to serve base
secure2# vi /usr/local/etc/apache22/httpd.conf
##place this at the bottom of httpd.conf
Alias /base/ "/usr/local/www/base/"
secure2# apachectl restart
chown -R www:www /usr/local/www/base/
mysql -u root -p
mysql> create database base_demo;
Query OK, 1 row affected (0.00 sec)
secure2# mysql -u root -p base_demo < /usr/local/www/base/sql/create_base_tbls_mysql.sql
Now that we have setup the previous components we can access BASE by browsing to http://ipofinstalledhost/base/ where you should see the following BASE configuration screen:

We will be going through this setup process in a bit, first we need to get snort with barnyard up and running.

snort - install and configure the system to use snort.
secure2# cd /usr/ports/security/snort/ && make install clean
#be sure to Enable MySQL support
#add tables to the database...
secure2# mysql -u root -p base_demo < /usr/local/share/examples/snort/create_mysql #configure snort.conf secure2# vi /usr/local/etc/snort/snort.conf #modify this file as needed for your network.... . #configure logging only for unified..i.e. the following lines output alert_unified: filename snort.alert, limit 128 output log_unified: filename snort.log, limit 128 #I'll write more about tuning SNORT rules later, but for now this will get you started. #before we can start snort to test, we will need to get the latest signatures using oinkmaster!
oinkmaster - magical snort rule updater?
secure2# cd /usr/ports/security/oinkmaster/ && make install clean
secure2# vi /usr/local/etc/oinkmaster.conf
#get your registration code from and plug it into the Snort 2.4 download url in the oinkmaster file....

barnyard - log unified snort output to database
secure2# cd /usr/ports/security/barnyard/ && make install clean
#be sure to Enable MySQL support
secure2# vi /usr/local/etc/barnyard.conf
#configure your barnyard to log the data..the following lines are important
# set the hostname (currently only used for the acid db output plugin)
config hostname: secure2
# set the interface name (currently only used for the acid db output plugin)
config interface: em1
# Converts data from the dp_log plugin into an approximation of Snort's
# "ASCII packet dump" mode. Argument:

output log_dump
# password database connect trash
output alert_acid_db: mysql, sensor_id 1, database base_demo, server, user root, password passwordhere
output log_acid_db: mysql, sensor_id 1, database base_demo, server, user root, password passwordhere detail full

Putting it all together and starting it up.
secure2# oinkmaster -o /usr/local/etc/snort/rules/
secure2# /usr/local/bin/snort -c /usr/local/etc/snort/snort.conf -i em1 -u root -D > /dev/null -n
secure2# /usr/local/bin/barnyard -c /usr/local/etc/barnyard.conf -g /usr/local/etc/snort/ -s /usr/local/etc/snort/rules/ -d /var/log/snort/ -f snort.log -w /var/log/snort/barnyard.waldo -p /usr/local/etc/snort/rules/classification.config

once all of this is done, your snort should be logging the unified data, barnyard reading it and slapping it into your database.

Now, let's get back to our configuration for BASE. Browse to http://ipofinstalledhost/base/ and select the continue option. The next few screens are filled with the configuration options to connect you to the base database(s). Simply input the information for the db, dbuser, dbpass and you will be all set!

Congratulations, you now have a functioning SNORT install using barnyard, MySQL and BASE. I did not cover the install of phpmyadmin, but you should be able to Google it and figure it out...

I'll be following this post up with the addition of bleeding snort rules, how to properly tune your snort configuration, the use of SGUIL (TRUE NSM) and several other goodies relating to network security... so stay posted.