Still Trying to Protect .htaccess

I wrote about my new attempt to protect the .htaccess file from being corrupted by simultaneous writes from WP Better Security in my last post.  My implementation didn’t work and the site went down again with a server configuration error message.

I reimplemented the same flock method I described earlier but this time, instead of directly locking the .htaccess file, I locked a dummy file.  My new method opens the dummy and attempts to lock it.  If the lock is successful, then it goes ahead with the rest of the function that opens and modifies .htaccess.  After that closes, the lock on the dummy file is released and the file is closed.

My thinking is that the entire section of code dealing with the .htaccess file should now only be able to be accessed by one calling thread at a time.  I’m not really sure why my last idea didn’t work but if this method also fails, then clearly flock will not help me.

Edit 7-19-13

The new method did indeed work.  The .htaccess file has not been corrupted since implementing this new fix back on April 17th.

Edit 9-26-13

I wrote a new article to more clearly explain the changes I made.  You can find it here.

 

Protecting .htaccess from WP Better Security

I previously mentioned my .htaccess file got corrupted and I guessed it was the fault of an addon.  I have since figured out it’s WP Better Security doing it.  The plugin has been very useful so rather than abandoning it, I looked into how to get around the problem.  The biggest problem is when the hidden file is corrupted, it brings the site down and I’m not immediately aware of it since I only check it every now and then.  Google’s bot will eventually send me an email after a certain number of failed attempts to access the site so I’m not in the dark for too long about the problem.  That’s one of the benefits Google webmaster tools includes.

The corruption is caused when two separate threads attempt to modify the file at the same time.  In my situation, it’s caused when the login bots attempt to guess passwords at the same time, either from the same IP address or from more than one IP address.

My first attempt to fix it, which I knew was not really a solution but did increase the odds of preventing it, was to introduce a random wait time before the file could be accessed.  That helped a lot but as with anything random, it’s still possible to get the same, or nearly the same, value.  Because of that, the file still got corrupted occasionally.

Today I noticed 404 errors in the logs.  The .htaccess file was corrupted in such a way that nothing except the administration pages worked.  It took me a little bit of time to figure out that the .htaccess file was the cause but sure enough, when I replaced it with a backup copy, all was well again.  That made me think it’s time to permanently solve the problem.

The solution I thought of first is a concept I learned in an Operating Systems class.  It’s called a mutual exclusion lock, or mutex lock.  Using such a lock guarantees no two threads or processes can access the contained section, known as the critical section, at the same time.  It’s wise to keep the area as small as possible to minimize performance impacts.

I found reference to it through a Google search but when I tried to place the appropriate statements in, I found it didn’t seem to work.  I’m not clear as to whether it’s currently implemented natively in PHP or not but I don’t think it is.  Since I couldn’t get it to work, I needed to come up with a different solution.

More searching on Google (and Bing) led me to the keyword flock, or file lock.  That method seems to have the same properties of what I’m looking for.

I found in WP Better Security, the function to write to the file is called writehtaccess() and is contained in the file common.php.  I added the following a bit after the file system pointer is received but also after the statements that take care of error handling are passed:

if (flock($f, LOCK_EX) == false)
{
   $sleepTime = rand(100000, 500000);
   while (flock($f, LOCK_EX) == false)
   {
      usleep ($sleepTime);
   }
}

That allows the calling thread to sleep for a random time between .1 and .5 seconds before trying again if the first try to gain the lock fails.  It might not be necessary to calculate a random time for the wait but I threw it in there for good measure.  Just before the file close statement, I added:

flock($f, LOCK_UN);

That statement releases the lock.  Hopefully that will be the end of the corruption issues I’ve been experiencing.  If not, it’s back to the drawing board or further research into why my implementation isn’t working.

Edit: It didn’t work.  I made another post outlining my revised solution.

Bad Passwords

I started this blog last summer and have been learning a bit about the challenges webmasters must contend with.  One of those challenges is login attempts.  I wrote about it in a previous post.  For a few months now, I have noticed a number of such attempts.  At first it was a single IP address.  I then began to notice what I believe is a bot-fleet attack.

The clue came in the form of the passwords themselves.  My security plugin only alerts me to the alleged IP address and the login name.  I modified the script to keep track of the passwords being used because I was curious about what passwords they were trying.  I have posted the results here.  I have chosen to remove various R-rated passwords that were originally in the list.  You can see near the beginning of the list when several years such as 1985, 1986, and 1987 are tried, all from different IP addresses.  It is possible that the IPs have been spoofed but I have no reason to believe that’s the case.

It would be a very good idea to make sure the passwords you use on any site isn’t anything like the ones that are on that list.  I thought it was interesting to see that almost all the passwords have only numbers and lowercase letters.  Good practice (by today’s standards) says passwords should be at least 8 characters and a combination of uppercase, lowercase, numbers, and special characters (such as @ and #).  There are many websites that give suggestions so I won’t go into them here.  The first site that came up when I searched “passwords best practice” on Google was a blog entry at Total Defense which has some good tips.

Opening with Microsoft Office 2010 by Default

I recently came across Microsoft Office’s upgrade offer (http://office.microsoft.com/en-us/offer/) and decided to take advantage of it.  I had been running Office 2003 (the last pre-ribbon version) for nearly a decade now so I bought a copy of Office 2010 and went through the steps to get a free copy of Office 2013.  I had been using Office 2010 at a university and because of that I found Office 2013 pretty different.  The way it looks takes getting used to.  I prefer the more colorful and “textured” 2010 version.

While it might be possible to tweak it in settings, I figured I would just make Office 2010 the default program for now since I really don’t need any 2013-specific features.  Unfortunately, the old trick of right-clicking on a file and using “Open with” and “Choose default program..” didn’t work.  It stubbornly kept Office 2013 as the default.  After a few minutes of searching, I came across an article called How to make Microsoft Word 2013 the default program even if Microsoft Word 2010 is also installedthat talked about something similar.  He had the reverse problem.  I am running Windows 7 (as opposed to his Windows 8) but I found the registry key he mentioned in exactly the same place.  It was already there so I didn’t need to add it.

The key the fix for me was going to Control Panel –> Programs and Features –> Microsoft Office Home and Student 2010 and clicking “Change” then “Repair”.  It completed after a few minutes (no disc needed) and told me I would need to restart to complete the process.  I opted to restart later but discovered the fix worked anyway.  Now when I double click a Word or Power Point file, it opens in 2010 by default.  The icons on the desktop and in Windows Explorer also reflect the change.

It’s unfortunate Microsoft didn’t make the “Choose default program” work like it was supposed to for Office but at least the fix is an easy one.