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

[Dave Piscitello <dave.piscitello@xxxxxxxxx>]

Some observations:

1. Fast flux is only one method of evasion. Please let¹s keep this in mind.

2. The notion of not burdening legitimate customers is a noble one, but
identifying a means of distinguishing good actors from bad is a hard nut to
crack. The criteria of ³old, stable customers² that you suggest provides a
profile for a bad actor to emulate when he impersonates a good actor, or
incents a bad actor to attack a good actor. For example, if the registrant
for example.com is a good actor, an attacker has strong incentives to spear
phish that or socially engineer that registrant¹s contacts. As I suggested
in my earlier post, I believe we have to think multi-dimensionally when we
try to distinguish normal from anomalous behavior.

3. The idea of using age as a criteria for ³unburdening² a domain registrant
­ old customer versus new ­ is hard for me to grasp. It sounds like you are
proposing some form of reputation system, where a registrant is not
considered trustworthy until it demonstrates some prescribed behavior or
³good behavior over time²? Or do you mean something else?

On 7/2/08 11:25 AM, "Marc Perkel" <marc@xxxxxxxxxx> wrote:

>
>
> 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
>
>