Linuxsecurity.com: Thanks for taking the time to interview with us. How you doing these days? The most we hear from you is when Postfix is updated, the mailing lists, or something like that. What are you up to?
Wietse: I have been finishing things, so that I can start work on new projects. After a major documentation rewrite for the Postfix mail system, I finished the manuscript for a book on computer forensic analysis with Dan Farmer. When I finish something, I normally start reading everything that I can lay my hands on and then inspiration comes.
Linuxsecurity.com: On your website you mentioned you go bike riding, weather permitting, how's the weather been where you are this year?
Wietse: It has been fairly typical here in southern New York state. We dig ourselves out from the snow a few times in January and February. Once the snow is gone in March, we spend quality time walking up a hill or riding a bike. Many several former railroads are/were converted into trails, and riding them is fun. Unlike Europe, where I grew up, the roads in southern New York state are not really safe for riding a bicycle.
Linuxsecurity.com: You have a suite of tools available on your website. Any new ones coming out that address basic fundamental security practices that still aren't followed or are you going to add any new functionality to your existing programs?
Wietse: Some tools such as TCP WRAPPER are complete, and adding more features does not make them more useful. I would update them only so that they survive changes in operating systems, language compilers and/or network protocols. Some tools such as SATAN have served their purpose, and now have historical value only.
Linuxsecurity.com: Does the continued success of TCP Wrapper surprise you? If so, why is that? What does TCP Wrapper have that makes it so valuable today.
Perhaps the biggest virtue is that tcp_wrappers works as expected. This means that not only the software is relatively error free, it is also possible for human beings to install, configure, and forget tcp_wrappers without getting into trouble.
It does not matter how well software is written when people can't figure out how to use it, or when it has sharp edges that make it unsafe to use. Being safe and secure is hard enough with software like tcp_wrappers that spans only a few thousand lines of code.
With a 10 times larger system such as Postfix, even relatively error-free software contains a number of errors, and one has to build additional safety features into the architecture to prevent accidents from happening. Just like elevators have safety brakes that prevent them from crashing into the basement, Postfix has safety brakes that most people never notice until they are needed.
Linuxsecurity.com: Postfix is a really good Mail Transport Agent (MTA), I've been using it for a long time and I set it up for someone any chance I get. Why did you decide to write a new MTA instead of scaling down an existing MTA? :-)
Wietse: Indeed, why would anyone spend so much time writing yet another UNIX-based mail system, when Sendmail and qmail already existed? When I was looking for a programming project, neither mail system was a desirable option for me, and enough people felt the same way.
Writing a new mail system from scratch was a change from previous projects. Normally I would retrofit security features almost invisibly, either by replacing an existing server such as portmap by a hardened version that was 100% compatible, or by adding a very thin layer such as tcp_wrappers. In the case of the Postfix mail system, there was no way that the changes could be made in an invisible manner.
Linuxsecurity.com: What is your take on spam and the role the MTA plays in helping to prevent it?
Wietse: Stopping email that contains spam is not fundamentally different from stopping email that contains viruses.
In both cases, complex content analysis is better done outside the mail system. That allows people to choose the best mail system and the best spam/virus software for their environment.
And in both cases, a lot of spam or viral email comes from systems that have no business sending email directly across the Internet. These are often PCs on residential networks that have been compromised via some worm of virus, and that are under remote control by criminals that use those systems to send spam and/or to infect more systems. These rogue systems can often be recognized by the way they implement the email protocols wrongly, if not by their residential IP address.
Blocking direct mail from rogue systems is best done by the ISP that hosts those systems, but that happens rarely. The next best solution is to block direct mail from rogue systems at the receiving end, and that is where Postfix can help.
Linuxsecurity.com: In one article, I wrote about how attackers are still breaking into computer systems using well-known exploits. Any ideas on how to help instill basic security practices in administrators and vendors?
Wietse: I think that learning by example is a good way to bring the point across. This is what Dan Farmer and I attempted years ago with our white paper on improving the security of your system by breaking into it.
I have the same experience when explaining how to build more secure software. People just don't see that there is a problem until you can show good examples of software that does not do the things that it obviously was meant to do. Security problems happen when there is a mismatch between expected behavior and actual behavior.
Linuxsecurity.com: How did you get into the forensics side of computers?
Wietse: The initial motivation for getting involved with computer forensics was to reconstruct computer break-ins, so that I could prevent them from happening again. An amazing amount of information can be found after an incident. As computers become more complex, humans have less control over when and where information is stored, and how that storage is recycled when information is discarded.
Because of this it is practically impossible to erase all information about an incident from a disk, without physically destroying the hardware. Erasing all memory is difficult too, if you don't want to draw attention by crashing the system. How much reconstruction is possible depends only on the amount of skill and effort you're willing to put in.
Linuxsecurity.com: You and Dan Farmer still work on The Coroner's Toolkit (TCT). What research, seminars, or open source programs you working on in forensics?
Wietse: We just finished a manuscript for a book on computer forensic analysis that we hope will come out this year. In this book we write about things that we learned after we released the TCT. For some experiments we used the TCT, and for other measurements we wrote a few new tools. When this book is published I will be happy to turn my attention to other projects.
Linuxsecurity.com: We just wanted to catch up with you and see how things were going. Can you please give us a final statement about keeping our systems secure?
Wietse: You don't make a system secure by patching the holes - if the system wasn't built to be secure then it never will be.
Linuxsecurity.com: Wietse provided this quote:
"As long as there is support for ad hoc fixes and security packages for these inadequate designs and as long as the illusory results of penetration teams are accepted as demonstrations of computer system security, proper security will not be a reality."
Roger Schell et al., Preliminary notes on the Design of Secure Military Computer Systems, 1973. Archive of seminal security papers at https://seclab.cs.ucdavis.edu/projects/history/seminal.html
Linuxsecurity.com: Okay one last thing, where were you and who drew that caricature on your website?
Wietse: The caricature was drawn, by an artist whose name I do not know, at a conference dinner in 1997 when the Forum of Incident Response and Security Teams (www.first.org) met for its annual conference in Bristol, UK. I have supported this organization for many years, and I even had the privilege of spending more than the maximal time as its chair.
Duane Dunston is an Information Technology Specialist (Security) for the National Climatic Data Center. He was previously a contractor for STG Inc. for the same organization. He received his B.A. and M.S. degrees from Pfeiffer University and he has his GSEC certification from SANS. Hey, Ann Curry!