Automated Response

This section examines architectural issues of automated response, mechanisms available to us, and the most popular implementation—PortSentry—as well as the automated response capability of personal firewalls. Obviously, the cheapest and easiest response is the automated response. This form of incident handling should be widely practiced and, if done wisely and with care, is safe. There are a couple of gotchas we will address from the start. Because intrusiondetection systems have a problem with producing false positives, you might err and respond against a site that never attacked you. The good news is that you could take a number of passive defenses. These passive responses I describe do not cause harm. You would have to have rocks in your head to hit a suspected attacker back with an automated exploit due to the potential for error from IP spoofing and false positives.

The other problem is that if your attacker determines that you have automated response on, he might be able to use this against you. Imagine setting up the equivalent of an Echo-Chargen feedback loop involving two sites' auto-responding intrusion-detection systems and a couple of spoofed addresses. Or, at a major deadline, the attacker could target a site with spoofed attacks from its partner/customer/supplier addresses and cause the firewalls to isolate from one

another so that the deadline cannot be met.

Architectural Issues

Because network-based intrusion-detection systems are generally passive, just tapping the bit stream, they do not usually respond to an attacker's stimulus. However, many commercial implementations of intrusion detection have the capability to connect directly to the firewall and this combination allows for automated response. In fact, hogwash, a firewall implementation based on Snort, actually integrates the two functions, and there are similar commercial products under development. The DMZ or Internet connection is an obvious place to implement automated response, but there are other very effective options that include internal firewalls and the host systems themselves.

Response at the Internet Connection

The closer to your site's Internet connection that you apply automated response, the more effective it will be; but the risk of harm to the organization coming from spoofing and manipulation also rises quickly. A primary reason for this is that your Internet connection is generally unfiltered—that is, after all, where you put your firewall and filtering router. This means these devices can be hit with any possible address (spoofed or not), 65,535 TCP ports with any number of flag and options combinations, 65,535 UDP ports again with options, ICMP, fragmentation, and all of the IP protocol types. This is a lot of space to defend against. Now a "deny all that is not specifically allowed" policy will prevent the overwhelming bulk of these possibilities from penetrating your perimeter, but the risk comes when we try to interpret all this using an automated policy. The bottom line, though, is that in the face of a rapidly increasing threat, and with the need to respond in the time it takes to evaluate a single packet, automated response is probably going to be widely implemented. And because you get the biggest bang for your buck by putting the capability near the Internet connection, we will probably continue to see solutions like hogwash and Tippingpoint's UnityOne (www.tippingpoint.com).

Internal Firewalls

Automated response using internal firewalls is much safer because the traffic an internal firewall receives generally is at least partially filtered. Also, you know your policy better. If you are defending five machines or so with your internal firewall, you have a pretty good idea with whom those hosts should be talking and on what ports. Of course, the catch is the automated response covers a lot less area. And there are cost issues both for hardware and software and

also administration. The good news is a number of appliance and near-appliance devices need almost no configuration. The DSL and cable modem revolution has created a huge market for these, and there are a number of options including appliance products from Cisco, Linksys, Netgear, and Symantec. I really like the little $500 PIX, but try putting your hands on one; they seem to be permanently sold out. Because Network Address Translations (NATs) are so effective at preventing attacks and the lower end devices run about $250, there is no reason not to deploy them throughout your organization. If people do widely deploy boxes like that, I might have to find a new line of work. In fact, I am already working on my delivery: "Would you like a hot apple pie with that order?"

Host-Based Defenses

Automated response on the host is clearly where you get the minimum bang for the buck, but this is widely practiced, and the risk from spoofing is much lower than a perimeter solution. The industry trend is twofold: internal appliance type firewalls and host-based firewall defenses. A number of people, especially in university environments, depend entirely on software such as Psionic's PortSentry for their UNIX systems. PortSentry blocks an offending host from making any further connections and even drops the route so that the host cannot get back to try again. The PC world has a large number of personal firewall solutions. Because this is an automated response chapter, we should mention the amazing BackOfficer Friendly, www.nfr.com/products/bof/index.html. This is far more than a personal firewall! Perhaps we could consider it a honeypot or even an active defense solution. If you have a Windows system and want to get started learning about automated response, download this and give it a look. The only downside is that it hasn't really been updated as the threats increase. Imagine what would have happened if they had managed to incorporate LaBrea technology early in the Code Red days! The good news is these host-based defense systems are very effective, becoming more prevalent, and are fairly easy to install, configure, and maintain. Why do people depend so heavily on these programs? Often, they are security-conscious administrators at sites with no filtering from the Internet whatsoever! There are four main sources for unfiltered addresses:

●Cable modems and DSL

●Commercial organizations that don't care

●Universities in the name of academic freedom

●Connecting while on travel such as at an Ethernet equipped hotel

The cable modem and DSL world is going to be an ever-increasing threat to site defenders, so maybe I don't have to worry about pushing hot apple pies on the fast-food drive-through after all. I have instrumented a number of cable modem connections and tend to receive between about 5 and 20 probes per day. Hundreds of people are hooking up to cable and DSL everyday, and most of them have unprotected systems. This is something we became very aware of in 2001 with Code Red, nimda, and Leaves. Most cable modem style defenses such as NATs and host-based firewalls do not implement automated response; but it isn't a bad trade: intrusion protection for intrusion detection.

Commercial organizations that are inept or don't care and connect to the Internet will not survive the transition to an information economy.Yet, a surprising number of sites either do not have a firewall or have inadequate perimeter protection. When you connect your organization to the Internet, you will be probed and tested. If your systems are not combat ready and can be seen from the Internet, they will fall. If you are lucky, you get the playful sorts of attackers, but even then your system will likely be used to attack and probe others. A commercial organization with a compromised system could share a far worse fate if the attackers decide to use it to acquire corporate secrets. As we suggested earlier, if I were in business, in addition to a main firewall, I would strongly consider the use of internal appliance type firewalls. After you get inside the perimeter of many facilities, they have neither detection nor protection capability. Key hosts would do well to have system level protections.

The interesting battleground that I have been watching for several years is the university world. Many of these sites have no firewalls or filtering at all. Already, I have seen departments set up their own firewalls in universities that don't want to put one at the front door. And, system protections are popular with proactive administrators. A fully open Internet connection is an archaic and brain-dead throwback to academic freedom, and I doubt the practice will survive another four years. It will be fun to watch. The academics that claim all packets must be free to travel the Internet will probably back down soon enough. Just wait until their department's budget suffers a 50 percent cut due to the university losing a major lawsuit brought by a dot.com that lost significant revenue when the university's systems were compromised and used in an attack.

Connecting while on travel requires a bit of thinking. I often carry a small Linksys router hub with me, so that I have two layers of defense: the NAT and my personal firewall. Also, it allows my wife and I to be online at the same time; when you are used to being online for 14 hours a day, you aren't very good at taking turns to check your mail. The NAT allows me to mitigate the risk to my relationship and my important documents—what could be sweeter?

I understand that you might have reservations about implementing automated response. I try to set things up in class and show a number of intrusion detects from December 24 and 25 and comment that Christmas is a special time of the year. Then, when we come to the automated response discussion, I point out that during the Christmas and Easter vacations people are normally not around, but systems are still up. This can be an excellent time to experiment with automated response at the Internet connection. Because very little work is getting done, especially at Christmas, this is a fairly low-risk time to take your automated response systems out for a spin and see what they are capable of.

Next, let's work through our response options. It is a good idea to keep in mind the previous

discussion about where the analysis and response functions are best accomplished.

Throttling

This is a smart response to port scans, host scans, SYN floods, and mapping techniques. The idea is to begin to add delay as a scan or SYN flood is detected; and if the activity continues, continue increasing the delay. This can frustrate several script-driven scans such as ping mapping to 0 and 255 broadcast addresses because they have to rely on timing for the UNIX/non-UNIX target discrimination. Enterasys and Cisco both have rate limiting. In fact, any device you can interface with that supports Quality of Service should be usable in this fashion. Throttling can also be done at the protocol level. For UDP, the IDS could forge a source quench. For TCP, if the traffic goes through a proxy firewall, the outbound interface could send a small window size. I would avoid using the LaBrea trick of a window size of 1. Attackers will be looking for that next time around, but 5, for instance, will drastically slow down the attack.

Drop Connection

Dropping the connection is straight out of the string-matcher handbook. When I say "connection," of course I am talking TCP primarily, but the same general effect for UDP can occur using a shun (as discussed in the next section).

The attacker establishes a connection to an active port. Then he sends the packet, or packets (for intrusion-detection systems such as Cisco Secure IDS or Snort with packet re-assembly capability), that contains the attack string, or exploit. This is the point of great danger for a vulnerable system. The IDS detects the string and orders the firewall to drop the connection. Now, you might have a compromised system, but the attacker can't make use of the compromise directly. In the case of a buffer overflow, the victim computer is now running whatever code was beyond the command length and is probably running it as root. If it is a grappling hook type program (a small telnet daemon running on some predefined port), dropping the connection might only buy you a few seconds.

Shun

I am going to continue the attack just described with the shun technique, and then discuss why shun might be one of the most important automated and manual techniques at your disposal. As the attack progresses, you have a new process running as root that has opened up a telnet

daemon or sent back an X Window or whatever open door into our victim system the attacker has chosen. Dropping the connection does not help, because he is already planning to initiate another connection; or in the case of an X Window, you have initiated the connection to him from our side. Shunning might buy some relief. When you shun, you do not accept any more traffic to or from the offending IP address. This is a good technique and can be executed on just the offending host or on its subnetwork. A capability to look for whether you want to implement shun is a "never shun" file (also called a white list); you can place the addresses of your customers and suppliers in this file. This protects you from an attacker being able to spoof these addresses with some obvious script kiddie attack just to isolate you from the systems you do business with.

Shunning does not help you if the attacker is using two address families, which is fairly common. My friend Pedro Vasquez sent me a trace from Brazil with a DNS buffer-overflow coordinated attack that did exactly this. The attack came from one host and the X Window was displayed to another host. Just because shunning does not help you in every case, however, doesn't mean you shouldn't employ the technique.

Proactive Shunning

It turns out that a number of Internet service providers and even whole countries cannot, or will not, manage their hosts. Over time, as you have been doing intrusion detection, you come to realize that an incredible number of the attacks that you and your friends deal with (you are sharing data, right?) come from the same network addresses. Why play with fire? Eventually, they will find a way to burn you! Block them. Let me take this a step further: be willing to block them at the two octet or 16bit mask. Be willing to block a whole country. Nobody is getting arrested for hacking, and it doesn't look like that is going to change any time soon. If countries that will not control their "research networks" start to be marginalized and are unable to reach large parts of the Internet, however, they will have to come to the table and talk turkey.

We have been experimenting with this on the SANS web server, and one single ISP that has open proxies has been the source network of more attacks than any other address group. We shunned them for about two months; they wrote and made promises, so we let them back into the site and within a day, we were attacked again. We are considering a permanent ban at this point.

Islanding

Islanding is the auto-response of last resort. The idea is, if a sufficient number of attacks occur over a time period (usually during time periods during which no analyst is on duty), the intrusion-detection system sends a command to an X10 or similar logic-controlled relay and drops the power to the router. The result of this is isolation of the site from the Internet. Although there is serious potential for a denial-of-service condition, this can be a reasonable strategy for three-day weekends at high-security sites. This capability can be hacked together with a few lines of code with any intrusion-detection system that issues SNMP traps. On second thought, maybe that SNMP trap idea is not so smart. Automated response does have a risk of self-inflicted denial of service. Only do something like this if you are willing to have the deadfall

occur on any given "red-alert" alarm condition.

SYN/ACK

Suppose the intrusion-detection system knew the ports that a site blocked with its firewall or filtering router. Further, suppose that every time the IDS detected a TCP SYN packet to one of these blocked ports, it answered back with a forged SYN/ACK. The attackers would think they were finding lots of potential targets; however, all they would be getting is false positives. If you think about it, the latest generation of scanning tools has caused a lot of problems for the intrusion-detection community with their decoy capabilities. This would be a great way to answer back. I finally got to see this in action. Some friends of mine got a Raptor firewall. This works great. The attacker completes the three-way handshake and thinks he has a victim. He