BSD

You are currently browsing articles tagged BSD.

Let’s get right to the point and set the record straight: I am not, nor have I ever been, affiliated with or employed by the FBI or any other government agency.

That’s why I was surprised when word surfaced that I had been implicated in some sort of conspiracy regarding a plan to place secret backdoors into an OpenBSD cryptographic framework, and that my recent advocacy of OpenBSD was based on my alleged involvement with the FBI.

I don’t know where the person who started this rumor got his information, but he is sadly mistaken regarding my involvement. Perhaps the other Scott Lowe is involved; I don’t know. What I do know is this: I’m not affiliated with, supported by, employed by, associated with, or in support of the FBI in any way, shape, form, or fashion. Quite simply, it wasn’t me.

Feel free to post any additional questions or courteous comments below. I’ll answer all relevant questions openly and honestly.

Tags: ,

This is one of those posts that is as much for my own benefit as it is for others. For a few weeks now, I’ve been working on a dynamic DNS setup for my home/home office network involving BIND and the ISC DHCP daemon running on a pair of OpenBSD virtual machines. I finally got it to work (thanks in no small part to this article and this how-to post) and then found that I needed to make some manual edits to the DNS zones.

After a great deal of stumbling and fumbling, I found an obscure reference to a need to use rndc when making manual edits. After some testing, I learned that the “correct” way to make manual edits is as follows:

  1. Halt changes to the dynamic DNS zone with the command rndc freeze <zone name>.
  2. Make the manual edits to the zone file, being sure to increment the zone serial number.
  3. Use the command named-checkzone <zone name> <zone file> to verify the syntax in the zone file.
  4. Allow changes to the dynamic DNS zone with the command rndc thaw <zone name>.

If you monitor the appropriate log files (on my system I had to monitor /var/log/daemon), you’ll see zone transfers take place to any secondary name servers, a strong indicator that the change has successfully been accepted and propagated.

A very simple task, I know, but hopefully this post will help me next time I need to do this same task again and hopefully it will help someone else out there in the same situation.

Tags: , ,

If you were following my tweets over the last few days, you probably already know that I have been working on setting up a CCNA study environment using Ubuntu Linux, GNS3, and VMware Workstation. After a couple days of difficulties, I finally managed to make it work last night. Here are the steps that I took to make it work.

Before we start, there is the standard disclaimer: these are the steps that worked for me; these steps might or might not work for you, and are almost guaranteed not to work with different Linux distributions or different versions of the associated software.

Here are the software components and versions that I am using in my environment:

  • Ubuntu Linux 8.04.4 LTS, 32 bit
  • GNS3 0.6.1
  • Dynamips 0.2.8-RC2
  • Dynagen 0.10.1.090807
  • VMware Workstation 7.0.1 for Linux, 32 bit

I won’t go into great detail on setting up Ubuntu Linux as there are plenty of resources available for that portion of this environment. You will need to be at least vaguely familiar with the Linux command-line interface (CLI) and basic Linux commands, or you’ll find this process a bit difficult.

Once you have Ubuntu Linux installed and configured appropriately, the first step is to go ahead and install some dependencies using apt-get:

sudo apt-get install dynagen python-qt4

This should download and install both Dynagen and the Python-QT4 libraries. Next, you’ll need to download and install GNS3 0.6.1. There are newer versions of GNS3 available, but earlier attempts to get this environment running with the newer version of GNS3 resulted in problems. Again, your results might differ. Version 0.6.1 of GNS3 is available from the GNS3 SourceForge site.

Once you have GNS3 downloaded, extract it into the directory of your choice (I chose to use /opt/GNS3).

After you’ve downloaded and extracted GNS3, create the following directories under the directory where GNS3 is found:

<GNS3 directory>/project
<GNS3 directory>/ios
<GNS3 directory>/cache
<GNS3 directory>/tmp
<GNS3 directory>/dynamips

Use the chmod and chown commands as necessary to ensure that your user account has full read/write permissions all of these directories except the dynamips directory.

Download a copy of Dynamips (it’s generally available here), put it into the dynamips directory you created, and use the chmod command to make it executable. I also found it necessary to set the Dynamips binary’s SUID bit so that it would always run as root; I know this is not best practice but I could not find any other workaround. (Without setting it SUID, GNS3 would always report an error when trying to launch Dynamips.)

Now launch GNS3 and use the Preferences in the application to set the correct path to your project directory (<GNS3 directory>/project) and the IOS/PIX directory (<GNS3 directory>/ios), the correct path to the Dynamips binary (<GNS3 directory>/dynamips), the correct path to the working directory (<GNS3 directory>/tmp), and the working directory for capture files (set it to your project directory).

At this point you should have a working GNS3 installation. You’ll still need to locate IOS images to use; once you have valid IOS images, place them in the ios directory you created earlier and configure them within GNS3 as needed. You should then be able to create a router instance, boot it, and access the router console from within GNS3.

You could stop there and have a pretty cool environment, but I wanted to go a step further. I also installed VMware Workstation 7.0.1 (I won’t go into detail here, it’s a pretty simple process) and then used the Virtual Network Editor to create some additional host-only networks (in addition to the default vmnet1). Again, this is well-documented already, so I won’t discuss the process in any length. Where it gets interesting is in how you connect GNS3 and these host-only networks so that VMs can be incorporated into your GNS3 router topology.

Here’s how you connect GNS3 and the VMware Workstation host-only networks:

  1. In GNS3, add a cloud object to the topology.
  2. Right-click the cloud object and select Configure.
  3. On the NIO Ethernet tab in the Generic Ethernet NIO section, select one of the host-only networks (like vmnet1) and click Add. This creates a link between the cloud object and the selected host-only network.

At this point, you can attach a VM to the selected host-only network, attach a router to the cloud, and be able to pass traffic from the VM to the router. Pretty cool, huh?

What I’ve done so far is create a simple network with two VMs attached to two different host-only networks which are in turn connected to two different cloud objects and two different routers. Then I created a “serial WAN link” between the two routers (GNS3 won’t, as far as I can tell, actually simulate WAN links with bandwidth limits and latency) and configured everything so that I could pass traffic from one VM to the second VM across the “virtual WAN”. The plan is to increase the network complexity—as much as my poor little Dell laptop will allow given its limited CPU and RAM—and work through the various CCNA study guides in preparation for my exam.

One other quick note about this setup (and the reason why I chose Linux as my host platform): by setting up SSH on the Linux system (with a simple sudo apt-get install openssh-server), I can now SSH into the Linux host system and then use Telnet from there to access all the various routers. In addition, because I’m using OpenBSD as the guest OS on my VMs, I can also SSH from the Linux host to the OpenBSD VMs (assuming my GNS3 network is configured correctly). I’m also thinking that there’s a way I can leverage some VNC connectivity through Workstation to access the VMs as well, but I’ll need to research that a bit to see how it works.

I would be remiss if I did not point out a couple of sites that were extremely helpful in getting this setup up and running. First, this site provided an excellent overview of the GNS3 installation on Ubuntu. Although the walk-through was for a newer version of Ubuntu, the instructions worked perfectly on 8.04.4 LTS. Second, this site gave me the “missing link” on how to connect GNS3 and VMware Workstation’s host-only networks so that you could mix the two environments. Thank you to both sites for outstanding information!

If you are a GNS3 expert or have some additional tips or tricks to share, please add them in the comments below so that all readers can benefit. Courteous comments are always welcome.

Tags: , , , , , , ,

I’ll start this off with a disclaimer: this post is really more for my own benefit than the benefit of anyone else.

OpenBSD is my OS of choice when it comes to setting up a quick, simple UNIX-based virtual machine (VM). Need a virtual firewall? Use OpenBSD. Need a router? Use OpenBSD. Need a web server or an FTP server? Use OpenBSD. Need to run some network security tools? Use OpenBSD.

The problem is this: once I get an OpenBSD system up and running, it runs so well that I rarely have to go set up another one. Because there is then this length of time between installations, I always find myself forgetting the steps to take when installing an OpenBSD system. Thus, the need for this post and why I say it’s really for my benefit more than anything else. Next time I need to install OpenBSD in a VM for some reason, I can quickly come back and reference my list. (I will say that the installation of OpenBSD in recent versions has gotten much simpler than it was in the past.)

Oh, another disclaimer is probably necessary here, too: this is not to be considered some sort of “best practices” guide, so please don’t hammer the comments with stuff like “You know, you really should…”. This is just a quick and simple setup.

With those disclaimers out of the way, here’s the installation procedure. This was written for use with OpenBSD 4.6:

  1. Boot from the OpenBSD installation ISO image. When prompted, choose “i” to install.
  2. Press Enter for the default keyboard layout (unless you need a different layout, naturally).
  3. Enter the system’s hostname in short form.
  4. Enter the name of the network interface to configure. When installing on VMware Fusion 3.0.2 on my Macintosh, the default interface is em0. On VMware vSphere 4, the default interface is vic0.
  5. Enter the IPv4 address or press Enter to use DHCP.
  6. Enter the IPv6 address or press Enter to not assign an IPv6 address.
  7. Press Enter to complete the configuration of network interfaces.
  8. Press Enter not to perform any manual network configuration.
  9. Enter and confirm the root password.
  10. Press Enter to start sshd by default.
  11. Press Enter not to start ntpd by default.
  12. Enter “no” to indicate that you will not be running the X Window System.
  13. Press Enter not to change the default console to com0.
  14. Press Enter not to create an additional user. (I generally prefer to create an additional user after installation is complete.)
  15. Press Enter to accept the default disk as the root disk. On my Mac running VMware Fusion 3.0.2, the default disk is wd0.
  16. Press Enter to use the whole disk.
  17. Press Enter to use auto layout of partitions on the disk. (I’m not sure what version of OpenBSD added this feature, but it is quite handy for simple installations.)
  18. Press Enter to use the CD to install the sets. The CD in the VM should be mapped to the ISO image of the OpenBSD 4.6 install CD.
  19. Press Enter to use the default CD (which showed up as cd0 on my system).
  20. Press Enter to use the default path to the sets.
  21. Remove the X Window System sets by entering “-x*” and pressing Enter.
  22. Verify that the X Window System sets (xbase46.tgz, xetc46.tgz, xshare46.tgz, xfont46.tgz, and xserv46.tgz) are unselected, then press Enter to complete set selection. OpenBSD will start installing the sets.
  23. Enter the timezone, such as “US/Eastern”.
  24. Enter reboot to reboot your new OpenBSD VM. You should now be ready to perform final configuration of OpenBSD, such as using pkg_add to install packages or editing rc.conf.local to control what daemons are launched at startup. (Of course, those are tasks for an entirely different blog post).

That’s it. Again, this not a best practice/ideal installation. It’s just a “drop dead simple” installation in a VM for when you need to get something done quickly.

Tags: , , , , ,

So, I’ve been searching for a good way to establish connectivity to the lab at my office for a while. My first attempt was to work with one of our CCIEs at the office to establish an IPSec-based VPN against a Cisco router at the edge of the lab network, but despite our best efforts we couldn’t get the IPSec VPN client I was using, IPSecuritas, to connect and authenticate. No amount of fiddling would make it work.

We finally gave up on that and instead I went with an OpenBSD box to which I could establish an SSH session and then tunnel traffic from there. That worked reasonably well, especially after I discovered the GNU Screen utility. Talk about a handy little tool! Anyway, I continued using the SSH gateway for quite some time and I had resigned myself to living with the limitations.

Then a co-worker from the office casually mentions that he’s set up a Linux-based OpenVPN server on another subnet in the lab (we have a range of different subnets for different engineers in the lab). He, too, is a Mac user, but still running Mac OS X 10.4 on an older 13″ PowerBook G4 and using the Tunnelblick OpenVPN client. I thought to myself, “Hey, this might actually work!”

Alas, some additional research indicated that Tunnelblick had some stability problems under Leopard, which I’m running on my MacBook Pro. Bummer! I continued to research the issue but didn’t bother trying to use the OpenVPN server until just a couple of weeks ago when I uncovered Viscosity.

Viscosity is a shareware, Leopard-only OpenVPN client. It supports Growl notifications (which I very much like) and operates as a simple menu icon that easily allows you to connect or disconnect individual connections. Owing partially to how OpenVPN works, Viscosity uses (and includes) a TUN/TAP driver for OS X and creates a new TUN/TAP interface for every connection. This makes routing much easier and much more logical, in my opinion.

I’m so pleased with OpenVPN thus far, in fact, that I’m going to be setting up my own OpenVPN server here at the house.

My experience thus far has been quite positive. If you are looking for a good OpenVPN client for your Mac, Viscosity would be an excellent choice. At only $9 for a license, it’s well worth it.

Tags: , , , , ,

New BSD Magazine

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.

Tags: ,

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…

Tags: , , , ,

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.

Tags: , , , ,

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.

Tags: , , ,

To help make it easier to find the various Active Directory integration articles I’ve written, I’m including links below to the latest version of each article. As new versions of an article are published, I can simply update this link to point to the new version.

I’ve grouped the integration articles according to product below.

Linux

Latest version for Windows Server 2008 (“Longhorn”)

Latest version for Windows Server 2003 R2

Latest version for Windows 2000 Server and Windows Server 2003 (pre-R2)

SuSE Linux Enterprise Desktop (SLED)-specific version

Solaris 10

Latest version for Solaris 10 x86

Firewalls

Latest version for Cisco PIX VPN

Latest version for WatchGuard Firebox VPN

VMware ESX Server

Latest version for ESX Server 2.5.x

Latest version for ESX Server 3.0.x

OpenBSD

Latest version for OpenBSD 3.9

Networking Equipment and Protocols

Latest version for 802.1x

Latest version for Cisco IOS

As new articles are published or existing articles are revised with new versions, I’ll update this post accordingly.

Tags: , , , , , , , , , , , , , ,

« Older entries