Monday, March 29, 2004

OpenBSD Funding Highlights Open Source Development Issues

In mid-March the OpenBSD Journal featured a story on funding OpenBSD SMP development. I found it interesting to get a glimpse into the workings of the open source community when it comes to making important advances in operating systems. The story was really a post of a message Theo made to a mailing list, but the commentary was interesting. It reminded me of the donations to Colin Percival's Freebsd-update project.

New Utilities for Investigating Systems

I've come across a few interesting utilities that deserve a look. PyFlag is a Web-based forensic analysis suite written in Python. It's a complete rewrite of the original FLAG tool.

Microsoft released portrptr.exe recently. Port Reporter runs as a service on Windows 2000/XP/2003 systems, logging sockets used to the c:\winnt\system32\logfiles\portreporter directory. Here are sample records:


The first is an FTP control channel. The last three are FTP data channels. I am not sure about the second entry but the source port is the same as that used for the first FTP data channel.

Online Debian Book

I decided to move my old Pentium 90 from Red Hat 6.2 to Debian. I installed 3.0r2 using the 2.2 kernel boot floppies. The P90 doesn't support booting from the blazingly fast 2X speed Sony CD-ROM, which also requires a the CDU31A driver. I couldn't find support for this driver in the 2.4 kernel boot floppies. I also had to load the 8390 and smc-ultra kernel modules to support a Linksys ISA NIC.

Along the way I found The Debian Universe, which "aims to become a complete guide to installing, managing and running Debian GNU/Linux." This is great because the last published book on Debian arrived in 2001 and described the 2.2r release.

I was able to update my kernel to 2.4.18 using the apt tools. This command showed me what was available:

apt-cache search kernel-image-2.4

Next I installed the 2.4.18 image:

apt-get install kernel-image-2.4.18-1-386

I added 'initrd=/initrd.img' to /etc/lilo.conf as prompted by the install process. When I rebooted I was running 2.4.18.

I intend to try upgrading to a 2.6 kernel using the packages provided by Debian Backports.

Friday, March 26, 2004

Draft Cover Art for my Book

I received draft cover art for my upcoming book The Tao of Network Security Monitoring: Beyond Intrusion Detection. That's a praying mantis on the cover. I first studied a form of praying mantis kung fu ten years ago in the town where I grew up. The school is still going strong as the Michael Macaris Kung Fu Academy in Billerica, Massachusetts.

Wednesday, March 24, 2004

The Applicability of Corporate Fraud to Digital Security

I've been on the lookout for Corporate Fraud: Case Studies in Detection and Prevention by John D. O'Gara. I thought it might contain insights useful for intrusion detection. Looking at the sample excerpt, (.pdf), it seems more suited to corporate types. However, I found this statement to be fascinating:

"Effective prevention depends on the probability of detection and prosecution more than on any other single factor, because management fraud typically involves override rather than taking advantage of control weaknesses."

This ties in to my idea that prevention eventually fails, for whatever reason. I also found the emphasis on recognition of indicators to be completely in line with my ideas:

"All competent professional internal auditors should have the ability to recognize the red flags and symptoms that indicate the possible existence of management fraud, and they should also be able to perform diagnostic procedures to assess the probability of occurrence. Investigation of cases of more complex management fraud beyond determining whether fraud probably occurred normally requires specialized experience and skills. Nevertheless, we cannot overemphasize the importance of recognition. Simply put, recognition must occur before investigation can start.

According to the Institute of Internal Auditors (IIA), 'The internal auditor should have sufficient knowledge to identify the indicators of fraud but is not expected to have the expertise of a person whose primary responsibility is detecting and investigating fraud.' Furthermore, the IIA maintains that '[d]etection of fraud consists of identifying indicators of fraud sufficient to warrant recommending an investigation.'"

That's similar to my description of Network Security Monitoring:

"NSM is the collection, analysis, and escalation of indications and warnings to detect and respond to intrusions. NSM tools are used more for network audit and specialized applications than traditional alert-centric 'intrusion
detection' systems."

Friday, March 19, 2004

New Sguil Installation Guide Released

I just released a new Sguil install guide using Sguil 0.3.1, FreeBSD 5.2.1 REL, Snort 2.1.1, Barnyard 0.2beta2, MySQL 4.0.18, and other updates. It's available in text form at The packages for FreeBSD 5.2.1 mentioned in the guide are available at sguil_0-3-1_f5-2-1_pkg.tar.gz (24 MB).

I wanted to get this out to accompany the article in Sys Admin magazine. The new guide is a text version, which I felt was more appropriate for the Sguil user community.

I composed the guide in vi, which didn't wrap the lines to 80 columns. I used fold -s to create the formatted result.

Wednesday, March 17, 2004 Publishes Benchmarking Results published several good articles on FreeBSD recently. I was impressed by the author's attention to detail for each report, but I am not in a position to try to confirm or refute his claims. With a three word summary, they are:

Snort_Inline: Snort-based "Intrusion Prevention"

The Snort_inline project released a version compatible with Snort 2.1.1 this week. Snort_inline works with firewall software on the same host to drop packets matching Snort signatures. Apparently there is experimental support for running Snort_inline on FreeBSD using using divert(4) and ipfw(8). Just the other day I read a news posting on the snort_inline mailing group archives, but today the archive is gone. I subscribed to the mailing list just now and plan to ask what's happened.

Update: The archive is back and here is the post of interest.

Weekly FreeBSD cvs-src Summaries

Want to know more about FreeBSD development? Don't want to subscribe to the freebsd-current mailing list, or search the archives? If the answer to either question is yes, visit Mark's weekly FreeBSD cvs-src summaries. Mark Johnston was inspired by this thread to post his first summary in late January. Mark reads emails on commits to cvs-src and summarizes what he believes is important.

Some of what he writes brings obscure topics to the FreeBSD public's attention. His 23 January report mentions a series of additions to the current tree called "Project Evil." The first commit occurred in December. Project Evil, also known as the NDISulator, helps FreeBSD use Windows device drivers. Bill Paul's December and January posts to freebsd-current give more details.

Latest Fedora News

I just received the latest Red Hat email newsletter, which contained this news on Fedora:

"Fedora, the community-supported Linux distribution project sponsored by Red Hat, has been making great progress as of late. Fedora Core 2, Test 2 is expected to be released in early April and the finished Fedora Core 2 distribution should be available in May. FC2 is the industry's first Linux distribution based on the Linux 2.6 kernel, and supports 32-bit x86 and 64-bit x86-84 systems. It also includes Security Enhanced Linux (SELinux) technology, which was co- developed with the U.S. Government's NSA. With Gnome 2.5, KDE 3.2, and 1.1, FC2 is the ideal Linux playground for technology enthusiasts and open source developers."

Soon the only Linux box I will have in my house is a Pentium 90 (with a non-bootable dual-speed CD-ROM) running Debian. I'll report on how I set it up in a future blog entry.

Saturday, March 13, 2004

ICSA Labs Announces Security Device Event Exchange (SDEE)

Sebastien Tricaud's post to Focus-IDS informed me of the Security Device Event Exchange (SDEE), an IDS alert format and transport protocol specification. ICSA's Intrusion Detection Systems Consortium (IDSC) devised the SDEE specification. The IDSC consists of Cisco, Fortinet, Infosec Technologies, ISS, SecureWorks, Sourcefire, Symantec, and Tripwire.
TruSecure, owner of ICSA Labs, published a press release which says in part:
"IDSC members Jeff Platzer and Mike Hall of Cisco Systems, Robert Graham of ISS, Marty Roesch of Sourcefire and Marcus Ranum of TruSecure Corporation co-developed the SDEE transport protocol specification format; this team will manage future revisions to the specification...
SDEE specifies the format of the IDS alerts as well as the protocol used to communicate events generated by security devices. SDEE is flexible and extensible so vendors can utilize product specific extensions in a way that maintains messaging compatibility. In addition, SDEE will provide corporations and security vendors better management of multiple vendor environments by having all alerts communicated in the same format. SDEE builds upon the XML, HTTP and SSL/TLS industry standards to facilitate adoption by vendors and users by allowing them to use existing software that implements these standard interfaces."
This effort may conflict with the IETF's Intrusion Detection Message Exchange Format. The Intrusion Detection Working Group just published a new draft of their standard in January 2004.
More information on SDEE is available through these means:
Option 1: To sign up for the ICSA Labs SDEE listserv & receive the SDEE specification file, simply send an email to with "SUBSCRIBE" in the subject line.

Option 2: To receive the SDEE specification file only, simply send an email to with "FILE" in the subject line.

Slyck is the Place to Understand Peer-to-Peer

Earlier today I reported on law enforcement's desire to wiretap all sorts of communications. While doing research I discovered an incredible resource for peer-to-peer users called Slyck does an excellent job categorizing and explaining a dozen individual file sharing methods, then offers information on programs implementing each method. This is a great resource for anyone trying to understand file sharing protocols they might see on their networks.

Incredibly Misleading Article Corrected by Commenters

An report, Thank Apple for FreeBSD, is one of the most inaccurate articles I've ever read. I don't recommend spending time on the article itself, but I do believe reader's reactions to the article are noteworthy. People often claim Apple's Mac OS X is somehow "built on" FreeBSD or is "FreeBSD underneath." Several of the people who commented on the OSViews story give true insight, especially this response. I find it ironic that the OSViews tag line is "Why should seasoned journalists have all the fun?" Simple -- they tend to avoid writing ridiculous stories!

Excellent Coverage of Wiretapping Issues at published an article titled FBI adds to wiretap wish list yesterday. This is the latest of many excellent articles on wiretapping issues in the United States. summarizes a a"joint petition for expedited rulemaking" (.pdf) submitted to the Federal Communications Commission by the US Dept. of Justice, FBI, and Drug Enforcement Agency.

The Feds are asking the FCC to expand the scope of the Communications Assistance for Law Enforcement Act, or CALEA. CALEA requires telecommunications carriers to allow law enforcement "to intercept, to the exclusion of any other communications, all wire and electronic communications carried by the carrier" and "to access call-identifying information," among other powers.

The EPIC wiretap page features the text of the law and supporting articles. The FBI maintains the AskCALEA site, which describes their interactions with the FCC and telecommunications providers. The FBI's rendering of the CALEA law text is easier to read than EPIC's version.

The heart of the matter is CALEA's distinction between a "telecommunications carrier" and "information services." CALEA says:

"The term `telecommunications carrier'--

(A) means a person or entity engaged in the transmission or switching of wire or electronic communications as a common carrier for hire; and

(B) includes--

(i) a person or entity engaged in providing commercial mobile service (as defined in section 332(d) of the Communications Act of 1934 (47 U.S.C. 332(d))); or

(ii) a person or entity engaged in providing wire or electronic communication switching or transmission service to the extent that the Commission finds that such service is a replacement for a substantial portion of the local telephone exchange service and that it is in the public interest to deem such a person or entity to be a telecommunications carrier for purposes of this title; but

(C) does not include--

(i) persons or entities insofar as they are engaged in providing information services; and
(ii) any class or category of telecommunications carriers that the Commission exempts by rule after consultation with the Attorney General."

Regarding "information services":

"The term `information services'--

(A) means the offering of a capability for generating, acquiring, storing, transforming, processing, retrieving, utilizing, or making available information via telecommunications; and

(B) includes--

(i) a service that permits a customer to retrieve stored information from, or file information for storage in, information storage facilities;
(ii) electronic publishing; and
(iii) electronic messaging services; but

(C) does not include any capability for a telecommunications carrier's internal management, control, or operation of its telecommunications network."

< he CALEA authors provided enough internal contradiction to confuse everyone. Law enforcement has complained that more and more criminals use "information services" to communicate, but service providers aren't designing their networks for ready access to these services. CALEA does not oblige service providers to provide easy access to information services; only telecommunications carriers must provide easy access.

The "Limitations" and "Encryption" sections of the law are very interesting:


(1) DESIGN OF FEATURES AND SYSTEMS CONFIGURATIONS- This title does not authorize any Law Enforcement agency or officer--

(A) to require any specific design of equipment, facilities, services, features, or system configurations to be adopted by any provider of a wire or electronic communication service, any manufacturer of telecommunications equipment, or any provider of telecommunications support services; or
(B) to prohibit the adoption of any equipment, facility, service, or feature by any provider of a wire or electronic communication service, any manufacturer of telecommunications equipment, or any provider of telecommunications support services...

(3) ENCRYPTION- A telecommunications carrier shall not be responsible for decrypting, or ensuring the government's ability to decrypt, any communication encrypted by a subscriber or customer, unless the encryption was provided by the carrier and the carrier possesses the information necessary to decrypt the communication."

These sections are interesting because makes this observation regarding the Feds' petition to the FCC:

"Legal experts said the 85-page filing includes language that could be interpreted as forcing companies to build back doors into everything from instant messaging and voice over Internet Protocol (VoIP) programs to Microsoft's Xbox Live game service. The introduction of new services that did not support a back door for police would be outlawed, and companies would be given 15 months to make sure that existing services comply."

It seems to me that CALEA explicitly prevents law enforcement from prohibiting services, yet their petition seems to ask for this power. A slightly more detailed analysis is available at

"The petition seeks a formal ruling that CALEA applies both to broadband Internet access and to broadband telephony. Since CALEA requires that all carriers and their services have built-in wiretap capability, this would mean that all Internet access and Internet telephony would have to have wiretap capability implemented at the time of deployment. It appears that any form of Internet access would be covered by the 'access' category, while any communications that are 'switched' in any fashion would be treated as telephony (Xbox Live, IM messages, etc.). All would be covered by CALEA.

The petition asks that the FCC make an immediate ruling that applies CALEA to broadband access and broadband telephony, perhaps without even taking comments (p.22).

Second, the petition calls for heavy regulation of any new Internet communications services. In essence, the petition asks the FCC to rule that CALEA will automatically apply to any new technology that directly competes with any service that is covered by CALEA (p. 33). Anyone who introduces a new technology that competes (or might compete) with an existing technology covered by CALEA would be required to go to the FCC to find out whether the new technology is covered (p. 54). If the technology is covered by CALEA, it could not be deployed until a fully satisfactory intercept solution was incorporated into the service (p.54). The effect would likely be that no new Internet services could be introduced without substantial regulatory proceedings and a design that meets all expected law enforcement requirements, starting with version 1.0."

One of the Steptoe's partners is Stewart Baker, former general counsel of the National Security Agency.

If the FCC rules that protocols previously classified as information services are not subject to CALEA, it will be difficult if not impossible for some services to comply. Voice over IP has been the biggest issue for the last few years. Last year reported that the FBI submitted a proposal for tapping VOIP to the FCC, and then:

"...extended it to say that if broadband providers cannot isolate specific VOIP calls to and from individual users, they must give police access to the 'full pipe' -- which, by including the complete simultaneous communications of hundreds or thousands of customers, could raise substantial privacy concerns.

A summary of the meeting prepared by the FBI said the FCC could 'require carriers to make the full pipe available and leave law enforcement to perform the required minimization. This approach is already used when ISPs provide non-CALEA technical assistance for lawfully ordered electronic surveillance.'"

An example of a service which presently cannot be centrally tapped is Skype, a peer-to-peer Voice over IP implementation profiled by last year. According to, the FCC voted last month to investigate "whether Internet phone providers should rewire their networks to government specifications to provide police with guaranteed access for wiretaps."

Last year mobile phone providers wrestled with providing access to their instant message protocols, according to this article. Members of the Global LI Industry Forum solved the problem. ("LI" stands for "Legal Interception," which must be unpopular enough to replace with the "LI" in the site's name and documentation.)

Wednesday, March 10, 2004

NSM Article in April Sys Admin Magazine

The April 2004 issue of Sys Admin magazine features an article I wrote titled "Integrating the Network Security Monitoring Model." Sys Admin summarizes it by saying: "This article examines intrusion detection through an operational model called network security monitoring (NSM). Bejtlich explains NSM theory and introduces several tools to integrate NSM concepts into existing systems." I imagine the April issue will be on newstands within the next few weeks.

After the article has been in print for a while, I will make a copy available in .pdf form at

I am still working on upgrading the Sguil installation procedure to use MySQL 4.0.x (probably 4.0.18), along with the newest versions of several of its Tcl components. I'd really like to include a release version of the new Barnyard as well.

Department of Health and Human Services Security Incident World Record

FCW reports the Department of Health and Human Services recorded "348.9 million [security] incidents" in 2003. In contrast, the Department of Housing and Urban Development reported a "single information security incident" last year. It sounds like DHHS reported every packet dropped by their firewalls. That's about 11 "incidents" per second. I can't imagine the sort of manager who let an outrageous figure like this leave his or her desk.

Sunday, March 07, 2004

Andrew Baker Announces New Barnyard Beta

Andrew Baker announced a new beta version of Barnyard today on the Snort-users mailing list. This is an important event because Andrew has integrated support for Sguil. op_sguil.c and op_sguil.h are now in the Barnyard CVS repository. This move reduces the amount of patching needed to get Sguil working with Snort and Barnyard.

Saturday, March 06, 2004

Article on Cfengine

I'm researching issues relating to administrating dozens or hundreds of similarly configured FreeBSD systems. I think I will try to use Cfengine to enforce configuration management. Kirk Bauer just wrote a Linux Journal article on Cfengine, which appears in the ports tree as sysutils/cfengine2.

I'm looking at using Nagios to gather system status and Samhain for file integrity. I'll probably centralize log collection with syslog-ng. I'd like to use binary updates installed from my own update server. I may place various server applications within jails. I'm also keeping an eye on the FreeBSD port of systrace.

For remote access I'd like the systems to be equipped with something like the PC Weasel 2000 to send BIOS data to a serial port. I'm also thinking about having a modem for emergency dial-in access. Remotely power cycling the box is a last resort, but a device like this from WTI could save a drive or flight to a remote location. This box would need to work with a good external modem, perhaps like this or this from US Robotics.

I've been playing with 5.2.1 a little and trying to determine the best filesystem layout for a sensor. I think I will use the following. It assumes a 8 GB (8191 MB) hard drive with 256 MB RAM. I installed the "developer" and ports collections, plus the Linux ABI, bash, lynx, and portupgrade. This is my "base OS" install.

Slice Size MB Used
----- ------- ----

/ 256 35 MB
swap 512 --
/usr 3456 925 MB
/var 512 214 KB
/var/db 1024 1.1 MB
/nsm 2048 4 KB
/tmp 383 6 KB

I use /var for system logs and /var/db for database files. I don't include a separate /home because this system will not have general users. /nsm contains network security monitoring data like pcap files and session logs.

Security Articles in Newest Cisco Packet Magazine

The first quarter 2004 issue of Cisco's Packet magazine is all about security. The Locking Down IOS article mentions enhancements in IOS 12.3T. The "T" means this IOS release is from the "advanced technology" "software train," from which the 12.4 mainline train will be released.

For me the most interesting addition is IP Traffic Export. This feature tells the router to export selected traffic out a LAN or VLAN interface, where a monitoring platform watches the traffic. Cisco touts these benefits:

"Without the ability to export IP traffic, the Intrusion Detection System (IDS) probe must be inline with the network device to monitor traffic flow. IP traffic export eliminates the probe placement limitation, allowing users to place an IDS probe in any location within their network or direct all exported traffic to a VLAN that is dedicated for network monitoring. Allowing users to choose the optimal location of their IDS probe reduces processing burdens.

Also, because packet processing that was once performed on the network device can now be performed away from the network device, the need to enable IDS with the Cisco IOS software can be eliminated."

A visit to the Cisco Feature Navigator for "RAW IP Traffic Export" shows only the 3640 (already end-of-lifed) and 7200 series routers support this feature. IOS 12.3(4)XD, 12.3(4)T3, 12.3(4)T2, and 12.3(4)T support the feature.

Using the search by release option, I found that although the 2651XM can run 12.3(4)T3, 12.3(4)T2, and 12.3(4)T, the RAW IP Traffic Export feature does not appear on that platform. SSH version 2 is available, though.

I've discovered the Cisco Software Advisor is hopelessly broken, at least for all of the 2600 series router configurations I've tried. I was able to get it to work months ago, but now I get errors like the following.

This shows "no support" for a new 2651XM router which is not at end-of-sale or discontinued. I get similar errors when trying to "research software" for the 2651XM.

Portupgrade Errors

It's been a while since I upgraded my ports tree, and I ran into errors when I upgraded the tree using portupgrade today. Here's some of what I saw:

! net/p5-Socket6 (p5-Socket6-0.14) (uninstall error)
! lang/python (python-2.3.3_1) (uninstall error)
! security/p5-Digest (p5-Digest-1.05) (uninstall error)

---> Session ended at: Sat, 06 Mar 2004 15:03:40 -0500 (consumed 01:25:26)
portsclean -CDD
/usr/local/sbin/portsclean:35:in `require': No such file to load -- pkgtools (Lo
from /usr/local/sbin/portsclean:35
Done updating ports tree at Sat Mar 6 15:03:40 EST 2004.

Doing some research I found that making lang/ruby18 the default requires special handling of portupgrade, according to this commit message.

I handled the situation this way:

janney:/var/db/pkg# ls | grep ruby
janney:/var/db/pkg# pkg_delete ruby-
pkg_delete: unable to completely remove directory '/usr/local/lib/ruby/site_ruby
pkg_delete: unable to completely remove directory '/usr/local/lib/ruby/site_ruby
pkg_delete: couldn't entirely delete package (perhaps the packing list is
incorrectly specified?)
janney:/var/db/pkg# pkg_delete ruby-1.8.1_2/
janney:/var/db/pkg# pkg_delete ruby-bdb1-0.2.1/
janney:/var/db/pkg# pkg_delete ruby-shim-ruby18-1.8.1.p3/
pkg_delete: file '/usr/local/bin/erb' doesn't really exist
pkg_delete: file '/usr/local/bin/h2rb' doesn't really exist
pkg_delete: file '/usr/local/bin/rdoc' doesn't really exist
pkg_delete: couldn't entirely delete package (perhaps the packing list is
incorrectly specified?)
janney:/usr/ports/sysutils/portupgrade# make clean
===> Cleaning for ruby18-bdb1-0.2.2
===> Cleaning for ruby-1.8.1_2
===> Cleaning for portupgrade-20040208
janney:/usr/ports/sysutils/portupgrade# make && make install

Then I ran 'pkgdb -F' to update the package database and ran 'portupgrade -va -x openoffice' to upgrade the ports which failed to upgrade earlier.

US Frequency Allocation Chart Available

My local amateur radio club informed me that the US Frequency Allocation Chart for 2003 could be ordered from the US government printing office Web site for $4.25. This is an impressive wall chart showing frequenices allocated by the FCC. I ordered one for my office.

There are .pdf versions available as well. The one-page graphical version is just barely legible, depending on the quality of your printer. The "text" version is 88 pages, but all entries can be read. I don't recommend bothering with that document though.

Browsing Ports with Pib

Pib is another useful package management tool. It's a Tcl/Tk-based browser which shows information on ports and their installation status.

The following is the Ports INDEX browser window. This screen shot shows the security/openssh-askpass port. We see it is installed because the green "install" keyword is lit. Ports that are not installed do not show "clean".

Pib is useful because one can quickly browse the ports tree, select a port, and read the description in the lower window. That window appears once the question mark icon is pressed. The window is persistent.

Pib also offers port searching capabilities. For example, one can search for a port and see its dependencies and the ports which depend upon it.

I'm waiting for this month's release of a new version of portsman, a ncurses-based package management tool.

Removing Packages with pkg_cutleaves

You may have read Dru Lavigne's article on Cleaning and Customizing Your Ports. She mentioned used portsclean to remove working directories and distfiles with 'portsclean -CDD':

orr:/root# portsclean -CDD
Cleaning out /usr/ports/*/*/work...
Delete /usr/ports/sysutils/gkrellm2/work
Delete /usr/ports/net/netmap/work
Delete /usr/ports/graphics/graphviz/work
Detecting unreferenced distfiles...
Delete /usr/ports/distfiles/graphviz-1.10.tar.gz
Delete /usr/ports/distfiles/legacy_132beta4_src.tar.gz
Delete /usr/ports/distfiles/netmap-0.1.2b.tar.gz

I learned of another housekeeping tool called pkg_cutleaves. It looks at installed packages and notifies the user of packages upon which no other package depends. These "leaf packages" might be candidates for removal. When you run the tool, pkg_cutleaves asks if you want to keep or deinstall each leaf package:

Package 1 of 108:
OpenSSH-askpass- - Graphical password applet for entering SSH passphrase
OpenSSH-askpass- - [keep]/(d)elete/(f)lush marked pkgs/(a)bort?
** Keeping OpenSSH-askpass-

Package 2 of 108:
XFree86-documents-4.3.0 - XFree86-4 documentation
XFree86-documents-4.3.0 - [keep]/(d)elete/(f)lush marked pkgs/(a)bort?
** Keeping XFree86-documents-4.3.0.


Package 9 of 108:
asclock-1.0 - Afterstep clock with some language extentions
asclock-1.0 - [keep]/(d)elete/(f)lush marked pkgs/(a)bort? d
** Marking asclock-1.0 for removal.


Deleting asclock-1.0 (package 1 of 8).
[Updating the pkgdb in /var/db/pkg ... - 269 packages found (-0 +4) .... done]
---> Deinstalling 'asclock-1.0'
[Updating the pkgdb in /var/db/pkg ... - 268 packages found (-1 +0) (...) done]

When done with the first round of deletions, pkg_cutleaves checks again to see if any of the deletions created new leaf packages. If so, the user is asked to keep or delete those. When totally done, pkg_cutleaves informs the user of all packages it deleted.

Wednesday, March 03, 2004

Shoki News

I have not yet tried the Shoki open source intrusion detection system, but I have been in contact with its author, Stephen Berry. I asked if he planned to augment Shoki to allow logging to a flat text file, and Stephen added the feature in the latest interim release of shoki (shoki- I also asked him about forthcoming releases:

"All of the interim releases are the result of me merging the stuff in my development tree with the stuff in my release tree. Once that's all done (Real Soon Now), I'll release that as the `official' 0.3.0 release.

After that, I'm planning on incorporating a bunch of other stuff that I've been working on: a formal grammar for linking events (i.e., signature matches), vulnerabilities (i.e., things found in Nessus reports), doctrines (those funny things covered in Section 2.2 of the Shoki User's Manual), and threat models (which aren't currently part of shoki); and some data handling tweaks for scaling (mostly distributed analysis stuff).

I started implementing this stuff when I sat down to rewrite the shoki code (several months ago). Then I realised that it was really going to take awhile to get the new stuff into shape, and it had -already- been several months since my last update. So I decided to postpone releasing the really new, wild stuff in favour of getting the reimplemented-but-mostly-like-0.2.x stuff released.

So: 0.3.0 is intended to do more or less the same sorts of things as 0.2.x, only with the new (cleaner, faster, easier-to-use) code. After I get that out, there may be 0.3.x bugfix releases, but the next major release (which should include the distributed analysis stuff and the grammatical stuff) will -probably- be the 1.0 release."

I plan to give Shoki a try in the coming weeks.

Monday, March 01, 2004

FreeSBIE Project Releases FreeSBIE-1.0

Last month I wrote about the FreeSBIE live CD-ROM FreeBSD distribution. The team just released FreeSBIE-1.0 for download. The announcement describes the project and the package list details all the goodies in the .iso image. This version is based on FreeBSD 5.2.1 RELEASE.

Update: This Slashdot post on FreeSBIE brought several other cool projects to my attention, including LiveBSD and BSDeviant, along with general sites like LiveCDNews. I also just found the sysutils/freesbie port, which will not be as current as the CVS version.

The latest version of FreeSBIE has this torrent and the desktop version of LiveBSD has this torrent. The FreeSBIE mailing list is archived at for easy perusal.