Defenses Against DCAs

Current defense against DCAs consists primarily of three
components; prevention, detection, and response.

Prevention

Preventing DCAs is highly desirable, but it is unlikely to be
fully effective in the near future because the nature of modern network
services.

A primary problem is that there is a strong trend in the computing
world toward retrieval of software from remote untrusted systems for
interpretation on the user's personal computer. This makes the planting
of Trojan horses simple and provides a wide venue for their rapid
distribution. Nowhere is this taken more to extremes than in the Java
language, which is a general purpose programming language designed to
operate within a Web browser.

A secondary problem is that there are so many insecure systems
that can be attacked and used as a springboard. In a target rich
environment such as this, a sophisticated attacker can break into a
popular Web site and plant their code. Even if the attack is traced
back, the site containing this code might have been a victim themselves,
and if they have inadequate protection, it may be impossible to trace
the attack back from there.

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.

If services are denied at the router and audit trails are not
generated in the process, even though the attack on the particular host
may not be noticed, it may be effective in reducing available bandwidth.

Router or firewall-based defenses are inadequate to prevent DCAs
from exploiting a Web browser to attack internal systems. In order for
access-controls to be effective they must be set on each system within
an organization, not just on a firewall, and they must be set against
access from all internal machines as well as external machines. Setting
up consistent access controls in a substantial organization may be cost
prohibitive.

There are imperfections in some implementations that may fail to
prevent attack in sufficiently high volume and attacks against defensive
perimiters that may open inner systems up to DCA attacks. For example,
if a DCA attack is being stopped by TCP wrappers, (Wietse Venema
(wietse@wzv.win.tue.nl), "TCP/IP daemon wrapper package", Department of
Mathematics and Computing Science, Eindhoven University of Technology,
The Netherlands.) enough volume may cause the build up of so many
processes that denial of legitimate services results.

A wide area DCA attack may involve networks with authorized access
to your site, thus making access controls ineffective against that
portion of the attack.

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.

Detection and Response

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:

link:all.net and not url:all.net

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.

Close The Loop

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.

Returning Fire

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.