This host appears to be resending nanog posts? : Received: from e500smtp01.nga.mil(164.214.6.120) by relay5.nga.mil via smap (V5.5) id xma020150; Tue, 29 Jun 04 10:25:13 -0400 Originally received yesterday sometime... ---------- Forwarded message ---------- Return-path: <MAILER-DAEMON@relay5.nga.mil> Envelope-to: steve@telecomplete.net Delivery-date: Tue, 29 Jun 2004 14:25:46 +0000 Received: from exim by mx-0.telecomplete.net with spam-scanned (Exim 4.22) id 1BfJYP-00065u-Li for steve@telecomplete.net; Tue, 29 Jun 2004 14:25:46 +0000 Received: from exim by mx-0.telecomplete.net with scanned-ok (Exim 4.22) id 1BfJYP-00065h-1o for steve@telecomplete.net; Tue, 29 Jun 2004 14:25:45 +0000 Received: from relay5.nga.mil ([164.214.4.61]) by mx-0.telecomplete.net with esmtp (Exim 4.22) id 1BfJYO-00065C-6w for steve@telecomplete.co.uk; Tue, 29 Jun 2004 14:25:44 +0000 Received: by relay5.nga.mil; id KAA20159; Tue, 29 Jun 2004 10:25:38 -0400 (EDT) Received: from e500smtp01.nga.mil(164.214.6.120) by relay5.nga.mil via smap (V5.5) id xma020150; Tue, 29 Jun 04 10:25:13 -0400 Received: from relay2.nga.mil(164.214.6.52) by e1000smtp2.nima.mil via csmap id 78e94c8c_c949_11d8_9cac_0002b3c81b76_16242; Mon, 28 Jun 2004 17:24:00 -0400 (EDT) Received: by relay2.nga.mil; id RAA13558; Mon, 28 Jun 2004 17:22:36 -0400 (EDT) Received: from trapdoor.merit.edu(198.108.1.26) by relay2.nga.mil via smap (V5.5) id xma010754; Mon, 28 Jun 04 17:14:29 -0400 Received: by trapdoor.merit.edu (Postfix) id 6C1A091277; Mon, 28 Jun 2004 17:12:33 -0400 (EDT) Delivered-To: nanog-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3590491285; Mon, 28 Jun 2004 17:12:33 -0400 (EDT) Delivered-To: nanog@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2AB5D91277 for <nanog@trapdoor.merit.edu>; Mon, 28 Jun 2004 17:12:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 568C759D1B; Mon, 28 Jun 2004 17:12:26 -0400 (EDT) Delivered-To: nanog@nanog.org Received: from uswgco34.uswest.com (uswgco34.uswest.com [199.168.32.123]) by segue.merit.edu (Postfix) with ESMTP id 21E1559C56 for <nanog@nanog.org>; Mon, 28 Jun 2004 17:12:26 -0400 (EDT) Received: from egate-ne2.uswc.uswest.com (egate-ne2.uswc.uswest.com [151.117.64.200]) by uswgco34.uswest.com (8/8) with ESMTP id i5SLCLSu006141; Mon, 28 Jun 2004 15:12:21 -0600 (MDT) Received: from ITDENE2KSM02.AD.QINTRA.COM (localhost [127.0.0.1]) by egate-ne2.uswc.uswest.com (8.12.10/8.12.10) with ESMTP id i5SLCKCx008243; Mon, 28 Jun 2004 16:12:20 -0500 (CDT) Received: from itdene2km08.AD.QINTRA.COM ([10.1.4.107]) by ITDENE2KSM02.AD.QINTRA.COM with Microsoft SMTPSVC(5.0.2195.5329); Mon, 28 Jun 2004 15:12:20 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: BGP list of phishing sites? Date: Mon, 28 Jun 2004 15:12:12 -0600 Message-ID: <9921AB57EA49D242A076864C5F473D3C650089@itdene2km08.AD.QINTRA.COM> Thread-Topic: BGP list of phishing sites? Thread-Index: AcRdUpLPcFNCkm3pQvC9Iiw2DaWELgAAelTA From: "Smith, Donald" <Donald.Smith@qwest.com> To: "Stephen J. Wilcox" <steve@telecomplete.co.uk> Cc: "Scott Call" <scall@devolution.com>, <nanog@nanog.org> X-OriginalArrivalTime: 28 Jun 2004 21:12:20.0544 (UTC) FILETIME=[9965D400:01C45D54] Sender: owner-nanog@merit.edu Precedence: bulk Errors-To: owner-nanog-outgoing@merit.edu X-Loop: nanog X-Virus-Scanned: by Telecomplete X-Spam-Checker-Version: Telecomplete X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00=-4.9 autolearn=no I agree phishing bgp feed would disrupt the ip address to all ISP's that listened to the bgp server involved. I was addressing a specific issue with listening to such a server and that is the loss of control issue. Sorry if that wasn't clear. So would ISP's block an phishing site if it was proven to be a phishing site and reported by their customers? Donald.Smith@qwest.com GCIA pgpFingerPrint:9CE4 227B B9B3 601F B500 D076 43F1 0767 AF00 EDCC Brian Kernighan jokingly named it the Uniplexed Information and Computing System (UNICS) as a pun on MULTICS.
-----Original Message----- From: Stephen J. Wilcox [mailto:steve@telecomplete.co.uk] Sent: Monday, June 28, 2004 2:58 PM To: Smith, Donald Cc: Scott Call; nanog@nanog.org Subject: RE: BGP list of phishing sites?
Hi Donald, the bogon feed is not supposed to be causing any form of disruption, the purpose of a phishing bgp feed is to disrupt the IP address.. thats a major difference and has a lot of implications.
Steve
On Mon, 28 Jun 2004, Smith, Donald wrote:
Some are making this too hard. Of the lists I know of they only blackhole KNOWN active attacking or victim sites (bot controllers, know malware download locations etc) not porn/kiddie porn/pr/choose-who-you-hate-sites ... clients (infected pc's) are usually not included but could make it on the list given enough attacks. It does mean giving up some control of your network which may not be acceptable to some ISP's. Its not much different then listening to an automated bogon feed.
Donald.Smith@qwest.com GCIA pgpFingerPrint:9CE4 227B B9B3 601F B500 D076 43F1 0767 AF00 EDCC Brian Kernighan jokingly named it the Uniplexed Information and Computing System (UNICS) as a pun on MULTICS.
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Stephen J. Wilcox Sent: Monday, June 28, 2004 11:56 AM To: Scott Call Cc: nanog@nanog.org Subject: Re: BGP list of phishing sites?
On Sun, 27 Jun 2004, Scott Call wrote:
On the the things the article mentioned is that ISP/NSPs are shutting off access to the web site in russia where the malware is being downloaded from.
Now we've done this in the past when a known target of a DDOS was upcoming or a known website hosted part of a malware package, and it is fairly effective in stopping the problems.
So what I was curious about is would there be interest in a BGP feed (like the DNSBLs used to be) to null route known malicious sites like that?
Obviously, both operational guidelines, and trust of the operator would have to be established, but I was thinking it might be useful for a few purposes:
1> IP addresses of well known sources of malicious code (like in 1> the example above) 2> DDOS mitigation (ISP/NSP can request a null route of a prefix which will save the "Internet at large" as well as the NSP from the traffic flood 3> etc
Since the purpose of this list would be to identify and mitigate large scale threats, things like spammers, etc would be outside of it's charter.
If anyone things this is a good (or bad) idea, please let me know. Obviously it's not fully cooked yet, but I wanted to throw it out there.
Personally - bad.
So what do you want to include in this list.. phishing? But why not add bot C&C, bot clients, spam sources, child porn, warez sites. Or if you live in a censored region add foreign political sites, any porn, or other messages deemed bad.
Who maintains the feed, who checks the sites before adding them, who checks them before removing them.
What if the URL is a subdir of a major website such as aol.com or ebay.com or angelfire.com ... what if the URL is a subdir of a minor site, such as yours or mine?
What if there is some other dispute over a null'ed IP, suppose they win, can they be compensated?
Does this mean the banks and folks dont have to continue to remove these threats now if the ISP does it? Does it mean the bank can sue you if you fail to do it?
What if you leak the feed at your borders, I may not want to take this from you and now I'm accidentally null routing it to you. Should you leak this to downstream ASNs? Should you insist your Tier1 provides it and leaks it to you?.. just you or all customers?
What if someone mistypes an IP and accidentally nulls something real bad(TM)? What if someone compromises the feeder and injects prefixes maliciously?
What about when the phishers adapt and start changing DNS to point to different IPs quickly, will the system react quicker? Does that mean you apply less checks in order to get the null route out quicker? Is it just /32s or does it need to be larger prefixes in the future? Are there other ways conceivable to beat such a system if it became widespread (compare to spammer tactics)
What if this list gets to be large? Do we want huge amounts of /32s in our internal routing tables?
What if the feeder becomes a focus of attacks by those wishing to carry out phishing or other illegal activities? This has certainly become a hazard with spam RBLs.
Any other thoughts?
Steve