Prepping for a dive and snorkeling trip in search of Lionfish in a Key Largo canal. We took the kayaks a mile to the mouth of the canal in the ocean, and snorkeled and dove along the dropoff into the channel. Roger later nets a Lionfish he’s been hunting for a year.
Roger spotted this invasive Lionfish in their canal in Key Largo. We scooped it up and disposed of it! This was my first video with the GoPro, sorry for the shaking!
With the recent public exploit of W3 Total Cache and the release of WordPress 3.5, it’s high time to tighten up security across the board on your WordPress blog. Here are a few things you can do to clean things up.
Perhaps one of the most important things you can do is clean up your file permissions. A lot of modification, use, and upgrading can cause your permissions to go askew. Here are two simple commands you can issue from the linux prompt which quickly and easily fix up file permissions recursively:
find /var/www/wordpress-root-directory/ -type d -exec chmod 755 {} ;
This changes all of your directories to 755, which is what WordPress recommends. Next:
find /var/www/wordpress-root-directory/ -type f -exec chmod 644 {} ;
This changes all of your files to 644, which is also what WordPress recommends. Lastly:
chmod 440 wp-config.php
Issue this command on wp-config.php to ensure that it’s only readable and writable by you and the web server.
Make sure to update ALL of the items that can be updated. This includes the WordPress core, all plugins, and all themes (even the ones you’re not using). This helps to ensure that all known security patches have been applied. Even unused theme files can supply the needed security holes that hackers take advantage of.
If you have unneeded themes or plugins, remove them. It’s just extra overhead, and provides more gateways for exploitation. Also, any scripts, files, or other things that aren’t needed for WordPress should be removed unless they’re needed for some other necessary function.
Go ahead and change ALL of your passwords – FTP, WordPress, cPanel, etc. Any account related to your WordPress install can provide an attacker with a gateway to your site. Use the obvious password length and character rules here – it’s incredibly easy to use a computer program to guess every word in the dictionary against your site, so use non-dictionary terms in combination with symbols and numbers.
Add the following to your wp-config.php file to remove the file editors from the wp-admin area. These features are terrible file editors and can lead to exploitation if left active.
[code language=”php”]define( ‘DISALLOW_FILE_EDIT’, true );[/code]
In my opinion, the file editors have little practical use and should be disabled in all production environments.
Go to this link to generate custom salts for your site if you haven’t done so yet. These keys should be updated in wp-config.php.
You are creating a regular backup and storing it off-site, right? No? Well get started. Most hosts provide a convenient way of doing this. If not, try a search for “backup wordpress” and you’ll find tons of literature on the subject. Believe me, nothing sucks worse than getting hacked or having a server crash, and not having a backup. It’s catastrophic to lose all of your hard work. Here’s how to create a full backup from the bash prompt under linux.
Navigate to your document root. This is usually the directory directly below your WordPress directory. Issue the following command:
tar czf filesystem-backup.tar.gz httpdocs
Depending upon the size of your site, this could take a few moments or it could be instant. It will create a compressed archive called “filesystem-backup.tar.gz” containing all of your site’s files. Copy this archive file and store offsite. Next, you will want to backup your database. Hopefully your host has the mysqldump utility installed. Just issue the following command tailored to your environment:
mysqldump [-h dbserver] -u [dbuser] -p[dbpass] [dbname] > database-backup.sql
The “-h dbserver” part only needs to be used if you have an external database server (non-localhost). Also, remember there should not be a space between the “-p” switch and the actual password. Copy “database-backup.sql” along with the filesystem archive and you have everything needed to restore all aspects of your WordPress site!
Most of these items need to be done at regular intervals to minimize your chance of compromise. My biggest recommendation is to keep everything updated. Any major security issues should be addressed promptly by the WordPress core team, plugin developers, or your theme’s author. This is by no means a definitive guide on WordPress security – Tweet me @CodeNinjaRich if you need guidance, advice, or consulting services. Good luck!
Thanks to the release of http://seclists.org/fulldisclosure/2012/Dec/242 on Christmas Eve, I’ve spent my holiday working security for several sites.
This exploit allows an attacker to take advantage of the “open” nature of W3 Total Cache’s cache files to extract password hashes from the database cache. I agree with Jason on this – why did the author of W3TC keep these directories open? The plugin already modifies .htaccess, why couldn’t they simple add
"Options -Indexes"
for the cache directories and keep everything a bit tighter? This security “misconfiguration” was not documented by W3TC or WordPress (that I could find) and it could lead to a catastrophic security breach. Since the potential bug is caused solely by W3TC, I believe it’s their responsibility to add the necessary fix, and not leave it up to site admins.
After further investigation, the fix suggested by Jason does not work on my servers (don’t know why). Here is my fix, which does the trick and causes w3-total-fail to totally fail.
Navigate to your /wp-content/w3tc folder and add a new .htaccess. Inside it, add the following:
[code]<Files *>
order deny,allow
deny from all
</Files>[/code]
Restart your web server for good measure with
/etc/init.d/httpd restart
or the equivalent for your server. Jason’s tool will no longer work against your site, but go ahead and check it once again for good measure. The tool should still show “Attempting…” repetitively, but this time it will iterate through the directories at a much faster pace because it can’t access the contents. No more hashes will appear.
I’ve pondered upon the topic of W3 Total Cache’s security for quite some time, and I’m well aware of this and a few other possible issues with W3TC. I’m surprised that it’s taken this long for someone to have the same thought and attempt to exploit WordPress using this concept.
Anyways, WP-Admins should download this and check the security of their sites and patch their sites accordingly. Hopefully Frederick Townes will release a self-patching version of W3TC really soon, as many WordPress sites heavily rely on this plugin and I’m sure most admins aren’t even aware of this security threat. Merry Christmas!
At first, this may not seem to have any real-world use, but consider this: You need to set up an independent development environment for your site, and you’d rather not copy gigabytes of files from your production server’s wp-content directory. Without the following function, keeping everything synced could turn into another full-time job, especially if your editorial staff is posting hundreds upon hundreds of articles each day.
Here’s how it works: This filter interrupts the output of wp_get_attachment_image and replaces the returned image tag’s src attribute with your production server’s url, therefore effectively telling the page to read images from a different server than the page is served from.
So here’s the WordPress code that makes it all happen. Put it in a file in your development server’s mu-plugins directory so it doesn’t get overwritten with theme synchronizations. Remember to swap out “yourserver.com” and “dev.yourserver.com” with appropriate values.
[code language=”php”]
<?php
function rewrite_images( $atts ) {
$atts[‘src’] = str_replace( ‘dev.yourserver.com’, ‘yourserver.com’, $atts[‘src’] );
return $atts;
}
add_filter( ‘wp_get_attachment_image_attributes’, ‘rewrite_images’ );
?>[/code]
What other creative uses can you think of for this snippet? Leave me a comment below!
http://www.richandtina.com/my-first-attempt-at-blogging/ Head over to our wedding website to read Tina’s first blog entry.
It has again been quite a while since I’ve written about our baby, mainly because up until now there hasn’t been much to say! It seems to me that it has been as normal a pregnancy as possible.
We’re getting close now! The third trimester is here and we’re starting to actually prepare for the arrival of our baby boy. Tina’s parents hosted a wonderful baby shower last weekend (view the photo gallery here) where we got to share our joy with family and friends. It was a lot of fun and we are very grateful for the amazing event that Don and Silvana put together. Thanks to all the guests and out-of-towners who sent gifts for our baby. We can’t express how thankful we are for your love and support!
So now we’re down to the final couple months before baby comes and it’s time to prepare. Here’s what we’re getting our hands dirty with lately:
We are fairly certain that we’ve picked out a name for our boy but it’s not definite until we sign the birth certificate.
I guess the next stop for this blog section will be baby room pictures. Stay tuned!
A YouTube video shot by Silvana and Don during the baby shower.
[youtube http://www.youtube.com/watch?v=q3fBvg2fPm8%5D
A few random shots taken in and around Daytona Beach after the baby shower.
