Current defense against DCAs consists primarily of three components; prevention, detection, and response.
Preventing DCAs is highly desirable, but it is unlikely to be fully effective in the near future because the nature of modern network services.
One effective defense for sites that don't allow remote access from anywhere is to refuse service to sites that aren't authorized for that particular service. This does not necessarily prevent a DCA, and in fact may help to mask it.
Another approach is to prevent services that are known to participate in DCA attacks. Unfortunately, this currently includes FTP servers and Web browsers as well as any service offering URL-based descriptions of services. Since this represents the majority of current Internet traffic, it is unlikely to meet with widespread acceptance, however, there is at least one case where this prevention technique has proven highly effective. That is the case of spams from mailing lists.
In the case of a mailing list spam, the attacker uses a mailing list as the vector for attack. By signing the victim up to a mailing list, the attacker obscures the relationship to the attack and causes high volumes of undesired mail to be sent to the victim. Fortunately, there are only a finite number of mailing lists on the Internet, the bulk of the mailing lists are managed by only a few hundred sites, and mail from most mailing lists comes from an address that is relatively easy to identify. As a result, it is possible to prevent mailings from more than 10,000 known mailing lists by blocking inbound mail that matches any of a list of only a few patterns. (For example in the ManAlMail package, a highly successful filter consists primarily of scanning for the patterns owner- and -owner in the From address and rejecting all such mail before the content is transmitted. Accepted mailing lists are explicitly listed before this rejection filter. Such a defense is in use at some Internet sites and is supported by some of the more advanced mail handling programs.
A third approach to prevention would be to enforce limitations on the software that implements these services. Unfortunately, many attempts to do this by companies including Sun and Netscape have failed repeatedly despite substantial time and effort. As these companies become more aware of the complexity of protection, they are improving, but to date, no Web browser is free of these problems, and almost all ftp servers are still vulnerable. There are likely many other examples of such vulnerabilities that are yet to be discovered. In essence, today's environment has deeply embedded design flaws that make DCAs possible. The current trends in computing make it highly likely that these flaws will be extended and enhanced, making prevention even more difficult and less likely.
If prevention is unlikely in the current and coming networking environment, the next logical approach would probably be detection and response. It turns out that detection of high volume DCAs is very easy, but that the implication of DCA detection and response creates a social challenge that must be met.
One simple detection method that picks up high-volume DCA attacks is a threshold scheme. By setting a threshold on the total number of anomalous behaviors in a given period of time, such attacks become clear immediately. Unfortunately, all threshold schemes suffer from the weaknesses of false positives and false negatives. The false positives come when non-DCA events cause a detection. The false negatives come when a DCA attacker throttles back the attack to remain below the detection threshold.
A common example of a threshold scheme is the detection of three failed login attempts from any given site in a period of a few weeks. Unfortunately, the Internet has millions of sites that can be used to launch DCAs and it is a simple matter to remain below this threshold while launching a very serious attack.
As far as we can tell, the only way to reliably track down a DCA is by coordinating audit trails between a set of sites that form a complete path between the attacker and the target. If the number of attempts per site is small, this means that administrators at other sites must be willing to track down the full details of as little as a single message being sent from their site to another site, and they must also be able to track down the site that their user was using at the time of the incident. If a DCA is created with even a few minutes of delay between being loaded and exploited, the audit tracking problem may be multiplied dramatically for each intermediate location because there may be a large number of possible sources over the time window.
This form of community response creates very serious social challenges. In the Internet, there are a substantial number of sites where administrators either don't care about what their users do to other sites or where a single attempted entry is considered unworthy of investigation. The challenge is to find a way to convince the other administrators to give assistance without having to personally contact each of them one-at-a-time as the attack rages. When we were under attack, our automated response system sent mail to each site.
Several sites complained vigorously about being contacted. We became quite concerned, but as we investigated, we found evidence in the audit trails that most of the sites making complaints had read about the attack on our site and then attempted to enter in order to generate the warning message just so they could complain. As we looked further, we found evidence that some of these administrators were collaborating with others in a joint DCA.
Another interesting defense against simple Web-based DCAs was proposed by an administrator in The Netherlands. He had the idea of exploiting Internet-based search engines to track down attackers. It turns out there are a number of search engines that use automated programs to search large portions of the publicly accessible areas of the Web. They collect millions of Web pages each day and provide remote capabilities for searching the entire Web for the information required. The results are presented as URLs that point to the Web pages that match the search criteria. The suggestion in our case was to search using the Altavista.Digital.Com Web-based search engine for:
This gives you a list of about 400 locations in the Web that refer to our site (all.net), and leaves out all links on our own site. Unfortunately, there is an average lag of about 3 months between the introduction of such pointers and their inclusion in this search process.
We have discussed the fact that most current DCAs are open loop attacks, and this leads to a defensive strategy with some promise. Instead of trying to prevent entry, some sites allow limited entry and try to exploit this in their defense. For example, by simulating an entry, capturing the details used to send the notification back to the attacker, and waiting for the attacker to reenter, you may be able to track down all but the most sophisticated attacks intended to gain reentry.
Unfortunately, not all attacks require reentry, nor is it always easy to track the source even when you are observing a perpetrator in action. A common attack in the Internet today is designed to deny services. In this sort of attack, the attacker never closes the loop. Another technique is to use anonymous postings to send commands to the planted Trojan horse as well as to get results back. Nevertheless, this technique may help in tracking down the sources of some attacks.
It has often been said that the best defense is a good offense. If the source of a DCA can be identified, and if all other attempts at stopping that attack fail, the only effective response to a DCA may be another DCA. We do not advocate such action except in extreme cases, however, it is important to note that most DCAs seen in the real world have been traceable to a source and that in cases where no assistance is available from the attackers side, there may be no other viable response option.