BSD

You are currently browsing articles tagged BSD.

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: , , , , , , , , , , , , , ,

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.

Tags: , , , , ,

OpenBSD as a Simple NAT Router

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.)

Tags: , , , ,

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.

Tags: , , , , ,

Thinking About Open Source

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.

Tags: , , , ,

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?

Tags: , , , ,

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.

Tags: ,

Static Routes on OpenBSD

Once OpenBSD was running on ESX Server, there was a configuration issue that had to be addressed involving static routes.  This is probably one of those times where the OpenBSD experts are saying, “This is so simple!”, but I had to search a bit to find the answer.  So, for future reference and for the reference of those of us who are not OpenBSD experts (yet), here’s the solution.

There are actually two solutions.  The first solution involves the use of the hostname.if file.  OpenBSD maintains a separate hostname.if file for each interface, where the “.if” is replaced by the devicename.  In a virtualized instance, this would typically be “le1” for the first NIC, “le2” for the second NIC, etc.  Therefore, the first NIC would be configured using hostname.le1, and the second NIC would be configured using hostname.le2.

To add a static route to an interface, append a route command to the appropriate hostname.if file.  Here’s an example:

inet 192.168.254.254 255.255.255.0 NONE
!route add default 192.168.254.1

The key, of course, is the “!route add …” statement.  This is the piece that I needed.

You can also add similar statements to /etc/rc.local, which will do the same thing.  Note, however, that these statements cannot go into /etc/rc.conf.local.

Tags: ,

OpenBSD on ESX Server

Having already successfully installed OpenBSD (version 3.8) on GSX Server, the task now becomes installing OpenBSD 3.8 on ESX Server.  For the most part, the experience is very similar, but there are a couple of important details.

First, of course, there is the issue with the pcn0 driver used by OpenBSD for the virtual NIC presented by VMware.  This issue is quickly and easily resolved.  At this time, there is no OpenBSD support for VMware’s more efficient VMXnet driver—only the vlance driver.

Second, the virtual SCSI driver must be switched to LSI Logic instead of BusLogic.  Since OpenBSD isn’t a supported guest operating system, an alternate selection must be made when creating the virtual machine.  FreeBSD is the next closest choice, but VMware will default to BusLogic SCSI adapters with FreeBSD virtual machines.  However, once you change to the LSI Logic SCSI adapter, everything seems to work just fine.

From there, the installation is perfectly straightforward.  There are no VMware Tools for OpenBSD, although I have heard rumors that people have gotten versions for other operating systems to run on OpenBSD.

Tags: , , ,

Quite a long time ago, I posted two short articles on transparent RDP tunneling (read more here and here).  To be honest, I had forgotten that I hadn’t posted more complete details on how exactly I went about making it work.  So, to rectify that problem, here are the full details.

First, some background.  I have a number of customers whose servers I manage remotely via Remote Desktop.  Remote Desktop (or Terminal Services, if running in Application Server mode), as you may be aware, uses Microsoft’s RDP as the protocol.  Not comfortable using RDP across the Internet, I always encrypted RDP using SSL (typically via Stunnel), but this proved unwieldy as the number of servers increased.  I needed a way that I could use any ordinary RDP client from within my office and transparently tunnel that RDP traffic inside SSL.

<aside>The reason this became unwieldy is due to the number of client-side definitions I had to create on my Mac OS X laptop using SSL Enabler.  After a while, it become difficult to remember which local port corresponded with each remote server.</aside>

So, using OpenBSD (then version 3.7, now version 3.8), I first added some additional IP addresses to the le1 interface by modifying the /etc/hostname.le1 file like so:

inet 192.168.100.1 255.255.0.0
alias 192.168.100.2
alias 192.168.100.3

Using ping, I verified that the new IP addresses were responding, then proceeded to configure Stunnel to accept unencrypted connections and forward them to another host as encrypted connections.  The Stunnel configuration looked something like this:

client = yes
[ms-wbt-server]
accept  = 192.168.100.2:3389
connect = 172.16.100.100:54321

I also had to add the “ms-wbt-server” to the /etc/services file with the appropriate port numbers (3389).

On the other end of the tunnel, Stunnel was set up in reverse—it was configured to receive an encrypted connection on port 54321 (for example) and forward that as an unencrypted connection to the standard RDP port (3389).  The Stunnel configuration looked something like this:

CApath = c:\winnt\system32\stunnel
cert = c:\winnt\system32\stunnel\stunnel.pem
client = no
service = SSLTunnel
[ms-wbt-server-s]
accept = 54321
connect = 3389

Again, the “ms-wbt-server-s” (for “secure”) had to be added to to the services file (on Windows boxes typically located in “C:\winnt\system32\drivers\etc”).  Then I registered Stunnel to run as a service (I believe the command-line was “stunnel -s <config file name>” or similar).  Upon starting the service, I verified that we now had a listening port using “netstat -an”.

When all looked good, I configured any firewalls to pass the appropriate traffic and tested the connection.  Done!  I was now able to connect to one of the internal IP addresses on the OpenBSD server using a standard, unencrypted RDP connection.  That connection was then encrypted in SSL and forwarded across the Internet to a waiting Stunnel instance, where it was decrypted and handed off to the RDP listener.

With a few modifications, this approach could easily be used to create application-specific VPNs between multiple locations within the same organization, or between different organizations.

Tags: , , , , ,

« Older entries § Newer entries »