Interview with Michael Rash, Security Architect and Author of "Linux Firewalls"
by Mirko Zorz - Monday, 12 November 2007.
There are still areas that need improvement:
  • Linux distributions (you know who you are) that under most deployments install as much software as possible and start up all sorts of services by default aren't helping the state of Linux security. Of course, there is a tradeoff between making a distribution functional vs. making it secure, but it seems as though more emphasis should be on the "secure" part.
  • Educating users about security, especially network and host security monitoring principles, is important and good information is available. I highly recommend Richard Bejtlich's book "The Tao of Network Security Monitoring". Also, education is a primary goal of the Bastille Linux project.
  • Fundamentally, achieving a high level of security requires that bugs be removed from software, and this means that strong source code review by knowledgeable developers is important. The best example I can think of for an operating system that builds this process into its core is OpenBSD.
You work on various security projects, which one is your favorite creation? Why?

My favorite project is "fwknop" (the FireWall KNock Operator) because I feel that it is hopefully the most innovative. So far, I don't think the security implications of Single Packet Authorization as implemented by fwknop (basically next generation port knocking on steroids) have been fully realized by the security community. An analogy can be drawn here between the evolution of email communications and the evolution of access control devices. Today, the effectiveness of email is being undermined by the pervasiveness of SPAM, and so mechanisms such as Bayesian filters and the Sender Policy Framework are commonly used to cut down the rate of unwanted email. The result is that email as a communications medium is becoming more restricted in order to minimize the effects of malicious traffic. In some cases, people even reject all email except for certain whitelisted addresses. This situation is similar to how network access control devices and firewalls became important to restrict access to services from an increasingly hostile and untrustworthy network. SPA does for network services what whitelists do for email. The difference is that SPAM can just be deleted, whereas a compromise of a system because a service was accessible from a malicious source is much more damaging.

SPA is certainly not a silver bullet and is not suitable for many services or network deployments, but using it to secure SSH communications is one area where SPA excels. Many people focus on password cracking attempts through the SSH daemon, and apply thresholds via log monitoring scripts to implement things like "if an IP address has N failed logins within 60 seconds, then automatically firewall off the IP". The problem is that while password security is important, exploiting a software vulnerability rarely has anything to do with finding a weak password. The Gobbles challenge-response exploit from 2002 proved that OpenSSH could be remotely exploited, and there is no password guessing anywhere in sight. The actual vulnerability has of course long since been patched, but a random glance at the Securityfocus vulnerability tracking database shows that there have been recent security issues in some of the latest versions of OpenSSH. This is not meant to pick on OpenSSH; security is really hard, and a defense in depth approach is needed.

The real problem is not about password cracking; the real problem is that SSHD is accessible from arbitrary locations around the globe. Why should some random IP have the privilege of scanning for SSHD, seeing that it is accessible, and then be free to try an exploit (perhaps a new 0-day) against it? If you know that you only need to access SSHD from a limited set of IP addresses, then it is easy to write a firewall policy around these addresses, but what if you are on travel? This is where SPA comes in by maintaining a default-drop firewall stance for all SSH communications. Then, by passively sniffing for specially constructed (that is, encrypted and non-replayed) packets on the wire, the default-drop firewall policy is modified to allow an SSH connection. Details can be found in my USENIX ;login: paper "Single Packet Authorization with Fwknop". There are also two chapters in the book about port knocking and SPA.

What's your take on projects such as IPCop and Sentry Firewall?

Providing an easy to use Linux firewall to the masses is important, and I think IPCop goes a long way to accomplishing this. It looks as though development on Sentry Firewall has stopped, but the goal of the project - a bootable Linux CD that turns your system into a ready-made firewall and IDS - is a great concept. It allows anyone to try out a Linux firewall essentially for free on commodity hardware.

The knowledge barrier to deploying security technologies should be made as low as possible, and this means that ease of use is paramount. Also, not everyone is familiar with Linux as a network security technology, so projects like IPCop and Sentry Firewall help to increase exposure of Linux in this scenario. Finally, I wish to add that IPCop also provides a good firewall solution, and it is compatible with psad (discussed extensively in the book).


Harnessing artificial intelligence to build an army of virtual analysts

PatternEx, a startup that gathered a team of AI researcher from MIT CSAIL as well as security and distributed systems experts, is poised to shake up things in the user and entity behavior analytics market.

Weekly newsletter

Reading our newsletter every Monday will keep you up-to-date with security news.

Daily digest

Receive a daily digest of the latest security news.

Mon, Feb 8th