Posted by ljmacphee on December 30, 2008 under security, things you should know | 
One of the more fun things to do with your blog is to post to it remotely from Flickr, your cell phone, email etc. I remote post to my personal blog, the rest I sit at a computer and log in to to write posts.
If you only write posts while logged onto WordPress you don’t need xmlrpc.php. This file is included only for remote publishing. When I installed WordPress 2.7 I turned off trackbacks and xmlrpc in my settings.
Despite turning it off the non-technical sites got slammed with trackback spam and comment postings from non users. Akismet caught all of it but I’d rather not have it even hitting Akismet.
If you do not do remote publishing on your blog I strongly recommend deleting the xmlprc.php file. Many of the WordPress security updates have come from problems with this file and assuming you haven’t done anything too creative with your WordPress install it’s your weakest link in security.
If you post to your blog from Flickr, email, Google Docs or similar clients you’ll need to leave in xmlrpc.php as they need it as an interface to talk to your blog.
If you allow trackbacks on your blog you need to leave the trackback.php file in your Wordpress install. If like me, you don’t allow trackbacks, go ahead and delete trackback.php. For me the spam to legit trackback ratio is just too high to be worth the trouble.
I don’t know why turning both of these off in 2.7 doesn’t work, perhaps a future patch will correct it?
More information:
How to combat WordPress trackback spam
Guide to reducing WordPress Trackback spam and comments
XML-RPC at SourceForge
XML-RPC WordPress Codex
Weblog Client (lists clients that require xmlrpc on WordPress )
XML-RPC Changes in WordPress 2.7
XML Rewriting Attacks: Existing Solutions and their Limitations
Posted by ljmacphee on July 21, 2008 under things you should know |
If you are new to web development or if you are debating which tools to use for your site you’ll want to give this paper a read. It covers all the main and many less common technologies. Descriptions, pros and cons of the various web technologies are covered.
Web-based application developers face a dizzying array of platforms, languages, frameworks and technical artifacts to choose from. We survey, classify, and compare technologies supporting Web application development. The classification is based on (1) foundational technologies; (2)integration with other information sources; and (3) dynamic content generation. We further survey and classify software engineering techniques and tools that have been adopted from traditional programming into Web programming. We conclude that, although the infrastructure problems of the Web have largely been solved, the cacophony of technologies for Web-based applications reflects the lack of a solid model tailored for this domain.
Download (pdf) Survey of Technologies for Web Application Development
Posted by ljmacphee on July 7, 2008 under security, things you should know |
I. Take your site offline.
You can do this with a temporary redirect in your .htaccess file.
RewriteCond $1 !site-offline\.html$
RewriteRule ^(.*\.php)$ http://www.yourwebsite.com/site-down-message.html [R=302,L]
2. Download everything on your website to a safe computer at home. You will want to see what went wrong and it’ll serve as an emergency backup.
3. Check all your CMS ( content managment software ) for new versions and load new, clean versions on to the site.
4. If you have a clean back up of your site upload it now, taking care not to over write the new CMS.
5. Check everything, then check it again. Make sure everything is clean and you’ve prevented future attacks by what ever method the attacker entered.
6. Check Google Webmaster tools to see if you’ve been banished and check Stop Badware. Let them both know your site has been attacked, cleaned, and it back up again.
— Many of the newer attacks plant things in your MySQL database to reinfect your site once you’ve cleaned it so be sure to wipe them too.
— But since no one is ever thinking I’ll be hacked today I think I’ll do a back up, you might not have a clean backup. Contact your hosting company, they might if you don’t.
— If there are no clean back ups you’ll have to do it by hand. This means you must find a corrupted file and see what the attacker added. Usually it will be in an iframe. If you have a Mac or Linux box you can go to the root directory of the website files and type
grep -R ‘iframe badStuff’ *
and get a list of every file that has the bad stuff in it. Replace badStuff with what ever string the attacker placed in your files. Do this also with the directory holding your MySQL backups. MySQL backups are text files and easily edited by hand.
If you have Windows you will need to download a copy of grep from WinGrep.
If you use
grep -Rn ‘bad stuff’ *
it will also give you the line number the bad stuff is found on each file.
Keep grepping for corrupted files and cleaning until you have a clean copy of your website.
Next check with all the content management systems you are using for updates. Very likely there has been an update to what ever software was hacked. Upload new, clean copies of the blogging, photo or other software. Then upload your cleaned files and restore your cleaned databases.
Download everything and check again to make sure you were not re-infected.
Now if you can run cron jobs on your webhost you will want to run the following script daily
find . -mtime -1 -print | ls -lt
And have it email you the results. This will send you a list of every file that has been changed in the last 24 hours. This way you can keep a close eye on your site until you are sure everything is locked down and secure.
And remember you can’t have too many backups.
Lastly contact Google to let them know your site is clean again
More information:
Know your enemy: web application threats
Posted by ljmacphee on June 5, 2008 under security, things you should know |
Since getting hacked last month I’ve seriously tightened up security. But it would be nice to stop attempts before they even get to the website. That is what Bad Behavior tries to do. It is a plugin that should work with just about any php based content management system.
Bad Behavior for WordPress and most other popular CMS
Bad Behavior Coppermine Plugin
Bad Behavior is completely different from any other anti-spam solution out there, in that it doesn’t specifically target spam itself. Rather, it targets the methods by which the spam is delivered. Until I released the first version in 2005, this approach had never been tried. It proved very effective at stopping a lot of malicious activity, not just spam: It also blocks many email address harvesters, meaning less e-mail spam, and some types of automated cracking attempts, improving your server’s security.
While a somewhat similar solution called mod_security exists, it has a rather different purpose, doesn’t target spam, and regular people can’t install mod_security on their shared web hosting accounts. Bad Behavior blocks spam as well as other malicious activity and can be installed by anyone.
On some high traffic sites, or those specifically targeted by spammers, the traffic from these spam attacks can be so excessive as to exceed your account’s bandwidth limits, or overload the server, and cause your account to be suspended. Bad Behavior helps to prevent both of these situations by blocking malicious activity as soon as possible, before either bandwidth or CPU are expended on a request which will turn out to be bogus.
It’s not the only tool you need but it is a great front line defense. The workings are straight forward; first BB checks the white list, then a known list of bad ips are checked, then bad user agents, then corrupted user agents. If POST is done instead of GET more tests are run. The author claims it runs by ‘black magic’. Looking at the simplicity of the code I have to say that is a good description.
You’ll also want the BB log reader for WordPress so you can see what Bad Behavior has been doing.
I found most of the bounces I had were from known trouble makers or browsers whose headers did not match what was expected of a particular browser.
I also found that BadBehavior gave a fair number of false positives. This doesn’t bother me so much on the Coppermine sites but it is one of the reasons I wrote the TTC Security plugin for Wordpress.. The second reason is that it is not easy for the user to change the criteria. I made this easy to do on the TTC Security plugin. So if those are important use the TTC security plugin, if not, use BadBehavior but use something. It also slows down posting a great deal. On the flip side it is quite a bit stricter than my plugin.