Read more five star service reviews?Website Malware andHack Repair Services
"Repairing Hacked WordPress Websites since 2012"
1. Update stuff at least monthly, including themes (because you will be hacked).
2. Maintain daily backups for 30 days (for recovery when you are hacked).
3. Add 2 step login verification (because it’s the smart thing to do).
Go to lunch and have a margarita—or three—on me!
Time to read: 5 minutes |
Time to write: 10 hours |
I imagine your first question may be, “Well if it’s so easy Jim, why don’t more people who have a history of being hacked or run high profile websites follow these instructions for locking files?”
Short answer: Either the website administrator lacks the education to do so, has limited server access, or finds the steps in doing so more complicated than it’s worth time and effort wise. I’ll discuss each of these possible reasons why below.
Shared web hosts of the 10ish dollar a month variety do not include root server access. Root level access is the highest level of access on a web server, and is often referred to as the Superuser account.*
According to Wikipedia, “In computing, the superuser is a special user account used for system administration. Depending on the operating system (OS), the actual name of this account might be root, administrator, admin or supervisor. In some cases, the actual name of the account is not the determining factor; on Unix-like systems, for example, the user with a user identifier (UID) of zero is the superuser, regardless of the name of that account;[1] and in systems which implement a role based security model, any user with the role of superuser (or its synonyms) can carry out all actions of the superuser account).
* Suffice it to say, once you have superuser access you have complete control of the server; and can edit or delete files indiscriminately if you choose.
If you wish to lock your files against hackers, you may need to upgrade your account to either a dedicated or Virtual Private Server (VPS). All real dedicated or VPS providers include both SSH and root level access as part of their service.
While some shared hosting providers may be willing to help you lock and unlock your files, others may not. If you are looking for an unlock friendly web host, comment below. When it comes to recommendations, this community rocks!
Now that you know the minimum requirements, let’s get down to the basics in how to lock your website against hackers.
The chattr command has been around since the dawn of Linux computers. In the old days, before the hacking of websites became so prolific, the chattr command was used by system administrators to restrict users from changing files in a particular way, and to help prevent server administrators from accidentally deleting critical files by mistake. Today, we can use this same approach to stop hackers cold!
According to Tecmint: Linux Howtos, Tutorials & Guide, “chattr (Change Attribute) is a command line Linux utility that is used to set/unset certain attributes to a file in Linux system to secure accidental deletion or modification of important files and folders, even though you are logged in as a root user.
If you run an HTML only website, the locking of all files is quite easy–just one command and it’s done.
The trick lies in setting the appropriate attribute for the file you wish to lock. Below is a single file locking example, to help you understand the basics of file locking using the chattr command.
To prevent anyone, even a root user, from editing or deleting a file, set the immutable bit of the file by entering this command after the prompt (#):*
# chattr +i filename
*The immutable bit option +i can only be set by a root user.
If you are not sure how to access root on your server, please ask your server administrator for instruction.
The power of the chattr command lies in the fact that no one can touch the file without root access. And that even with root access, another command will need to be run by the server administrator in order to unlock the file. Once you’ve mastered the basics of file locking, the process is quite straightforward.
To unlock your file, run this command after the prompt (#) :*
# chattr -i filename
*It’s the same command, but with a -i instead of a +i
chattr can also be used to set or unset many other file attributes as well. For brevity sake, I won’t cover them here. But you can learn more about the chattr command, at either of these other websites: http:/
Now that you know how to lock individual files, let’s move on to discussing how to lock all of your public files. The command is similar, though there are some caveats. If your website account includes server generated content like cache, log files or backups, you’ll need to take special care in locking only static files, such that server generated files can still be written to respectively.
Some content management systems (CMS’s) may allow you to move server generated content above your public directory. Since you only want to lock files within your public directory, if your CMS allows you to move log files and the like “above” your public directory you’ll save a lot of time later when you begin the locking and unlocking of files within your account.
When I refer to your public directory, I’m referring to the public_html or www directory, where your publicly accessible files are accessible. For the purpose of this article, I’ll assume your public directory is public_html.
Regardless of the CMS you may use, most of your files may be locked against hacker manipulation. In WordPress for example, the downside of security plugins and other PHP level techniques for locking files against editing is that all PHP scripts have the same permissions level. So, if I can write a PHP script to disallow editing of a file, like to the .htaccess file for example, then a hacker can write a similar script to do the opposite. This is why PHP level locking is ineffective against hackers who find a way to inject malware into your website files or directories. Once they are in, they can edit or delete any file they choose. Locking files at the root level literally locks the door against hackers.
Again, you need to be mindful of actively-written-to directories. Before locking files, make a note of the directories or files which are routinely written to. You’ll need to exclude those later.
Begin by locking all files.*
# chattr -R +i public_html
*This command will recursively lock all files and directories within public_html and prevent the addition or removal of all files within.
At this point, neither you nor your server will be able to upload or edit files until the directory is unlocked.
Note and unlock all files and directories with actively-written-to files. Examples:*
# chattr -R -i public_html/wp-content/uploads
# chattr -R -i public_html/wp-content/wflogs
# chattr -i public_html/error_log
*In WordPress, the uploads directory is where images are saved, so be sure to unlock that directory to start. Then repeat the same command for other directories which are actively-written-to by WordPress or plugins. In the example list above, the second line relates to Wordfence logs and the third the error log file.
* Once you’ve locked you files accordingly, given it 30 minutes or so, then check the error_log file to see whether you’ve missed anything.
Upload your favorite deny script execution .htaccess file into the directories where you wish to allow files editing. Example:*
# Disallows execution, except for browser readable images <FilesMatch "(^#.*#|\.(asp|bak|config|cxz|dist|exe|fla|htm|inc|ini|jsp|log|mso|php|pl|psd|py|sh|shtml|sql|sw[op])|~)$"> Order allow,deny Deny from all Satisfy All </FilesMatch>
*Using .htaccess to deny execution in this way will prevent the execution of scripts even if the hacker uses an injection exploit to add or edit files within your “open” directories.
And the final step, be sure to limit access to your WordPress login to just your IP Address:*
# Deny access to your WordPress dashboard for all but your IP address
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_URI} ^(.*)?wp-login\.php(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^(.*)?wp-admin$
RewriteCond %{REMOTE_ADDR} !^xxx.xx.xx.xxx$
RewriteCond %{REMOTE_ADDR} !^xxx.xx.xx.xxx$
RewriteRule ^(.*)$ - [R=403,L]
</IfModule>
*This step will ensure that hackers can not log into your WordPress Dashboard and edit your database content as well. Locking files does not protect your database from injection. See the article, “Protecting WordPress Against Brute Force Attacks,” for more discussion on this topic.
This question is why I find most well-educated server administrators choose not to discuss this option with their clients, and why this how to stop website hacking technique has remained such a secret within the server administrator community.
The abject terror most web server administrators feel when giving root access to untrained “web designers”; the training requirements associated with setup (most of which I’ve described above); and the periodic requests that will most certainly follow in going down this path…. well, you get the gist.
I would venture to say, that only the most patient server administrators may be willing to handle the extra, more than likely unpaid workload required to both maintain the locking and unlocking regimen of an active and persistent website hosting client or designer.
For CMSs like Joomla, WordPress, Drupal, and others, making changes, or updating core files, themes, plugins, and components will require unlocking of the public directory for the period of time required to complete necessary updates (command shown below), followed by working through steps #1, #2, and #3 above once again.
# chattr -R -i public_html
*This command will recursively unlock all files and directories within public_html.
With good notes, the process for locking and unlocking a website’s files using the chattr command can become routine. Of course, the locking of files does not mitigate database injections. A regular backup and updates strategy must still be followed.
My hope in using the term “The Last Stand!” is that you’ll view this technique as a last-ditch defensive effort in securing your website account against hackers.
And while many may find the file locking method described above as overkill for most websites, if you are going on vacation or simply need to delay the upgrade of your CMS for an extended period of time, the file locking process described above will help to ensure your site remains in a pristine state until you have time to revisit updates respectively.
For a more traditional approach in securing websites against hackers, please see my other website security article , “BUMMS – Website Security Preparation for Today“.
Enjoy!
Personal notes and commentary:
And a warm Thank You! out to the few folks who helped me in proofreading and editing this article:
Mike Dudas, Joyce Walker, Elizabeth Pampalone, Sarah Dilks, and all the other wonderful people who helped in clarifying my scribbles.
A prediction: I suspect this article will be rewritten and posted in wpmudev dot org without citing HackRepair.com as the source soon after being published. 🙁