On Tue, Jan 02, 2007 at 06:20:01PM -0700, Bill Nash wrote:
The biggest challenge I can see is scrubbing phishing reports that aren't.. themselves.. maliciously crafted phishing attacks against a registry of such addresses.
Can you rephrase that? I want to understand but I'm failing.
Likewise, since BGP isn't application aware, when you blackhole an address that's both website and mail server, how do you inform the end user about their problem, or get a notice from them that it's been fixed?
This kind of solution has a huge trust factor hole in it.
However, it has been done with MAPS... they do indeed have a BGP-compatible DNS lookup thingamabob, and for a while Above.net was using it. Apart from MAPS blacklisting the whole netblock of a site that was selling (but not using) spam software, there are also externalities involved. Above.net started blackholing traffic to those sites, but they did it for all the traffic that crossed their network, not just the traffic they originated. So the net result was that some of these sites were not reachable, just because your traffic traversed above.net, and sometimes they were. And as you point out, there was no way to know what was happening without effort. For the kind of user that gets fooled by a phishing site, I'm sure it could get very confusing.
Distributing a BGP based blackhole list is trivial. The intelligence that goes into it is the hard part. There are companies that provide managed services like this (bgp blackhole route servers for known problem sites, like drone C&C's). (disclaimer: I do development for one.)
As another poster discusses, collateral damage is of concern. I do some forensics for a web hosting company and occasionally someone sets up a phishing web site instead of spambots and IRC connections. Typically we can make it inoperable within a few minutes of knowing exactly what is going on (chmod -R 000 ...), so I think a detailed email to abuse is going to be more effective, as long as they have the ability to read and respond to the email in a timely fashion. For companies that aren't that timely, I would think that'd be a good candidate for firewalling. I know next to nothing about BGP yet, but I suspect that you could direct traffic for that IP to go through a firewall device (or implement an ACL, though I suppose that would mandate the slow path in a router), to block TCP ports 80 and 443 with a TCP reject, to give some feedback, or an ICMP administratively unreachable. This also gives the end-user the ability to figure out who is doing the blocking and get in touch with them (or at least their network guy acting as their agent, I suspect most end-users can't track down a provider by IP or sniff to get the IP in the first place). IIRC, Riverhead DoS-mitigation systems use a similar mechanism for filtering out DoS packets en route. Oh, and yes, even for one IP, you're still going to have collateral damage if they're doing shared hosting, since one IP serves many sites. The only way around this is to actually do layer 7 decoding, but if the intruder can already set up one phishing account, I would be hesitant to assume the other co-located sites are really safe to browse. I suspect the trust problem is pretty easy to deal with, if you have a human and GPG. Usenet cancel messages, rmgroup messages, key distribution for mixmaster remailers... the hardest problem is deciding who you trust, and getting their key securely; the rest is easily automated. Although some sites might be difficult to distinguish from phishing sites; recently discussed on the cryptography list was (IIRC) a Citibank email that told users to log into some site and enter confidential data... the site was legit but did not have citi anywhere in the domain name, and was located in New Zealand. Some people tried to explain why this was bad to Citibank, and apparently a clue was nowhere to be found. And yet, people trust them with their money. -- A: No. Q: Should I include quotations after my reply? <URL:http://www.subspacefield.org/~travis/> -><-