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 August 29, 2008 under how to, php, security |
If something happens in your php script you may want to force an HTTP error, rather than continue or redirect the user to another page. This is very simple to do. Just be sure the first line of output from your script to the browser is
header(’HTTP/1.0 403 Forbidden’);
or
header(’HTTP/1.0 404 Not found’);
Or which ever standard code other than 200 you wish to send.
If you are using the Security Plugin instead of redirecting the attacker to an error page you can send back an HTTP error.
There are two HTML Error pages in the security script, one for blocked ips, one for all else.
// print error page
print “<html>\n”;
print “<head><title>Banned</title></head>\n”;
print “<body>\n”;
print “<h2>Banned: $blacklisted: $code</h2>\n”;
print “<p>If you believe this to be in error please contact <a href=\”mailto:timestocome@gmail.com\”>timestocome@gmail.com</a>”;
print “</body>\n”;
print “</html>\n”;
What you will do is remove or comment out the error page and in it’s place put:
header(’HTTP/1.0 403 Forbidden’);
No print, no extra quotes - use it just as I have it here.
$code = “Sorry but you are listed on our ip blacklist”;
global $wpdb;
header(’HTTP/1.0 403 Forbidden’);
exit();
Feel free to use any of the standard codes.
HTTP/1.1 Error Codes
Posted by ljmacphee on August 6, 2008 under coppermine, mysql, security |
Coppermine 1.4.19 has been released to fix a MySQL injection flaw, again. This is how TimesToCome was hacked last April and why you now have all these shiny new security tools and information on this website.
I went to the Coppermine site only because there was a huge increase in cross site scripting attempts last night on the Coppermine albums.
Anyhow update if you have not.
Posted by ljmacphee on July 28, 2008 under security |
Way back yonder when spam first started to appear on the internet, long before filter programs, the first thing everyone did was use a white list.
A white list let in all the email by people you knew and dumped everything else in the trash can. It totally kept out spam. It also kept out anyone whose email address had changed or that you hadn’t yet met since those addresses weren’t yet on your white list.
So white listing fell away and blacklisting came to be in the world of email. Now everything wound up in your in box except what you had told your email program not to let in. This too works but you have to get a bad email first to know what to block. So it took time to build up rules that kept most bad things out. And those rules lists could get awfully long.
Most security programs on your computer work the same way. Some things get white listed, some things get blacklisted. Too much white listing keeps good things out, too little blacklisting lets bad things in.
The security plugins I just wrote for WP work on black lists. You need to tell it what not to let in. As time goes on and new problems appear, the black list needs to be updated to reflect new threats. This is what your home anti-virus software is doing when it is updating daily.
Black listing has improved with centralized black listing. This allows us all to compare black lists, blacklisting is more accurate and much faster this way. [ Spamhaus, Stop Forum Spam, Emerging Threats, rules ]
White listing is slowly coming to the internet. I expect before too much time goes by you will have a master login that lets everyone know you are a good guy. We have fought for anonymity on the internet long and hard. but unless we can come up with something better than white and black lists it may not be a choice.