Re: [Asrg] Re: Bots

Douglas Otis <dotis@mail-abuse.org> Tue, 17 January 2006 21:41 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyyaE-0000Hj-Mi; Tue, 17 Jan 2006 16:41:42 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyyaC-0000Gn-JM for asrg@megatron.ietf.org; Tue, 17 Jan 2006 16:41:40 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27113 for <asrg@ietf.org>; Tue, 17 Jan 2006 16:40:10 -0500 (EST)
Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyyiK-0001t6-RE for asrg@ietf.org; Tue, 17 Jan 2006 16:50:06 -0500
Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id k0HLfNX6004424 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 17 Jan 2006 13:41:24 -0800
In-Reply-To: <43CD4634.174C@xyzzy.claranet.de>
References: <OF4768D65E.ECA3CB39-ON802570F8.004A9BA8-802570F8.004AA408@slc.co.uk> <43CBF4CD.30708@dcrocker.net> <17355.64568.706837.635025@world.std.com> <014a01c61b5a$5369ff60$0601a8c0@pc6> <17357.14471.781702.895067@world.std.com> <43CD4634.174C@xyzzy.claranet.de>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <48397C91-8A6D-4787-80A5-81354DD0B305@mail-abuse.org>
Content-Transfer-Encoding: 7bit
From: Douglas Otis <dotis@mail-abuse.org>
Subject: Re: [Asrg] Re: Bots
Date: Tue, 17 Jan 2006 13:41:24 -0800
To: Frank Ellermann <nobody@xyzzy.claranet.de>
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Content-Transfer-Encoding: 7bit
Cc: asrg@ietf.org
X-BeenThere: asrg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Anti-Spam Research Group - IRTF <asrg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/asrg>
List-Post: <mailto:asrg@ietf.org>
List-Help: <mailto:asrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=subscribe>
Sender: asrg-bounces@ietf.org
Errors-To: asrg-bounces@ietf.org

On Jan 17, 2006, at 11:32 AM, Frank Ellermann wrote:

> Barry Shein wrote:
>
>  [9]
>> bzs: ok, this botnet was used in a DoS attack but I think it  
>> underscores the general theme that they exist, are dangerous,  
>> numbers of PCs involved (20,000 in this case), and becoming  
>> legally dangerous to their operators.)
>
> It also underscores why "block port 25" won't solve the zombie  
> problem, "block port 25" is a delusion, unless it's a temporary  
> step in a strategy to find and clean (multi-) infected systems.

Although port 25 blocking offers a degree of containment, zombies use  
any avenue available.  Rather than waiting for keystrokes, password  
recovery allows immediate access when applications store passwords.   
The victims are also less likely to know there is a problem, as  
zombies are getting better at creating the appearance of normality  
while disabling protections.  Some even include artificial  
intelligence able to mimic someone responding real-time to concerns,  
while offering assurances everything is fine.  The social engineering  
involved and extent of the problem is rather startling.

Avenues of infection offering traceable source identifiers would  
allow tracking the infections.  Lacking conventions, a large amount  
of resource is expended in this effort.  Traceable identifiers do not  
need to expose personal identifiers any more than a MAC or IP address  
would, and, in my view, should not look like email-addresses.  The  
goal would be to locate the infected machine, not identify the author  
of a message.  Once the machine is identified, there are many ways  
users can be alerted and directed to a cleanup process.  At this  
point, scrubbing programs work reasonable well, but they must always  
adapt.  Even this aspect represents an escalating battle.

Even applying delinquent patches to the OS may result in a corrupt a  
filesystem when an older disk maintenance application becomes  
confused by modified low level APIs.  It is really depressing to see  
a file-system recovery tool estimate restoration to take tens of  
thousands of hours.  What fun.

-Doug



_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg