A Hacker Experience (And Protecting Your Site)
A hacker tried to break into a client's website a few days ago. Persistent dude, tried for several days.
First, I'll talk about what happened and some actions taken to counter it.
Then, I'll talk about some things you can do to make your own websites less vulnerable.
When it Started
It first came to the client's attention because he received numerous emails from Master Form V4 indicating something unexpected was occurring.
I was brought in right away because I do some work for him and Master Form V4 is Willmaster software.
What the Hacker Was Trying to Do
Looking at the emails and the log files, the hacker was trying to get at password and other sensitive files below the document root. He used every trick in the book, it seemed, including cross-site scripting attempts, MySQL-breaking techniques, spoofed referral URLs composed of directory paths, and file names in hidden fields designed to access what he was after.
I can tell you now, Master Form V4 withstood all of that. That's one tough piece of software.
The First Thing We Did
The auto-submission protection wasn't turned on for the Master Form V4 forms. So I turned it on as soon as I came on board for the additional protection it would provide.
But by that time, the hacker had his automated software on the job. Although his software tried this and that, the auto-submission protection was securely in place.
Even without the auto-submission protection, Master Form V4 is coded to not, under any circumstances, read or write or in any other way access or report locations of any files below the document root directory. It also has great cross-site scripting protection. MySQL break-in attempts don't bother it because Master Form V4 doesn't use MySQL.
He couldn't break Master Form V4. But he could try other things. And he did.
What the Hacker Did Then
He directed password-guessing software onto a login page. And he actually did get in – not to the server, to a membership area. We found out when the client got notices from a form accessible only within the membership area. That was yesterday.
The hacker continued to use all his devious methods to try to access sensitive files. Some of the forms in the member area do access MySQL tables. Happily, all his breaking attempts failed. So far.
Yes, the hacker's IP addresses were blocked. But he could continue his attack with a different IP address at any time.
That's why we had to do more.
What Else We Did
Because the hacker is persistent and it's conceivable he'll eventually find a way to the server (or another hacking might in the future), Files Monitor was installed.
Files Monitor is a nifty piece of software. It scans the server every day (or more often, whatever frequency you determine).
If any files have been added in the document area of the server that aren't listed in the databased, it sends you an email to tell you which ones. Similarly, if any files have been deleted. And if any have been changed. (Change can be detected by file size change or by content change.)
With Files Monitor, any file changes are spotted. And you're emailed about it.
Files Monitor doesn't run continuously, so its server resource use is friendlier than software that's always in memory and running. Files Monitor runs only when you're using the control panel or when scanning the server for file anomalies.
What we have in place at this point is document directories files backup (previously installed), Database Back Up and Restore for MySQL tables (also previously installed), and Files Monitor to detect any hacker activity that might occur in the document area.
So the client is pretty much set insofar as the ability to recover. But prevention things still needed to be done.
Prevention Things To Do
After setting up the "recovery if needed" software, two things were left to do.
Form Lock Out
The login form will gets a lock-out mechanism.
-
After so many unsuccessful log-in attempts, the IP address is locked out for a certain amount of time.
-
When username root, admin, administrative, and other server-sensitive names are tried, the lock out is immediate and for a longer period.
The reason to expire IP addresses from lock out is twofold:
-
In case a valid member has a really hard time logging in and triggers the limit.
-
Because it is suspected that compromised PCs are being used for the attack and we don't want to forever bar those who are relatively innocent.
Log-in Form Obfuscation
To become less noticeable to hackers' roving robots in the future, the web page with the login form no longer has a file name with the word "login" in it. In addition, the form doesn't have a type="password" field.
The log-in form submits to a script named without the word "login". No redirect or other hidden fields contain the word "login," "password," or other sequence of characters that hint the form may be a login form.
The type="password" field is coded as type="text" in the form. JavaScript changes the field to type="password" after the form has loaded. Robots see the type="text" and people's browsers see type="password".
What You Can Do To Make Your Sites Less Vulnerable
Here's a list of things that can be done to make a hacking attempt less likely.
-
Keep your login forms as invisible to roving robots as you can. See the above "Log-in Form Obfuscation" section.
If you can't do everything in that section, at least do those you can.
-
If you can, put a lock-out mechanism on your log in forms. See the "Form Lock Out" section.
-
Keep a backup of files in your server's document directories. That would be the document root (the directory where your website's main or index web page file is located) and its subdirectories.
If files are constantly changing, like log files, for example, Directory Zip (WebSite's Secret exclusive software) can be used to ZIP up a copy at regular intervals.
-
If you use MySQL tables with data you can ill afford to lose, use Database Back Up and Restore to make a daily backup of your MySQL tables.
-
To alert you when a file is added, deleted, or changed in the document areas of your server, use Files Monitor. (The software is a WebSite's Secret exclusive.)
-
Form submissions need to be processed by software with security to prevent cross-site scripting and for blocking access to any area other than the cgi-bin and document root directories. I'm certain there are numerous software titles out there that will do the job. If you don't currently have one, consider that Master Form V4 has proven its strength.
-
Don't keep passwords on your office, home, or any other computer or pad except with software designed to keep them secure. Otherwise, a compromised computer could let a hacker grab all your passwords.
-
Never, ever send a password via a non-secure medium, which includes email. If the person requiring your password doesn't have a secure form or other secure means to do so, a telephone call can be used to deliver the password verbally.
-
When your hosting account has been accessed by authorized people and they're done with what they were there to do, change the password.
This is actually quite important. It's not that you don't trust the people who worked on your server; it's in case their own computers get compromised and your password inadvertently gets into a hacker's paws.
-
For lots of articles related to website security, go to Willmaster.com and use the search box near the top-right of the web page. Type in "password protection" and, after that, "server security" (both no quotes).
If you need help making your server is less vulnerable, use our contact form. I may be able to provide assistance.
If You Get Hacked
If you get hacked, block the hacker's IP address if you happen to have it (it can be obtained in your server's access log if you have no other means to get it).
An IP address can be blocked with the .htaccess file at the document root (the directory where your site's home or index page file is at). Put the word "deny" into the .htaccess file followed with the IP address on the same line. Example:
deny 127.18.29.211
Your server needs to be inspected for files the hacker may have left behind or changed. If you're using Files Monitor, this should be fairly easy. Otherwise, it will need to be a manual inspection. Whatever software you use for the inspection, ensure it will list file names beginning with a period, as files can sometimes be hidden that way.
When the document directories have been cleaned, restore your backup. Check the backup first to ensure the hacker's file didn't get into it. If they did, restore from the most recent backup without the hacker's files.
If you have a recent MySQL tables backup, that can be restored.
Watch your server and your MySQL data, in case a door to your server has been left open for the hacker.
I hope you never have to deal with a hacker. To make it less likely, do all the steps in the "What You Can Do To Make Your Sites Less Vulnerable" section that you can.
Will Bontrager
