RE: IP-based reputation services vs. DNSBL (long)
"Hallam-Baker, Phillip" <pbaker@verisign.com> Thu, 13 November 2008 15:13 UTC
Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 276313A6806; Thu, 13 Nov 2008 07:13:46 -0800 (PST)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D28A83A6806 for <ietf@core3.amsl.com>; Thu, 13 Nov 2008 07:13:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.202
X-Spam-Level:
X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TdLUdnxHpdx for <ietf@core3.amsl.com>; Thu, 13 Nov 2008 07:13:43 -0800 (PST)
Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by core3.amsl.com (Postfix) with ESMTP id 848713A63EB for <ietf@ietf.org>; Thu, 13 Nov 2008 07:13:43 -0800 (PST)
Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id mADErgks025467; Thu, 13 Nov 2008 06:53:42 -0800
Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Nov 2008 07:13:43 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: IP-based reputation services vs. DNSBL (long)
Date: Thu, 13 Nov 2008 07:10:07 -0800
Message-ID: <2788466ED3E31C418E9ACC5C316615572FFB40@mou1wnexmb09.vcorp.ad.vrsn.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: IP-based reputation services vs. DNSBL (long)
Thread-Index: AclE8Ix7GLfQpisNSsaX4oaZNU9WewAsV260
References: <49172BCE.2000705@network-heretics.com> <alpine.LSU.2.00.0811111711310.14367@hermes-1.csi.cam.ac.uk> <4919C264.4000209@network-heretics.com> <4919C6FA.909@earthlink.net> <4919CB7C.3070604@leisi.net> <4919D1FC.9070801@earthlink.net> <4919FD8F.5010200@nortel.com> <2788466ED3E31C418E9ACC5C316615572FFB38@mou1wnexmb09.vcorp.ad.vrsn.com> <491B1977.9060504@nortel.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: Chris Lewis <clewis@nortel.com>
X-OriginalArrivalTime: 13 Nov 2008 15:13:43.0454 (UTC) FILETIME=[6ABCB3E0:01C945A2]
Cc: IETF <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1931234097=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
To answer your question about how they got round port 25 blocking, my guess is that they sent the initial packet out on yet another connection that was unblocked. I don't see how the timing issues are so great, this is at worst going to double the round trip time and double the lost pckets. I have seen something similar described recently in the context of a cyber-conflict type attack. ________________________________ From: ietf-bounces@ietf.org on behalf of Chris Lewis Sent: Wed 11/12/2008 12:59 PM Cc: IETF Subject: Re: IP-based reputation services vs. DNSBL (long) Hallam-Baker, Phillip wrote: > Agree with your conclusion but your statement is not quite accurate. I know that. I had composed a footnote outlining split-routing in my original email, but removed it because it would confuse the issue precisely for the reasons you yourself outline below, without invalidating anything I said. Since you raise it, I'll elaborate. You said: > Some spammers have in fact developed schemes that involve spoofing the > source IP address of TCP sessions, but only where both IP addresses were > under spammer control. <details of split-routing elided>. Precisely. Both IP addresses are under spammer control, the listing still has precisely the desired effect (blocking the undesirable email), and FPs are no more likely than if the "alleged source" really was the true source. Now if there were plausible circumstances where, say, infesting a real MTA with split-routing malware was any more likely or preferable than infesting a real MTA with non-split-routing spamware, it could be of concern. But there isn't. Split-routing requires very intimate and synchronous real-time bidirectional communications between both IP addresses of the split. I believe that most if not all implementations were where both IPs were on the same machine, both IPs were "legitimately held" by the spammer (not by infection). That scenario is no longer feasible at typical BOT volumes. > I don't know if it is still widely used but when is was being used the > disruption caused to the network was cosiderably higher than for normal > spam as you can expect. It is not widely used any longer. At best, the technique is of value in very limited circumstances ("effectively free/super cheap accounts with associated real IPs", eg: AOL "first month free" disks). Secondly, it also requires there to be a more "valuable" asset (the true source, a paid high bandwidth account) that the spammer is trying to protect. With BOTs, there is no "paid high bandwidth account" to protect, or at least, not by these means - all parts of the spam-sending exercise, and much of the immediately visible portions of the web content delivery are expendable (eg: domain tasting, expendible intermediate proxies, etc). Secondly, the volumes that spammers need to send to get any return are too high for this technique to be feasible. At its height, a number of people noted that the only known mass-use of this technique was via AOL. The CBL once listed over 20,000 AOL "ipt" (end-user IPs) that were also outbound port 25 blocked by AOL. Yes, there was some confusion (including that of AOL admin staff) of how this was possible, but _not_ because it was interfering with legitimate email - their non-spamming customers _couldn't_ send email that way anyway. However, once they understood what the issue was, the fix (block inbound port 25) was accomplished in very short order. If anything, the juxtaposition of a CBL listing of the port 25-blocked AOL "split-end" <grin> greatly speeded up resolution of the entire issue - certainly a lot easier than whack-a-mole of thousands of individual accounts. We've seen this situation a few times since then in a small way (none in the last year or longer), but established practise is tending to eliminate this as spammer-economy-viable (eg: see MAAWG Port 25 considerations document). In fact, I think the AOL experience is one of the prompters of that document's existance. Aside from unusual situations like AOL (back then), it is no longer a useful technique for spammers to exert effort on, and even if it was, the distinction is moot, because the effect/consequences of a DNSBL listing of the back-haul of a split-routed connection is identical to a non-split-route connection. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
- IP-based reputation services vs. DNSBL (long) Keith Moore
- Re: IP-based reputation services vs. DNSBL (long) John Leslie
- RE: IP-based reputation services vs. DNSBL (long) Lawrence Rosen
- Re: IP-based reputation services vs. DNSBL (long) John Levine
- RE: IP-based reputation services vs. DNSBL (long) Lawrence Rosen
- Re: IP-based reputation services vs. DNSBL (long) Eliot Lear
- RE: IP-based reputation services vs. DNSBL (long) michael.dillon
- Re: IP-based reputation services vs. DNSBL (long) Keith Moore
- Re: IP-based reputation services vs. DNSBL (long) Eliot Lear
- Re: IP-based reputation services vs. DNSBL (long) Keith Moore
- Re: IP-based reputation services vs. DNSBL (long) Dave CROCKER
- Re: IP-based reputation services vs. DNSBL (long) Dave CROCKER
- Re: IP-based reputation services vs. DNSBL (long) Dave CROCKER
- RE: IP-based reputation services vs. DNSBL (long) Hallam-Baker, Phillip
- Re: IP-based reputation services vs. DNSBL (long) Sam Hartman
- Re: IP-based reputation services vs. DNSBL (long) TS Glassey
- Re: IP-based reputation services vs. DNSBL (long) Tony Finch
- Re: IP-based reputation services vs. DNSBL (long) Keith Moore
- Re: IP-based reputation services vs. DNSBL (long) Keith Moore
- Re: IP-based reputation services vs. DNSBL (long) TS Glassey
- Re: IP-based reputation services vs. DNSBL (long) Matthias Leisi
- Re: IP-based reputation services vs. DNSBL (long) Matthias Leisi
- Re: IP-based reputation services vs. DNSBL (long) Eliot Lear
- Re: IP-based reputation services vs. DNSBL (long) TS Glassey
- Re: IP-based reputation services vs. DNSBL (long) Chris Lewis
- RE: IP-based reputation services vs. DNSBL (long) Hallam-Baker, Phillip
- Re: IP-based reputation services vs. DNSBL (long) Chris Lewis
- Re: not spoofing, was IP-based reputation serviceā¦ John Levine
- RE: IP-based reputation services vs. DNSBL (long) Hallam-Baker, Phillip
- Re: IP-based reputation services vs. DNSBL (long) Chris Lewis
- RE: IP-based reputation services vs. DNSBL (long) Hallam-Baker, Phillip