Re: [gnso-ff-pdp-may08] Jump start on answering GNSO questions regarding fast flux

[Marc Perkel <marc@xxxxxxxxxx>]

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.
IMPORTANT POINT

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.
PROVIDING INFORMATION

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 
registrars are.
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.

Marc Perkel
Fearless Leader
Junk Email Filter