AoIS Interviews Michael Rash, Part 2

Michael Rash Headshot

The Art of Information Security continues our interview with Michael Rash, Network Security expert and the driving force behind several open source security tools including PSAD, FWSnort, and FWKnop.

In Part 1 of the interview Michael discussed how he came to be involved in Network Security and Intrusion Detection system design. Here in Part 2 we get a little deeper into Michael’s philosophy on Network Intrusion Protection and discuss more open source tools that he is involved with the develop and support of.

Erik: How do you see network based attacks changing ?

 Michael: Over time, I think network based attacks will continue to be more automated and therefore accessible and deployable by more people. When it comes to educating oneself on the details of network insecurity, excellent projects such as Metasploit, Nessus, and Nmap point the way – and this is essential also for people trying to defend networks too. We will see more attacks delivered over IPv6, and we will see ever more clever ways to exploit the natural tendency of people to trust data in ways they shouldn’t. For me as a person trying to protect networks, the later is the most worrisome. A good example of a new and clever attack is “in-session phishing” as described here (Arstechnica link).

Erik: The firewalls that I run are utilized as host based protection. As you see network security becoming increasingly important, do you see the firewall “concept” become a hybrid of network protection layered over host based network controls?

Michael: With good firewall implementations (such as iptables) that do not place undue burdens on network processing that takes place on hosts, I do believe that firewalls will be viewed more and more as an essential protection mechanism for the host. The network perimeter will also continue to be an important deployment point for large firewalls to enforce global policy, but limiting the damage a successful exploit against an internal system is a problem that such an external firewall is not well-suited to address. Having a hardened network security stance on each host can provide an important benefit in this area. Further, as firewalls offer more application layer processing features, hosts can deploy customized policies that define sets of application layer data (derived from Snort rules) that are unfit for communicating with local sockets.

There are challenges though regarding managing all of those host-level firewall policies, and this is where some patience and scripting ability can play a roll.

Erik: And then came FWSnort? What were the principles that drove the development of FWSnort ?

Michael: The fwsnort project was inspired originally by the snort2iptables script written by William Stearns. This was back in the Linux 2.4 days when the string match extension was still distributed within the patch-o-matic system from the Netfilter project. Being interested in intrusion detection and firewalls at the same time, it was a goal of mine to see how far iptables could be taken in the direction of detecting (and blocking) malicious traffic. The snort IDS had a well-developed signature language, and at that time the signatures were still free and released under the GPL. So, it was natural to try and extend the snort2iptables code, and fwsnort was created.

The main goal of fwsnort is to use facilities provided by iptables to recast Snort signature sets within iptables policies. A clean translation is not always possible particularly with complex Snort signatures that use regular expression matching (because no regex engine is available to the iptables code running in the kernel), but many Snort signatures can faithfully be translated.

 Erik: Was your vision that PSAD and fwsnort teamed up as host IDS dynamic duo, or more as services that strengthen network firewalls?

Michael: Ideally I would say both here. The difference between the two types of deployments is negligible from psad and fwsnort’s perspectives – both can be deployed just as effectively against the iptables INPUT chain (for packets directed at the local system) as the FORWARD chain (for packets directed through a network firewall). The effect of not deploying host firewalls is that the outside of the network may be protected by a crunchy shell, but the inside is a chewy center. If any system can be compromised internally on such a network, an attacker is presented with few barriers to additional actions once the perimeter is breached.

 Erik: But wait – there’s more ! You are also the driving force behind FWKnop !

Michael: Thanks for mentioning fwknop. This project has received a large percentage of my attention in the last year or so. It was started originally in 2004 as the first port knocking system that added passive OS fingerprinting as an authentication parameter, but in 2005 Single Packet Authorization was added. SPA solves many of the protocol limitations that are built into port knocking (ease of replay attacks, lack of decent data transmission, and difficulty of scaling to many users), and takes the idea of “default-drop” to a new level. That is, a service such as SSH is itself made completely inaccessible before the lightweight SPA packet is passively sniffed and the firewall is reconfigured to allow access only if the SPA packet is valid. This essentially combines techniques from the IDS world (passive packet sniffing) with techniques from the authentication and authorization world (encryption and the like).

Erik: And how did the book come to be ?

Michael: I have generally tried to capture my thoughts on computer security by writing them down. In 2001 I started writing articles, and wrote a few for the Linux Journal after working with Jay Beale on the Bastille Linux project. From there, I joined Jay with writing material for Snort books for Syngress. My open source development interest has always remained in IDS and firewall technologies, so I eventually decided to write a book about the two together. The result was the No Starch book. Let me just mention here that if any of your readers is interested in writing a book, I can wholeheartedly recommend No Starch as an absolutely fantastic publisher to work with.

Stay Tuned for Part 3

Part 3 of this series is coming soon, with more discussion about network security as well as the impact that contributing to open source tools has had on Michael professional opportunities.

Cheers, Erik

 

Advertisements