[Dshield] Analyzing DShield data for indications of possible problems?

Bruce Lilly blilly at erols.com
Fri Jun 28 16:08:12 GMT 2002


> From: "Ed Truitt" <ed.truitt at etee2k.net>
> Date: Thu, 27 Jun 2002 09:14:18 -0500

> Specifically, if we could establish a baseline which represents the
> "normal" level of scanning activities, then we could let the
> computers analyze data as it was gathered, and look for
> "statistically significant" events - those which deviate from the
> norm enough that they indicate that something has changed.  After
> all, we know that Port 80 scanning activity will drop off around the
> 20th of the month, them pick back up around the first, as this is the
> default behavior for CR/Nimda.

I wouldn't consider Code Red and/or Nimda to be "normal".

In fact, as a single-IP dialup site forbidden from running a
publicly-accessible server by ISP TOS, I consider *any* probes
abnormal.

> DShield.org has the data.  Does anyone else see value in approaching
> scans/probes/hacktivity from this perspective (process control)?  It
> seems to me to be a better approach than people asking "have you
> noticed...?".

Several potential problems with such a scheme:
1. If a hacker does testing over a limited range of IP addresses,
    the preliminary recon will get lost in the noise, so you won't
    see any effect until the actual exploits hit.
2. Likewise, an exploit designed to spread slowly may be able to
    "fly under the radar" of such a scheme, since there wouldn't be
    a sudden jump in activity.
3. Policies differ. As noted above, sites with a "reject anything
    that is not explicitly allowed" would consider many more probes
    as abnormal than an "anything goes" site. A "one size fits all"
    approach in fact probably won't fit many sites' needs.

FYI, my recent query about port 113 probes turned out to be related
to a sendmail configuration change which resulted in directly sending
mail to the destination's MX host rather than relaying via my ISP's
SMTP server; most of the port 113 activity came from overly-nosy MTAs.
And I still consider port 113 connections unwelcome, due to known
security exploits and to privacy issues.







More information about the list mailing list