BSD DevCenter
oreilly.comSafari Books Online.Conferences.


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.

Pages: 1, 2

Next Pagearrow

Sponsored by: