Slashdot Mirror
Secure Architectures with OpenBSD
The godfather of OpenBSD, Theo De Raadt, was given space on the cover for a snarky comment, his blessing apparently, that the book "works in tandem with OpenBSD's manual pages. As a result it will help many users grow..."
This comment is apropos, since the OpenBSD man pages, beginning with man afterboot, are some of the best getting-started OS documentation available anywhere on the net. So it is perhaps fair that a certain justification be offered for texts on this topic. This book gives many example configurations, some shell scripts, and an organizational approach that are simply beyond what one can realistically expect from the online manual pages. So yes, Theo, this book is destined to help mere mortals grow in knowledge and skill.
One nice feature of this book is that its authors refer to Linux equivalents where appropriate, e.g., in terms of configuration and system file locations and names. This makes it an ideal text for a Linux sysadmin who wants to take OpenBSD for a test drive on the public network. Two chapters covering the OpenBSD packet filter (pf) and IPSec are the gems of this text and even advanced Linux users will likely benefit from alternative approaches to solving the same problems in the alternate universe of a different operating system.
The Start-Up and Shutdown chapter has a careful and complete walk-through of /etc/rc, the equivalent of Linux's inittab. I found this to be a useful part of the book, because the various parts of this script are not always obvious from a first read through of the shell commands. Palmer and Nazario break it down into 41 sections, each with a discrete purpose. After running through the primary boot process run commands script, a brief explanation is given of each of the seven default OpenBSD processes.
Although a close examination of a minimalistic OS setup shouldn't be foreign to any mildly accomplished sysadmin, even those of the Microsoft camp, reviewing exactly what it is that the process list tells you is always a worthwhile exercise.
Like other opera omnia, the work falls into three parts, in this case: I. Getting Started, II. Configuration and Administration, and III. Advanced Features. The index and contents occupy only 25 or so pages out of the total 500 and will readily direct the casual reader into an appropriate chapter of her choice. The index entry for chroot, for instance, will direct the reader to the section on the most commonly encountered chroot issue: dynamic content generation under apache.
Coverage of the X Window System is as minimal as it should be on a platform where the benefits derived from its use have little immediate relevance for client-side GUI applications. Mac OS X users might find the book helpful, since OpenBSD can be installed, for those willing to undergo the hassle of repartitioning, on pretty much all current hardware from Apple. Many of the recipes (apache, sshd, gdb, sudo) are directly relevant to their own Darwinian flavor. Windows users will also find various parts of this book useful, since the Services for Unix product from Microsoft/Interix is widely known to be based upon an early version of OpenBSD. Note: Microsoft here joins a very long list of BSD-license adherents in opposing the world of GPL functionality, whether this be for better or for worse. So although the audience for this text is decidedly directed at those who are taking the plunge with Puffy the Blowfish, other audiences will benefit from the insights into basic systems administration activities.
This text may also serve as potent advocacy for the systems-administration practices of BSD masters. For instance, the process of user removal from a Red Hat or Debian system versus OpenBSD's rmuser script. The lifecycle of user accounts on long-lived systems does, after all, have an end as well as a beginning, so this process deserves attention, though it may occur less frequently in growing systems it nonetheless deserves attention. Note also the detailed description of rate-limiting, packet-scrubbing, transparent filtering, and load-balancing features of the platform's packet filter. It hardly seems fair to criticize snort2pf for being immature when pf itself is a novel feature with the 3.4 openbsd kernel.
Backup and Housekeeping chapters are particularly well laid out, and include strategies, not merely howto recipes. This is an important and often-neglected body of sysadmin knowledge. The Towers of Hanoi strategy backup script that uses key-based authentication to remotely backup servers will likely be a useful tool for readers of the text who are administering a remote server that needs to have routine off-site transfer of its contents.
An explanation of how to modify the default send-only setup of sendmail starts off the chapter on mail administration. Unfortunately, there is no mention of how to set up certificates for secure IMAP or POP authentication. This is an obviously necessary part of administering an email server in which passwords are not sent in the clear and I consider it to be the most egregious omission of the book. Perhaps the authors don't see email services as a place in which BSD actively or effectively contributes. X.509 key generation is covered in the Apache section for SSL and then again under the IPSec chapter, but configuration of the popular mail serving daemons to use cryptographic authentication surely deserves a place in this text which claims "secure architectures" as its purpose.
The appendices may be worth the price of the book alone for junior sysadmins first discovering the joys of BSD. These include a walk-through of CVS basics, how to use patch and diff, kernel tuning with sysctl, how
to make sense of dmesg output, and the basics of core file analysis, interpretation of RAM dumps by gdb produced at crash time. If pkg file creation were given similar treatment, it may help the *BSD package system find a broader appeal.
If you take a "hold forever" approach to your investment in books, it might be worth waiting until the second edition. Brandon Palmer indicated in a posting to the OpenBSD journal that a rewrite of the book would
likely include greater coverage of spamd administration as well as BGP and some of the high-availability features in CARP. No timing on the second edition is available and it should be noted that everything in the text is appropriate for OpenBSD 3.4, i.e., the Robin Hood puffinfish, not the 3.5 Monty Python puffinfish. I'd expect that in two more release cycles, summer 2005, it will be time to ask around about an update to this text. The IPv6 chapter will likely need a dramatic rewrite by then since it gives helpful configuration parameters for a handful of the current crop of IPv6 v.6 applications. As it is, the book stands on its own: current and relevant. A year and a half is many generations of kernel compiles in Linux-land but only a few rounds of planned upgrades for the slower-paced approach of BSD admins.
Attention to documentation seems to be the distinguishing mark of a mature project. In that vein, the recent round of OpenBSD texts can be seen as an argument that the platform is destined for greater mainstream use. Listed here are a few other recent texts on OpenBSD. The most direct competitor to this text is Absolute BSD: Unix for the Practical Paranoid by Michael Lucas and Jordan Hubbard which has been available in bookstores now for more than a year. For greater detail on the packet filter, refer to Building Firewalls with OpenBSD and PF by Jacek Artymiak or OpenBSD Firewalling by Jorg Kutemeier which is so far only available in German. Brian Carter's text OpenBSD: Implementing the Secure UNIX Platform was not available to the reviewer at the time of this writing but is expectedly to be out in distribution shortly.
Daniel Hartmeier's quotation on the back cover stating that the book's organization will help you save time is right on target. Although time will tell whether this book becomes the de facto standard as a systems handbook or complete text on OpenBSD, it is a book you can confidently recommend to anyone who wants their first experience with OpenBSD to include learning the ropes of minimalistic, and therefore robust, secure server administration practices.
Postscript: Addison Wesley has made the index of the book available. You can purchase the Secure Architectures with OpenBSD from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, carefully read the book review guidelines, then visit the submission page.
great, it's dead again.
...i.e., this.
Hopefully they've set up throttling...
The Army reading list
I am thinking of changing from NetBSD. They can set the Internet2 landspeed record but they still have not managed to choose a new logo. This is killing me...I want to know.
I can't be the only one who read that as "...the joys of B&D, can I?
(Jose is also an occasional Slashdot book reviewer, and a good cook.)
;)
timothy knows, she made him breakfast on many occasions.
The "Insert Quote Here" line is almost as predictable as inserting an actual quote.
I'm afraid I wasn't aware of Slashdot in the late 90s; I started reading in 2001.
How was Slashdot different in the late nineties? Would anyone care to compare the differences between then and now? I'm wondering if there were even any significant differences, or if this is just someone's misguided nostalgia.
Little off topic but ther is a good article about Linux emulation on NetBSD over at Newsforge
Help fight continental drift.
I encounter a broad spectrum of BSD-derived and SYSV-derived operating systems, (as well as hybrids such as Solaris), and even in going back and forth between FreeBSD and OpenBSD can bring confusion, particularly with the very different way the two handle system startup scripts.
I would like to see somebody publish a book that does include information on using OpenBSD with X-windows as a secure desktop OS. Everybody focuses on the security of Open as a server OS for infrastructure, but it can be usable (if not user friendly, at least not user hostile) on the desktop.
I do not deploy Linux. Ever.
------------
mobile porn
OpenBSD is an excellent operating system for running dedicated network hardware. It's fast, stable, and secure. My only two complaints are that it doesn't support PowerPC hardware, and its lack of SMP. I have a Power Mac 9600/300 dual processor box that is of no use to us in the shop but would take care of three installed boxes' network duties if I could put OpenBSD on it. I don't think that Linux or Darwin are up to the task, so the machine sits.
BLING BLING. Meet the architecture that's changing everything.
There is something prophetic about having references to deadly and undeadly in a *BSD review :-p
Get it direct from OpenBSD https://https.openbsd.org/cgi-bin/order.eu
Here is a nice picture of Theo De Raadt creating *BSD.
"Existence of the Secure Architectures with OpenBSD text was first made public on the OpenBSD Journal in early April 2004. The OpenBSD Journal, also known as deadly.org and now undeadly.org, recently changed hands from James Phillips to Daniel Hartmeier amid several more or less obscure references to Pogues lyrics."
What the hell? Two sentences and I'm already completely lost.
Comment of the year
I have used OpenBSD since 2.8 for firewalls and I actually just finished reading this book. Though this book is a broad overview of OpenBSD, it does contain alot of useful info for both new users and experienced admins. If you havent used any of the power of OpenBSD or just a few core features like me, this book is really great to have on the shelf.
http://zeus.theos.com/deraadt/hosts.html
http://openbsd.org/images/newrack.jpg
Seriously though, they keep a wildly assorted compile farm, to periodically build/test everything. If you took back your hardware, you might not be supported for long :)
I'll bite on this flamebait:
Ask that same question of any IT security professional out there.
90% of the IT security people I know prefer using OpenBSD as their firewalls or VPN tunnel boxes. They are fast, reliable, and easy to work on.
And writing rulesets for pf is definetly MUCH easier than writing them for iptables.
I've seen these EXACT words used a number of times before on different sites. Seems somebody learned how to cut and paste.
Truth is, *BSD is far from dead. In fact, until this April, FreeBSD to quote Netcraft "...had without exception been the most common operating system amongst the top ten each month.". This quote was in relation to a most reliable web servers list. In April, 5 of the top 10 were Linux based systems and 4 were *BSD (the other 1 if your curious was Windows).
While Packard was a real company, LaSalle and DeSoto were created as divisions of GM and Chrysler respectively. Their death no more represented the death of a company than Apple deciding not to make any more Apple ]['s was.
Actually, if you check out some of the links at the USRBAC security system project *modestly points*, you'll notice several extras for Linux that can make it inherantly more secure than OpenBSD. Particularly, PaX gives better guarentees than ExecShield (redhat) or W^X (OpenBSD) can about the existence of W|X pages, to guarentee the blockage of code injection ("shellcode"); and PaX has better ASLR (instead of crappy library load order randomization) to effectively block ret2libc type attacks.
I personally use Hardened Gentoo with stack smash protection (propolice) and PaX. I'm also working on a book called "Hard" about this stuff, which will also detail out proper coding practices; for example, how do you order your variable declaration? Like this:
Also, in functions, allocate your structures with function pointers AFTER all other structures with arrays, and try to use only one (or allocate pointers to them and new[] or malloc() them). For structures, reverse it.
My point here is that you have to partly rely on the actual programs, rather than the OS. BSD shares much of its underlying system (GNU tools, X, user programs like Mozilla and Gimp) with Linux and other Unixes. Even with stack smash protection, you can't i.e. protect a function pointer after (below) an array in a structure. ProPolice (patch for gcc, for both Linux and BSD, probably Windows too) also doesn't stack smash check until return, because checking at each pointer or at each fp call would be a lot of overhead.
I have no trouble with iptables rules myself. A nice GUI would be good, though, because as much as we all LOVE to brag about how our big dicks can satisfy the console's yearnings, it's simply faster and easier to use a more user-friendly interface (as long as it's not buggy).
Support my political activism on Patreon.
Don't forget that ALL of the servers with the longest uptime are BSD-based.
/* oops I accidentally made a comment, sorry */
It's just you cause works great here and has all day long.
Supposed to be released on May Day. I'm still waiting too...
Forget thrust, drag, lift and weight. Airplanes fly because of money.
Everyone still thinks that Macs suck. Only now they tell you that Macs are great. However, it is just like public television. Everyone tells you how great it is, but they don't watch it or spend money in it. This is how it is with Macs.
How can you secure something with an os that is inherently insecure? OpenBSD uses SSP kernel which makes the kernels extremely vulnerable to information leaking. The problem is that with even just one information leaking problem you can get the canopy (SSP thingy) and after that you have a free pass to almost everywhere. (Go to find an other bug to exploit it too, but anyways) SSP uses fixed canopy which is extremely dangerous.
Ok, it's just one small detail of the several hundred. But the point is, OpenBSD developers are very arrogant and although they have been told about the issues they refuse to acknownledge them and fix them. They just dig themselves a hole and crawl in without even considering the possibility of having being wrong for the last 10 years or so.
The other extremely bad thing about OpenBSD is that they mark the security fixes as umm "reliability" issues and mix them with the rest of the bugs. The only reason why there has been only "one" remotely exploitable hole in the system for the last 8 years is that it has by default nothing running.
Turn the usual things on (what you will anyways) and you are just as exploitable as with any other system. Perhaps even more. It might be even so that the only reason why OpenBSD seems to be secure in the field is that it is so obscure. No one uses it so no one realizes the tricks to exploit it. If it was as common as for instance Windows XP or some standard Linux, it would get smashed even more.
There are currently lots of unfixed security flaws in the OpenBSD that they won't fix. Perhaps ever will. Some of them have been open for couple years already. OpenBSD developers seem to be just resort to blackmouthing the reporters on the mailing lists and being stubborn about their own ways of interacting. (Causing a lot of harm.)
It is jsut good that the arpa funding was suspended and it would be good if ALL the rest of the supporters would quit too. Let that crappy monster die, please.
Flamebait? It was a joke, people! Lighten up!
In Soviet Russia, Chuck Norris will still kick your ass.
You forgot a step before Denial.
Usage.