Investigating Advanced Security Techniques

---

You've now got a firewall, and you have a basic understanding of how to manage and maintain it. You've also got a network set up, with a few computers connected. You've realized a boost in productivity, and you've got a little more piece of mind about the security of your systems.

So, what now? This section will describe some interesting, more advanced techniques that you should now be quite capable of implementing, if you desire. With some diligence and research, you should be able to put any of these together.

Using the Tripwire Intrusion Detection System

Tripwire is an Intrusion Detection System (IDS). An IDS does just what its name suggests: It detects intrusions. This is a useful tool to have on a firewall, since it provides notification when a system is compromised and early notification is crucial to minimizing damage.

The task of intrusion detection is obviously not an easy problem to solve, and there are a variety of ways of approaching it. Some IDSs run on a separate computer on the network and monitor (or "sniff") network traffic. They watch for certain patterns in the flow of traffic that might signal an attack, using a variety of statistical and analytical methods. They can typically be configured to notify network administrators when attacks are detected. This type of system is probably most useful on larger networks.

Another approach to intrusion detection is to watch for changed files. The one thing that you're essentially guaranteed when a system is compromised is that the attacker will change files; after all, if he doesn't change any files, he can't do anything with the system he's just cracked. IDSs such as Tripwire monitor individual systems for files that change, and notify administrators when they do. Since a firewall is a server that exists for one purpose only, you don't expect its files to change very much; this means that it's a good candidate for using Tripwire effectively. Tripwire (and other similar IDSs) can't protect you from attacks, but they might help you quickly learn of compromises and minimize the damage if your system is somehow cracked.

The problem with a naive IDS is that it will notify you when any file changes on the system. You might be surprised at how many files change on a system, even a firewall server—for example, log files in /var/log, the random seed state for the random number generator in /var/lib/random-seed, the record of user logins (wtmp and utmp), and so on. As a result, a too-simple IDS will overwhelm the administrator with false alarms.

Tripwire, though, is not a naive tool, and has extensive features that allow you to stipulate which files should change, which should not, and even identify the specific ways in which a file may change (such as change in length but not ownership, as with a log file). Of course, this flexibility comes at a price: A typical Tripwire configuration is nontrivial, to say the least. Really, Tripwire requires extensive knowledge of a distribution, and to an extent knowledge of the particulars of the given installation. In other words, configuring Tripwire from scratch is too large a task to cover in this book.

Fortunately, Tripwire is an optional package included with Red Hat Linux. You can install it in the usual ways—either by installing it from scratch or by using the up2date utility. Obviously, Red Hat also includes a good default configuration for Tripwire, which goes a long way toward helping you set up this particular IDS.

If you want an IDS installed on your firewall, then Red Hat's Tripwire configuration is a good place to start. To activate Tripwire, you should install the "tripwire" package, and then consult the documentation. The package itself contains some documentation (use the rpm -qi tripwire command to see a list), and full online documentation is available at http://www.tripwire.org.

Probably the only problem you'll run into as a result of the content in this chapter is that you'll need to have sendmail installed; otherwise, Tripwire won't be able to send you email notifications. If you followed the details of this chapter, then you'll have removed sendmail and will have to add it back. If you reinstall the sendmail package, don't forget to use chkconfig to disable the sendmail server!

Tripwire (or any IDS) can be a very valuable addition to your firewall, and a boon to security. As with all such tools, though, it's not infallible or universal, so don't rely solely on it.

Integrating a Wireless LAN

A very popular feature that many people are adding to their networks is a wireless LAN based on the IEEE 802.11b standard. Typically, this involves adding a Wireless Access Point (WAP) to an existing Ethernet network. The real relevance here is to make sure that the new wireless segment of the network works properly with the firewall.

When you constructed the DHCP server configuration earlier in this chapter, you reserved an IP address for a Wireless Access Point. In most cases, connecting a WAP to your network is as simple as hooking the WAP up to your Ethernet switch. The WAP will usually bridge the wireless network to the main wired network, and computers connected to the wireless network will behave identically to computers connected to a wire. That is, systems on the wireless network will have access to the internal DHCP and DNS daemons, and will be protected by the firewall.

However, there are a few caveats for this case. First, many (if not most) of the inexpensive WAPs on the market require a Windows system for configuration. If your system is strictly Unix or Linux-based, you may have some troubles. Even some WAPs that are advertised as supporting the standard SNMP still do not have enough information available to actually make that possible. This can be either a minor inconvenience or a major headache, depending on your situation.

A larger, and vastly more dangerous problem, is that the WAP's bridging is a two-edged sword. It provides machines on the wireless network transparent access to the internal network, but this can be a huge vulnerability if misconfigured. Specifically, the 802.11b standard supports a Wired Equivalent Privacy (WEP) scheme that includes encryption of transmissions between the nodes and the WAP. However, most WAPs are shipped with this functionality disabled; even if it's enabled, it's been cracked rather completely, to the extent where it really has to be regarded as insecure. Additionally, some WAPs themselves are not highly secure beyond WEP, and can easily be hijacked by attackers.

The potential issue here is that after you've gone to all that trouble to secure your private network from the wild, wild Internet, you add a WAP and open it right up again. Maybe your neighbor notices you have a wireless network running and decides to mooch off your bandwidth (which may violate the terms of service with your ISP), or an attacker may notice your unsecured wireless LAN and decide to do some real damage.

Unfortunately, discussing solutions to these issues is beyond the scope of this book. The goal here is simply to make sure you know what you're getting yourself into. The firewall configuration discussed in this chapter will be available to your wireless network, but that can cut both ways. Make sure you do your homework on 802.11b, its WEP security scheme, and the particular WAP hardware you purchase before turning on that switch. Above all, be aware that using a wireless LAN vastly reduces your network's security. Your firewall will still protect you from typical "script kiddie" attacks on the Internet, but adding a wireless LAN will make you easy pickings for anyone who is truly motivated to attack your systems.

Enhancing the DNS Server

One thing that you'll probably very quickly notice is that if you have two machines on the internal network, they can only refer to each other by IP address. For example, if you wish to access the firewall itself, you have to refer to it as 192.168.0.1, as in this example for SSH: ssh -l root 192.168.0.1. Depending on how you use your network, this may not be a problem, but then again you might want a better solution.

One alternative is to assign common hostnames in /etc/hosts. (This file works as a sort of "mini-DNS" for the local computer, by mapping IP addresses to names.) Unfortunately, this means you have to maintain the same /etc/hosts entries on multiple machines, and it doesn't work well with dynamic IP addresses used by DHCP. A better option is desirable.

Well, you've already got a DNS server running, so why not extend that? By adding some entries to /etc/named.conf, you can instruct it to create an internal "zone" for your network. The ISC's bind server actually has a degree of integration with the ISC's dhcpd DHCP server, which makes it pretty painless to dynamically update host names when IP addresses change … once you've got it running, at least.

The main challenge is that you'll also have to create a zone file for your internal network, which can be a rather arcane process. Your best bet here is to consult the ISC's documentation on bind and dhcpd. This one might be a challenge, and it may not be worth it for a small number of hosts, but if you have more than a few computers on your internal network, you should consider it.

Booting from Read-Only Media

Suppose your firewall is compromised, and an attacker somehow gets inside. The main risk here is that she does something permanent to the system that lets her get back in whenever she wants to. However, what if the firewall's file systems were mounted read-only? In that case, she wouldn't be able to write to disk, and it would be impossible for her to do much to the system.

This involves more than just mounting the hard drive partitions as read-only, of course, because the attacker could always just remount them as read-write. What you really need here is read-only media—something that physically can't be written to, such as a CD.

Normally this isn't possible on a typical workstation or even server, because so many files have to change frequently, such as log files, spool files for printers, and so on. However, this system is a firewall, and not much changes at all. The only dynamic thing the firewall does is generate log messages—and if you've implemented the remote logger described earlier, even that doesn't get written to the local disk.

So, it's very possible to boot a firewall from a read-only medium such as a CD, and run it from there. This requires a significant amount of work, of course, and you'll have to chase down a lot of loose ends to make it work. There are tools available that help you do this, such as the Read-Only Linux work at http://www.ultimeth.net/RdoLinux/ maintained by UltiMeth Systems.

Booting your firewall from a read-only medium such as a CD or a physically write-protected disk might be a lot of work, but by now you should know the basics of what you need to do it. If nothing else, you can just treat it as an academic exercise: How would you go about doing this?

Setting Up a VPN with SSH

If the network you've set up needs to be occasionally connected to another (such as connecting to an employer's network from home), there's a good chance you're familiar with the notion of a virtual private network. A VPN is just two otherwise disconnected networks at separate locations that are connected via some kind of encrypted connection. The most popular method is the "IP Secure" (IPSec) protocol developed for the IP version 6 next-generation Internet project. However, most devices and software that support IPSec tend to be expensive, limited in functionality, or difficult to configure.

However, if you're willing to roll up your sleeves and do it yourself, you can put together a really slick VPN by using PPP across an encrypted SSH connection. Using PPP allows you to create actual network interfaces on your system, so you can do whatever routing you need to do to connect your two computers or networks transparently.

Here it is in a nutshell: You need Linux systems on both ends of the VPN "pipe", and you need root access to both. The destination machine needs to have an SSH server running. Then, you just log in to that machine via the SSH protocol (such as by using OpenSSH), and run the PPP daemon pppd on the remote end. Locally, you also run pppd and connect the two. Voila! An instant VPN. Figure 16-3 depicts this scenario.

Figure 16-3: A VPN using PPP over SSH

Of course it's not quite that simple, but it almost is. The real challenge is to connect the two pppd processes, which are running on different systems; getting them to communicate properly can be a bit tricky. What you have to do is somehow map their standard inputs and standard outputs to each other. If you hunt around on the Internet, you'll find a variety of programs in Perl or C that do this for you. However, even with these tools, you still have to physically establish the connections between the servers, meaning that you also have to automate several things.

Going into this in detail would really be getting off track for this book. However, a complete solution for a VPN using PPP over SSH automated by an expect script is presented on the web site for this book, at http://www.apress.com. If you're interested, check it out.

---