It took me about two and a half years to write the book, which was slower than I had anticipated. Some books are harder to write than others I suppose, and the most difficult part about this book was the simultaneous software development that I needed to do in support of some concepts I wanted to present. So, writing the book resulted in new features implemented in all three of psad, fwknop, and fwsnort. For example, here are a few of the features added throughout the course of writing:
- Support in fwsnort for Snort rules with multiple application layer content matches.
- Support in fwknop for sending SPA packets over the Tor network.
- Support in psad for creating visualizations of iptables logs by interfacing with Gnuplot and AfterGlow.
Intrusion detection systems and firewalls commonly offer the ability to tear down TCP connections by forging a RST packets, but the specifics of how this is done varies quite a bit across different IDS and firewall implementations. The most interesting fact I stumbled across during my research concerns differences in the handling of the ACK control bit on RST packets. For example, the iptables REJECT target implements an inverse relationship between setting the ACK bit on a RST vs. the packet that causes the RST to be generated. So, if a packet has the ACK control bit set and this packet is processed by iptables and matches a rule with the REJECT target, then the resulting RST packet coming from the Linux kernel will not have the ACK bit set. In contrast, the Snort "react" detection plugin never sets the ACK control bit on a RST regardless of whether the packet that causes the RST to be sent has it set, and both the "flexresp" and "flexresp2" detection plugins always set the ACK control bit on a RST. The REJECT target more closely emulates the behavior of a real TCP stack.
In your opinion, what are the most important things a Linux administrator has to do in order to keep a network secure?
Beyond the canonical tasks of deploying a restrictive firewall policy, making sure systems have the latest security patches applied, and educating users, it is important to recognize that security is a process. Applying security monitoring principles both at the host and network levels helps to catch suspicious activity early and provide time to do something about it. Deploy a good network IDS such as Snort, and use Nmap and Nessus regularly on the network to look for changes in how software is deployed and watch for new exploit paths. Consider running iptables on every Linux system; the burden of running iptables from a management perspective can be quite low considering the easily scriptable interface to iptables commands. If you have enough spare cycles, deploying SELinux can limit the damage from a successful compromise.
One area that is often not given enough emphasis is the client side exploit. All of the nice filtering provided by strong firewall policies means little when web connections are allowed out, and if a high profile website is compromised and serving up malicious code, then many internal users could be affected. With the complexity of web applications and encoding schemes, even proxies and inline IPS can be insufficient to detecting such exploits. Paying special attention to client-side vulnerabilities (particularly in web browsers) should be an integral part of a security administrator's efforts.