Archive for the 'WordPress' Category
Bad Behavior 2.2.6 and 2.0.48 have been released. This update is a security update for WordPress users and affected users should update as soon as possible.
Please note: The 2.0 series of Bad Behavior is receiving limited updates, including unblocks, bug fixes and security fixes only. Users who have not yet updated to the 2.2 series should plan to update as soon as possible. Support for the 2.0 series will end June 30, 2013.
Who Should Update?
WordPress users should update to prevent cross-site scripting (XSS) attacks targeted against the blog administrator(s). Users of other platforms are not affected by this issue, but port maintainers may wish to take a moment to check their ports for similar issues.
Download
Download Bad Behavior now.
What’s New?
Changes since 2.2.5 and 2.0.47:
- Due to a change in the way PCRE works, input validation code added to the previous release to guard against cross-site scripting attacks failed to work properly on PHP versions higher than 5.2.6. This issue has been fixed.
Support
Bad Behavior still needs your support. If you haven’t donated recently, or at all, donate today to ensure that I can keep going in the fight against our mutual enemies, the spammers.
Bad Behavior 2.2.5 and 2.0.47 have been released. This update is a security update for WordPress users and affected users should update as soon as possible.
Note that due to the security validation used in this release, the WordPress system requirements have changed. Bad Behavior 2.2 now requires at least WordPress 3.1 or higher; Bad Behavior 2.0 requires at least WordPress 2.9 or higher.
Please note: The 2.0 series of Bad Behavior is receiving limited updates, including unblocks, bug fixes and security fixes only. Users who have not yet updated to the 2.2 series should plan to update as soon as possible. Support for the 2.0 series will end June 30, 2013.
Who Should Update?
WordPress users should update to prevent cross-site scripting (XSS) attacks targeted against the blog administrator(s). Users of other platforms are not affected by this issue, but port maintainers may wish to take a moment to check their ports for similar issues.
Download
Download Bad Behavior now.
What’s New?
Changes since 2.2.4 and 2.0.46:
- Several XSS vulnerabilities were found by a third party and disclosed on a security web site a few days ago. Since I was never notified directly prior to the disclosure, it took longer for me to respond than it normally would have. These vulnerabilities have been fixed through the addition of sanitization and input and output validation. Thanks to Mark Jaquith who provided a patch partially addressing the issues.
Support
Bad Behavior still needs your support. If you haven’t donated recently, or at all, donate today to ensure that I can keep going in the fight against our mutual enemies, the spammers.
Bad Behavior 2.2.3 has been released. This is a strongly recommended update for WordPress users; it is optional for users of other platforms.
Port maintainers should take note of an additional callback function which needs to be implemented in your ports prior to releasing this version.
Who Should Update?
WordPress users should update to take advantage of bug fixes and a new feature in this release. Users of other platforms do not need to update.
Users who have not yet updated to the 2.2 series should plan to update as soon as possible. Support for the 2.0 series will end June 30, 2013.
Download
Download Bad Behavior now.
What’s New?
Changes since 2.2.2:
- WordPress: The WordPress automatic update system destroys a user-provided whitelist.ini file, making it difficult for WordPress users to maintain a whitelist. For this reason, Bad Behavior no longer uses whitelist.ini on WordPress. Instead, a new administrative page is now available where users can manage their whitelists within WordPress.
- WordPress: Some code which was present for backward compatibility with very old, no longer maintained versions of WordPress has been removed.
- WordPress: A bug causing cookies to be malformed in an uncommon server configuration has been fixed.
- The code which checks whether a form submission originated from the same web site now considers hostnames beginning with “www.” and without “www.” to be equivalent.
Port maintainers should note that a new function bb2_read_whitelist() should be implemented in order to read the whitelist on any host platform. This will allow you to implement your own administrative pages if you desire (saving the whitelist is up to you). For backward compatibility, Bad Behavior will by default load the whitelist.ini file if you haven’t implemented this function, but this will be removed in a future release. See the default implementation in bad-behavior-generic.php and contact me if you have any questions.
Support
If you didn’t read my appeal last month including the roadmap for Bad Behavior 3.0, please check it out. While many people stepped up and donated last month, and I appreciate even the smallest donations, I did not receive nearly enough donations for me to put significant time into the project.
Bad Behavior still needs your support. If you haven’t donated recently, or at all, donate today to ensure that I can keep going in the fight against our mutual enemies, the spammers.
It’s that time again.
Time for me to take Bad Behavior, throw its core engine away and rewrite it from scratch.
For the second time.
Why?
As of now, Bad Behavior is shockingly effective, as one user said, at blocking automated spam and other malicious activity. However, that doesn’t catch all possible spam. There’s one important class of automated spam I would like to catch but cannot right now: that is delivered from hijacked Web browsers. This accounts for virtually all of the spam that Bad Behavior currently misses.
I believe I have a good strategy for catching this class of spam, but Bad Behavior’s current design won’t accommodate it.
In addition, there are a number of features which were pushed to post-2.2 because the current design won’t easily accommodate them either.
Thus, it’s time to redesign Bad Behavior.
I’ve already begun laying out Bad Behavior 3, and depending on the time available to me, I hope to have an alpha quality release by the end of the month.
To make that happen, though, I need your help right now.
Core Changes
Bad Behavior 3 will include an automatic update facility which you will be able to use to keep Bad Behavior up to date automatically, even if your host platform does not allow for automatic updates. For host platforms that have their own automatic update process, such as WordPress, you will be able to choose which process you want to use to keep Bad Behavior updated. Updates distributed with this new method will be protected via digital signature.
Bad Behavior 3 will support internationalization and localization, with translations available in as many languages as I can find translators for. Bad Behavior will use the PHP gettext extension, which is available on virtually all platforms including Windows, for core i18n/l10n. I will make a call for translators sometime in the next few days.
As of now, Bad Behavior 3 will require PHP 5.2 or later. If your server is still running some antique server software, now is a good time to update it.
Platform Connector Changes
Bad Behavior’s platform connectors will also be completely redesigned; the API for version 3 is completely different from version 2 and will not be backward compatible. The new design will enable features on various platforms which were difficult or impossible before, such as PostgreSQL support and a special page on MediaWiki, better Drupal 6 and 7 integration, a 100% functional generic platform out of the box including SQLite support, and many other things.
In cases where platform connectors provide platform-specific text, Bad Behavior will use the host platform’s i18n/l10n functions instead of using gettext directly. This will put some extra work on both myself and translators, but it is necessary to ensure maximum compatibility with all possible host platforms.
The integrated administrative pages which currently exist for WordPress will be generalized as much as possible, so that their functionality can be provided for multiple host platforms. Because every platform has a unique method of handling administrative pages, this may not be complete for all platforms at 3.0 release. At minimum, though, platforms which provide such administrative pages should all be able to change Bad Behavior’s settings and manage a whitelist through such a page.
For platforms capable of it, a second administrative page will allow full searching through Bad Behavior’s database, as the WordPress port does today, in addition to export functionality which you will be able to use to send me copies of spam you have received or other traffic that you think should have my attention. This export process will be released for WordPress shortly. As always, I hold such submissions in strict confidence, on encrypted media, use them solely for security analysis, and destroy them within 90 days. I never use personally identifying information which might be present in such submissions.
Database access has been generalized further so that different platforms can provide database access in their own unique ways. This new design is highly database agnostic, and fairly closely resembles Drupal’s database abstraction. It allows for the use of almost anything from SQLite to Oracle and much in between, including the use of database masters/slaves as in MediaWiki.
Development Process Changes
The test suite planned for Bad Behavior 2.2 never quite took shape, which has resulted in several embarrassing incidents where code was released that still contained obvious errors and typos. With Bad Behavior 3, I will be building the test suite (using PHPUnit) alongside the code, ensuring 100% coverage and hopefully this will make for more stable releases.
I have set up a completely new development environment which is linked to github. Github will be the primary source code repository for Bad Behavior 3, and from it, release engineering scripts will test the code and construct releases for all available platforms. These releases will then be offered for download here and pushed to third party download sites such as WordPress. This process flow should virtually eliminate releases with syntax errors and obvious regressions.
Using github will also allow me to integrate more closely with third parties who develop platform connectors, by pulling in their updates as they make them available and by providing users with a single download regardless of host platform. I’ll be providing more details on this as work progresses.
Spam Prevention
The new techniques for blocking spam from hijacked web browsers which I mentioned above will be incorporated into Bad Behavior 3.
I am currently working on a ruleset-based design which will allow for Bad Behavior’s spam blocking rules to be distributed independently of the core and the platform connector. This will simplify most updates and allow for environments which restrict updates, such as enterprise installations, to still keep up to date on spam blocking rules. Again, these updates will be protected with digital signatures.
A feature planned for 2.2 was to allow Project Honey Pot users to provide honey pots or QuickLinks on their web sites. This is still something I want to do, and the new platform connectors should make it possible. No guarantees on this, though.
Status
As I write this, the display at the bottom of this page says Bad Behavior has blocked more than 19,000 access attempts in the last week, on this site alone. In that same time, 34 messages got through and were caught by Akismet, which I use as my secondary spam plugin.
Now I’m after those last 34.
But, as I mentioned above, I need your help.
One night back in early 2005, when I first started blogging, I got my first comment spam. Unfortunately, my first comment spam was followed by 700 more over the space of a few hours. As you can imagine, I was thoroughly pissed. I spent some time looking at anti-spam solutions, but at the time there wasn’t much, and what there was didn’t work all that well. I felt I had to roll my own. A couple of months later, Bad Behavior was born.
I still clearly remember cleaning up after that first incident, and killing link spam has become something of a personal crusade for me. But I’ve learned that I can’t possibly do it all alone. Fortunately this field has grown significantly and there are now a whole lot of smart people working on various aspects of the link spam problem. What Bad Behavior brings to the table is to take that 700 spam attack and allow fewer than one percent to reach your blog. Having to clean up 7 spam is much easier than cleaning up 700. (This is one reason why I advise using more than one anti-spam solution.)
As new spammers start up and new botnets come online, some find themselves already blocked, while others need to be analyzed and updates made to block them, so Bad Behavior will always require continuous development. Often this development is delayed because I have to pay bills. As you may be aware if you’ve been a very long time user, I lost my job in 2005 and since then I have lived on revenue from blogging and paid web consulting work. Therefore I can only work on Bad Behavior when my finances permit.
Historically, keeping up with the spammers has not been that difficult, as there is only so much the spammers can do while maintaining their high rates of spamming. Today, 100,000 or more spams in a single run is not unusual, and one spammer I’ve blocked can send 1,000,000 in a day. Bad Behavior attempts to drive up the cost of link spamming by blocking as many automated spammy requests as possible, forcing the spammers to resort to much slower manual methods, or ideally, give up and find more honest work. And Bad Behavior 3 promises to cut into the spam delivered by those much slower methods.
Only one thing remains, and that is to do the work. As I have noted before, Bad Behavior is a user-supported project. If you think this roadmap looks good, and want to accelerate Bad Behavior development, your financial contribution will help ensure that I can devote more time to its development and bring it to fruition much faster. Otherwise, I have to spend my time first on other work which brings in revenue, and that means it will be much longer before you see these features.
I would estimate that all of the above would take me about six months to complete if it isn’t otherwise funded. At the same time I think contributions totaling $500 or more would allow me time to complete the majority of the above within a month. I know that a lot of you are having financial trouble due to the economy; so am I. Even if you are unable to send a contribution, please leave your comments so that I know you support Bad Behavior and wish it to continue. And, thank you to all of you who have sent in contributions recently.
This is also the time to send in feature requests. If Bad Behavior doesn’t do something you would like it to do, please leave a comment. (And remember that feature requests accompanied by a contribution are more likely to be implemented sooner.)
On that note, if you know someone who needs custom code written for WordPress, you should also contact me.
Thank you again for your support, and here’s to a future without spam.
P.S. I am still looking for someone who knows how to deliver electric shocks over the Internet. If you do, please contact me. This could be the ultimate spam-prevention feature.
Bad Behavior 2.2.2 has been released. This is a maintenance release and is recommended for all users.
Who Should Update?
MediaWiki and WordPress users, as well as all users who have enabled the Reverse Proxy feature, should update in order to receive the important bug fixes contained in this release.
Users who have not yet updated to the 2.2 series should plan to update as soon as possible. Support for the 2.0 series will end June 30, 2013.
Download
Download Bad Behavior now.
What’s New?
Changes since 2.2.1:
- When a site enabled the Reverse Proxy option when it was not actually needed, Bad Behavior would sometimes fail to acquire the correct IP address for incoming requests. Bad Behavior’s code to detect this situation and acquire the correct IP address has been completely rewritten.
- MediaWiki: The default for the setting $wgBadBehaviorTimer has been reset to false. This setting enables an HTML comment to be inserted into wiki pages with run time information; however this causes blank lines to appear in pages with transcluded content or HTML forms. This code will be revisited in a future release.
- WordPress: A spurious PHP warning was being emitted when Bad Behavior captured a copy of incoming spam that was identified by another plugin. This warning has been removed.
Support
Donate today to ensure that I can keep going in the fight against our mutual enemies, the spammers.
Bad Behavior 2.2.1 has been released. This is a maintenance release and is recommended for all users.
Who Should Update?
All 2.2 series users should update in order to receive the important bug fixes contained in this release.
Users who have not yet updated to the 2.2 series should plan to update as soon as possible. Support for the 2.0 series will end June 30, 2013.
Download
Download Bad Behavior now.
What’s New?
Changes since 2.2.0:
- On platforms where database logging is available, Bad Behavior would sometimes continue to log even when the logging setting was turned off. This has been fixed.
- When a site enabled the Reverse Proxy option when it was not actually needed, Bad Behavior would sometimes fail to acquire the correct IP address for incoming requests. Bad Behavior’s code to detect this situation and acquire the correct IP address has been improved.
- WordPress: When a different anti-spam plugin identifies a request as spam, and Bad Behavior did not, Bad Behavior will now log a copy of that request (if logging is enabled). This is to help facilitate reporting of spam not yet detected by Bad Behavior. WordPress users may view the log by visiting the administrative page Tools » Bad Behavior Log.
- WordPress: To improve compatibility with other plugins, Bad Behavior no longer stores data in PHP sessions while screening requests.
Support
I will skip the usual speech. If you’re reading this you already know how valuable Bad Behavior is. Donate today to ensure that I can keep going in the fight against our mutual enemies, the spammers.
Bad Behavior 2.2.0 has now been released. This is the first general availability release for the 2.2 series and is recommended for all users.
Support for the Bad Behavior 2.0 branch will end June 30, 2013. All users should make plans to migrate to version 2.2 prior to that date.
Who Should Upgrade?
All users should plan to upgrade to Bad Behavior 2.2.
IPv6 users, and users who use reverse proxies, load balancers or content distribution networks such as Akamai and CloudFlare, should accelerate their migration plans and upgrade as soon as possible.
Download
Impatient? Go download Bad Behavior now. The on-site documentation has already been updated for version 2.2, so please check the documentation before upgrading to familiarize yourself with the changes and new options.
What’s New?
Bad Behavior 2.2 adds new features, including some designed to assist enterprise users with very high traffic installations on large server farms, as well as convenience features for all users and a variety of fixes and improvements.
Since Bad Behavior 2.0:
- Some additional known spammers have been identified and blocked.
- IPv6 support has been improved, including new support for IPv6 whitelisting.
- New configuration options are available for web sites running behind reverse proxies/load balancers and third party content distribution networks such as Akamai and CloudFlare. These options ensure that Bad Behavior can correctly screen requests when operating in these environments.
- Search engines are screened faster and more accurately, improving search engine metrics such as Google Page Speed and YSlow and virtually eliminating the possibility of false positives for search engines. (Bad Behavior still blocks most malicious traffic originating from search engine providers’ networks.)
- Blackhole lists other than http:BL have been removed as unsuitable for sites running Bad Behavior. Because of its comment spammer tracking, http:BL remains the only blackhole list Bad Behavior uses. (It is disabled by default; enable it in your settings if you wish to use it.)
- For platforms without built-in administrative pages, Bad Behavior has a simplified method of changing settings. Settings changes on these platforms are preserved through software updates.
- Bad Behavior’s whitelisting feature has been completely revamped. Whitelists are much easier to maintain and are preserved through software updates.
- Across the board performance improvements have been added.
- Messaging displayed to blocked requests has been significantly improved for clarity and to facilitate issue resolution.
- MediaWiki: Fixes for database access have been incorporated. It should no longer be necessary to place strange hacks in LocalSettings.php to use Bad Behavior on MediaWiki.
- WordPress: Minor display issues in the log viewer have been corrected.
- Numerous additional minor improvements.
What’s Coming?
Shortly I’ll be posting my roadmap for Bad Behavior 3.0, the next major version. This will be a ground-up rewrite of Bad Behavior incorporating lessons learned over the past seven years of fighting link spam and programming in general.
I will also once again be adding new spammers to Bad Behavior as I catch them. Analyzing spammers is an ongoing process and is probably the most time-consuming part of this whole project.
Support
I will skip the usual speech. If you’re reading this you already know how valuable Bad Behavior is. Donate today to ensure that I can keep going in the fight against our mutual enemies, the spammers.
Bad Behavior 2.1.1 and 2.0.36 have been released. These are a security release and affected sites should upgrade as soon as is practical. This security issue was fixed in both the 2.1 development series and the 2.0 stable series, resulting in today’s simultaneous release.
Please note: The 2.0 series of Bad Behavior is receiving limited updates, including unblocks, bug fixes and security fixes only. Future development is taking place in the 2.1 development tree.
Who should upgrade?
WordPress users should upgrade to prevent internal data from leaking to the web browser when the database encounters an error. Users of other platforms are not affected.
What’s new?
New in this release (since 2.1.0 and 2.0.35):
- Due to recent changes in the WordPress database code, any database errors that may occur because of WordPress, other plugins, or server trouble may be inappropriately displayed in the web browser. This could result in the leakage of information useful to attackers. This issue has been fixed. Thanks to Andrew Zhang for reporting this issue.
Download
The 2.1 development releases will not be offered through the WordPress automatic upgrade facility.
Download the 2.0.36 stable or 2.1.1 development release of Bad Behavior now!
Support
This release would not have been possible without the support of people like you who find Bad Behavior valuable enough to make a financial contribution to ensure its further development.
Your contributions ensure that I can continue to devote time to bringing you the features you want, as well as continuing work on making spammers’ lives hell.
If you haven’t already done so, consider setting up a recurring contribution for as little as $5 per year, or make your most generous one-time contribution for any amount.
Thank you again for supporting Bad Behavior development!
The first 2.1 development release of Bad Behavior is now available. It contains a number of new and frequently requested features, and may be appropriate for you. Please review the information given, and if you do not find it appropriate for you, then continue to use the latest 2.0 stable releases.
Who should upgrade?
Users who use Bad Behavior’s whitelisting features, or who customize Bad Behavior’s settings on a platform other than WordPress or LifeType, should upgrade to take advantage of new features offered in this release.
What’s new?
Development of Bad Behavior 2.1 generally follows the roadmap outlined earlier. In this initial release, the following features have been implemented:
- Bad Behavior now reads whitelists from a separate file which is preserved through updates. See below for preliminary instructions on using this feature.
- On platforms where Bad Behavior cannot store settings in the host platform’s database, Bad Behavior now reads settings from a separate file which is preserved through updates. See below for preliminary instructions on using this feature.
- Bad Behavior’s core has been reworked to facilitate testing its core logic. While the actual logic tests have not yet been written, a test mode is available for developers to experiment with. See below for preliminary instructions on using this feature.
Whitelists
Bad Behavior now reads its whitelists from a separate file named whitelist.ini. This file is not distributed with Bad Behavior, so that future upgrades do not disturb the whitelist. This means that anyone who wants to use the whitelist must download the whitelist.ini, customize it, then upload it to their server. Place the whitelist.ini in Bad Behavior’s top level directory (the same directory that contains bad-behavior-wordpress.php, README.txt, etc.).
Note for IPv6 users: At this time, single IPv6 addresses can be whitelisted, but IPv6 networks cannot be. This will be fixed in a future release.
Settings
On some platforms, such as WordPress and LifeType, Bad Behavior stores its settings in the host platform’s database and provides an interface through the host platform for changing the settings. On other platforms, Bad Behavior is not capable of storing its settings in the host platform’s database, either because there is no database, or because the database cannot be used in that way.
On these platforms, Bad Behavior can now read settings customizations from a settings.ini file. This file is not distributed with Bad Behavior, so that future upgrades do not disturb your settings. This means that on those platforms, anyone who wants to customize their settings must download the settings.ini, customize it, then upload it to their server. Place the settings.ini in Bad Behavior’s top level directory (the same directory that contains bad-behavior-wordpress.php, README.txt, etc.). This feature has been implemented for the MediaWiki and generic ports; other platforms will need to implement the feature in their platform connectors before it is available to you.
Testing
Bad Behavior’s core logic now supports “black box” testing. This won’t be of much interest to most people, except that testing will help improve the quality of the product. A test suite is still planned and will be released later.
In addition, Bad Behavior now supports a live “test mode” in which it will not actually block any requests, but will report on whether they would have been blocked. This is fully implemented in the WordPress port; to use it on other ports, the platform connector must provide a method for the platform to report the results. To enable test mode, define a PHP constant BB2_TEST.
Download
The 2.1 development releases will not be offered through the WordPress automatic upgrade facility.
Download this development release of Bad Behavior now! You can install Bad Behavior using the usual installation instructions; there are no special requirements for this release.
Remember to subscribe to the Bad Behavior RSS feed to receive notice when Bad Behavior development updates are available.
Support
This release would not have been possible without the support of people like you who find Bad Behavior valuable enough to make a financial contribution to ensure its further development.
Your contributions ensure that I can continue to devote time to bringing you the features you want, as well as continuing work on making spammers’ lives hell.
If you haven’t already done so, consider setting up a recurring contribution for as little as $5 per year, or make your most generous one-time contribution for any amount.
Thank you again for supporting Bad Behavior development!
Bad Behavior 2.0.34 has been released. It is a maintenance release and is recommended for specific users of WordPress identified below.
Please note: The 2.0 series of Bad Behavior is receiving limited updates, including unblocks, bug fixes and security fixes only. Future development will be to the 2.1 development tree.
MediaWiki and WordPress users who have not updated in the last year or so should take note of special upgrade instructions below.
Who should upgrade?
WordPress users who use the W3 Total Cache plugin should upgrade to ensure that users are not blocked inappropriately due to flaws in W3 Total Cache.
What’s new?
New in this release (since 2.0.33):
- On some WordPress installations which use the W3 Total Cache plugin, W3 Total Cache could inappropriately store the error page which Bad Behavior serves to illegitimate requests. When this happens, the cached error page would be served to subsequent legitimate requests. Bad Behavior 2.0.34 contains a workaround which forces W3 Total Cache to not cache these error pages. (To be clear, W3 Total Cache is still broken and needs an update, but this resolves the immediate problem.)
Authors of caching plugins should consider following the “standard” set by WP Super Cache: check for a constant DONOTCACHEPAGE which can be set by other plugins; and checking to ensure that non-cacheable error responses are never cached, regardless of which plugin generates them.
Support
Thank you to everyone who has chosen to make a financial contribution toward further development of Bad Behavior. Your contributions ensure that I can prioritize Bad Behavior development and make more frequent and timely releases, like this one.
Download
Download Bad Behavior now!
Special Upgrade Instructions
Users of MediaWiki and WordPress upgrading from version 2.0.20 or earlier should follow these special directions (from 2.0.21 or later, upgrade normally):
For MediaWiki: Before installing this version of Bad Behavior, manually remove (e.g. using FTP or ssh) any old versions you may have, including the lines added to LocalSettings.php. Then install the new version fresh, following the installation instructions for MediaWiki.
For WordPress: If updating to this version through the automatic updater fails, manually remove (e.g. using FTP or ssh) any old versions you may have installed. Then upload and install the new version fresh, following the installation instructions for WordPress. After doing so, future automatic updates should proceed normally.
For other platforms: No changes to your upgrade procedures should be necessary.