Re: [gnso-ff-pdp-may08] Jump start on answering GNSO questions regarding fast flux
- To: "gnso-ff-pdp-May08@xxxxxxxxx" <gnso-ff-pdp-May08@xxxxxxxxx>
- Subject: Re: [gnso-ff-pdp-may08] Jump start on answering GNSO questions regarding fast flux
- From: Marc Perkel <marc@xxxxxxxxxx>
- Date: Wed, 02 Jul 2008 08:25:20 -0700
I'd like to make the suggestion that perhaps one of the solutions to
fast flux might be in providing more information about domains rather
than just adding restrictions like rate limiting changes. I am in the
spam filtering business (http://www.junkemailfilter.com) and I've found
that it is much easier to detect phishing by the behavior of the spammer
than by the content of the message. Thus the more information I have the
better I can detect phishing.
Spammers are always on the run and having to change to avoid detection.
If a spammer were on a stable IP address that IP would quickly make all
the popular DNS based blacklist and nothing they sent would make it
through anyone's filters. In the spam filtering world we tend to work
together to create collaborative technologies to block spam
collectively. This a stable spammer is easy to detect.
A key principle to keep in mind is that spammers and phishers always
want you to do something. They want you to "click here". The want you to
reply to the email. If the spammer is going to get the victim's money or
identity they have to be able to establish a connection with the victim
and get the victim to either send them money or visit a fake web site
where the victim give up their passwords to their accounts.
In order to phish the phisher has to accomplish a number of things. They
have to create a platform for sending large quantities of spam. That is
often a botnet. Then they have to get their message past spam filtering
- people like me - in order to get their message in the victim's inbox.
They then need to seduce the victim into acting. Often they pretend to
be a bank and the message is "Your account has been suspended. You need
to log in to your account to fix the problem." A link is provided which
redirects the victim to the fake web site where the victim enters their
login information and the phisher clean out their bank account.
This kind of spam is usually not hard to detect. And one can follow the
link to the phisher's web sites and shut them down. These web sites are
usually either part of the botnet or legitimate domains that have been
exploited due to a security flaw. If the targer web server is shut down
then all the phisher's emails are wasted. The victim clicks on the link
and nothing happens.
Thus to extend the life of the fake servers phishers have resulted to
using fast flux hostig. This allows the phisher to rapidly change name
servers and to change the A record rapidly so that as the servers get
shut down the phishers can redirect victims to new servers and continue
to get their money.
In the case of fast flux the domain is under the control of the phisher.
The phisher has to log in and make changes. This is probably done
through automation. The phisher probably has a lot of domains and they
have scripts that manage all of them. They need to be able to go in and
make rapid changes to their setting and we have already identified that
as a point we can control by rate limiting changes.
Let me however introduce some new ideas at this point. Registrars have
customers and customers have domains. These are two different databases
that the registrar controls. In order for a phisher to get a domain for
fast flux they first need to be a customer. So if I'm a phisher I'm
going to be a fake customer with a lot of domains or I might be a lot of
customers with a one domain each. I suspect the most phishers are one
customer with lots of domains.
One of our missions here is to make sure we don't burden legitimate
people who are doing legitimate things. I've found that most every time
I create some new restriction I run into an exception where someone
legitimate runs into my restriction. So - I want to stop and make an
important point here.
Instead of just actively detecting criminals, our solution should also
actively detect non-criminals. We should treat old customers with old
domains differently than new customers with new domains.
One of the ways I get my accuracy up in spam filtering is that I don't
only look for spam. I actively try to detect non-spam and pass it
through the system without restrictions. And non-spam is easier to
detect because it comes from servers that are long term stable servers
that send millions of good emails every day. For example, my bank Wells
Fargo (wellsfargo.com) never sends any spam at all. All their outgoing
servers come from hosts whose Forward Confirmed RDNS always resolves to
*.wellsfargo.com. If I get an email from *.wellsfargo.com then I know
it's good and I can skip all other testing and pass the message. This
precludes the possibility that some other test might accidentally block it.
So if a registrar has an old customer with old stable domains then those
customers and domains should be treated differently than a new customer
with new domains. We can then look at behavior and determine if someone
is fast fluxing and if someone is not.
Although the registrars can implement steps to detect fast fluxing they
could also provide more public information through DNS calls to help
other, like me in the spam filtering business, to detect faxt flux and
generate blacklists of fast fluxing domains. Registrars could then
download the URIBL lists and see what domains they control are on those
lists as an indicator of where trouble might be. The registrar doesn't
have to do all the work here - we in the spam filtering community can
help because we might be in a better position to detect fast flux than
For example - suppose I could find out the age of the domain (by it's
current owner) and the number og NS changes made in the last 3 days.
99.99% of all these would be domains that are older than 90 days with
less than 2 changes. Then there will be a group that is very new domains
of new customers and there are say more than 3 changes. This domain
would be highly suspect. If that information were combined with
information in an email that I was processing where I determined a spoof
had occurred then I could assert with a very high degree of accuracy
that a fast flux domain had been detected.
I could then use some kind of automated reporting system to report back
to registrars suspected trouble. And if other spam filtering companies
also were sending reports on the same domain then the registrar could
freeze NS changes or disable the domain.
So - my question to this group is - what additional information can
registrars legally and practically provide about a domain? Right now
registrars provide NS records telling the world what the name servers
are. Can registrars tell us the age of the domain and the number of
receint changes to the NS records?
Also - if registrars used capcha to discourage automated NS changes - at
least for new customers our new domains, that would stop automated
scripts from updating NS fast and kill a lot of fast flux.
Hope this email isn't too long. I hope these ideas are thought inspiring.
Junk Email Filter