TaoSecurity Blog

After reading PHK's Why Bother? article, I wondered about the goals of the FreeBSD project. I found them in the handbook : "1.3.2 FreeBSD Project Goals Contributed by Jordan Hubbard. The goals of the FreeBSD Project are to provide software that may be used for any purpose and without strings attached. Many of us have a significant investment in the code (and project) and would certainly not mind a little financial compensation now and then, but we are definitely not prepared to insist on it. We believe that our first and foremost 'mission' is to provide code to any and all comers, and for whatever purpose, so that the code gets the widest possible use and provides the widest possible benefit. This is, I believe, one of the most fundamental goals of Free Software and one that we enthusiastically support. That code in our source tree which falls under the GNU General Public License (GPL) or Library General Public License (LGPL) comes with slightly more strings attached

In the October issue of Daemon News , Poul-Henning Kamp asks "Why Bother?" He wants to know why people use FreeBSD when Linux gets most of the attention from users and vendors. He also wants to know why developers should continue to work on FreeBSD. I will tailor my response for FreeBSD, as that is the BSD with which I am most familiar. Some of my arguments will apply to other variants. Some of my reasons even apply to other open source operating systems, like Linux. Few will apply to closed operating systems, least of which Windows. 1. FreeBSD is open source , with a business-friendly license . Being an open source, BSD-licensed operating system means I am free to modify the OS as I see fit and can continue to support and evolve any part of it, should the official developers decide to abandon any aspect of the project. I can use FreeBSD in commercial projects as long as I retain the copyright notice and disclaimer with the product. 2. FreeBSD is an integrated, co

As a former intelligence officer and computer network defender I was asked my thoughts on the US Air Force 's new computing deal with Microsoft . In short, Microsoft will provide core server software, maintenance and upgrade support, and Dell will supply more than 525,000 Microsoft desktop Windows and Office software licenses to the Air Force. From a business perspective, this is an important deal for Microsoft. For all of their seeming independence, the services tend to watch each other closely to see what technological advances are being considered or pursued. When the Navy began work on its Navy Marine Corp Intranet (NMCI), Air Force leaders scrambled to "catch up" to match the "progress" the Navy was assumed to be making. (NMCI has since produced mixed results for the Navy and financial woes for EDS , prime NMCI contractor.) I have first-hand knowledge of the Air Force's response to NMCI. In the fall of 2000, the AFCERT sent me to Washington, DC

On Wednesday I mentioned that a chapter from my book appeared in a new form at Informit.com. A snort-users reader asked how Sguil differed from ACID and BASE . In short, there are five reasons: 1. Sguil is a real-time interface to Snort alerts (and more). 2. Sguil is a Snort alert management system with integrated analyst accountability features. 3. Sguil offers growing alert handling capabilities. 4. Sguil is built to minimize "window management," "form management," and other non-analytical tasks. 5. Most importantly, Sguil is not limited to investigating events using Snort alert data alone. To read explanations of each point, please see my response to the snort-users mailing list. You'll also find in that message three "features" that are not present in Sguil. I should have mentioned that Sguil is the single tool most likely to provide analysts with the information they need to make a decision . With Sguil, a Snort alert is not the end of t

While browsing the tcpdump-workers mailing list I came across a post describing the The Meta Traffic Processor PCI Card . This device "is a standard 32-bit/33MHz, PCI half-card with two copper Ethernet ports. The MTP appears to the host's operating system as a standard network interface card capable of enforcing from 600 to 1500 stateful policies to capture and/or block specific packets. The policies can be directly derived from public domain signatures or they can be completely user defined." These "policies" can be Snort rules or one day BPF filters. The product appears to be the result of work done for a NSF grant . Metanetworks founder Livio Ricciulli described his project to NANOG in May 04. I had heard from a .mil type that DoD was working with a vendor to run Snort-like applications in hardware. Perhaps this is what he meant? I intend to contact Livio to see if his card works with FreeBSD.

Several recent Blog entries described ways to keep FreeBSD applications up-to-date. Based on my use of these tools, this is how I chose to update one of my servers this morning. First I updated the ports tree, INDEX-5, and INDEX.db: cd /usr/ports portsnap fetch portsnap update make fetchindex portsdb -u Next I checked to see which applications needed to be updated: janney:/usr/ports# portversion -v -l "<" bash-3.0.15 < needs updating (port has 3.0.16_1) freebsd-update-1.6 < needs updating (port has 1.6_1) sudo-1.6.8.1 < needs updating (port has 1.6.8.4) I prefer to update applications by using precompiled packages provided by the FreeBSD team. Unfortunately, the packages-5-stable FTP site hasn't been updated since 15 Nov. I decided to press ahead and update these three packages on my own by building the upgrades from source. I used portupgrade to (in the order of the switches shown), be verbose, update all package

Last night the FreeBSD ports tree broke the 12,000 mark. The tree has added about 2000 ports per year for the past four years. This graph shows the number of ports added per year since 1995. I commend FreshPorts for providing such an excellent interface to the tree, and for keeping up with the growth in the number of applications available. FreshPorts recently integrated VuXML data, allowing users to visually see what port versions have a security issue. More details and information on other upgraded FreshPorts features are available here .

Now that we've seen how to keep the ports tree up-to-date using tools like Portsnap, and seen how to generate an INDEX-5 file with 'make index', I'd like to offer an alternative INDEX-5 generation mechanism. Matthew Seaman's Portindex is a Perl tool replacing a similar application of the same name. The old version was pulled from the ports tree when the developer started acting strangely. Here's the problem Portindex solves. If you use CVSup to update your ports tree, you will not have an INDEX-5 file. The INDEX-5 file included in CVS was reportedly always out-of-date, so you had to issue a command like 'portsdb -U' or 'make index' to create the INDEX-5 file. This was very time-consuming. Portindex is a much faster alternative, once you've set up the system. Portindex is available in the ports tree as sysutils/p5-FreeBSD-Portindex , so installation is easy (as long as your ports tree is updated!) My installation is based on Matthew

In January I explained how I installed the java/jdk14 port on FreeBSD 5.2. Today I installed the java/jdk14 port on one 5.3 RELEASE system, janney, and then used packages built during the install process to install the JDK on my 5.3 RELEASE laptop, orr. The FreeBSD project cannot distribute packages of the latest Java software due to Sun's licensing restrictions. (Really old 1.3.1 binary packages are offered from the FreeBSD Foundation .) I can create my own packages for personal use as I have read and accepted Sun's licenses. I cannot redistribute those packages for others to use. First I ensured my ports tree was updated. Next I placed the necessary archives for the installation in /usr/ports/distfiles. These included: bsd-jdk14-patches-6.tar.gz j2re-1_4_2_06-linux-i586.bin j2sdk-1_4_2-bin-scsl.zip j2sdk-1_4_2-mozilla_headers-unix.zip j2sdk-1_4_2-src-scsl.zip j2sdk-1_4_2_06-linux-i586.bin The first is available at EyesBeyond.com . The second is available as the

CERT/CC just published ten Principles of Survivability and Information Assurance . They are: 1. Survivability is an enterprise-wide concern. 2. Everything is data. 3. Not all data is of equal value to the enterprise – risk must be managed. 4. Information assurance policy governs actions. 5. Identification of users, computer systems, and network infrastructure components is critical. 6. Survivable Functional Units (SFUs) are a helpful way to think about an enterprise’s networks. 7. Security Knowledge in Practice (SKiP) provides a structured approach. 8. The road map guides implementation choices (all technology is not equal). 9. Challenge assumptions to understand risk. (Think like an intruder.) 10. Communication skill is critical to reach all constituencies. Some of these principles are backed up by their own papers or CERT practices. They are a good starting point to measure an organization's overall security posture.

My buddy Keith McCammon told me he found Informit.com serving up chapter 10 from The Tao of Network Security Monitoring as Why Sguil Is the Best Option for Network Security Monitoring Data . Controversial, and not my doing. :) Still, the whole chapter is there in browsable HTML, along with embedded screenshots. We are still testing Sguil 0.5.3 but expect to release it soon.

When the FreeBSD Security team released an advisory for fetch(1), I knew I could turn to Colin Percival's FreeBSD Update for binary security upgrades. Installation is simple. Here's how to installing via package: pkg_add -vr freebsd-update mkdir /usr/local/freebsd-update cp /usr/local/etc/freebsd-update.conf.sample /usr/local/etc/freebsd-update.conf Here is how FreeBSD Update patched the fetch(1) vulnerability: orr:/root# freebsd-update fetch Fetching public key... Fetching updates signature... Fetching updates... Fetching hash list signature... Fetching hash list... Examining local system... Fetching updates... /usr/bin/fetch... Updates fetched To install these updates, run: '/usr/local/sbin/freebsd-update install' orr:/root# freebsd-update install Backing up /usr/bin/fetch... Installing new /usr/bin/fetch... That's it. I didn't need to CVSup to STABLE or manually patch the fetch(1) binary. FreeBSD Update handled it, and with the change being to userland,

The traditional means to update the FreeBSD ports tree involves using CVSup in a manner described well by Dru Lavigne . After the sysutils/cvsup port is installed, and ports-supfile modified to point to a real CVSup server (e.g. *default host=cvsup8.FreeBSD.org'), you run commands like this: cvsup -g -L 2 /usr/local/etc/ports-supfile portsdb -uU The first command updates the ports tree in /usr/ports. The second command creates or updates the INDEX file (via the 'U') and then creates or updates the INDEX.db file (via the 'u') from the INDEX. There is now an alternative to CVSup available in the ports tree: Portsnap , written by FreeBSD-update author Colin Percival . Installation via packages is easy: orr:/root# setenv PACKAGESITE ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-5-stable/Latest/ orr:/root# pkg_add -vr portsnap ...edited... Package portsnap-0.2_1 registered in /var/db/pkg/portsnap-0.2_1 Before you can use portsnap, you will have to create an

I always enjoy reading Professor Orin Kerr's Computer Crime Case Updates . This week he comments on the dismissed wiretapping case mentioned by SecurityFocus.com and Slashdot . Although some commentary from the likes of Slashdot is helpful, I prefer reading the opinions of a Harvard Law graduate and former Supreme Court clerk . The case is simple: does use of a keystroke logger constitute a wiretap? The judge in the case said no. I agree with Prof Kerr's assessment that the opinion is wrong. If someone listens in on a phone between the handset and the base unit, it's still a wiretap. It's no different if someone collects keystrokes using a device between a keyboard and CPU. However, I disagree with Prof Kerr's reasoning concerning interstate commerce. Plenty of judges disagree with me, but I don't think connecting to the Internet makes a system automatically engaged in "interstate commerce." I think the use of the so-called Interstate Com

The UK-based news site The Register was victimized by an advertisement provider, Falk AG , beginning Saturday. The ads served by Falk AG were carriers for the Bofra worm , which uses a buffer overflow in FRAME, IFRAME, and EMBED elements of pre-XP SP2 Internet Explorer. The Register promptly issued a warning on Sunday morning, followed by a statement on restoration of service this morning. The Register estimates the number of visitors who could have been affected by this event, which is a good way to scope the extent of the incident. Falk AG has also owned up to the incident, although its wording leaves a little to be desired. From the company's statement : "Early Saturday morning (20.11.2004) an unauthorized individual exploited a weakness in a load balancer on the European AdSolution network. The purpose of the exploit was to establish a redirect to malicious code through a javascript component of Falk’s ad delivery... Unauthorized access was possible only as a

Back in January I described installing OpenOffice.org 1.1.0 on FreeBSD 5.2 RELEASE. I used packages from the FreeBSD OpenOffice Porting Team . I am happy to report I installed OpenOffice.org 1.1.3 on FreeBSD 5.3 RELEASE using packages hosted at http://oootranslation.services.openoffice.org/pub/OpenOffice.org/ooomisc/FreeBSD/ . The FreeBSD project does not maintain precompiled packages for OpenOffice.org (OOo), presumably because it takes too long for the build cluster to create the packages from source. Therefore, one cannot do 'pkg_add -vr openoffice' and expect to download packages from a FreeBSD FTP site. This means that you usually download the appropriate OOo package from the aforementioned Web site and execute 'pkg add -v OOo_1.1.3_FreeBSD53Intel_install.tbz' . If you are missing a dependency, however, you must add it manually. Consider what happened when I took these actions: pkg_add -v OOo_1.1.3_FreeBSD53Intel_install.tbz Requested space: 274391836

Fixing Weird Behavior after Thunderbird and Mozilla Upgrades FreeBSD 5.3 RELEASE shipped with thunderbird-0.7.3_1.tbz and firefox-0.9.3_1.tbz . Newer precompiled packages are available, so I upgraded to thunderbird-0.9_2 and firefox-1.0,1. When I started Thunderbird, I found I had no mail in any of my folders. My default folder languages had also changed to Arabic. After searching the Web, I found this forum which suggested deleting the compreg.dat file in the .thunderbird/default.XXX directory. Sure enough, after renaming the file, a restarted Thunderbird performed as it should have. When I started Firefox, I found that middle-clicking on links launched a new, yet empty, tab. I also couldn't use my arrow keys to navigate the address bar. I decided to move the compreg.dat file in the .mozilla/firefox/default.XXX directory. After restarting Firefox, it too worked fine.

freebsd.png" align=left>As much as I like FreeBSD's ports system, I dislike keeping the tree up-to-date using CVSup . I haven't yet tried Colin Percival's portsnap tool, which uses HTTP to distribute compressed and cryptographically signed snapshots of the ports tree. This is a great alternative, but I try to avoid compiling from source using the ports tree when possible. I run several very generic and slow systems, and I'd much rather install and upgrade software using precomplied packages. Portupgrade is the tool of choice to update software on FreeBSD. Portupgrade is powerful because it can (far more often than not) resolve dependencies to upgrade software en masse. It doesn't matter if an application is installed via ports or precompiled packages. Once installed, FreeBSD treats it like a package using tools like pkg_info . When invoked with the -PP switch, portupgrade can be told to only upgrade installed software by using packages. This avoi

Now that FreeBSD 5.3 has arrived, users are trying to determine if any performance issues are caused by their hardware, OS, or applications. There's a great freebsd-stable thread discussing a user's attempt to improve NFS performance. One of Robert Watson's comments is especially useful, since he spells out five steps to troubleshoot network performance: "I think the first thing you want to do is to try and determine whether the problem is a link layer problem, network layer problem, or application (file sharing) layer problem. Here's where I'd start looking: (1) I'd first off check that there wasn't a serious interrupt problem on the box, which is often triggered by ACPI problems. Get the box to be as idle as possible, and then use vmstat -i or stat -vmstat to see if anything is spewing interrupts. (2) Confirm that your hardware is capable of the desired rates: typically this involves looking at whether you have a decent card (most if_em cards are

Jeremy Hewlett announced the release of Snort 2.3.0 RC1 . The major additions are the snort_inline code and the new sfportscan portscan detector. Sguil users should recognize that alerts from the new portscan detector are not yet fully integrated, due to lack of support in Barnyard. Bamm is working on a modified op_sguil Barnyard component to support sfportscan output. If you enable sfportscan with Sguil, you'll see the alerts appear in the Sguil interface. However, they will not be inserted into the alerts database. This means sfportscan alerts will not be available for review once they are cleared from the display. Below is an example of how the new sfportscan alerts appear in Sguil. The interesting aspect of the new sfportscan system is the creation of a "pseudo-packet" with the alert details. The alert above shows sfportscan believes ports 21 through 80 were scanned, although the activity which generated this report was directed at ports 21 through 25: nmap

Back in July I described my experiences running a June snapshot of FreeBSD 5-CURRENT on a Dell Poweredge 750 1U server. Recently I installed FreeBSD 5.3 RELEASE on the same hardware; here is the dmesg output for a kernel recompiled with SMP support. While perusing the freebsd-current mailing list I came upon this thread which in part debated the merits of recompiling for SMP support on HTT machines. According to Intel : "Hyper-Threading Technology, available on Intel Pentium 4 processors supporting Hyper-Threading Technology, is a form of simultaneous multithreading (SMT) that makes a single processor look like multiple processors to the operating system. In its current implementation, HT Technology delivers two logical processors that can execute different tasks simultaneously using shared hardware resources. While an HT Technology–enabled processor doesn't equal the computing power of two physical processors, performance can be boosted with very little increase in co

While perusing the freebsd-questions mailing list, I read a post by Robert Watson describing FreeBSD 5.3's networking performance. In short, it seems FreeBSD 5.3 will process packets slower than FreeBSD 4.x, due to the transition to the SMPng architecture. Performance will improve over the next few months as optimizations are done within the new architecture. Tracking 5-STABLE will cause these improvements to be integrated into running systems. I am deploying FreeBSD 5.3-based systems now, as the 5.x tree supports the Dell hardware I'm using. I have not had any problems with 5.x yet and I expect it to only get better. Robert also mentioned a new FreeBSD Network Performance site, describing in detail the work done to enhance the performance of the FreeBSD network stack.

I downloaded the .iso for the live CD version of the Sun Java Desktop System . When booting it reports being based on the Linux distro Morphix , version 0.4. I was sad to see the X autoconfiguration fail on my Thinkpad a20p, so I couldn't test it on my primary system. I was able to boot the CD on my Shuttle SB52G2 and on a Dell Optiplex GX100. On the Shuttle JDS was not able to automatically detect my Linksys WMP55AG A+G Wireless PCI Adapter. I didn't feel like fiddling around with Linux so I wasn't able to access the network on the Shuttle. Since the Dell had a recognized Ethernet NIC, I was able to manually configure it for network access. JDS (like most live CDs) tries to find an IP via DHCP, but I don't provide DHCP on my test LAN. Launching a terminal showed me I was running as user 'morph', which means Sun didn't change even the basics of this Morphix version. I was able to 'su -' without a password and configure the network myself.

Dru Lavigne published an excellent article called FreeBSD for Linux Users . She does a nice job explaining run levels, kernel differences, startup scripts, package installation, and documentation. She plans to follow up the article with one on similarities between FreeBSD and Linux.

I previously wrote about my experiences using an external 2.5 HDD enclosure . Today I received my AMS Electronics Venus DS3 external 3.5 HDD enclosure. I liked this model because it supports Firewire and USB 2.0, has an on-off switch, and provides an internal fan to cool hotter drives. I found mounting the drive inside the enclosure very easy and the product itself seems sturdy. The on-off switch should have been a rocker switch and not a somewhat weaker toggle, but it works ok. On my laptop, when attaching the DS3 to the Firewire port on my Adaptec Duo Connect Firewire/USB adapter, dmesg reports the following: fwohci0: BUS reset fwohci0: Async DMA Receive error err = 1f fwohci0: node_id=0xc000ffc1, gen=3, CYCLEMASTER mode firewire0: 2 nodes, maxhop <= 1, cable IRM = 1 (me) firewire0: bus manager 1 (me) firewire0: New S400 device ID:0030e0f4e0204651 da0 at sbp0 bus 0 target 0 lun 0 da0: Fixed Simplified Direct Access SCSI-4 device da0: 50.000MB/s transfers da0: 4110MB (841