BGP list of phishing sites?

Mon Jun 28 20:52:54 UTC 2004

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 at 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 at merit.edu [mailto:owner-nanog at merit.edu] On 
> Behalf Of Stephen J. Wilcox
> Sent: Monday, June 28, 2004 11:56 AM
> To: Scott Call
> Cc: nanog at 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 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
> 
> 
> 