By Jeffrey Carl
Boardwatch Magazine was the place to go for Internet Service Provider industry news, opinions and gossip for much of the 1990s. It was founded by the iconoclastic and opinionated Jack Rickard in the commercial Internet’s early days, and by the time I joined it had a niche following but an influential among ISPs, particularly for its annual ranking of Tier 1 ISPs and through the ISPcon tradeshow. Writing and speaking for Boardwatch was one of my fondest memories of the first dot-com age.
If you aren’t familiar with the OpenBSD project (www.openbsd.org), it’s worth your time to find out about it. The core of OpenBSD’s mission is to provide the most secure Unix operating system available. For many ISPs, this is a very powerful consideration for protecting their customers’ data and their own – and one that can give them a competitive advantage among security-conscious customers.
OpenBSD offers a free variant of the BSD Unix operating system. It runs on a variety of platforms (from Intel x86 to Motorola M68k to Sun SPARC and several others). It has a number of native ports of popular software, and includes binary emulation options to run programs written for other operating systems including Solaris, Linux, FreeBSD, BSD/OS, SunOS and HP-UX.
OpenBSD runs on a tight budget. The project is funded primarily by the sales of installation CD-ROMs, T-shirts and goodies, plus donations of money and equipment. OpenBSD has various commercial support options, and is available via anonymous FTP (www.openbsd.org/ftp.html) or on CD (www.openbsd.org/orders.html).
Answers from Louis Bertrand
Recently, I had a chance to interview Louis Bertrand (an OpenBSD developer, and the project’s unofficial PR guy) on the past and future of OpenBSD, as well as why ISPs might want to deploy it. Here’s what he had to say.
Question: What’s the short version of the history of the OpenBSD project?
Bertrand: Started in 1995 by Theo de Raadt, OpenBSD’s primary goal was to address the deplorable state of Unix and network security at the time. The cryptography angle was a natural outgrowth because it allowed the team to address security problems inherent in some protocols without breaking standards. The main effort was a comprehensive code audit, looking for the kind of sloppy coding practices that lead to buffer overrun attacks, races and other root hacks. Another goal was to release a BSD-derived OS with completely open access to the source code: OpenBSD was the first to let any and all users maintain their own copy of the source tree via anonymous CVS. We also kept the multi-platform aspects of BSD, subject to manpower – security comes first.
The OpenBSD source tree was created in October 1995, the first FTP-only release (2.0) happened in Fall ‘96, the first CD-ROM release (2.1) came out in Spring 1997, and CD-ROM releases have been coming out like clockwork every six months. 2.6 just came out Dec.1, 1999.
OpenBSD is derived from NetBSD (Theo de Raadt was a co-founder of that project). NetBSD is in turn derived from the Berkeley Computer Systems Research Group final releases of 4.4BSD-Lite.
Q: What does OpenBSD see as its niche or mission? Will that stay the same in the future?
Bertrand: OpenBSD is unique because of the security stance and the code audit, and the cryptography integration. There are no plans to change that focus. I mean, why should we? No other OS vendor (open source or commercial) is doing an active code audit, and nobody integrates encryption the way we do.
OpenBSD’s mission continues to be working proof that it is possible to offer a full-function OS that is also secure. The software industry and consumers (both commercial and open source) are locked into the “New! New! New!” mindset. Consequently, the accepted security stance is to back-patch whenever someone finds a problem. We completely reject that – ideally we’ll have corrected all the problems before they can be discovered and exploited by the bad guys.
OpenBSD’s existence is also a constant reminder that the US government’s ban on exporting strong cryptographic software (it’s considered “munitions”) has become essentially futile. It is now easier to obtain strong encryption software outside the USA than inside. Being free software, we also completely avoid the restrictions of the Wassenaar Arrangement (UN-based arms export controls).
Q: Where does the project stand now (version, newest features added)?
Bertrand: The most important addition to 2.6 was OpenSSH, a free implementation of the SSH1 protocol (www.openssh.com). OpenSSH is integrated in OpenBSD 2.6. It’s an essential replacement for telnet and rsh for remote access where there is a danger of password sniffing over the wire. You can also use scp to transfer files instead of rcp or ftp. The last hurdle to complete crypto coverage in OpenBSD is the patent on RSA public key encryption, as used in SSL for SSH and secure web servers). OpenSSL is used everywhere
except the USA, where you can only use the RSAREF library, and then only for non-commercial applications.
Another big improvement in 2.6 was the huge effort to improve the documentation (both manual pages and web FAQ) and to make sure the information was up to date and correct. We’re trying to avoid the situation where people are dissatisfied with the main sources of information and start writing their own how-to documents – that only serves to fragment the sources of information, and users end up wasting a lot of time hunting around for reliable information.
Q: What’s coming up on the roadmap for the next major/minor versions? What new features? When might we expect to see them?
Bertrand: If all goes according to plan, there will be a release 2.7 in early summer 2000. There are no plans for a “major” release (e.g. 3.0).
Currently there’s a lot of work going on to integrate the KAME (www.kame.net) IPv6 networking code into OpenBSD (it’s already supported, but this actually integrates it into the source tree). There’s also a major rework of the “ports” tree, the facility by which people can download and build applications simply by doing make install in the target directory.
There is also some exploratory work going on for multi-processor support. Previously we flatly turned down the idea because it would be a huge effort that would only benefit a minority of users who are running SMP machines. But the recent drop in prices of SMP hardware means that it’s time to revisit that decision, and a few developers are interested in doing it. We still need to make sure we’re doing it right, not just heating up the second processor.
Q: What are OpenBSD’s weak spots right now, or what needs the most work?
Bertrand: The main criticism leveled at OpenBSD is that it doesn’t track the very latest standards. It’s a fair comment because we’ll often hold back on a new feature because of stability concerns. We held back APM (power management) support from the 2.5 release because it hadn’t been tested enough, and we still use named-4.9.7 for DNS because of security concerns, even though named-8 is in routine use elsewhere (there was a remote root hole found in bind-8.2.1 as recently as last November).
A lot of people have been asking for multi-processor support. Up to now, that was out of the question, but SMP hardware has been getting cheaper and several developers are interested in starting on it.
Also we don’t support the Macintosh PPC platform or the HP PA-RISC platforms. Again, there’s some work going on to change that. We’ve also dropped active support on Alpha because we were getting no support from Compaq. It still builds and runs, but we’re falling behind on hardware support.
Q: From an ISP/webhosting perspective, what specifically would you cite as reasons to choose OpenBSD?
Bertrand: Security and code correctness, along with the “secure by default” configuration. They all go hand in hand.
Start with the “secure by default” philosophy. It means that a sysadmin doesn’t have to rummage around dark corners shutting down risky or useless server daemons that the installation script enabled by default, or run around tightening up permissions. Sysadmins are very busy and we let them get their job done by enabling only those services and daemons they actually want and need. The default installation of OpenBSD has no remote root holes, and hasn’t had one for over two years.
Then there’s the security/correctness angle. The OpenBSD code audit discovered that if you fix the bugs, you have gone a long way to securing the system. In fact, it’s not necessary to prove that some buffer overflow would have caused a security hole – it’s enough to know that the software is now doing what it’s supposed to do, with no nasty side effects. That’s the kind of proactive measures that allowed OpenSSH to avoid the recent RSAREF vulnerability in SSH.
Finally (but not least), there’s the built-in cryptography. Whether you’re setting up an IPSec VPN between subnets across the Internet, or just running a modest client/server VPN with SSH and stunnel, OpenBSD has the built-in tools, maintained and tested for interoperability with commercial vendors. You don’t have to download, build, test and integrate your own cryptographic subsystems. No other OS ships with this level of integration.
Q: Can you point to any user base or constituency that OpenBSD is a “must-have” for? If so, why?
Bertrand: Any users who need to run intrusion detection, firewall or servers carrying sensitive information (e-commerce too!). For intrusion detection, there’s no point in trying to guard against malicious behavior on your network if the IDS system or firewall itself is vulnerable. For sensitive data, the built-in SSL makes it very easy to set up a secure web server. (Note, however, that the RSA patent restriction is still something US-based service providers must deal with).
Security is also a concern if you’re offering VPNs: any encryption scheme is worthless if the underlying OS is vulnerable (this is like an intruder bypassing a steel door by breaking a window).
Q: How vital do you see security as being to the future of the ‘Net and the future of OpenBSD?
Bertrand: Extremely vital for both. I’d like to say concern for security is going to hit a threshold where more and more people are going to ask tough questions of their software vendors, ISPs and e-commerce outlets, but it’s probably wishful thinking. We’d like to see more than just “safety blanket” assurances from vendors.
One nasty trend is the growing full-time presence of powerful servers on end-user DSL and cable modems. This means there will be a fresh batch of compromise-able machines available for concerted attacks. If more vendors adopted a “secure by default” stance, that would go a long way to reducing the exposure of naive sysadmins.
Should You Use OpenBSD?
There are positives and negatives to OpenBSD’s focus on security. On the plus side, it’s the most secure free operating system you can get anywhere. If your number-one concern is making your server safe from intrusion, look no further than OpenBSD.
All Freenixes offer options for securing your system, but the fact that OpenBSD is secure “right out of the box” is a major advantage for the inexperienced administrator who isn’t sure how to secure a system, or the busy administrator who has the knowledge but not the time. A plain-vanilla installation of the OS will already include a number of security features that might take hours of installation and configuration (plus some considerable knowledge and research) with other Unixes.
On the negative side, OpenBSD’s security comes as a tradeoff for new gadgets and features – a tradeoff you may or may not be willing to make. Also, there’s a very true old saying that “security is inversely proportional to convenience.” And tight security can be very inconvenient. A lot of administrators (myself included) are used to saving time through leaving ourselves little insecurities (like rsh, allowing logins as root, or not using TCP-Wrappers for services like ftpd or telnetd). Conversely, many of the same busy or inexperienced administrators who find benefits in a “secure by default” installation may not have the time or the knowledge to then enable these insecure items if they want them.
And remember that you, the server administrator, can easily foil OpenBSD’s security precautions by doing something boneheaded, like installing third-party software with known security holes, or running your webserver as root. You yourself can make OpenBSD insecure by twiddling the knobs and switches if you don’t know what you’re doing.
Unless security is your primary consideration, you probably aren’t going to use OpenBSD for all of your Unix servers. Linux, FreeBSD and NetBSD all excel in various areas where OpenBSD does not. However, OpenBSD certainly has its place, and should be part of any network administrator’s toolkit. For your most security-sensitive tasks, OpenBSD is very likely to be “the right tool for the right job.”