Published on (
 See this if you're having trouble printing code examples

Securing Small Networks with OpenBSD TRUSTSECURE 2002 Report

by Jacek Artymiak

I had the pleasure to attend the TRUSTSECURE 2002 conference, which took Sept. 16-17, 2002 in Warsaw, Poland. It was the second edition of TRUSTSECURE, organized by AVET Information and Network Security (also known for their support of the bugdev and bugdev-pl mailing lists) and Edu-Tel Centrum Ksztalcenia Telekomunikacji i Informatyki.

My presence there was possible thanks to Aleksander Czarnowski, the president and CEO of AVET, who invited me to speak about OpenBSD and whom I'd like to thank for this invitation. Considering the fact that TRUSTSECURE is a gathering of some the best IT security minds in Poland, many of whom are well known in the worldwide developer and IT security communities, it was a honor for me to be invited to speak. Another thing that makes TRUSTSECURE special is the fact that it is self-financing and does not receive money from commercial sponsors. As such, it is a forum for free exchange of information and discussion instead of being a place for vendors to sell their goods.

Day 1

The conference opened with a summary of the last 12 months from the point of view of IT security and an interesting talk about using technology to curb creative accounting. Alek Czarnowski of AVET presented both subjects. His views on how technology could be used to prevent accountants and board members from cooking the books were very interesting, but I must say that I find it very unfortunate that we need to devise complex technology solutions to control people whom we should trust. Alas, as the Enron, Worldcom, and Arthur Andersen cases have proven, it is necessary. I suspect that it may get worse, which sends shivers down the spine of anyone who'd rather not see this world totally controlled by cold, unforgiving technology.

Related Reading

Practical UNIX and Internet Security
By Simson Garfinkel, Gene Spafford, Alan Schwartz

Later, Andrzej Zdzitowiecki of 4pi spoke about risk analysis in IT security management. Although his company helps large financial institutions and government agencies manage risk, a lot of what he said could be applied to all organizations managing information because information has become the most important asset of all. Unfortunately, many medium and small companies and organizations still don't know how to audit and manage security or how to assess risks. On the other hand, many security solutions and education and consulting services are still too expensive for the small guys. There clearly is a lot of room for enterprising educators, service providers, and consultants to teach this market segment about security and risk analysis.

Next, Alek presented his innovative way of constructing attack trees, a method for modeling and analysis of attacks. Although these tools are well known in the security analysis field, his approach to the problem is very innovative, because it is more flexible than earlier ways of constructing attack trees and allows for better analysis of attack attempts. I was particularly interested in their use in the analysis of costs of security and attacks. I hope we'll hear more about Alek's methods in the near future.

Maurycy Prodeus and Janusz Niewiadomski of iSec Security Research then took the stage to present common programming errors in server-side scripts. This wasn't exactly anything new or groundbreaking, but it was a good refresher on the subject. I was much more interested in their answers to questions from the audience, which shed a light on many more advanced topics. After that, Piotr Chytla, also of iSec, showed us how DoS and DDoS attacks work, how to detect them, and how to prevent them. His presentation was heavy on details, with a lot of practical suggestions.

Przemek Frasunek gave a long and exhaustive overview of his rexec and Cerber projects. Both packages perform tasks similar to OpenBSD's systrace although they are not quite for the faint of heart. These tools are not well documented and still need a lot of work on the user interface side of things as well as on data structures optimization. Let's hope they can get them finished soon. They are looking for help, so if you would like to develop or test code or write documentation for the project, visit the project home and volunteer. Przemek told us about his future plans for rexec and Cerber. In short, don't wait for rexec for FreeBSD 3.x or for FreeBSD 5.x unless they cannot release Cerber for FreeBSD 5.x. I hope that he finds the resources to finish Cerber and that it will become part of the official FreeBSD code. It would be a shame for such an interesting effort to go unnoticed.

Next, Aleksander Czarnowski showed us how to go about hardening IIS and ISA servers. This was very interesting, and I must praise Alek's skill and perseverance in finding ways to make the IIS/ISA behemoth behave, but one has to wonder why Microsoft is making admin lives so difficult. Surely these servers can be made secure, but the road to achieving even basic security is unnecessarily bumpy and twisted. If you thought configuring everything from the command line was hard, prepare yourself for a real hell.

Why is Microsoft adding so much functionality that we cannot use anyway? I mean, it looks like to make IIS and ISA safe we need to switch off two-thirds of their functionality, which is a strange thing. It is the reverse of what we do with Apache, where we add the functionality we need. In IIS we need to remember to disable most of it before we can safely expose the server to the outside world.

The last session of the first day belonged to Jan K. Rutkowski, whose presentation of the patchfinder rootkit detector for Linux turned into a lively discussion of rootkit and rootkit detection design methods. The most active participants in that discussion were the iSec team, who demonstrated deep knowledge of the Linux internals. After over an hour of exchanging ideas--one could almost see the lines of kernel code flying in the air, I kid you not--all agreed that the fight between the designers of rootkits and rootkit detectors will not end in the near future. It will only be limited by the resources available to both sides and their determination in devising new ways to outsmart each other.

Day 2

The second day of the conference began with an excellent presentation of the Freenet project delivered by Pawel Krawczyk of ABA. As an unplanned bonus, Pawel treated us to a practical demonstration of the MSIE6 certificate vulnerability, which he was the first to describe. Unlike many people in the IT field, Pawel has great presentation technique and a gift for explaining complex ideas in simple terms.

Next, Pawel Pisarczyk of IMMOS captured everyone's attention with a detailed overview of security mechanisms implemented in the Trusted and Secure class of operating systems. What I learned certainly made me want to learn more about these systems in the future. At the same time, what I learned about the methods for controlling the behavior of processes has made me think if constructing long lists of complex rules for processes is the right way to go. It seems to me that such constructs are very difficult to manage and get right because they assume that we can determine the system's behavior and allow for plenty of opportunities to miss some rule that may open dangerous holes in the system. I am not qualified to judge the relative merits and flaws of these designs, but I liked the approach to security presented by Rafal Wojtczuk of 7bulls. Rafal showed us how the Openwall project achieves high security by making modifications that do not change the way the administrators, users, and applications see the system. Their way of securing passwords and limiting privileges is quite ingenious, and it would be a very good thing if their ideas were copied by other commercial and free UNIX system designers and programmers. The Openwall project is one of those refreshing changes that are fun to watch because they produce practical solutions.


As mentioned, I had been invited to speak about OpenBSD. In my presentation, I tried to give a brief overview of OpenBSD itself, its typical uses, and how it could be used in corporate environments. As was the case with Linux a few years ago, the biggest obstacle on the OpenBSD's road to the corporate environment is the lack of certification.

By the way, in my private talks with security people from large Polish banks and corporations, I noticed that everyone said that unless they have some kind of "insurance policy," i.e. certification or paid support, they will not be allowed to use OpenBSD in their work. It is, of course, a huge chance for companies looking for a business plan or ideas. Linux has it easier because it is now possible to purchase support, and there are certification efforts underway.

The questions and comments that I heard from the audience could be divided into two categories: Theo and the old design of the OpenBSD kernel. Is old kernel design a problem for OpenBSD? I don't think so. It may look old to people who like microkernels or modular kernels, but that does not mean that it is useless; it just cannot be all things to everybody. As far as I can see, the preset kernel architecture did not prevent OpenBSD from becoming a stable platform for many interesting security solutions. Therefore, and I repeat here what I said at the conference, if you are a security professional, it is a very good idea to get to know OpenBSD and see how it can help you.

For all the criticism of Theo's decisions related to the OpenBSD projects, we all agreed that he's very good at managing the project and avoiding code and filesystem bloat found on many other free operating systems. We also agreed that the project badly needs more human resources. At the same time, a lot of people who criticized OpenBSD admitted openly that they "have a small OpenBSD server sitting in the corner and [they] like it very much." Now, this is something I had heard before, two or three years ago, when people were happily running small Linux servers in the corners of their offices. Could this mean that OpenBSD is close to achieving the critical mass it needs to become noticed outside of the current OpenBSD users' circles? I certainly hope so.

Personally, I am very optimistic about the future of OpenBSD, and I hope that it will find a rich commercial sponsor in the near future. Before it happens, there is something we can all do now. (I got this idea on my way home, so it was too late to present it during the conference.) The OpenBSD project has a page where we can all make donations. Tthey also have a Paypal account. If everyone who is interested in helping OpenBSD would make a $5 donation every month, that'd give the project a lot of money to use for a good cause. The math is simple. A $5 a month donation is $60 per year. Multiply that by 3,000 to 12,000--estimates of how many people read this series based on the number of page views I was given by my editor--which would mean $180,000 to $720,000 annually. That's certainly enough to pay people who develop OpenBSD, and it doesn't cost us much. I guess that's a tax we all can live with.

I think Theo owes me a pint of Guiness for having to endure Przemek's questions and comments. Will you two sort things out for the benefit of the rest of us? ;-) Seriously, I think you can do a lot of good things for OpenBSD, FreeBSD, and the open source community as a whole.

Overall, I found the conference one of the highlights of this year and I plan to attend the next edition. As Alek Czarnowski promised, plans for the next edition of TRUSTSECURE are already in progress, which is a very good thing for all security professionals in Poland.

(PS. I'd like to thank Przemek Galczewski (AVET) for giving me a lift to the bus terminal.)

Jacek Artymiak started his adventure with computers in 1986 with Sinclair ZX Spectrum. He's been using various commercial and Open Source Unix systems since 1991. Today, Jacek runs, writes and teaches about Open Source software and security, and tries to make things happen.

Read more Securing Small Networks with OpenBSD columns.

Return to the BSD DevCenter.

Copyright © 2009 O'Reilly Media, Inc.