Jump to content

Wordsmiths needed - fast flux 'cure?'


Wazoo
 Share

Recommended Posts

ICANN Ponders Ways to Stop Scammy Web Sites leads one to the large (PDF) collection of notes, thoughts, etc at Initial Report of the GNSO Fast Flux Hosting Working Group ....

Wow! Even worse than the spam itself, being thrown right back into the "I know it when I see it, but I can't define it" mode. Only taken to the extreme of the "not sure if 'we' have jurisdiction .. even if 'we' could define it." ....

Long read, for sure, but ... there's a window of opportunity for folks to jump in if they've got some answers to help those folks out ..... which in turn might help everyone out (or perhaps make everyone's life a bit more complicated ????)

Link to comment
Share on other sites

What is wrong with the idea that ICANN makes a rule that any site contained in an email cannot be fast flux except those sites where a password is required to enter and the password has been applied for on the web. (no generic passwords in the email). That would be easy to report and verify, wouldn't it? That wouldn't eliminate phishing attempts since that's the purpose of phishing - to get people to use their passwords, but it would prevent consumers from replying to spam selling anything without deliberately going to the web and going to the website. It would not affect legitimate businesses' mailing lists offering special deals or sending notices of invoices, etc. (Well, it might affect the deals since consumers would have to apply for passwords and many won't, but legitimate business is also unable to reach many consumers because of the strict anti-spam policies of ISPs. If there were less spam, then they could reach more people.)

The way to cause trouble for phishers is to limit the number of domains that can be registered at one time or make it a lot more complicated, ISTM. Legitimate businesses who want to register a lot of domains at one time are not going to have a problem with a waiting period while credit cards are being verified, addresses and contact information verified (like the letters that are sent when one registers at some websites - only after the letter is sent and verification is done by the information in the letter are you allowed access). An initial 'bond' amount could be required also, that the registrar can refund after a period of time if they are satisfied that the domains are being used legitimately or waive, if the organization is known to them. ICANN can certainly make some requirements that slow phishers down that determine whether or not a registrar continues to be allowed to issue domains - loose enough that if a registrar makes a mistake, it can redeem itself, but enough that if there is a consistent pattern of allowing criminals to register, their authorization can be yanked (so that a registrar just doesn't consider fines for being lax part of his business expense). Some sort of monetary inducement probably be best to get registrars to implement anti-phish techniques. And as the Anti-phish organization article states, the registrars themselves are affected by phishing attempts. And, although requiring money up front would discourage 'free speech', it does also offline. You need money to publish a newspaper, for instance, and if it is large enough, you will be easy to find if government can shut down opposing newspapers. It wouldn't stop anyone from having a website that didn't redirect or being anonymous to any authorities who might want to find the publisher for political reasons if these requirements were only necessary for the registration of a certain number of domains at one time.

Neither one of the above ideas restricts the use of fast flux on the web in general. Companies would be able to use it on the web for legitimate reasons without any restrictions - other than the set up fees would be more and require more paperwork. Neither can be used for censorship since enough money can allow you to set up fast flux if you want as long as you do not send email with a link to a non-password protected site. Phishing is so lucrative that there will always be attempts, IMHO, but registrars will always want to shut them down as quickly as possible. It will be a lot easier to do because if you send email randomly to a lot of people, some of it is bound to go to someone who will report it.

And it eliminates any complicated definitions. No fast flux websites in email except password sign in sites. Verification of payment method and business information before purchasing a certain number of domain names at one time or within a certain period of time.

Miss Betsy

Link to comment
Share on other sites

ICANN Ponders Ways to Stop Scammy Web Sites leads one to the large (PDF) collection of notes, thoughts, etc at Initial Report of the GNSO Fast Flux Hosting Working Group ....

Not even I have enough free time to digest the entire report, but the fact that it is so large suggests that they can't find the proper target.

To me, fast-fluxing per se is not evil, not something we should necessarily seek to "prevent." That is, simply rotating your domain rapidly over a large number of addresses is just another networking technique, and is morally neutral in and of itself. We probably wouldn't object, for example, if SpamCop or maybe Spamhaus started using fast-flux to fend off DDOS attacks against its websites.

What is objectionable about the way spammers (and other crooks) do fast-fluxing is that they use services belonging to others without asking permission or making proper contracts for them. They violate the property of others (i.e., through botnetting) in order to get the resources that enable them to use fast-flux so effectively. They commit the same sin that they did back in the days of open relay mail hosts: THEFT. Gigging the spammers for "fast fluxing" is like ticketing Willie Sutton for parking illegally in front of the bank -- it is missing the point.

I recall some discussion (here or elsewhere) about possibly setting larger minimum values for DNS A-record TTL values, as a means to slow down the fluxing. I wouldn't object to this in principle, although I'm not sure how you would enforce such a policy on thousands upon thousands of independent DNS administrators (including crooked ones) all over the world. If I ran a DNS operation, I could probably jigger the nameservers to reject short TTL times without waiting for "guidance" from ICANN. Even so, I'm not sure what good this would do my users.

-- rick

Link to comment
Share on other sites

Yes, I agree that just like bulk email, there is nothing wrong with fast flux and should not be targeted. That's why I think the target should be fast flux in email and to make it more difficult and expensive to get a lot of domains. Nothing is going to stop the criminals from attempting to connect with a patsy, but if you make it easier to identify hir attempts and make hir go to greater lengths to hide identity then you reduce the number who can do it and make it easier to catch hir in the act. Although it doesn't do much good to ticket the getaway car, didn't they take down one hoodlum on income tax evasion? If the registrars can kick off someone (which they already can do) for incomplete registration, pretty soon one crook will run out of registrars or be able to be arrested for some other crime in covering up hir identity.

Miss Betsy

Link to comment
Share on other sites

... didn't they take down one hoodlum on income tax evasion? ...
"One hoodlum"? J. Edgar Hoover would be turning in his grave. Not just any old gangster in fact but arguably the biggest of the lot. Hopelessly O/T but in the interests of preserving US culture ;) - Al Capone. Sort of apposite, with St. Valentine's day approaching.
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...