Related link: http://www.honeynet.org/papers/trends/life-linux.pdf

People are used to an ever-increasing flow of attacks against Internet-exposed system. Thus, the latest research from the Honeynet Project might come as a surprise to many (I certainly was susprised when I first noticed this trend in my honeynet, run as a part of the Project).

Linux systems are actually attacked much less now than 2-3 years ago. Not only the systems are attacked less, they survive much longer even if no security safeguards are applied. It was unthinkable that an unpatched RedHat box will sit there for 3 months, but now it happens fairly often. Obviously, default Linux installs are much more secure now, but this is only part of the picture…

Related link: http://www.knoppix.org

It’s been a few months since the last major Knoppix release (3.6 was released back in August), but Klaus is back just in time for Christmas. Knoppix 3.7 includes lots of updates and a few new features which I will go over below.

Some of you who follow Knoppix development might say “Didn’t 3.7 come out a few months ago? I remember downloading the torrent.” While labeled “Knoppix 3.7,” that release was actually based on a special version of Knoppix that Klaus created for PC-Welt magazine. There are often special releases of Knoppix intended only for conferences such as LinuxTag, or to be released with magazines, but you won’t find these versions on any official mirror. Often someone with access to the CD will create and distribute an unofficial .iso for the release. Yesterday’s release, however, is the official “download edition” and features upgrades across the board for all of the software on the system. KDE gets a boost to version 3.3.1, the kernel versions are the latest and greatest at 2.4.27 and 2.6.9 (with ACPI support), and even Java has the lastest security update.

These upgrades do seem to make KDE operate smoother, and Klaus has also added a quick link in the KNOPPIX menu for “Samba Network Neighborhood” which opens up Konqueror pointed to “smb:/” and lists any available Windows workgroups on your network. I have previously had to perform some extra steps to get lisa to browse my windows shares, but with 3.7 it found all of the local networks and browsed to them without a hitch. Knoppix 3.7 also includes a new ISDN configuration script, but I don’t have an ISDN line to test it with.

The live software installer included on the CD maintains the same software, but over the past few months klik has really taken off. I don’t believe I’ve discussed klik much before, but klik is a nice 3rd-party live software install system for a Knoppix CD. Installation is as simple as going to http://klik.sf.net and running the command they list at the top. After you install klik, you simply need to click on a link on that page to install software directly to your system. After software installs, it will show up in the Kmenu under “Applications (installed by klik)” for easy access.

You might notice that the klik link syntax is klik://packagename. Once klik is installed, you don’t even necessarily have to visit klik.sf.net to install software, you can simply type in klik://firefox and the firefox install script will launch. Also, recent versions of klik added support to Mozilla and Firefox in addition to the traditional Konqueror support, so you can execute klik:// links any of these browsers. The list of klik packages continues to grow, so if Knoppix 3.7 doesn’t have your favorite software, check klik.

Overall I’m pretty impressed with Knoppix 3.7. If you are using 3.6 you won’t notice too much of a difference, but if you are still using 3.3 or 3.4, Knoppix 3.7 might be worth checking out, especially if you are a laptop user who has had some problems with ACPI. Right now most of the Knoppix mirrors are pretty busy, so if you have bittorrent installed, I recommend using the Knoppix torrent link.

Those of you who have a copy of BSD Hacks will find a copy of my old up-to-date script on page 343. You can just skim over the bits of this blog that you’re already familiar with. And for those who haven’t tried scripting (or even using) “cvsup”, I’ve included step by step directions of the pieces you need and how to put them all together.

There are quite a few applications available to assist you in keeping your system up-to-date. My script uses several third-party components. Here, I’ll quickly add the necessary packages; you can “grep” through “pkg_info” to see if any of these are already installed on your system:

# pkg_add -r cvsup-without-gui
# pkg_add -r fastest_cvsup
# pkg_add -r portupgrade
# pkg_add -r freebsd-update
# pkg_add -r docproj-nojadetex

To use “cvsup”, you’ll need a
cvsup file. Mine will keep src, ports, and docs up-to-date as a FreeBSD 5.3 system:

# more /root/cvs-supfile
*default host=cvsup.freebsd.org
*default base=/usr/local/etc/cvsup
*default prefix=/usr
*default tag=RELENG_5_3
*default release=cvs delete use-rel-suffix compress
src-all
ports-all tag=.
doc-all tag=.

If this is your first “cvsup”, don’t forget to make a directory for it to use:

# mkdir /usr/local/etc/cvsup

While these configurations can keep things up-to-date, I also wanted to script a daily check for operating system security patches using “freebsd-update” as mentioned in Richard Bejtlich’s November 25th blog.

This program won’t work until you rename this program’s configuration file:

# mv /usr/local/etc/freebsd-update.conf.sample \
/usr/local/etc/freebsd-update.conf

Hack #89 in BSD Hacks explains that the cvsup’d doc changes are in SGML and how to use “docproj-nojadetex” to convert them to HTML. Now, if you decide to use a “refuse” file with “cvsup”, the command will abort with an error once it encounters the missing doc files for the languages you don’t “cvsup”.

You can edit “/usr/doc/Makefile” to remove the languages you don’t “cvsup”. For example, mine now looks like this:

# $FreeBSD: doc/Makefile,v 1.34 2004/09/27 00:26:48 josef Exp $
#
# The user can override the default list of languages to build and install
# with the DOC_LANG variable.
#
.if defined(DOC_LANG) && !empty(DOC_LANG)
SUBDIR = ${DOC_LANG}
.else
SUBDIR = en_US.ISO8859-1
.endif

Unfortunately, "cvsup" will overwrite your changes to this file. One work-around is to remember to do this before you run cvsup:

# cp /usr/doc/Makefile /usr/doc/Makefile.orig

The other work-around is to not use a "refuse" file at all.

Finally, make a script to tie everything together:

# more /root/cvsup
#!/bin/sh

#use fastest_cvsup to find fastest geographically
#close mirror; I'll check Canada and the US
if SERVER=`fastest_cvsup -q -c ca,us`
then
echo "Running cvsup"
cvsup -L2 -h $SERVER /root/cvs-supfile
else
echo "There's a problem" 1>&2
exit 1
fi

#-U (which takes a long time to execute) isn’t needed
#with the fetchindex command
echo “Updating ports index”
cd /usr/ports
make fetchindex
portsdb -u

#send copious output to the bit bucket
echo “Updating docs”
cd /usr/doc
cp Makefile.orig Makefile
make install > /dev/null

echo “Looking for security patches”
freebsd-update fetch

echo “The following ports need upgrading”
portversion -l “<”

echo “Finished at `/bin/date`.”
exit

Make your script executable and give it a go, watching for any error messages.

I like to run this script manually (while drinking my morning coffee) so I can watch its output. This gives me an idea of which src, ports, and docs have changed. If there’s new source, there’s probably a new security vulnerability. And I certainly want to know if there’s any new docs so I can check them out.

I also want to look at the output of freebsd-update; if there’s a security vulnerability in the operating system, I want to know about it.

This script will NOT upgrade your ports; instead, it will tell you which ports need upgrading. I like to manually run “portupgrade -arR”, once I’ve determined that I do indeed want to upgrade all of my ports.

I also considered including “/usr/ports/security/portaudit” in the script, but decided it added too much additional output. Instead, I enabled it as a periodic script so the results are emailed to root. Once the package is installed, see “man portaudit” for details.

I finally had a chance to upgrade my home systems to FreeBSD 5.3. Here’s my working notes for both a fresh install and an upgrade from 5.2.1 to 5.3.

First, I started with my laptop which was running FreeBSD 4.10. For those who are looking for migration examples from 4.10 -> 5.3, I can’t help you there as I chose to do a fresh install on purpose.

When I originally installed the laptop back in early October, I had planned on installing 5.2.1. However, the default kernel hung solid during its load, never getting me to the install screen. At the time, I started a thread on the freebsd-mobile mailing list and the concensus was either an IRQ conflict or a conflicting BIOS option. After fiddling with several CMOS settings, I settled for installing 4.10 as the 4.x install utility allows you to disable unneeded drivers.

I was now curious to see if that mysterious IRQ/BIOS setting had been resolved with 5.3. I was hopeful as the migration guide indicated that the initial floppies had been revamped from 2 to 3, allowing the addition of more features. (my laptop lacks a built-in CDROM so I have to start the install with floppies)

So, I went to the floppies section of the FTP site and downloaded boot.flp, kern1.flp, and kern2.flp. Once I had “dd”d the images onto 3 floppies, I inserted boot.flp and followed the directions. And, voila, the kernel loaded and the system installed flawlessly. Once the operating system had installed, I used the installation program to quickly install packages of all of my favourite software. As soon as I had rebooted into the new system, I fired up my trusty cvs-supfile and used portupgrade to ensure all of my software was up-to-date.

One thing I noticed missing from the install’s post-configuration utility was the option to configure X. So, I went to the updated section of the
handbook as this was my first time using Xorg instead of XFree86. I typed “Xorg -configure” and held my breath. The configuration script did its thing and I was very pleased when “startx” worked as expected. (I had already installed the kde package and had created an ~/.xinitrc with the line “exec startkde”) All in all, the full install was a very painless procedure.

Now that my laptop was taken care of, I did a backup of my main system and used “scp” to copy the backup to my laptop. I didn’t expect any problems but I wasn’t going to take any chances with the data on my main system. I then changed the tag in my cvs-supfile from RELENG_5_2 to RELENG_5_3 and ran cvsup to download the sources for 5.3. Once the sources were on my main system, I ran this series of commands:

# cd /usr/src
# make buildworld
# make buildkernel KERNCONF=GENERIC
# make installkernel KERNCONF=GENERIC
# shutdown now (to go to single-user mode)
# cd /usr/src
# make installworld

That last command failed with an error regarding a missing user account. Those who use “mergemaster” would have already resolved this, but I don’t like using “mergemaster”. Instead, I took a closer look at “/usr/src/UPDATING”. Aaah, I hadn’t read back far enough as the info I needed went way back to 20040623 and 20040308.

Fortunately, my laptop had the correct user accounts and group so I used “vipw” to add the “proxy” and “_pflogd” accounts and used “vi” to add the “authpf” group to “/etc/group”.

Once the “installworld” was successful, I rebooted into the GENERIC kernel. “uname -a” indicated that I was now at 5.3-RELEASE-p2. I was a bit worried about X, but “startx” worked flawlessly. It was now time to see if 5.3 liked my modified kernel:

# cd /usr/src
# make buildkernel KERNCONF=NEW

This quickly gave me an error that “device pcm” (for my soundcard) was not supported. I remembered reading something about that in the Release Notes . I remmed out that line in “/usr/src/sys/i386/conf/NEW”, reissued the command and read through “man 4 sound”.

The manpage suggested adding this line to “/boot/loader.conf”:

snd_driver_load=”YES” # All sound drivers

I double-checked my edit and saved my change. Once the kernel finished building, I then:

# make installkernel KERNCONF=NEW
# reboot

Everything seemed fine until I ran “startx” and it stopped cold with this error message:

xf86EnableIO: Failed to open /dev/io for extended I/O

I was glad I had my laptop nearby as it took less than a minute of Googling for that error message to indicate that I needed to add these lines to my kernel configuration file:

device io
device mem

So, I recompiled the kernel, rebooted and tried again. It worked, so I decided to push my luck by replacing XFree86 with Xorg. I followed the instructions in “/usr/ports/UPDATING” for 20040723 and ran this series of commands:

# cd /var/db/pkg
# portupgrade -o devel/imake-6 imake-4*
# portupgrade -o x11/xorg-libraries XFree86-libraries
# portupgrade -o x11/xorg-clients XFree86-clients
# portupgrade -o x11/xorg-manpages XFree86-manuals
# portupgrade -o x11/xorg-documents XFree86-documents
# portupgrade -o x11-fonts/xorg-fonts-truetype XFree86-fontScalable
# portupgrade -o x11-fonts/xorg-fonts-100dpi \ XFree86-font100dpi
# portupgrade -o x11-fonts/xorg-fonts-75dpi \ XFree86-font75dpi
# portupgrade -o x11-fonts/xorg-fonts-type1 \ XFree86-fontDefaultBitmaps
# portupgrade -o x11-fonts/xorg-fonts-cyrillic \ XFree86-fontCyrillic
# portupgrade -o x11-fonts/xorg-fonts-encodings \ XFree86-fontEncodings
# portupgrade -o x11-servers/xorg-server XFree86-Server
# portupgrade -o x11/xorg -f XFree86

The “-o” switch tells “portupgrade” to upgrade an existing package with a different package. In this case, to replace XFree86 with Xorg. Some of the commands didn’t work on my system as I hadn’t installed that particular package–for example XFree86-fontCyrillic wasn’t installed on my system.

I then ran “Xorg -configure” on my main system which appeared to work. However, when I ran “startx”, it aborted with an error when X tried to load the default font. So, I looked at the first Font line in the configuration file:

# grep -m1 Font /root/xorg.conf.new
FontPath “/usr/X11R6/lib/X11/fonts/misc/”

Hmmm, I wondered if I was missing a necessary font?

# ls /usr/ports/x11-fonts |grep misc
xorg-fonts-miscbitmaps

That looked like a likely candidate and a search through “pkg_info” indicated it wasn’t on my system. So:

# pkg_add -r xorg-fonts-miscbitmaps
# exit
$ startx

And, that seemed to do the trick. Once KDE was up and running, I opened up XMMS to test my soundcard and was pleased to have sound on the system.

I still have to tweak Xorg a bit. The default display of 1400×1050 was way too tiny for my myopic eyes, but a right-click on the KDE desktop->configure desktop->display let me change the default to something more reasonable. When I have more time, I’ll have to play with the fonts as they look pretty crappy in Firefox.

If you’ve been following the 5.x series through cvsup, it won’t be that difficult upgrading to 5.3. In fact, your upgrade will be even easier if you have already integrated the changes to PF and Xorg. You can decide to keep PF out of the 5.3 base by adding NO_PF to your make.conf BEFORE you issue your “make buildworld” command. You can also choose to continue to use XFree86 if you prefer not to switch to Xorg at this time. Do make sure those two options are in your kernel, though, as either version of X requires them on 5.3.

Related link: http://ezine.daemonnews.org/200410/dadvocate.html

When I first read that article, I found it intriguing that a famous FreeBSD developer was willing to share his own experience and open up the discussion of why BSD users use BSD. I started a blog with my own response back in early November but my work schedule prevented me from finishing it until now.

In the mean time the article has spawned an interesting thread on the FreeBSD chat list as well as Richard Bejtlich’s thoughts on his blog .

And since the publication of my article on FreeBSD for Linux users, I’ve received several emails asking me why I use FreeBSD.

Keep in mind that a person’s operating system preference is a personal matter–what one person considers to be a feature may be an irritation to another. Inertia often also comes into play: we all know what it feels like when a command or interface we are used to using isn’t present on another operating system.

I like to think that I’m fairly operating system savvy since I’ve used (and have in most cases taught) every MS operating system since Windows 3.1, every Netware since 3.12, a dozen or so Linux distros, Sco UnixWare, Solaris and Cisco IOS. I’ve discovered likes and irritations with each. However, there’s only one operating system that I’ve fallen in love with and that’s FreeBSD. Yes, I know that’s such an absurdly nerdy thing to say. But I feel at home when I use FreeBSD; to me, everything else is just another operating system.

It’s always hard to explain our gut reaction to things. Can we fully explain why one person falls in love with another? No, we can only attempt logical reasons that barely describe the surface of the matter. With that in mind, here are my attempts at explaining the reasons why I bother:

1. The ports and packages collections. I love installing and trying out software. I am also an impatient person who doesn’t appreciate having to reinvent the wheel just to get a job done. I get irritated when I have to scour the Internet for software. You don’t want to be in the same room with me if I’m on an operating system that complains about missing dependencies without attempting to resolve them for me. Installing software should be easy. On FreeBSD it is. If I’m in a hurry “pkg_add -r whatever” will painlessly install whatever. I also have the flexibility of compiling the program to suit my needs and FreeBSD’s standardized Makefile’s make it easy to find out what options are available to me.

2. cvsup and portupgrade. What’s the point of installing software if you can’t keep it up-to-date without breaking things? In this day and age of security advisories and software features, keeping software at its latest versions should be a trivial task that doesn’t require a paid subscription. On FreeBSD this is easily achievable and, as the name suggests, free.

3. a clean “netstat -an”. Very few operating systems are installable with absolutely no listening TCP/IP ports. In fact, on many operating systems you break core functionality when you start closing ports. This is not the case with FreeBSD.

4. Flexible security. I could write an entire book on FreeBSD’s security features. Instead, I’ll leave you with some key features: blowfish hashes, MAC framework, sysctl to change kernel state on the fly, built-in firewall support, an easy to understand kernel configuration file, ACL support, vuxml to warn of application vulnerabilities, easy access to security advisories.

5. The ability for anyone to contribute. I’m a good example of how you don’t have to be a programmer to contribute to an open source project. And I don’t think I’ll ever quite get over the amazement of how a middle-aged single mother from her Canadian living room was able to have a positive impact on other users from every country on the planet.

6. The FreeBSD community. We’re all social creatures and quite frankly the atmosphere of a community impacts on its success. While it has its expected ups and downs, on the whole the FreeBSD community is a positive place to be. I can’t count the number of times a developer has responded to a question with insightful advice or a patch. Or how many people take the time to help others out or point them in the right direction. Or the number of email friends I’ve developed–people who write periodically so we can exchange what is happening in our respective neck of the woods. I even belong to two user group mailing lists, both of which are too far geographically to attend meetings–yet the on-line support and feedback of its members is well worth the extra space in my in-box.

That’s all the time I have for now; hopefully I’ve done some justice to Poul’s question.

Why do you bother?

Related link: http://sweb.cz/tripie/utils/wmctrl/

From the “why didn’t I know about this before now?” file: this evening I discovered the wmctrl tool. With this you can access all of the Extended Window Manager Hints functions of your windows from the command line. What does this mean? Imagine hitting a key sequence and a specific window moves, and resizes to a certain section of your desktop. Hit another button and it shades, no matter what window has focus. I’ll get into how to unlock all of this potential below.

Now, being a user of the enlightenment window manager for some time, I have been accustomed to being able to script window events through their included eesh tool. The downside to eesh is that it only works for enlightenment. This sort of feature was one of the main things keeping me using enlightenment apart from fine-grained window memory. Since fluxbox recently gained similar window memory functionality all that was missing was eesh–until today. The wmctrl tool works with any window manager that supports Extended Window Manager Hints which means that it will work with icewm, kwin, metacity, openbox, fluxbox, enlightenment, sawfish, xfce, and a ton of other window managers.

To illustate why this is a cool program, I will show you how to use it to create a “quake console.” If you have ever played doom or quake, you are familiar with the little command console that shows up whenever you press the ~ key. I wanted to have similar functionality on my desktop so that when I hit alt-~ a terminal would pop down to type in, but otherwise it would disappear out of my way. To do this you need to hide a window up at the top of your screen in a shaded state, and then have it unshade whenever you hit ~ (or alt-~ so you can type ~ inside the terminal).

First, download wmctrl from http://sweb.cz/tripie/utils/wmctrl/, unpack it, and build it with the standard ./configure && make && make install that you might use for building any other Linux program from source.

Once wmctrl is installed, type wmctrl -l to get a list of open windows. It will look something like this:

greenfly@boxer:~$ wmctrl -l
0x00600003 0 boxer gkrellm
0x01800047 0 boxer quake_console
0x01000072 0 boxer Mozilla Firefox
0x01600012 0 boxer irssi_term
...

The first column is a unique ID number assigned to each window, the second column specifies which desktop the program is on, the third column tells you which machine the window is running from, and the fourth column tells you the all-important title of the window.

If you want to create a quake console, open a terminal and use command-line arguments to give it a unique title. This argument varies depending on your terminal, but if you used xterm you would type something like xterm -title "quake_console". As you can see, I already have a window in my window list with that title. Now move this window to the top lefthand corner of your screen, and if you can, move it so that the titlebar is actually moved off the screen and out of sight, and only the terminal itself is showing (this way when it shades it will totally disappear from view).

Now, to shade this window, all you need to do is open up a different terminal and run wmctrl -r "quake_console" -b toggle,shaded. The window should shade out of sight. Run the command again and the window will come back into view. Now you can set this command to a keybinding of your choice like alt-~ and have a true quake console always at the ready.

This is only the beginning of the possibilities a program like this presents. Say you usually like your web browser to fill up your desktop, except for when you are IMing with friends. In those cases you resize it to make room for both windows. With this program you could set up all of those resizing and movement functions inside a script and bind it to a key sequence. Want to browse and IM? Hit a key sequence and all the windows move and resize. You can then hit another key sequence and be back where you started. If you wanted, you could even write a script that made a window bounce across the screen.

The sorts of things you can do with wmctrl are mostly limited by your own scripting ability. What’s nice about it is that once you have your scripts set up, you can move from one window manager to the next and your scripts will still work. Want to switch from KDE to Gnome? All you have to do is reset your key bindings and wmctrl will still work the same.