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)

Cheers,
JJC

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.


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