By mdroste on

We all know the trouble with web spamming from poker-, game-, roulette-, discount sites and so on.

At my site learn-php i put the following code at the top of index.php of the core drupal
code:

$server = getenv("HTTP_REFERER");
$ip = getenv ("REMOTE_ADDR"); 
if (preg_match("/cash/i", "$server")or preg_match("/loans/i", "$server")or 
preg_match("/buy/i", "$server")or preg_match("/credit/i", "$server")or 
preg_match("/discount/i", "$server")or preg_match("/randppro/i", "$server") 
or preg_match("/allkinds/i", "$server") or preg_match("/texas/i", "$server") 
or preg_match("/roulette/i", "$server") or preg_match("/black/i", "$server") 
or preg_match("/yunza/i", "$server")or preg_match("/hawai/i", "$server") or preg_match("/doctor/i",
"$server") or preg_match("/low/i", "$server") or preg_match("/epraha/i", "$server") or
 preg_match("/poker/i", "$server")or preg_match("/casino/i", "$server")or preg_match("/gambling/i", 
"$server")or preg_match("/game/i", "$server"))

{
    
header("Location: " . $server); // send them back

exit;
}

Of course it's a hack. But it works well on my site. As a result i get a far more realistic statistic.

I could imagine that the redirect to the "spam server" header("Location: " . $server)is a possible way to beat them with there own weapons. If we all do it this was.

What do you think about this "solution"?

Comments

mdroste’s picture

mdroste commented

the correct link to my site is:
learn-php.de

--
mdwp*

eldarin’s picture

eldarin commented

It's a nice strategy to bounce the visitors with bad intentions.

Similar techniques are used by the email spam-filtering services too, albeit usually just dropping the emails, or possibly bouncing them (i.e returning to sender). With emails bouncing - that sometimes mean unwitting people get the bounced messages, since email spammers fake sender-addresses.

With http you can't that easily fake your address - although it's not very difficult. One way the spammers could get in was by using an IP without any reverse lookup record. Many webserver services include a few IPs a many times your own nameserver.

For someone being hammered by spammers it is a quick and easy fix, though. What tool or language one choose to use to remedy the problem is not that important, as long as it works. The idea is good.

A sidenote: I am not an Apache config wizard, but I guess with some rewrite-rules it can be done in .htaccess as well ?

I use mod_dosevasive and have a packet-inspector in front my my servers, so I get some relief from the worst kind of pack, but the more intricate, sneaky ones always tries to get the better out of you.

The worst thing around now has been the HTTP 302 out-ranking as mentioned on www.webmasterworld.com ... whereby a site doing massive deferring can "steal your ranking, search spot" in Google etc.

mdroste’s picture

mdroste commented

Thanks for your interesting comment.

meinolf
--
go with us - learn php

--
mdwp*

Jo Wouters’s picture

Jo Wouters commented

Your preg_match will not stop them if they are posting links to 'p0ker' or 'c4sino' sites.

Maybe it's a better idea to check the addresses in these lists: http://www.surbl.org/
The spam module should be able to do that. ( http://drupal.org/project/spam )

mdroste’s picture

mdroste commented

I know that this little script cannot stop all spams.
But since i use it i found a very small amount of such
referrers in the admin/logs/referrers.

I will try the spam module also.

meinolf
--
go with us - learn php

--
mdwp*

signal9’s picture

signal9 commented

The spam module is helpful, but it won't do anything for the access logs and whatnot being inundated by these sites. I do wish there were a way to filter such messages out of the logs... Thanks for this interesting approach.

-----------------
Govorite po-russkij? Want to?
http://sobrania.net

laura s’s picture

laura s commented

It includes IP blocking of repeat spammers, among other things.

Laura
===
pingVision • scattered sunshine

_____ ____ ___ __ _ _
Laura Scott :: design » blog » tweet

KeithDaniels’s picture

KeithDaniels commented

I have been fighting comment spam to the tune of 3 to 5 thousand per day for 9 months now. I was successful in blocking it using spam.module but that did not do anything about the load and bandwidth usage from all of those spam post.

I set up mod_security and was able to block spam post before they got to Drupal and was able lower the server and bandwidth load considerable. So much so that there was an obvious increase in server response time. Then I started using it to block run away robots and again was able to reduce the server load.

For those with server load problems I would suggest using mod_security and if you have problems with DOS, run away robots, people downloading your entire site using wget or just want more control, you might also consider these modules or systems some of which work fine with mod_security:

mod_evasive
mod_spambot
or
scrutinizer-1.03

You can google for the download sites and more info.

Keith Daniels

sangamreddi’s picture

sangamreddi commented

Check out the badbehavior module. it has some intresting features.

http://drupal.org/node/30501

Sunny
www.gleez.com

pokerfan237’s picture

pokerfan237 commented

Thanks for advice. Only local images are allowed.

eldarin’s picture

eldarin commented

.. this thread again, and don't know how I forgot this:
You should patch your Drupal core installation and any module which uses forms. Current Drupal forms do not adhere to current well-known best practices for handling (x)html forms, and therefore is open to several automated spam attempts etc. You can see this on several issues reported elsewhere on related Drupal problems.

You should patch your Drupals to do the following:
- in the form include a secret which is generated when serving it up.
- the secret is a string of hidden type included with the form.
- the form should only be accepted if the secret is validated.

There are several ways to generate a good secret string.
;-)

This should take care of any automated http POSTing circumventing reviewing, unpublished nodes. It also resolves a whole host of other spoofing attacks you could encounter. It will require more hardcore spoofers and others to request the forms-page instead of posting directly, effectively complicating their automated spamming some.

You can also use more controls on how you deliver these forms and whether you accept them. Suffice to say there are some *really* good ways to discern if it's a spidering spambot or a true user-agent browsing your site and requesting to POST.

The best secret-string is similar to a design I had where thousands of concurrent users would have a specialized session-key syncing with servlet-running Apache and how to make it "impossible" to spoof.

Point is, design flaws makes it pretty easy to spam Drupal sites. Putting on small band-aids wherever it leaks won't help save the ship.
;-)

laura s’s picture

laura s commented

If not, I would urge you to consider doing it.

Laura
===
pingVision • scattered sunshine

_____ ____ ___ __ _ _
Laura Scott :: design » blog » tweet

eldarin’s picture

eldarin commented

Haven't gotten around to it.
The core team seems pretty much swamped right now cleaning up issues into the freeze to get the work going. I also doubt they would let a new "feature" in right now, although it's not a major workaround or legacy-code-breaker.

It's really a quick fix for anyone who wants to break spammers attacks, so I think it pertinent to advice in the right thread to those who are affected first. They're the ones who sweat over this every day. The design flaw will still take considerable time before it gets out to users - IF they upgrade (or even can upgrade in an easy way).

And no matter of spam-modules are truly effective no matter how fast they can apply band-aids to a ship taking in innumerous drops of spam.
;-)

edit: will add a feature request, so that it can get resolved sometime in the future.

edit2: actually I just found a duplicate, and upcoming solution by Jeremy from kerneltrap.org - http://drupal.org/node/28420 . Better close the one I made. ;-)

laura s’s picture

laura s commented

I take it what you describe is something not addressed with the capcha module? I believe there's also a challenge-type module that asks a simple math question. Are you describing something different?

Laura
===
pingVision • scattered sunshine

_____ ____ ___ __ _ _
Laura Scott :: design » blog » tweet

eldarin’s picture

eldarin commented

capchas are different. It is another solution when already having applied the solution I described, or not bothering to because it has been proven to not deterr the spammers attacking.

Don't be alarmed, it's not a major security hole. It's just not handled the best way - it's a design flaw which opens for spam attacks.

Capchas can actually also be beaten, so the best way is to use all the security weapons in one's arsenal if spammers are truly relentless.

If you have e.g user registration and already use capchas - and spammers can even circumvent this - then some really intricate solutions must be applied.
;-)

PS! Made the issue a critical bug (some might not agree though) so maybe it can get included for 4.7 - instead of seeing as a feature request. I think it's a design-flaw and not really a bug in itself. Drupal forms works the way they're supposed to already.

edit: see the duplicate I found resolving the issue forward on - http://drupal.org/node/28420 . Closing my request/bug. ;-)

eldarin’s picture

eldarin commented

I was just reviewing the patches for the comment and contact form POSTing of forms. The one thing that immediately strikes me is how weak the basic strings used are. Jeremy's approach with a private key generated might be better - although I did not review that part. It could require mcrypt on PHP installations, and that would be a bad thing as many have no access to this on shared hosting etc.

The problem is that all the ingredients except the random integer being used as key are all known to the spammer - thus making it practically useless as part of the hash key. MD5 is okay to use because it's blazingly fast and can be pretty secure - unless you have mostly known ingredients like here.

The point is that for you security-aware out there, a more strict secret-sting (or token) limiting reuse of ingredients or guessing of ingredients is better.

As it stands now - the limiting factor is a guess of a random integer value below 32768 on some platforms. It also reuses the random value for a whole 24h ... getting 100 spams a minute will quickly go through the numbers then - and freely spam for the rest of the day.

Well, security isn't always easy - and spammers can be very clever. Remember, they make money on this stuff ...
;-)

My tip: edit your secret-string into a simple - or very complicated - password or just gibberish - since you don't need to remember it. That way they will have a very hard time to guess the secret string based on ingredients. Spelling it out: have a unique ingredient input by the site-admin in a configuration is probably best.

For you guys remedying this on your sites now instead of waiting for 4.7 - just set a fixed string in your module-codes . Remember that it can mixup CVS-type patching if you follow some of these, but you probably already knew that.
;-)

mdroste’s picture

mdroste commented

After I post my little anti-spam script here on Aug.19, I run a test on my server... long ago.

--
mdwp*