Tuesday, December 18, 2007

Ubuntu Bashing Continued

It has been a while since I upgraded and subsequently wrote about my experience of upgrading Ubuntu 7.04 to Ubuntu 7.10. I gave Ubuntu 7.10 the good old college try, but have to report that I am now back to my FreeBSD Laptop.

The primary issues that I had with Ubuntu 7.10 had to deal with wireless networking. The connection speed would never exceed 23mbps and even when the driver stated that it was connected at 23mbps I could not achieve throughput of more than 5mbps, even with the laptop sitting 5' from the AP. The second, and most irritating, issue with the wireless networking setup of Ubuntu 7.10 was the consistent disconnects and intermittent reconnects. Often it would not reconnect and I would have to reboot and piss with it for 30 minutes before it would inexplicably reconnect. Of course this started to remind me of M$ reboots and I had to immediately remediate the situation with ufs and FreeBSD!

At first I thought that this was potentially related to the Broadcom 43XX chipset in the test laptop. I then tested with different Intel (non proprietary) wireless cards and different APs. An additional reason that I tested with different access points was due to the range limitation that I was experiencing with Ubuntu 7.10. I was only able to get to roughly 30' from the AP before I would lose signal.

The combination of these three wireless issues, in addition to the upgrade pain, led me to flatten the system and slap FreeBSD 6.2 REL onto it. That said, I am now back into my comfort zone of *BSD. I will also say that I have loaded the Broadcom 43xx windows driver using ndis and that I now have full 54mbps connectivity and a range of greater than 50' from the same APs that I had less than 30' with Ubuntu 7.10.

So, to conclude and finish this mild rant, I think that the new Ubuntu 7.10 is a decent distro overall "for the click brigade" but I also think that more time should have been put into the guts as opposed to the shininess of the whole thing. Of course, if you read some of my previous postings about the shininess setup issues that I experienced out of the box with Ubuntu 7.10....then perhaps they should have put more time into that as well.

Previous articles:
Ubuntu 7.04 to 7.10 Upgrade Notes Pt. 1
Ubuntu Upgrade to 7.10 Strike 2
Ubuntu Upgrade....or not (with compiz)


Thursday, December 13, 2007

InProtect Update...

And a few operational notes....

We are working hard to get out the next RC for your scanning pleasure. In the meantime, please continue the use and bug reporting, it's been great thus far!

Now, as to a big bug and how to properly handle it. In previous versions of InProtect you were able to control the number of scans with the max_scans value in the Nessus Servers configuration dialogue. Unfortunately with the modification of the nessus_run.pl script to streamline the scanning process, the max_scans variable does not properly control the actual scans being processed by the scanner. A simple example is as follows;

Lets say you schedule a scan with 60 hosts (IP Addresses) to be scanned and have limited in the Nessus Scanner Max_Scans setting a maximum of 10 concurrent scans on said server. When this scheduled scan starts to run it will start out with 10 scans, once those begin to complete it will immediately say that it's running 20 scans then 30 and so on.

To remediate this issue, you need to do a couple of things...first lets go ahead and kill our sched.pl process so that we can clean up the database (if you still show multiple scans running and none are actually running "ps -auxxx | grep nessus"). Once this is complete, go ahead and look in your Inprotect database under the nessus_scan table for any record with a value of 'R' in the status field ( select * from nessus_scan where status='R';". If you find that you do have records with 'R' as their status, you need to set them as 'C' "UPDATE`inprotect`.`nessus_scan` SET `status` = 'C' WHERE `status` = 'R' ; ", you will also need to reset the current_scans value in the nessus_servers table "UPDATE `inprotect`.`nessus_servers` SET `current_scans` = '0';". After completing these steps you can now start your sched.pl up again. As another note, you may want to set all of the status values to 'C' just to clean up that table, once you restart sched.pl it will clean out all of the 'C' status scans and set their main schedule back to a scheduled status.

Now that we have cleaned up the remnants of the aforementioned bug, lets go ahead and talk about the current workaround. This workaround is fairly straightforward and consists of two simple modifications to your scan profile and your nessus server settings. First, let's get into the InProtect GUI and select Settings -> Nessus Servers -> Edit, at this point we will be modifying the value for Max number of hosts to scan and setting it to an extremely high number such as 10000 or more.

The next part of this workaround is to define the maximum hosts that will be scanned in the actual scan profile. This will tell the nessusd server itself how many scans that it is allowed to run at the same time. Select Settings -> Nessus Scan Profiles -> Edit your existing default profile -> Preferences, under the serverprefs section are the options max_checks and max_hosts. The max_checks value defines the number of test to be run concurrently against a single hosts and the max_hosts defines the maximum concurrent number of hosts that the nessusd server will scan. As you can see by the below image, I have set my default values to 4 checks and 10 hosts.


Monday, December 10, 2007

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`

Monday, December 3, 2007

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).

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.


Monday, November 26, 2007

beta.openpacket.org updates

Several updates have been made to the http://beta.openpacket.org:8080 site, please stop by and help us continue to test the site.


InProtect Beta 0.80.2

In the interest of continuing a good thing (although this post is a bit late), we have released a new bugfix version of InProtect 0.80.x. This version is 0.80.2 and can be found at our sourceforge download location.

We hope to have an official release out on or about the new year and are working hard to meet this deadline. I would like to thank all of the users for their feedback and continued support of this project. It is always refreshing and energizing when there is good positive community usage and feedback!

As always, I invite you to join us in freenode or arcnet in #inprotect to tell us about your experiences, issues, bugs and the like.


FreeBSD jabberd port mysql bug

As a quick post (esp since I have not been posting much lately) I recently ran into another issue with jabberd on freebsd. I say another, if you will remember a previous post concerning sasl - http://global-security.blogspot.com/2007/08/pidgin-on-linux-w-jabberd2-on.html.

This has more to do with cleaning up some of the errors that seem to exist in the mysql schema. Specifically, if you install jabberd2 from the ports tree "/usr/ports/net-im/jabberd" and configure it to use mysql as it's storage engine, you will receive several errors in your stdout our log files (depending on your configuration). These errors are generated when a users status changes, i.e. login, logout, away etc... I have included a quick snapshot of the errors below.

Nov 26 14:48:48 secure2 jabberd/sm[1629]: mysql: sql delete failed: Table 'jabberd2.status' doesn't exist
Nov 26 14:50:26 secure2 jabberd/sm[1629]: mysql: sql delete failed: Unknown column 'collection-owner' in 'where clause'
Nov 26 14:51:10 secure2 jabberd/sm[1629]: mysql: sql select failed: Unknown column 'object-sequence' in 'order clause'
Nov 26 14:51:10 secure2 jabberd/sm[1629]: mysql: sql insert failed: Unknown column 'status' in 'field list'
Nov 26 14:52:17 secure2 jabberd/sm[1629]: mysql: sql insert failed: Unknown column 'show' in 'field list'
Nov 26 14:52:58 secure2 jabberd/sm[1629]: mysql: sql insert failed: Unknown column 'last-login' in 'field list'
Nov 26 14:55:46 secure2 jabberd/sm[1629]: mysql: sql insert failed: Unknown column 'last-logout' in 'field list'
Nov 26 14:59:46 secure2 jabberd/c2s[1631]: [7] [, port=3746] disconnect jid=user@test.com/Home, packets: 15
Nov 26 14:59:46 secure2 jabberd/sm[1629]: session ended: jid=user@test.com/Home
Nov 26 15:00:05 secure2 jabberd/c2s[1631]: [7] [, port=3932] connect
Nov 26 15:00:05 secure2 jabberd/c2s[1631]: [7] SASL authentication succeeded: mechanism=DIGEST-MD5; authzid=user@test.com
Nov 26 15:00:05 secure2 jabberd/c2s[1631]: [7] bound: jid=user@test.com/Home
Nov 26 15:00:05 secure2 jabberd/c2s[1631]: [7] requesting session: jid=user@test.com/Home
Nov 26 15:00:05 secure2 jabberd/sm[1629]: session started: jid=user@test.com/Home
To remediate this, simply run the following against your jabberd2 mysql database:

CREATE TABLE `status` (
`collection-owner` varchar(256),
`object-sequence` bigint,
`status` text NOT NULL,
`show` text,
`last-login` int DEFAULT '0',
`last-logout` int DEFAULT '0',
PRIMARY KEY (`collection-owner`));
This will get ya going, I'm not gonna go into what's wrong with the script that is included in the jabberd2 install, I think that it's pretty straight forward.

Also note, I will try to post more regularly now but it's been a hectic few weeks for me (new job, family visiting etc...)


Monday, November 12, 2007

InProtect 0.80.1 Beta

Fixed a few of the issues that everyone was experiencing... also updated the following:
  • clean install - fixed bad syntax issues
  • clean install - set proper version in db
  • clean install - changed admin to Admin in user group data (Admin is the original user for conformity)
  • upgrade - set proper version in db
  • upgrade - changed admin to Admin in user group data (Admin is the original installed user and this setting must match the current user so that proper access is given to Admin)
Also added note that Admin password is "admin" in INSTALL, this is changed as of versions 0.80.x

new tarball can be found here:


We should have the sourceforge project site updated with this tarball at some point tomorrow. I will also be following up with upgrade instructions tomorrow, as the current instructions do not include details of upgrading to 0.80.x.


InProtect 0.80.0 Beta *fixed clean install sql*

My apologies for the issues that people have been experiencing with the new Beta of InProtect, but please remember that this is the purpose of a beta.

I appreciate all of the feedback in IRC and comments on this blog. Below is the URL to a version of InProtect with a cleaned up clean install sql script. Note that you may still have issues with the actual install script (not the .sql) and I am working on that right now, hopefully will have that out shortly for you.

InProtect 0.80.0 Beta **FIXED**


Thursday, November 8, 2007

InProtect 0.80.0 Beta Released!

So we have *finally* managed to get the 0.80.0 Beta out the door, unfortunately the new packaged does not include any of the new info for the install or upgrade (there are twelve of us working on this). I'll be covering some of these topics in follow up articles over the next day or so.

Get the InProtect 0.80.0 Beta Here!

For now, let's talk about some of the major changes that we have incorporated into this version.

  • Completely revamped menu system, access control driven.
  • User customizable dashboard.
  • Html and PDF report formats match.
  • Exportable xls reports.
  • Cleaned up excessive and unneeded sql queries to enhance speed.
  • Role-Based permissions.
  • Exception list for hosts.
  • Host specific lookup capabilities.
  • Cleaner interface.
  • All passwords are encrypted using user definable cryptographic standards such as blowfish.
  • Sensitive data is encrypted.
  • Database structure modified to allow for role-based permissions.
  • Database structure modified to enhance and improve large query response (including indexing).
  • Max server scans are now run in a single session rather than multiple individual sessions, this reduces the load on both the nessus scanner and the InProtect console server.
  • Encryption and decryption functions added for sensitive data.
  • Multiple unneeded queries removed to enhance performance.
  • Query function creation and destruction cleaned up to enhance performance.
That is basically a quick run-through of the new features (there are more.. but these are the big ones IMHO). There are a few additional perl libraries that are not yet mentioned in the documentation contained in the 0.80.0 tarball but are required in addition too those mentioned in the documentation, I'll list them here for you.

New Perl libraries:
  • Crypt::CBC
  • MIME::Base64
  • IO::Socket
  • Socket
This should be some good info to get you started for now, but as I said earlier, I will be posting some additional information (detailed info) for new installs and upgrades over the next few days. I will also try to update the official wiki and FAQ with these instructions.

So, for now feel free to download and play with it, let me know what you think, I can usually be found in #inprotect on freenode.


Monday, November 5, 2007

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: Gecko/20071008 Firefox/
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=; SessionDDF1=933aa40e14c3e8ee00fd99a3ab029eea43bb704eb259248a

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


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
XGghi9I70PnpFuWeEkzE11U2IkyX3jb6GP4uOAl4KEZtQoF8LSsezdXPjlBP%2f1Q0upnPXJTzy0RNTfZZ0bdOuqnC13%2fNXIL96aZKgo0KVILrKN7E2uJYGkavoYyeK7Efolb%2f%2fgLSrX%2bUoicGc2oLceCWhrVxXdZAVt%2b0c7YNUTQ%3d%3d; domain=.myspace.com; path=/; HttpOnly
Set-Cookie: MSCulture=IP=; 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
5LjM5LjExMC4yNycmc2NobD0wJnNjaGw9MCZzY2hsPTAmZ3JwPTAmZ3JwPTAmZ3JwPTAmY3VsdHVzZXJwcmVmPTEwMzM=; domain=.myspace.com; path=/
Set-Cookie: MSCulture=IP=; 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!


Sunday, November 4, 2007

Coming Soon - InProtect 0.80.0 Beta

I am excited to announce that we are on track for a beta/alpha release of InProtect 0.80.0 this coming week. You will see a great deal of enhancements in this version, including cleaner reports and graphs, user customizable dashboard, more efficient scan scheduler and controller...and much more!

I have included a "teaser" screenshot below. Note that the latest code is always available from the InProtect Sourceforge SVN repo (but that should be considered "alpha" only)...since we are consistently making changes, fixes, tests and updates...

I am also entertaining the idea of replacing / augmenting the nmap functionality with unicornscan (sice unicorns are fast! <3 Unicorns), let me know what your thoughts / concerns / comments are.


Wednesday, October 31, 2007

Nessus 3.06 on Ubuntu 7.10 _Gutsy Gibbon_

Post upgrading to Gutsy Gibbon on one of my test systems I needed to install an application that I regularly use (Nessus). To install this I downloaded the standard Nessus 3.0.6 deb package from nessus.org and attempted install via the package manager. The installation attempt produced the following Error: Dependency is not satisfied: libssl0.9.7. Normally I wouldn't write about this, but given the fact that I noticed several locations on the internet (various forums and blogs) about this issue being unresolved for many users I figured I would post what worked for me.

The first thing that I did was install libssl-dev "sudo apt-get install libssl-dev". After installing libssl-dev I again attempted to install the Nessus 3.0.6 deb package and received the same error " Error: Dependency is not satisfied: libssl0.9.7". My next step was to download libssl0.9.7_0.9.7g-5ubuntu1.1_i386.deb directly from packages.ubuntu.com and install this deb package. That's what did the trick, Nessus is now up and running and everyone (me) is happy.


Monday, October 29, 2007

HeX-VA (Virtual Security Appliance)

I am pleased to announce the release of the HeX Virtual Appliance!

To facilitate quick and easy use of the tools that are built into the HeX Live CD, we have installed the Live CD on four Virtual Machines to create four Security Virtual Appliance Images. These images are intended to aide in the rapid deployment and usability of the HeX Live Toolkit and we are dubbing it HeX-VA. The images are designed for use with Parallels, Qemu, VMware and Virtualbox virtualization technologies. If you have any problems using these images or have any suggestions, please feel free to contact us or stop by #rawpacket on freenode.

Thanks to geek00l for the screenshots and continued hard work on this project! I have included the US Mirrors below for your downloading pleasure. If you are not US based, there are other Malaysian mirrors listed on the official rawpacket.org site under the Virtual Appliance project section.

HeX-Paralleles | md5 | sha256
HeX-Qemu | md5 | sha256
HeX-VMware | md5 |sha256
HeX-Virtualbox | md5 |sha256

I'll be posting some detailed directions shortly on the usage of NTop and some specifics on tuning it for your environment (by request).


Screenshots of various HeX-VAs:

Friday, October 26, 2007

HeX 1.0.1 Release (Bug Fixes)

So, due to several flaws that people were experiencing with HeX 1.0R we are releasing an updated version (1.0.1). The fixes in this version include increased bootup speed; during the extraction and loading of the data into mfs /var, the IO process of several different system types was causing an apparent system hang, this has been resolved.

Another major issue that was occurring was with the msfweb not loading properly or not functioning when loaded. It turns out that this was actually a firefox related issue; deleting ~/.mozill/firefox and using the global Firefox configuration fixed the problem (note that this also fixed javascript issues in ntop and darkstat).

As geek00l says, we are "shamelessly" releasing this fixed version. As always please give it a roll and let us know if you experience any issues. You can report bugs using our Trac interface, the Mailing List or via IRC in #rawpacket on freenode.

Download URLs:

Tuesday, October 23, 2007

Openpacket.org Beta

The openpacket.org beta site is live (and has been for a while, but I did not think to post about it) :-\

This site is the brainchild of Richard Bejtlich who announced the beta at http://openpacket.blogspot.com. Please swing by and drop some pcap data or just some comments / requests.

The site is located at http://beta.openpacket.org:8080


Monday, October 22, 2007

InProtect, on track for alpha release

...We hope to have an alpha/beta release of the upcoming InProtect 0.80.0 within two weeks.

Good positive progress has been made tuning all of the elements of the engine itself for improved performance in lowering the overall load of the scheduling engine itself. We are currently working on migration scripts for users using both the 0.22.5 and 0.22.5JC versions.

You will see some big database changes and enhancements to the GUI in the form of role-based permissions, a per-user customizable dashboard at login, cleaned up table indexes and optimized queries and much much more.


Saturday, October 20, 2007

Ubuntu Upgrade...or not (with compiz)

Perhaps it was a lack of patience on my part, or poor forward planning on Ubuntu's part, but I could no longer continue to attempt upgrading after what was likely the 30th failed attempt. As a result of this upgrade attempt outcome I decided to backup the /home/* directories and perform a clean install.

As one would expect the standard install succeeded with no problem. The expected options were available from custom partitioning to setting initial user and permissions during the installation. The only real issue that I had was with the "seamless" compiz implementation that I had heard so much about.

For this installation I used an HP laptop that I have, this laptop contains an ATI X series video card and therefore supports 3D acceleration. I was disappointed that the compiz (3D) desktop acceleration did not work out of the box, so here is what I did to make it work: Initially I simply tried to enable Extra effects after enabling the proprietary video card. This only produced the error "Composite extension not found"...after enabling in xorg.conf (as described below) I received the fairly generic error "Unable to enable visual effects" or similar... So here are my steps to enable compiz on Ubuntu 7.10 with ATI drivers (what worked for me)

  • Enable all of the repos that have proprietary software and the like System -> Administration -> Software Sources.
  • Enable the proprietary video card driver from the Restricted Drivers Manager.
  • Make sure composite extensions are enabled : vi /etc/X11/xorg.conf
Section "Extensions"
Option "Composite" "1"
  • Install xserver-xgl "sudo apt-get install xserver-xgl
  • Install compizconfig-settings-manager "sudo apt-get install compizconfig-settings-manager" *this is not a requirement but gives you a level of customization that is nice.
  • Restart X
  • Try it out System -> Preferences -> Appearance -> Visual Affects (select what you want here...I used Extra then Custom from the last apt-get install)
Everything else worked nicely, enabled the proprietary fwcutter for my wireless card and it worked, no more mucking with it as in previous versions, very nice!

All in all, I give this version a Thumbs Up despite the upgrade mess, seems more stable so far and clean.

Hope this helps someone out :-)


Friday, October 19, 2007

Ubuntu Upgrade to 7.10 Strike 2

As I write this, I have attempted roughly 10 "upgrades" via the Update Manager with the same result each time as displayed below.

Obviously this is producing some anxiety on my behalf, as I am anxious to upgrade. That said, I fear that the upgrade process, much like previous upgrade processes from the Ubuntu folks, is a complete joke.

In preparation for the joke to be a fact, I kicked off the download and noted again that the servers are getting hammered... bitTorrent anyone?


Thursday, October 18, 2007

Ubuntu 7.04 to 7.10 Upgrade Notes pt 1

Time to see if the Ubuntu folks have cleaned up their upgrade process. Previous upgrade attempts have been painful to say the least (this means pre-7.10).

I kicked the process off at about 21:30 EST by updating my existing 7.04 installation with all of the latest package updates as noted in the Ubuntu upgrade process documentation. The update went smoothly with the simple exception that a boatload of other users must be doing the same thing and loading up the repos. I did have to restart the updates a few times to get all files to download (again, likely related to repo overload, considering the fact that I regularly update my Ubuntu systems and this is not a normal occurrence). It should be noted that the Upgrade to 7.10 option was available prior to updating my packages, but IAW the upgrade documentation I performed the package update first.

The first thing we do after making sure all packages are updated is click on the Upgrade button to kick off the 7.04 to 7.10 upgrade process and again click Upgrade in the release notes. This kicked off the upgrade process and started to download the Upgrade Tool (again a little slow...likely load related). Once the Upgrade Tool finished downloading and kicked off, more downloading and waiting as the Upgrade Tool runs through upgrade preparations, software channel modifications, fetching upgrades, installing upgrades, clean up and system restart.

This is where the trouble began, again I suspect due to load on the distribution servers. After waiting for about an hour on file 50 of 56, I canceled the process and started again in the hopes that it would jumpstart the download. Unfortunately this did not work, so I left it to fetch overnight, and woke up to the screenshot to the right.

With all of the excitement and everyone else attempting to update and upgrade at the same time, I'll be intermittently trying to complete my upgrade over the next week in the hopes that it will complete. That being said, I have spoken with a few of my associates that were able to fetch all of the upgrade files (~6 hours of downloading at painfully slow rates) and they had their upgrade fail roughly halfway through the process, thereby rendering their system useless and forcing a clean install of 7.10.

The same associate of mine "giovani" also suggested using bittorrent for the mass distribution medium, to alleviate some of the pain that we are all feeling with the seemingly overloaded repos. Something definitely needs to be done, bittorrent or otherwise, to clean up these load produced upgrade and update failures.

More to follow...


Optimizing MySQL on FreeBSD part 1

I have written a few other times at a few separate locations about tuning MySQL in the past, so I'm going to attempt and write a bit of updated material and keep it all in one place, this blog. I will be following up in the next few months concerning additional tuning steps that can be taken.

Recently while browsing the interweb, I came across a nifty little perl script written by Major Hayden of rackspace.com.

I put a copy of this perl script here for ease of downloading and use. To get it, simply download -> extract it -> make executable. Of course you need perl installed to use it...

Some examples of output that I received when I ran the script ./mysqltuner.pl on one of my higher transaction test servers:
General recommendations:
Reduce your overall MySQL memory footprint for system stability
Enable the slow query log to troubleshoot bad queries
Reduce or eliminate persistent connections to reduce connection usage
Adjust your join queries to always utilize indexes
Variables to increase:
*** MySQL's maximum memory usage exceeds your installed memory ***
*** Add more RAM before increasing any MySQL buffer variables ***
max_connections (> 125)
key_buffer_size (> 11.1G)
query_cache_size (> 256M)
join_buffer_size (> 1024.0M, or always use indexes with joins)
Variables to decrease:
wait_timeout (<>
I modified most of the variables in question in my /etc/my.cnf and restarted mysqld and let it run for a few days. I then ran the script again and got the following output:
MySQL High-Performance Tuner - Major Hayden
Bug reports, feature requests, and downloads at mysqltuner.com
Run with '--help' for additional options and output filtering
Please enter your MySQL login: root
Please enter your MySQL password:
[OK] Currently running supported MySQL version 5.0.41-log
-------- General Statistics --------------------------------------------------
[--] Up for: 6d 5h 5m 20s (8M q [16.393 qps], 139K conn, TX: 2G, RX: 4G)
[--] Reads / Writes: 65% / 35%
[!!] Maximum possible memory usage: 442.7G (1341% of installed RAM)
[OK] Slow queries: 0%
[OK] Highest usage of available connections: 49%
[OK] Key buffer size / total MyISAM indexes: 12.0G/11.1G
[OK] Key buffer hit rate: 99.8%
[OK] Query cache efficiency: 31.5%
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0%
[!!] Joins performed without indexes: 2838670
[OK] Temporary tables created on disk: 0%
[OK] Thread cache hit rate: 99%
[OK] Table cache hit rate: 78%
[OK] Open file limit used: 13%
[OK] Table locks acquired immediately: 99%
-------- Recommendations -----------------------------------------------------
General recommendations:
Reduce your overall MySQL memory footprint for system stability
Enable the slow query log to troubleshoot bad queries
Adjust your join queries to always utilize indexes
Variables to increase:
*** MySQL's maximum memory usage exceeds your installed memory ***
*** Add more RAM before increasing any MySQL buffer variables ***
join_buffer_size (> 1.5G, or always use indexes with joins)
All in all, this is a highly useful script to get some quick stats and easy adjustment variables to help tune your MySQL server. I should also note that this is not specific to FreeBSD, but I happen to be a FreeBSD junkie and this this was all tested on a FreeBSD 6.2 Rel box.


Canonical releases Ubuntu 7.10

Canonical Ltd. released the latest version (7.10) of the Ubuntu Server, Desktop, Kubuntu and Edubuntu Editions today. You can get more information about these releases and download them at the official Ubuntu site.

The Ubuntu developers have also created an upgrade path for users that are currently on the 7.04 ("Feisty Fawn") release. As stated on their website, the migration is as simple as insuring that all updates have been applied to your Feisty Fawn installation then opening System -> Administration -> Update Manager -> Select Upgrade (you may need to check for new updates). At this point you simply follow the on-screen instructions.

I will be testing this process tonight on my HP laptop and posting my results when complete.


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)


Wednesday, October 10, 2007

Loose lips sink ships!

During recent interweb browsing and reading I came across the following and have to comment, it's been in the news lately but this just brought it up again for me; http://www.nysun.com/article/64163.

WASHINGTON — Al Qaeda's Internet communications system has suddenly gone dark to American intelligence after the leak of Osama bin Laden's September 11 speech inadvertently disclosed the fact that we had penetrated the enemy's system.

The intelligence blunder started with what appeared at the time as an American intelligence victory, namely that the federal government had intercepted, a full four days before it was to be aired, a video of Osama bin Laden's first appearance in three years in a video address marking the sixth anniversary of the attacks of September 11, 2001. On the morning of September 7, the Web site of ABC News posted excerpts from the speech.

But the disclosure from ABC and later other news organizations tipped off Qaeda's internal security division that the organization's Internet communications system, known among American intelligence analysts as Obelisk, was compromised. This network of Web sites serves not only as the distribution system for the videos produced by Al Qaeda's production company, As-Sahab, but also as the equivalent of a corporate intranet, dealing with such mundane matters as expense reporting and clerical memos to mid- and lower-level Qaeda operatives throughout the world.

Has the media lost all of their capability to make good discretionary decisions? Further, typically they have subject-matter experts, one would think that such experts would know better. But I suppose that it is all about the ratings and making that next buck!

While intranets are usually based on servers in a discrete physical location, Obelisk is a series of sites all over the Web, often with fake names, in some cases sites that are not even known by their proprietors to have been hacked by Al Qaeda.

Similar to a botnet etc... effectively a chain of pwned servers. This is certainly not a new concept and usage of such a concept in conjunction with services such as ToR (The Onion Router) would make tracking Obelisk users virtually impossible.

One intelligence officer who requested anonymity said in an interview last week that the intelligence community watched in real time the shutdown of the Obelisk system. America's Obelisk watchers even saw the order to shut down the system delivered from Qaeda's internal security to a team of technical workers in Malaysia. That was the last internal message America's intelligence community saw. "We saw the whole thing shut down because of this leak," the official said. "We lost an important keyhole into the enemy."

We most certainly did lose an important keyhole, ya think? If a keyhole is what you would call it. The intel received from such a source could easily help thwart future planned terrorist and military actions etc...

By Friday evening, one of the key sets of sites in the Obelisk network, the Ekhlaas forum, was back on line. The Ekhlaas forum is a password-protected message board used by Qaeda for recruitment, propaganda dissemination, and as one of the entrance ways into Obelisk for those operatives whose user names are granted permission. Many of the other Obelisk sites are now offline and presumably moved to new secret locations on the World Wide Web.

The founder of a Web site known as clandestineradio.com, Nick Grace, tracked the shutdown of Qaeda's Obelisk system in real time. "It was both unprecedented and chilling from the perspective of a Web techie. The discipline and coordination to take the entire system down involving multiple Web servers, hundreds of user names and passwords, is an astounding feat, especially that it was done within minutes," Mr. Grace said yesterday.

I agree with Mr. Grace, to an extent, it would be a feat indeed if individual personnel were involved. I think that it's also plausible to think that this network operated much like a botnet. From that perspective there could have been a simple command or series of commands that initiated the automatic shutdown or action to be taken in the event of a security breach.

The head of the SITE Intelligence Group, an organization that monitors Jihadi Web sites and provides information to subscribers, Rita Katz, said she personally provided the video on September 7 to the deputy director of the National Counterterrorism Center, Michael Leiter.

Ms. Katz yesterday said, "We shared a copy of the transcript and the video with the U.S. government, to Michael Leiter, with the request specifically that it was important to keep the subject secret. Then the video was leaked out. An investigation into who downloaded the video from our server indicated that several computers with IP addresses were registered to government agencies."

Yesterday a spokesman for the National Counterterrorism Center, Carl Kropf, denied the accusation that it was responsible for the leak. "That's just absolutely wrong. The allegation and the accusation that we did that is unfounded," he said. The spokesman for the director of national intelligence, Ross Feinstein, yesterday also denied the leak allegation. "The intelligence community and the ODNI senior leadership did not leak this video to the media," he said.

Ms. Katz said, "The government leak damaged our investigation into Al Qaeda's network. Techniques and sources that took years to develop became ineffective. As a result of the leak Al Qaeda changed their methods." Ms. Katz said she also lost potential revenue.

A former counterterrorism official, Roger Cressey, said, "If any of this was leaked for any reasons, especially political, that is just unconscionable." Mr. Cressey added that the work that was lost by burrowing into Qaeda's Internet system was far more valuable than any benefit that was gained by short-circuiting Osama bin Laden's video to the public.

I personally think that it's more than unconscionable, I dare say it's borderline treason!

While Al Qaeda still uses human couriers to move its most important messages between senior leaders and what is known as a Hawala network of lenders throughout the world to move interest-free money, more and more of the organization's communication happens in cyber space.

"While the traditional courier based networks can offer security and anonymity, the same can be had on the Internet. It is clear in recent years if you look at their information operations and explosion of Al Qaeda related Web sites and Web activities, the Internet has taken a primary role in their communications both externally and internally," Mr. Grace said.


Tuesday, October 9, 2007

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!


InProtect Wiki and Update

The project continues to gain speed and support from the community (thanks again everyone!). The core team is currently meeting every other Sunday, in the secret InProtect cave, to hash out the roadmap and future plans. Unfortunately I was not in town for the most recent meeting and away from the interweb and therefore did not make the meeting.

However I still have some updates that I can post;
The InProtect Wiki is now online and we will be working hard to keep it updated with the latest goodies, FAQ, etc...! http://inprotect.wiki.sourceforge.net, please check it out and let us know what we can do to improve it or what you would like to see added.

I continue to get visitors to #inprotect on irc.freenode.net and appreciate all of the continued feedback.

We anticipate having the CVS -to- SVN conversion done shortly and subsequently publishing an Alpha release of the new version. We will also be updating the InProtect home page with meeting notes, roadmap and so on, in the near future!


Monday, October 1, 2007

FIXED::[Bug 1641] NessusClient 3.0.0 Beta 4 Crash on Server Connect

I must say that I am quite pleased with Renaud Deraison of nessus.org for his rapid response and remediation of the bug that I discovered last week (NessusClient 3.0.0 Beta 4 Bug). There was an uninitialized pointer when a class was created from an XML file (rather than dynamically), which in turn created a bad memory access and therefore crashed the client.

Nessus.org has posted a fixed version, Beta 5 of the 3.0.0 NessusClient at their typical download location: http://www.nessus.org/download/.

I would also like to add to my previous posting about the feature set of the NessusClient and it's inability to export to XML (this is still true) but can be worked around (too a degree anyway). When you scan a host and if you chose to save the session, upon exiting the NessusClient, it creates a .nessus file which is pure XML (albeit it's a different XML format than the CLI xml), and which contains much more information about the scan than the other formats (it contains all the scan results, the policies, the targets associated to each scan, etc...

Thx again Renaud!


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: http://bugs.nessus.org/show_bug.cgi?id=1641


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 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.


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 = http://www.bleedingthreats.net/rules/bleeding.rules.tar.gz
#save the file
Now, let's retrieve the files and put all of the sid-msg.map trash together....for simplicity sake let's just put this into a script...
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`

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 irc.freenode.net 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 http://inprotect.sourceforge.net 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 snort.org 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/gen-msg.map -s /usr/local/etc/snort/rules/sid-msg.map -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.