Defending Against a WordPress Brute Force Attack

Security experts are warning about a large botnet attacking WordPress sites using brute force attempts to break passwords.

It is important to note that WordPress is not insecure.  It is a target fir hackers due to the massive number of installed sites., Many of these are installed using “Admin” as the user, and with “password123″ as the password.  You have that, there’s a reason you’ve been hacked.

Do yourself a favor, protect your WordPress site from brute force attacks – hire a professional to install it or at least to run a security audit on it. If your site is hacked, email me and I can try to fix it.

Here is a list safety measures to protect you from a WordPress Brute Force Attack

  • Install the plugin to Limit Attempts to Access Admin – this may not stop it cold as some reports have the current attack using over 90k ip addresses.  Still, this is worth while. http://wordpress.org/extend/plugins/limit-login-attempts/
  • Change your password (and ALL passwords for your site ) to something that uses at least 8 characters, including numbers, symbols and uppercase.
  • Do not use “Admin” as your user name.  If you do, set up a new administrator account and delete the admin user.
  • You can install a second layer of security by installing an htaccess password.  Instructions here.

If you can’t do this, then please contact me and I can do it for you.

Blue Ice now available!

blue_ice_coverBlue Ice  by Mark N. Cahill (yeah, that’s me) is now released.  You can find it on Amazon.com, at Createspace.com, on the Kindle, and on the Nook.  Additionally, it’s up on Goodreads.com and I’ve been accepted into their Authors Program.

There will be a book release party on 4/6 at Sakura Tokyo in Worcester at 7:30 which is open to the public.  Cash bar, and there will be a band in the lounge at around 9, so join us for dancing and fun with friends.

So the book…

I started writing it a long time ago.  It was pretty much complete in 1998, and was on the publication list for Little, Brown and Company that year for a little while, but it got bumped by James Patterson, if I recall correctly.  It was then picked up by Vantage for their summer list, but dropped due to budget cuts.  No one seemed to want to give a first time writer the love in those days.

So I recently decided I was ready to start writing again and I decided it would border on criminal not to release Blue Ice before I started on anything else.  So I have.

Blue Ice is a story about a pair of US Treasury agents on the trail of diamond lasers that are being illegally shipped out of the country.  IN the process they meet an engineer, Jim Anderson, who becomes involved in the development of synthetic diamonds.  That puts everyone around him in mortal danger as the diamond cartel ruthlessly attempts to protect their monopoly.

It is a fast past techno-thriller which will keep you on the edge of your seat.  I certainly hope that you get as much enjoyment out of reading it as I did from writing it.

Migrating from Drupal to WordPress

On my personal blog, I just posted a series of Mysql database scripts that will help you migrate from Drupal to WordPress (Drupal 6.22 to WordPress 3.4.2 specifically).  I was very surprised to find so little out there on the subject.

You can read my full post on the script at Allthingscahill.com – but I thought I’d put a few observations here.

  • Drupal content in the 6.22 version at least contains tons of inlines styles.  This will make it hard for you if you’re doing a major theme shift.  On the other hand, your content block will most likely maintain its formatting if you’re not making a big change.
  • The db to db script I worked with does not move the images into the media library. If I had more time and if this site was staying in WP, I’d definitely go a different route and use the db scripts to create a WXR file for import so my content is properly moved.
  • Drupal categories apparently aren’t completely unique.  It was a problem for my move, as Snark appears to be the same category slug as snark to WordPress.  It took a little data massaging to get it right.

Well, give the post a read if you’re looking for more info on how to migrate Drupal to WordPress.  If I do another move, especially from Drupal 7, I will most likely create a WXR and perhaps I’ll release the script for reuse or hand it off to my friends at Automatic (the folks who make WordPress).

Google SEO Guide for A/B Testing

For established sites, big changes virtually require A/B testing to ensure continued we maintain our search engine rankings.  For most of us, this is a gray area fraught with danger.  Any prudent developer worries what’s going to happen if they make a mistake.

Today SearchEngineLand brings us the Google SEO Guide for Multivariate A/B Testing

No Cloaking

Use rel=“canonical”

Use 302s, Not 301s

Don’t Run Experiments Longer Than Necessary

Go to the article for the full text.  For the most part, this is what we expected., Google hates cloaking in all forms, a canonical link is a no brainer, and 302 redirects are made for just this type of circumstance.

You aren’t A/B testing big changes?  Click here to find out more from Smashing Magazine….

 

Welcome to Retina-stan

Quote

The Web, Balkan-ized

The old George Santanaya quote that “Those who cannot remember the past, are condemned to repeat it” has reared its ugly head once again, and this time its turned up in the world of web design.

In the dark old days of the nascent web, mistakes were made. The two browser giants, Microsoft and Netscape allowed their paths to diverge, and webmasters (we did it all back then, no specialists required) were forced to separate elements of their presentation for one browser or the other using Javascript sniffers; little bits of code that would send the viewer to one page or another based on what browser was detected via the user agent.  It was hugely ponderous and we all feared what might happen if there were 4, 5 or even 6 viable browsers we needed to code separately for.  But thankfully the issue was resolved by CSS and our fears were averted.

Meanwhile in the present day, designers have to deal with a web that requires a “responsive” design – on that by using @media queries will present the appropriate css 3 styles to a browser, be it on a phone, tablet, laptop or whatever. Essentially, we’ve created a variable driven CSS; one of the things we realized virtually from the outset of CSS that was missing.  Say good bye to those funky old conditional comments calls that allowed use to work around that failing.

Now we have retinal displays, which unlike the phones and tablets that require different widths and sizes, actually changes the pixel density of the images and fonts that are presented.  It’s all pretty cool, but honestly, its also more work if you want to do it right.

To find out how to do retinal displays correctly with CSS 3, I direct you to the latest from Smashing Magazine, entitled “Towards a Retina Web“.

With the recent announcement and release of the Retina Macbook Pro, Apple has brought double-density screens to all of the product categories in its current lineup, significantly paving the way for the next wave of display standards. While the fourth-generation iPhone gave us a taste of the “non-Retina” Web in 2010, we had to wait for the third-generation iPad to fully realize how fuzzy and outdated our Web graphics and content images are.

In the confines of Apple’s walled garden, popular native apps get updated with Retina graphics in a timely fashion, with the help of a solid SDK and a well-documented transition process. By contrast, the Web is a gargantuan mass whose very open nature makes the transition to higher-density displays slow and painful. In the absence of industry-wide standards to streamline the process, each Web designer and developer is left to ensure that their users are getting the best experience, regardless of the display they are using.

That walled garden unfortunately won’t be contained.  To continue the analogy, the crops have propagated out onto the neighbors fields.  Retina displays are coming whether you like it or not.

So here we are, now our designs must support not only all major web browsers, but also all form factors presented by tablets, phones, etc. In widths alone, we ought to be considering everything for 1600 px wide, down to 300.  Now throw on retina display changes and we’ve got what we always feared, a fully Balkan-ized web.

Take Away

It’s not enough to evaluate a design based solely on how it looks in the browser anymore.  You’re analytics (you have those, and read them, right?) should be showing you that you’ve got more people coming from disparate devices than ever before.  As such, you need to evaluate your designs on their performance not only on the web, but on phones, tablets and that you’re providing the best possible display to each.  In the case of newer Apple products, that means handling Retina Display.

Ignore them at your peril…

 

Good article on Crap Hat SEO Tricks that need to die…

For those that don’t recognize the term, craphat (in this example at least) is short for that crap SEO professionals should know better than to do, but do it anyway because they’re lazy SOBs. For some reason, these craphat SEO techniques just won’t die. They keep holding on – like that nasty, bitter, rich, 110-year-old relative nobody likes…

The ones listed below are just a few; there are plenty more out there. If you have a SEO “professional” talking about providing these SEO techniques for you, we’re so, so sorry. If you are a SEO professional still talking about these SEO techniques, dude – quit crapping on our industry, m’kay? Go find a different industry to use as your personal toilet.

Read it here…

WordPress Plugins – The Good, The Bad and the Ugly

<Cue Ennio Morricone’s theme from The Good, the Bad and the Ugly>

For most of the problems I see in WordPress, we’ve got no one to blame but ourselves.  I get a lot of emails, calls, etc. and they generally come down to one thing: plugins that are improperly configured or are causing conflicts with other plugins.

I typically run my WordPress installations with around 5-6 plugins, all installed to provide very specific functionality and all of which I have closely reviewed to make sure they’re going to do what I want them to do, and not bring “other functionality” to the party that I don’t want.

Before we start, I should probably offer a definition of what wordpress plugins are:

 A Plugin is a group of php functions that can extend the functionality present in a standard WordPress weblog. These functions may all be defined in one php file, or maybe spread among more than one file. Usually, a plugin is a php file that can be uploaded to the “wp-content/plugins” directory on your webserver, where you have installed WordPress. Once you have uploaded the plugin file, you should be able to “turn it on” or Enable it from the “Plugins” page in the administration interface of your weblog. The WordPress source code contains hooks that can be used by plugins. <from the WordPress Codex Glossary http://codex.wordpress.org/Glossary>

Fairly benign, eh?  Well we should remember these, along with, to a lesser degree, theme files, the main way in which we extend the functionality of the WordPress system. Anything from adding a Facebook “Like” button to adding on a full user management system.

My argument against using too many WordPress plugins isn’t the one you’d expect.  I don’t worry about plugins slowing websites down.  Look at WordPress.com – they use 200 plugins per page load (*I should note this is second hand info from Wordcamp SF this year).  If plugins are slowing page load, then it’s due to your use of poorly coded plugins.

My argument against excessive plugin use comes down to this:

  • Plugin Conflicts – the more you’ve got, the more likely your’re going to have something go horribly wrong.
  • Debug Nightmares – There’s a showstopper bug and the site is running 30 plugins. Have fun, Mr. Developer…
  • User Experience – the more you modify the system, the more you’re going to have trouble training new users.  I should also point out that training is generally an ongoing issue for companies.
  • The Bad Apple Affect – even with a modicum of due diligence on your part, it’s possible your going to let a bad plugin slip through the vetting process.
  • Most Plugins Aren’t Essential – and a very high percentage are never, ever used by the customer.  So why are they there?

So what makes a good wordpress plugin? My general list:

  • Simplicity – something that provides the fuctionality I need and not much more.
  • Popular Acceptance – if the rest of the community is using the thing, then we can reasonably expect the developer will continue support.  Even if the developer doesn’t, there’s a good chance someone else will, if the need arises, as notably happened when the original develop of All in One SEO gave it up, and the development responsibilities were picked up by hallsofmontezuma.  Just because lots of people use a plugin doesn’t mean it’s good, but it does increase the likelihood.
  • Code Accessibility – (for major functionality) it has become a practice for some commercially developed plugins to user obfuscated (encrypted) code to protect their intellectual assets.  I support their right to do that, but I will do everything in my power not to use plugin that doesn’t allow me code level access.  Just last week I was debugging an issue for a customer, and found the bug was in code that had been obfuscated.  We’d already found we had trouble getting support from the plugin supplier, so we were essentially at a road block.  I was able to provide a work around, but there was no reason we should have had to do that.
  • General Manners – if the plugin inserts links into my site to itself without providing a way to turn them off easily, or if it adds a feed from the developers site into my admin console without providing a way to turn it off, I won’t use it.

My general rule when it comes to plugins is this: Know what functionality you need, why you need it, and how the plugin provides it.

5 Common MySQL Mistakes That Cost Performance

Rotten MySQL performance can generally be attributed to a couple of simple optimization errors I see over and over again.  Sometimes the problems are from our initial server setup, other times they are due to the growth of our database size.  Give these a check:

  1.  Using MyISAM tables- MyISAM tables are a deadend.  No more development is coming on them, and honestly, there is only one reaason I can think of other than laziness to use them: if you are using full text search functions in MySQL.  Here are a couple reasons why not to use them:
    • Table lockingonce you get over 50k rows of data in the table, it every write will lock the whole table.  InnoDB offers row level locking that resolves this.
    • MyISAM is prone to table corruption, which can ruin your day.
    • MyISAM only buffers indexesproperly configured InnoDB tables can be fully buffered.
  2. InnoDB Buffer size – Did you ever try running a marathon with a sweatsock stuffed in your mouth? That’s essentially what you do when you don’t give the server adequate InnoDB buffer size.  The default is 8m which is ludicrously small – I like to see a full gig or more depending on the db server.  Read more here at the MySQL Performance Blog. I have seen 10x speed improvements from just this one change.
  3. Undersized DB Machine- it shouldn’t happen with relatively cheap and available machines, memory and disk space, but hardwae is a perennial problem.
    • Not enough disk space
    • Not enough memory (*remember, you’re going to want to keep the whole db in buffers…)
    • Overused resource – you’re running HOW MANY DBs on that server?
  4. Storing Transient Data forever – another classic – how about 100 million rows of application data you never should have stored in the first place?  Or how about low level logging of user actions like “SnurfMonkey uploaded a file at 10:23″ – there are better places for that stuff, even if it isn’t traditional transient data.
  5. Backups – do you have backups?  Do they work?  Honestly most people don’t really know.  Even at fairly large companies, many mission critical dbs may not be fully backed up and their utility is rarely tested.  In the case of small hosted sites, most site owners rely on the hosting company to handle backups.  The problem is, they have no idea if the backups are really happening, or where.  For a system like WordPress, I use a plugin to simply backup and mail a copy of the db to me for safekeeping.  Its saved me a bunch of times.