Recently I had an opportunity to speak with Daniel Swan, author of the comp.os.linux.security FAQ. Daniel announces his FAQ after spending the last several months writing and researching the information necessary to provide a Linux administrator with the information necessary to secure his Linux box.
LinuxSecurity.com: Why did you decide to write the FAQ?
Daniel Swan: During the course of my participation in comp.os.linux.security, I saw many of the same questions being asked, questions that were often Linux specific, and not covered within other security FAQs.
LinuxSecurity.com: Who are your target audience and why?
Daniel Swan: The FAQ is geared towards intermediate to experienced Linux users. They are in a much better position to understand the issues discussed within the FAQ, and to properly implement the solutions necessary.
There is a section geared towards those who want to harden their home box without immersing themselves in the painful details of Linux security. It essentially says "Keep your patchlevels high, and shut down unnecessary services".
LinuxSecurity.com: How did you get started with Linux and security?
Daniel Swan: Well, my first adult exposure to computers was AIX, while at university, which I instantly fell in love with. The combined complexity, power, and arcane feel of Unix really spoke to me. Several years later, I learned that I could have Unix at home and for free, and downloaded Slackware. After Slackware, the next step was Red Hat.
My interest in security was born of necessity. My house server was remotely rooted, which really annoyed me. Determined to not let it happen again, I buried myself in Linux security for several months, reading all I could, and participating in comp.os.linux.security.
LinuxSecurity.com: What are your future plans for the FAQ?
Daniel Swan: Kernel 2.4 is going to open up a whole new kettle of fish, as will the recent release of dsniff. Many of the firewall configuration statements will need to be updated to include syntax for the new iptables. Things are changing so fast, it will be enough of a challenge just to keep the FAQ up to date.
I also want to cover backup and mirroring methods in future versions of the FAQ. Solid backups are quintessential to the security of a system. This is painfully overlooked these days, with the focus so much on the network component of security.
Also to be covered is encryption, such as PGP, GPG, or filesystem encryption. I'm not happy with these sections to date, and they were cut from the present version of the FAQ. Also covered will be logfile monitoring tools and methods.
LinuxSecurity.com: What are some of the major pitfalls Linux Administrators fall into? How can your FAQ help to avoid these problems?
Daniel Swan: I believe that the greatest pitfall a Linux Administrator could make is to assume that their box is completely secure, and the second greatest pitfall is to fail to keep current backups. I have been bitten by both. I also feel there is an overemphasis on the minutiae of computer security by many Linux Administrators, without understanding security in a holistic sense.
My goal in writing the FAQ was to impart an understanding of some of the conceptual issues surrounding computer security, and to facilitate and encourage further learning.
LinuxSecurity.com: What do you feel is the most common Linux system vulnerability? What can be done to prevent this?
Daniel Swan: Well, the vulnerability du jour changes so frequently, it would be a disservice for me to suggest that readers protect themselves against a single particular sploit or vulnerability. They would be much better off to learn the practices of good computer hygine, such as keeping patchlevels current for their distribution, minimizing network services offered, using strong passwords, etc, etc, etc. Good habits of this nature will serve not only to protect them against known threats, but also against those that have not yet made it to Bugtraq.
LinuxSecurity.com: Do you believe the open source nature of Linux provides a superior vehicle to making security vulnerabilities easier to spot and fix?
Daniel Swan: I do. However, to make full use of this, Linux must yet come under the intense scrutiny of a collective code review of not just the kernel, but supporting applications, such as has been done with OpenBSD.
I think there's room here for another Distribution which does this, which by necessity will always be a couple of steps behind the latest and greatest release, but can offer greater security in a default installation.
LinuxSecurity.com: Thanks very much for the opportunity to speak with you, and wish you all the best.
The comp.os.linux.security FAQ and other authoritative Linux security documents can be found in our documentation section.