Re: [Asrg] Countering Botnets to Reduce Spam

Chris Lewis <clewis+ietf@mustelids.ca> Sat, 15 December 2012 03:23 UTC

Return-Path: <clewis+ietf@mustelids.ca>
X-Original-To: asrg@ietfa.amsl.com
Delivered-To: asrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF09F21F86A5 for <asrg@ietfa.amsl.com>; Fri, 14 Dec 2012 19:23:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.378
X-Spam-Level:
X-Spam-Status: No, score=0.378 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibDXFbgOSDkZ for <asrg@ietfa.amsl.com>; Fri, 14 Dec 2012 19:23:30 -0800 (PST)
Received: from mail.mustelids.ca (unknown [174.35.130.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5A91721F866E for <asrg@irtf.org>; Fri, 14 Dec 2012 19:23:30 -0800 (PST)
Received: from [192.168.0.8] (otter.mustelids.ca [192.168.0.8]) (authenticated bits=0) by mail.mustelids.ca (8.14.4/8.14.4/Debian-2ubuntu2) with ESMTP id qBF3NT0R005789 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for <asrg@irtf.org>; Fri, 14 Dec 2012 22:23:29 -0500
Message-ID: <50CBED31.2030308@mustelids.ca>
Date: Fri, 14 Dec 2012 22:23:29 -0500
From: Chris Lewis <clewis+ietf@mustelids.ca>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: asrg@irtf.org
References: <20121215011734.54813.qmail@joyce.lan>
In-Reply-To: <20121215011734.54813.qmail@joyce.lan>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] Countering Botnets to Reduce Spam
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
List-Id: Anti-Spam Research Group - IRTF <asrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/asrg>, <mailto:asrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/asrg>
List-Post: <mailto:asrg@irtf.org>
List-Help: <mailto:asrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Dec 2012 03:23:31 -0000

On 12-12-14 08:17 PM, John Levine wrote:

> Other than the magic term P2P, what does this provide above what
> packages like Tripwire do now?  Any particular distribution of Linux
> is installed from a known set of masters, where the files have known
> checksums.  The checksums are not large, and are not a big deal to
> retrieve.  What does P2P add?  Random other Linux boxes are certainly
> not more likely to have a set of good checksums than, say, an https
> server run by a well known distribution organization.

I _suppose_ it might make it a bit more feasible to obtain checksums of
random code that isn't necessarily in sync with a Linux dist.

In many hosting environments, there can be literally as many versions
of, say, Wordpress, as there are customers.  The admins steadily patch
the basic O/S, but often they won't touch the customer's images for fear
of breaking them.

Or virtualized systems.  Just imagine how many different O/S images
there are on a cloud.  Eg: Amazon expects the customer to do their _own_
patching.

I really don't think the idea would work in the end of the industry
(cloud, multi-host platforms) that need it most.