Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×

What Ways Can Sites Handle Spambot Attacks? 75

Amazing Quantum Man asks: "I'm a member of a site devoted to nitpicking TV shows and movies. It has always had an open posting policy — no registration required, and you could use any name you wanted. This policy was instituted way back in 1998, and led to some quite fun, freewheeling threads on various boards. Recently, we have come under spambot attack, with spambots posting links to gambling and porn sites on every single discussion board on the site. The admins have been trying to block IPs, but it's useless against a botnet. As a defense, it looks like the site is going to require registration, and disable anonymous posting. Many regulars, while they understand the need, are concerned that the freewheeling character of the site will be lost. Let me continue by saying that I'm not a site admin, merely a member there. Also, if it helps, the site in question is running Discus. Has anyone here been in a similar situation? How did you handle it, and what did it do to the 'culture' of your site?"
This discussion has been archived. No new comments can be posted.

What Ways Can Sites Handle Spambot Attacks?

Comments Filter:
  • by Ucklak ( 755284 ) on Friday November 03, 2006 @10:50PM (#16712239)
    I have about 100 sites (really) and I've evolved with different methods. This is what worked with me.

    First, when I identified what the spambots read, then I figured out how to fool them.
    They read the form data; what the form posts to and what the form names are.
    They populate the form names and posts to the action.

    I removed all javascript validation. It's useless. Do 100% server side validation, verify email address are valid, links are valid, dates are valid, word count for submission, check for duplicate data for multiple form elements, etc...

    I added session ID checks and this cut down on 75% of spamming where the sessionID is in a hidden field and if the request doesn't match the sessionID, it doesn't post.

    I then separated the form from the page by using iframes.
    On the initial load of the form, the proper HTTP REFERER is comitted in a session. If the form doesn't have the allowed referer, the form doesn't load and that form is blocked for the session with the IP address noted.
    99% of the IP addresses are from China, Latin America, Russia, The Netherlands, and Africa.

    Of the 25% of spam still coming through, I had to figure out the next step to stop it without compromising user functionaliy as in CAPTCHAS. There is no way I was going to use those nor use a `click the kitten` method either.

    I rewrote the form code to change the form elements names for every load.
    It was pretty much a hack but it worked.
    I had a random 6 character word generated every load.
    I dismantled that word every 2 characters and put 2 characters in every other character for the form element names that had been base64 encoded.
    I had an empty hidden element that had to remain empty as well.
    Bots tend to take every element and give it a value.

    That seemed to get rid of the other 20%. After a while, the spam would continue at nowhere near the level it once was but we noticed that the timing was 5 minutes between replies instead of seconds meaning that the elements had to be filled out semi mechanically instead of automatically.

    After copying that format for a number of forms, the spams that were coming through were from the same pool of networks.

    After data crunching and some time, I realized that the obfuscating of element names really didn't deter much as much as sessionID and allowed refering pages did.

    I started to actually have a single form for all like forms and use that one form for multiple sites so that updates can happen across all sites at the same time instead of updating 80 or so forms across sites.
    I also am in the practice of banning IP address blocks for form access. If they really have something to say to us, they can contact us via email.

    Email you say is probably the bane of existence for us that receive spam.
    There are tons of javascript mail obfuscators and as long as you have a single email for mail contact, obfuscate it and only use that for mailto links.

    I can seriouly attest that for the past 13 months, I've never received a penis enlargement mail at that address or any other stock tip.

    My forms are hosted at a single location and have strict referer checking. Any attempt to `figure it out` by looking at the iframe source is banned.

    If I get a form with non-relevant data, that IP is banned and all my sites and forms benefit.

    I've gone from 300-400 form requests a day to the legitimate 10 valid responses a day

It is easier to write an incorrect program than understand a correct one.

Working...