Absorbent Perimeters

For years, the primary advance in perimeter security was the silent drop, where a probe was dropped without a response, such as an ICMP administratively prohibited message. Today, it is possible to construct perimeters that are even harder to probe from an attacker's point of view than these black-hole-style systems. Chapter 10 discusses a number of host-based firewalls, including SunScreen and Psionic PortSentry. One such host-based firewall that remains a bit ahead of its time is NFR's BackOfficer Friendly (http://www.nfr.com/resource/backOfficer.php). This technology incorporates a kind of active defense. If the attacker is scanning for a web server, NFR's BackOfficer Friendly provides a valid HTTP response. It answers to Telnet requests or even Back Orifice pings. The logic is to keep the attacker off base. Raptor firewalls have a similar capability at the perimeter. These devices, possibly in conjunction with the occasional silent drop, make reconnaissance a more challenging proposition for attackers. Other technologies we can employ to create a perimeter that is able to absorb attacks include honeypots, rate limiting, and failover.

Honeypots

One early example of a honeypot was the deception toolkit (DTK) developed by Fred Cohen and available from his website (http://www.all.net/dtk/dtk.htm). DTK was a state machine written in Perl that made it possible to emulate almost any service. The software came preconfigured to emulate about 20 network services, including a Telnet written in the C language. NFR's BackOfficer Friendly, which we just discussed, can also be considered a state machine. It is a honeypot as well as a personal firewall. Such technology has two major advantages for the organization that deploys it. It tends to tie up the attackers' resources as they are burning their time and effort against the honeypot, and it provides you with information about what the attackers are trying to do.

The Internet Storm Center (ISC) depends on honeypots to capture malicious code, after they determine it is running, by large changes in the destination port number of traffic. In this case, the honeypot is the actual Windows or Linux operating system with a weak security model so that it can be infected. This is an alternative to the state machine approach. The state machine is advantageous because it is unlikely that an attacker can break out of the state machine and use the honeypot to attack someone else. The native operating system is advantageous because it becomes a thousand times more difficult for the attackers to figure out they are dealing with a fake system.

No discussion of honeypots is complete without mentioning the Honeynet project (http://www.honeynet.org/), championed by Lance Spitzner and a number of security researchers. The Honeynet project continues to add to our understanding of attacker techniques and motivation. Today, the Honeynet Alliance is available for organizations interested in fostering research about honeypots. The Honeynet Alliance tends to use actual operating systems for its technology; the original Honeynet was an actual network with firewalls, targets, and an IDS. Today, through the magic on VMware, it is possible to simulate an entire network using only a single computer. This solution is much cheaper and less complex, and it might allow the defensive community to deploy more honeypots. There is also Neils Provost's excellent honeyd, a free software solution that is rapidly becoming the honeypot of choice. More information is available at http://www.honeyd.org/.

Should your organization consider a honeypot? It is an advanced technique. If you already have your perimeter functioning well, an IDS collecting data, and host-based intrusion detection on at least the critical systems, a honeypot might be a next logical step. A honeypot can be deployed on the screened subnet or DMZ as a third DNS server, an FTP server, or any other server. Also, it would draw fire and not be obviously out of place. A honeypot might be the only way to actually capture the full attack if the perimeter is knocking down the traffic. As defenses advance and defenders consider automated response, this technology can be used to help assess threat. Originally, the primary auto-response capabilities were to drop the connection, forge a reset to knock down the attack, and shun the attacker's IP address. Each of these has drawbacks, and a significant potential exists for self-inflicted DoS. Nevertheless, as the attacks we face become ever more sophisticated, auto-response must be considered as a defense-in-depth tool.

In addition to the types of active response we have discussed in this section, another tool to consider is rate limiting.

Rate Limiting

Rate limitingmanaging the amount of bandwidth granted to a connectionwas developed for Quality of Service (QoS) reasons. Throughout the history of networking, we have had to deal with various degrees of service and capability. Researchers have long proposed various QoS solutions, including buffering, advances in queuing theory, and protocol advances. These are primarily for performance, especially with services that do not react well to changes in throughput, such as streaming audio or video; however, QoS solutions offer fascinating possibilities for creating perimeters that absorb attacks as a defensive methodology. Like any other auto-response, these techniques come with their own problems and dangers, but they are worth considering, especially to buy time to evaluate and respond to an attack. The primary advantage is to avoid tipping our hand to the attacker whose activity we have identified. Rate limiting is similar to the active response and honeypot-style defenses. Also, if we do accidentally target the wrong host with our active defense, we do less damage because we slow the attacks down more than stopping them. The three possible ways to implement rate limiting are in the network switch we control, in effective use of the protocol, and at the application.

Network switches are rapidly becoming more sophisticated, and QoS is available in off-the-shelf products, such as the Entarasys switch. If the IDS detects an attack, it can simply begin to modulate the available bandwidth to the attacker. This might be a security option that managed service providers could deploy. You can't have a conversation with someone in this business for five minutes before you start hearing a story about a customer who made a change without informing him or her, setting off the security alarms and whistles. Not all switches support rate limiting, but there are some fascinating things that we can implement with existing and emerging protocols.

If an attack were UDP based, it would be simple for the perimeter defense mechanisms to issue an ICMP source quench message. This tells the sender to slow down. You can modify the performance of a TCP connection in several ways. If the other side is Explicit Congestion Notification (ECN)capable, we can send a congestion message and ask the sender to back off. Even if the attacker does not run ECN, we can take a page out of the LaBrea work done by Tom Liston and send an initial response with a small TCP window size and then set it to zero from time to time to keep the attacker from sending data.

These first two approachessetting a limit using hardware, such as a switch, or ICMP source quenchcan easily be set in motion by an IDS as an auto-response, and there have been applications of both. One simple example at the application layer is when a user mistypes his password several times. The response can be to slow down the rate at which the system tells the user that the password is incorrect. We can also consider defense at the application, although this will not be practical until we start using better practices in coding. That said, it is worth noting that the software application might be the best place to detect and respond to certain attacks, such as illegal values and buffer overflows. It would be interesting to see Sendmail and named implementations with a built-in defensive capability. Named, for instance, could trivially identify attempts to use the obsolete query class CHAOSnet. It could send an alert to the defensive systems, respond by delaying the answer, and then possibly transmit a BIND version number that would send attacks down the wrong path, such as 4.9.1, an ancient version of BIND. If such technology does become available, it certainly would help us implement defense in depth.

In this section of the chapter, we have considered several techniques for implementing perimeters that are more flexible than the standard border router firewalltype perimeter. None of these techniques should ever be used in lieu of those technologies, but they can supplement and enhance our perimeter defense. One of the critical issues in a perimeter, of course, is uptime or availability, and one of the most important technologies to help us achieve this is automated failover.

Failover

Failover is the practice of maintaining a hot standby and transferring operations to the standby if the primary fails. When you're considering purchase requirements for firewalls and other perimeter devices, one crucial capability is failover. Many commercial and freeware products and designs seek to balance security and degree of polling, usually through Hot Standby Routing Protocol (HSRP), maintaining NAT tables and connection state, as well as load and performance balancing. If you plan to implement failover, buy all the firewalls at the same time and maintain strict configuration management so that they have the same patch level at all times to avoid problems.

Failover products are dynamic by nature, but it never hurts to ask the manufacturer's technical representatives if it is possible to deploy their products in a failover mode that allows both failover and static routing between the secure or intranet sides of perimeter devices. Static routing helps you avoid the risk that the compromise of a single router could lead to the manipulation of the organization's dynamic routing tables. If an attacker can manipulate the routes, he can cause traffic to pass through an arbitrary IP address he controls. The security mechanism for routing tends to be a password or an MD5 hash, which is not considered fully robust. Passwords can be sniffed, and although MD5 is a strong security mechanism, cryptographic experts have asserted that the implementation for routing was hastily done and is not perfect. Static routes are read from a table; therefore, even if a router is compromised, as long as the remaining routers do not accept ICMP redirects or router discovery messages, they and their routes will remain intact.

Maintaining near 100% uptime is great, but it also means that a failure in our security design, process, or procedure results in our precious information leaking all the faster. Next, we will consider defense in depth with information, covering the problems and some of the solutions we can employ.