Wietse Venema is best known for the software TCP Wrapper, which is still widely used today and is included with almost all unix systems. Wietse is also the author of the Postfix mail system and the co-author of the very cool suite of utilities called The Coroner's Toolkit
or "TCT". He is currently working at the Thomas J. Watson Research Center
and he has gratiously agreed to allow us to catch up with him and and see
what he's been up to lately.
Wietse Venema is best known for the software TCP Wrapper, which is still widely used today and is included with almost all unix systems. Wietse is also the author of the Postfix mail system and the co-author of the very cool suite of utilities called The Coroner's Toolkit
or "TCT". He is currently working at the Thomas J. Watson Research Center
and he has gratiously agreed to allow us to catch up with him and and see
what he's been up to lately.
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 http://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!