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 ( 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.


iPhone 5

I was two months away from the end of my contract with AT&T Wireless and found out I was eligible for an upgrade.  I’ve been thinking about getting an iPhone because I know other people who have it and like it a lot.  Even one of my brothers previously had an Android phone and switched to a 4S and said it’s superior in pretty much every way.

I don’t know anyone who has an iPhone 5 so I read a bit on it and decided to try it out.  I’m told I have 14 days to return it and cancel the contract or 30 days to switch phones.  If I do the latter, I’ll probably either go with a Samsung Galaxy S3.  I have also been eying a coworker’s Google Nexus 4.  It’s amazing how much bigger his screen is than mine.

The transition should be an interesting one coming from my Motorola Atrix 4G.  The first thing I notice is how fast the iPhone is.  The A6 processor screams compared to the Tegra 2 1 GHz dual-core.  When on Wi-Fi, web pages load a LOT faster on the iPhone than they do on the Atrix.  The HSPA+ that the Atrix uses doesn’t compare to the LTE that the iPhone uses.  It’s truly like going from dial-up to broadband, particularly as the pages render so much faster.

I did have a lot of trouble getting it to connect to my Wi-Fi.  I would think tapping the access point’s name would allow me to specify the encryption type and enter the password.  All it showed me were the setting details sans the stuff I wanted.  After searching the web and coming up empty, I tapped “Other” and manually entered the name.  That worked out well but I still think I shouldn’t have to do that.

The other major problem I had was creating an email address.  The names I wanted were taken so they suggested one I thought was okay.  I tried to pick it but the phone just kept coming up with an error.  I tried the same thing on my MacBook Pro and it stayed on the screen without giving any type of error.  After unsuccessfully searching for an answer to that, I tried a completely different name and it accepted that.  They really need to come up with better messages (or at least some message in the case of the MacBook) to let the user know what to do.

The only other issue I’ll mention right now is that when scrolling in Safari, the page only goes a little ways up or down.  I’m used to Android’s way of scrolling really fast if you flick it quickly.  Unless there’s some work-around, it could take quite a while to scroll on a really long web page using the iPhone.  I’ll look it up later.

Transitioning from the Android device to an iPhone is proving to be quite an experience.  I can’t simply insert my SIM into the iPhone since it doesn’t use the same size which means I don’t have a super-easy way to import contacts.  I’ll have to read up on what others have done.


.htaccess file corrupted

My site has continued to receive attacks from the login bots I mentioned in my last post so have been getting emails about the system locking them out.  A couple of days ago the emails stopped so I thought they finally gave up (or ran out of usable IP addresses).  Yesterday I received an email from Google saying its bot couldn’t get to my robots.txt file.  I found I couldn’t get to any part of my site and just got an error message.  By checking the errror logs, I found the problem was that the .htaccess file was corrupted, or at least misconfigured.  I have never manually edited that before so I had to figure out how it was supposed to look so I could fix it.  I looked at an old backup of the file and got an idea what it was supposed to look like.  I was able to fix it after that.  I can only guess that one of the WordPress addons I have was the cause of the corruption.  Hopefully it won’t happen again.

Of course now that the site is back up, the login bots are back too.  There’s only so many IP addresses they can use so the attackers should run out eventually.  My logs do show quite a few 403 “Forbidden Access” messages too which means they’re still trying those bots I already blocked.  Oh well, let them waste their time.