Category Archives: Security

My (DNSBL) Blacklist list

Posted on by
Reply

Here is my current list of DNSBL’s that I use for blocking [much] spam, proxies, hijacked PC’s and “problem” IP’s.  Note that even using all of these DNSBL’s at the same time still will not prevent all spam, but when used in combination with Akismet, your site can be 99.9% spam free.

The real use for these DNSBL lists is to block open proxies and other IP’s that can cause trouble:

  • rbl.efnetrbl.org
  • spam.spamrats.com
  • combined.abuse.ch
  • xbl.spamhaus.org
  • web.dnsbl.sorbs.net
  • dnsbl.ahbl.org
  • problems.dnsbl.sorbs.net
  • opm.tornevall.org
  • cbl.abuseat.org
  • dnsbl-2.uceprotect.net
  • dnsbl.mags.net

Is your Drupal data safe ?

Posted on by
Reply

There are many modules available for Drupal to back-up your Drupal site, but I’ve always felt that in addition to backups on your server the best (and more secure) way to get the data was directly from the database – and the best place to store that data is OFF/AWAY from your server and on your local PC hard drive, included in your local PC data backup scheme. Keeping the data locally will not only protect you from catastrophic server issues, but will also protect you from the occasional “my hosting company locked me out of my account!” issues that I read about all the time.

Don’t forget that in addition to the MySQL data, you also need your Drupal files which can easily be downloaded/backed-up using FTP.

If you have never done a MySQL data export, don’t fear, it’s spelled out at the Drupal.org website: Export Drupal Data

For all you WordPress users, all this applies to you too if you value your blog.

Cootsinnovationregister .. Yah.. Cootsinnovationregister !

Posted on by
2

Crazy FaceAfter what I thought was a flawless Drupal integration with Facebook, after a day or two I ran into one problem: Cootsinnovationregister

For some reason, when visitors did a Facebook “Like” or “Share” on some pages, instead of posting the page title and description to their Facebook wall, only the word “Cootsinnovationregister” would be posted. Google turned up very few results for the word Cootsinnovationregister, and it certainly had no obvious meaning to me.

After a little troubleshooting with the Facebook Linter tool, I was able to narrow down and resolve the problem. It seems that with Mod_Security enabled, Cootsinnovationregister was being returned as the Page Title and Description. There was no mention in the Mod_Security logs, and I don’t know if the ‘Cootsinnovationregister’ string is particular to just my site or all sites/servers using Mod_Security – but if you are having the same problem and came here via Googling “Cootsinnovationregister”, here is the fix: Whitelist all of Facebook IP’s in Mod_Security and Facebook will then be able to correctly access and read your webpages, titles, and page descriptions – no more Cootsinnovationregister! If you have trouble getting the Facebook server IP’s (there are several!) hit me up via my contact page or on my Facebook page, and I will be happy to send you the entire list.

UPDATE: After much obsession and digging, I finally found the real cause of this issue: We have a custom Mod_security rule that detects a specific kind of invalid header. Because this type of invalid header configuration is a common trait of spammers and because so many bots hit the server with this type of header, all logging and auditing was disabled. Instead of blocking requests with this invalid header, we re-direct them to our HoneyPot.. Which has a page title of, you guessed it, “cootsinnovationregister”.. It turns out that the Facebook servers also have this ‘invalid header’ and were getting redirected to the honeypot. Because we already had some of the Facebook servers whitelisted, but not all of them, the issue was intermittent.

Chances are you will never see this issue with the specific wording that I was seeing, but it is possible that you would see something similar – Facebook pulling incorrect page titles and descriptions..

Disable CSF blocking without disabling CSF

Posted on by
Reply

Yet another of those seemingly simple things that seems impossible to accomplish until you realize how simple it is.

The problem:

You use CSF to block proxies, servers, trolls and spammers and have amassed quite a large block-list in your CSF.DENY file.  For whatever reason (probably troubleshooting) you want to temporarily disable blocking all the IP’s in CSF.DENY, but you don’t want to lose the firewall protection by fully disabling CSF.  A quandary!

The solution:

Create a new text file and call it something like CSF.PERM and place it into the same directory as your CSF.DENY file (probably /etc/csf).  Move (cut & paste) all of your permanently blocked IP’s and CIDR ranges from CSF.DENY into your new CSF.PERM file.

Add the following line into CSF.DENY:

Include /etc/csf/CSF.PERM

  (you may have to adjust the path)

Restart CSF for  your changes to take effect.

Now when you want to disable your IP blocking list, just comment out the Include line you added into CSF.DENY like this:

#Include /etc/csf/CSF.PERM

  (just put a # in front of it)

Restart CSF and the firewall will now be active, but your block-list will not be active (easy!)

To re-enable your IP block list, just UNcomment the Include line by removing the # and restart CSF.