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.
