BSD

A new print magazine focused on the various BSD operating systems—FreeBSD, OpenBSD, and NetBSD—has started up. You can get more information about the magazine at http://www.bsdmag.org.

I’ve written about OpenBSD several times here, and while I’m lightyears from being any sort of BSD expert I have a great deal of respect for the BSDs. (After all, Mac OS X is based on FreeBSD.) If I weren’t so incredibly overloaded on technologies as it is, I’d probably be interested in learning more about all the BSDs. Unfortunately, there’s only 24 hours in a day, and other technologies—like virtualization, VMware, storage, SANs, etc.—already keep me busy enough as it is.

Best of luck to the new BSD Magazine editors! I hope the new magazine is successful.

I’ve been doing some interoperability testing with VMware ESX Server and VLANs (a separate article on that is in the works), and needed a guest OS that supported VLAN interfaces.  From my previous (but limited) experience with OpenBSD, I suspected that VLAN interfaces were indeed supported, and after setting up a quick VM running OpenBSD 4.1 I found that I was indeed correct.  Not only are they supported, they are incredibly easy to setup and configure.

The command to configure a VLAN interface is simply a variation of the standard ifconfig command (note that I’m using a backslash to denote a line continuation, so that I can wrap lines here for readability):

ifconfig <VLAN interface name> vlan <VLAN ID> \
vlandev <physical network device>

So, by example, the command I used to create a VLAN interface for VLAN ID 3 looked like this:

ifconfig vlan3 vlan 3 vlandev pcn0

I did find that I couldn’t name the VLAN interface (“vlan3”, in this case) anything other than vlanX, where X was a number.  I don’t know if this is an OpenBSD limitation, or just an error on my part.  The latter is certainly a distinct possibility.

Once the VLAN interface, is created, then I just followed the standard OpenBSD way of provisioning an interface—create /etc/hostname.ifname (where ifname is the name of the VLAN interface) for each VLAN interface and that should be that.

The ESX Server configuration to support these VLAN interfaces at the guest level was pretty easy, too.  I just had to create a port group with a VLAN ID of 4095 and attach the OpenBSD guest to that port group.  ESX Server automatically passed the VLAN tags up to the guest and everything worked as expected.  (Again, I’ll have a separate article on that published soon.)

Next, perhaps I’ll try this with Linux or Solaris…

Having tested a couple of the previous releases of OpenBSD on various versions of ESX Server (OpenBSD 3.8 here and version 3.9 here), I decided to test OpenBSD 4.1 on ESX Server 3.0.1.  I didn’t really expect any problems at first, but then I stumbled across this article describing a problem between OpenBSD 4.1 and ESX Server 2.5.  Fortunately, it appears as if that problem does not affect ESX Server 3.0.1.

The VM configuration was pretty straightforward; just change the SCSI controller to LSI Logic instead of BusLogic and everything should work beautifully.  The OpenBSD 4.1 release notes indicate a new driver for the VMware VMXnet NIC driver, but I haven’t had the opportunity to test this yet; my installation is still using the pcn0 driver.

After installing OpenBSD, I was able to successfully install a number of packages using pkg_add (pulling the packages down via FTP).  Not confident that I had transferred enough data to be sure that I wasn’t going to see the same issue the other blogger ran into with his installation, I fired up Interarchy and transferred a 450MB ISO file via SFTP.  The file transfer completed successfully and I ran into no problems.

I’ll likely experiment with adding the VMXnet driver within the next few days to see how that works and how it affects network performance.

I’ve got a lot of respect for OpenBSD, whose maintainers’ relentless focus on security has really paid off.  Until today, the OpenBSD tagline was “only one remote hole in the default install in almost ten years.”  Now, due to the discovery of a new critical vulnerability, that tagline must change to its current form:  “Only two remote holes in the default install, in more than 10 years!”

Fortunately, this new vulnerability is fairly easy to mitigate and is fairly limited in scope to begin with.  This page (look for the security fix dated March 7, 2007) provides some workarounds and a link to the patch that fixes the problem.  If you’re already using OpenBSD’s pf firewalling functionality, then pf can easily be configured to block the traffic that triggers this vulnerability.

If you manage any OpenBSD-based systems, it would be prudent to configure pf and/or apply the patch to address this vulnerability.

After doing some additional research on the authentication architecture for OpenBSD, I learned that OpenBSD does not support PAM (Pluggable Authentication Mechanism), nor does OpenBSD support NSS (Name Switch Service).  I found this particularly interesting, but not terribly surprising as the OpenBSD leaders have made it very clear that they won’t include software that doesn’t meet their stringent security and licensing requirements.  I suppose that’s a good thing, even if it does make certain tasks impossible.

In any case, I did find some veiled references to login_ldap, which uses the underlying bsd_auth mechanism employed by OpenBSD.  Unfortunately (again), not all the software installed with OpenBSD supports bsd_auth and therefore also doesn’t support login_ldap.

There is a bright spot here, though, and that’s OpenSSH.  OpenSSH supports native Kerberos authentication, i.e., passwordless authentication from a Kerberized SSH client to the OpenSSH daemon, which is itself Kerberized.  I wrote about passwordless Kerberos authentication for Linux and Solaris a while ago; it turns out the process is almost identical for OpenBSD.

To enable native Kerberos authentication in OpenSSH, make sure the following commands are present in the sshd_config file (typically found at /etc/ssh):

KerberosAuthentication yes
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

Be sure to restart the SSH daemon after making these changes.

Also, configure the krb5.conf file (found in OpenBSD at /etc/kerberosV—note the capitalization!) appropriately; refer to any of the Kerberos-related articles here for more information on the appropriate configuration.  For this test, I also created a keytab (using ktpass.exe) and placed it in the /etc/kerberosV directory as well.  I don’t know for sure if that’s required.  As I have time, I’ll do some additional testing and try to find out.

Because there is no NSS support in OpenBSD, you’ll need to maintain accounts (but not passwords) in the local files.  So, to test this, first be sure to create an account (using useradd), create the home directory, and assign appropriate permissions to the home directory.  Otherwise, it won’t work.

Once the configuration changes have been made, SSHd has been restarted, and a local account created, SSH connections from a Kerberos-enabled client (with a valid Kerberos ticket) should just work without any prompt for password.

Although this doesn’t provide the broad integration with Active Directory that some may be seeking, it can at least help with SSH access to the OpenBSD systems, and that’s better than nothing.

To setup a simple NAT router/firewall using OpenBSD, use these steps as a general guideline.  I’m assuming that you have general knowledge of OpenBSD.

First, configure the network interfaces appropriately.  Typically, this will involve editing the hostname.<NIC type> file.  In a VMware ESX Server environment, OpenBSD uses pcn0 for the first virtual NIC, pcn1 for the second virtual NIC, etc., so the appropriate configuration files would be hostname.pcn0, hostname.pcn1, and so forth.

Next, enable IP forwarding by editing /etc/sysctl.conf and making the following change (the line is present in a default installation, you just need to uncomment it):

net.inet.ip.forwarding=1

Next, we’ll need to enable the OpenBSD packet filter, pf.  This is typically done by creating/editing the file /etc/rc.conf.local and making sure the following line is present:

pf=YES

Next, we’ll configure pf for network address translation (NAT) and simple packet filtering.  If you’ve never configured pf before, I highly recommend this OpenBSD PF guide; it will introduce you to the functionality of this very powerful packet filtering engine.  (Sometimes I wish Mac OS X would switch to using pf.)  You configure pf by placing a ruleset into /etc/pf.conf.

Here’s a quick sample ruleset (keep in mind this is based on OpenBSD running as a virtual machine in a VMware environment):

# Set some variables for use later
ext_if=“pcn1”
int_if=“pcn0”
icmp_types=“echoreq”

# Skip all loopback traffic
set skip on lo

# Scrub all traffic
scrub in

# Perform NAT on external interface
nat on $ext_if from $int_if:network -> ($ext_if:0)

# Define default behavior
block in
pass out keep state

# Allow inbound traffic on internal interface
pass quick on $int_if

# Protect against spoofing
antispoof quick for { lo $int_if }

# Allow other traffic
pass in on $ext_if proto tcp to ($ext_if) port ssh flags S/SA keep state
pass in inet proto icmp from $allowed_hosts icmp-type $icmp_types keep state

This is a really, really simple configuration, but it will get the job done.  (I did title this “OpenBSD as a Simple NAT Router”, after all.)

For more advanced configurations, I highly recommended reviewing the OpenBSD documentation (which, by the way, is very thorough and very extensive; kudos to the OpenBSD team for their documentation efforts.)

In earlier posts (on the pcn0 driver in OpenBSD 3.8 and on running OpenBSD 3.8 on VMware ESX Server 2.5) I’ve provided information on running OpenBSD in a virtualized environment.  With the release of OpenBSD 3.9 a few weeks ago, I’ve completed some testing.  Here are the results.

Here’s the configuration of the virtual machine under ESX Server that I used for my testing:

• Guest operating system set to FreeBSD (OpenBSD is not an officially supported guest OS)
• Single CPU (virtual SMP is not supported)
• 128MB of RAM
• LSI Logic SCSI controller (this is a change from the default BusLogic controller)
• Standard vlance network controller

I have not yet tested to see if the BusLogic controllers works under 3.9; it for sure did not work under 3.8 (OpenBSD wouldn’t see the disks).  If time permits, I will test that soon.

I am very happy to report that the pcn driver now works as expected; it’s no longer necessary to disable the pcn driver and use the le driver instead.  It is my understanding that the pcn driver is faster and more efficient than the older le driver, so I’m pretty excited that this is now working as expected.  My subjective analysis indicates that there is a small performance gain, at least in my environment.

If I run across any additional information, I’ll be sure to share it here.

Reading about the “Vulnerability Discovery and Remediation Open Source Hardening Project”—a security audit funded by the Department of Homeland Security to regularly review popular open source software (this article has more information)—got me thinking.

The article that sparked my thinking discussed how a critical flaw had been discovered in the X Window System.  This flaw was described as one of the most serious flaws uncovered to date.  The flaw was corrected quickly, as is typical of most open source projects, but it wasn’t really the flaw itself or the quick response to the flaw that really got to me.  Instead, it was the fact that someone was even able to search for such flaws.

The war-cry for open source proponents has always been, “Our software is more secure because more people have seen the code and reviewed it.”  Until now, I wasn’t so sure about that argument; after all, how many people were like me?  People who loved the projects, supported them in whatever way they could, but aren’t developers?  An ordinary guy like me can’t contribute anything significant to an open source project because I don’t know C, C++, C#, Java, Objective-C, or anything else.  The fact that I could review the code, until now, didn’t really do me any good.  Or so I thought.

Perhaps I’m just coming late to the party.  Perhaps it’s the involvement of the government, using my tax dollars, that has driven the idea home.  Either way, now I see that the very right to review the source code is what makes open source projects so powerful in comparison with closed source software.  As this DHS-sponsored project pores over millions of lines of code to find obscure bugs like the one described above, everyone (even Windows users) benefits.  As security flaws, buffer overflows, etc., are corrected in software packages such as Apache (which runs the majority of web sites on the Internet, last I checked), FreeBSD, the Linux kernel, MySQL, the Internet and our own private networks become more secure, more protected, and less likely to be used in attacks against others.  This is what the open source proponents have been so excited about, and why support for open source software is so strong.

This doesn’t mean that open source projects are automatically “more secure,” nor does it mean that we should all eschew all forms of commercial software in favor of open source equivalents.  But it does mean that we do need to strongly consider open source equivalents, especially the high-profile ones, when developing solutions for customers.  In my opinion, it would be a disservice otherwise.

As part of ongoing interoperability testing with ESX Server, I tested running FreeNAS (version 0.65) on ESX Server 2.5.3 today.  Since FreeNAS is based on FreeBSD (which VMware states is a supported guest operating system for ESX Server), I didn’t really expect any major surprises.  I was wrong.

Basically, I couldn’t make it work.  Despite trying both the BusLogic SCSI adapter (the default) and the LSI Logic adapter, the FreeNAS distribution wouldn’t see the virtualized SCSI hard disks, and therefore I could never install FreeNAS to the hard disk for use.  Without the XML configuration file on a read/write media, FreeNAS lost its settings (such as the IP address or the network interface to use) every time it rebooted.

It’s odd that FreeBSD, a supported guest OS, didn’t appear to work, yet I was able to make OpenBSD (an unsupported guest OS) run without any major problems.

Anyone have any tips for making FreeNAS 0.65 work under VMware ESX Server?

One more quick lesson learned from the recent experiment getting OpenBSD running on VMware ESX Server involved modifying the default operation of OpenBSD’s DHCP client, dhclient.

In this case, OpenBSD only needed to obtain the IP address and subnet mask from the DHCP server.  Specifically, OpenBSD should not obtain the default gateway, as another NIC on a different subnet would be directing traffic to a separate Internet connection.  I found that by editing the /etc/dhclient.conf file, it is possible to control the behavior of the DHCP client so that it only “listens” to certain configuration parameters passed down by the DHCP server.

For example, to have the DHCP client only pick up IP address and subnet mask, change the “request” line in dhclient.conf to look something like this:

request subnet-mask, broadcast address;

The standard dhclient.conf “request” line looks something like this:

request subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, host-name, lpr-servers, ntp-servers;

Obviously, this list can be trimmed to pick up only the items that are needed by the server.  Another neat trick is using the “prepend” statement; this allows the local client to use a value configured locally, then use the values passed down by the DHCP server.  Check the man page for dhclient.conf for more detailed information.