Steps to perform after your site is hacked,and how to prevent it by getting hacked
The server configuration discussed here is Linux/Apache with cPanel.The general steps will be the same on any server, but the specifics will differ.
There's a good chance you came to this page because your website was hacked and you want to know how to clean it up.
Step-by-step repair after a website hack
This will probably take several days. Don't think it's going to be easy.
1) Log into cPanel
If the line at the top that says, "Last login from: IP address" is not your IP address from the last time you logged in, write it down. It is probably the hacker.
2) Change passwords for cPanel and for publishing
Use strong passwords. A password MUST NOT BE a single word that is in any human language dictionary, and it SHOULD NOT CONTAIN any real word. It should be random characters.
a) If you publish with FrontPage, 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. 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.
After changing the FrontPage password...
b) Log in to your webhosting account and change the password there
Some webhosts might use cPanel for this. Others might have a separate login for password changes. Consider changing the passwords for your email accounts, too.
3) If it is a dire emergency, take your website offline
If the hacker inserted extremely offensive pages or installed a virus, protect your visitors and your reputation by taking your site offline.
While it's closed, you likely won't be able to access your site through FrontPage. That's why you changed your FrontPage password before taking the site offline.
4) Enable log archiving in cPanel
1. Go to cPanel > Raw Log Manager.
2. Check the "Archive Logs..." box.
3. Uncheck the "Remove the previous month's archived logs..." box.
4. Click Save
If log archiving was off at the time of the hack, it may be too late to see the original hack. However, if the hackers come back, their activity might now be logged, allowing you to identify their IP address.
5) Find and remove all files installed by the hack
This describes an ideal cleanup operation. Will you be able to fully complete every step? Probably not.
If your site isn't huge, you might save a lot of trouble by deleting everything inside your public_html folder and republishing your entire site from a backup copy. You'll still need to inspect your root directory (above public_html) and its other subdirectories for damage.
5a) Get a complete list of all the files in your website
There are three methods (Sections 5a, 5b, 5c). For most purposes, this first cron job method will be easier to review in detail than the other two methods.
You probably don't have direct access to Linux on your server to create a directory listing, but you can create a cron job that will do it. It is the equivalent of the DOS command dir /s.
1. Go to cPanel > Cron jobs > Standard.
2. Enter the email address where you want the output sent,
3. Enter the command line to run. The switches are case-sensitive, so use exactly this capitalization:
Here it is in upper case to make the letters distinct, but this command is NOT the same as the one above. Don't use it: LS -1AFLQR.
The switches for the ls command are described at http://www.ss64.com/bash/ls.html and http://en.wikipedia.org/wiki/Ls.
4. Make selections in all the other fields to specify a time several minutes in the future.
5. Click "Save Crontab".
6. After it runs, go back to Cron Jobs > Standard and delete this job.
The email will contain a listing with lines that look like the following examples for one directory and one file:
drwxr-x--- 33 user user 4096 Feb 5 20:51 public_html/
-rw-r--r-- 1 user user 16669 Feb 5 20:51 index.htm
A brief explanation:
d indicates a directory
The 3 groups of 3 (rwxrwxrwx) are permissions for User, Group, World.
r, w, x stand for Read, Write, Execute a program or Enter a directory.
Walkthrough of the above:
public_html above is a directory.
The User (owner, me) can read, write, or Enter that folder.
The Group (that I am member of) cannot Write to that folder (thus the "-" where the w would be)
The World (everyone else) has no permissions here ("---"). (I know that seems odd for public_html, but the reasons why are not useful here.)
index.htm, the home page:
User can Read or Write.
To everyone else (Group and World), the file is Read-only.
The user fields should show only your hosting account userID or some other ones that are obvious system names.
The numbers are file sizes.
The timestamps are timestamps.
There is further explanation in this post at Lunarforums.
How to use the listing:
7. If you have a file list like this that you made before the hack, compare the two lists to identify files in the new listing that don't belong.
8. If you don't have a prior list to compare against, review the new list for files that seem out of place. See What To Look For, below.
5b) Examine your site's files in cPanel > File Manager
If you can't use the cron job method, this is an alternative, but navigating up and down the directory tree will get very tedious very fast.
In File Manager, file and folder permissions are shown numerically. R=4, W=2, X=1. The permission level for a user is the sum, so the maximum a user can have is 7. If, for example, the User has RW, but Group and World only have R, then the permissions will be: 644.
5c) Examine your site's files using FTP
With an FTP view of your website, the folders and files look like what you are used to in Windows Explorer. FTP view is available using Internet Explorer 6 or 7 and Windows Explorer. FTP view is easy to navigate, but it doesn't show file and folder permissions.
a) FTP by IE6
In the IE6 address bar, type the FTP address for your site. It is probably something like: ftp://yourdomain.com/ or ftp://ftp.yourdomain.com/ If you don't get a login prompt, click File > Login As...
b) FTP by IE7
Help for this is available in IE7 Help (F1) > Contents > FTP.
1. Open Tools > Internet Options > Advanced
2. Make sure "Enable FTP folder view (outside IE)" is checked.
3. Click OK.
4. In the IE7 address bar, type the FTP address for your site.
5. Ignore the error page.
6. Click Page > Open FTP site in Windows Explorer...
7. At the FTP Folder Error dialog box, click OK.
8. Click File > Login As... to obtain the login prompt.
c) FTP by Windows Explorer
1. Enable the address bar (View > Toolbars > Address bar). You may need to unlock the toolbars, relocate, and resize it.
2. In the address bar, type the FTP address for your site.
3. At the FTP Folder Error dialog box, click OK.
4. Click File > Login As... to obtain the login prompt.
5d) What to look for
Regardless of the method you used to get your file list, look for and repair the following. If hacked pages contain clues such as URLs that will help identify the hacker, copy and save the useful text somewhere before you repair the page:
* Files you know don't belong there. Some hacks install files with ridiculously obvious names like hacked.html or vulnerable.php, etc. Other files might have nonsensical names or names consisting of random character strings. Some files might be in locations that make them suspicious, like a .php file in your /images folder.
Be watchful for any files you don't recognize, but be careful because some of them are probably required for your site to function properly and you just never noticed them before. You cannot just delete all the files you didn't put on the site. Determine whether each one is malicious or not. When in doubt, try a web search on the filename or post a question in a forum where other people can tell you if that file is normal.
* Check your root directory ("/") and its subdirectories for malicious or altered files. Inspect everything carefully. Even if you delete the contents of your public_html and republish the site from scratch, this doesn't overwrite your folders above public_html, so you must check those manually.
* Find and remove malicious scripts. Look especially for PHP and CGI scripts that you didn't create. Inspect existing PHP and other plain text scripts for signs of tampering. Backdoor scripts left in place can allow the hackers back in even after you've changed your password.
When in doubt, it is safest to stop using scripts you suspect might have been weak, especially ones you wrote yourself, until you can examine them and determine that they're safe. Rename or delete them so the hacker can't continue to access them by their previous names.
* Pages with modified dates more recent than you last saved the page yourself. Inspect the text and replace the file with a backup copy, if necessary.
* If you publish with FrontPage HTTP, it appears that whenever you publish any files, the timestamp of every .htm file on the site is set to the time of the publish. So in this case your timestamps may all be identical, except for hacked pages.
6) Check all file and folder permissions
Using the complete file list you made, or File Manager, 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 might have different rules, common permissions for world-accessible folders are 755, and common permissions for world-accessible files are 644. It is left to you to figure out why. If you start running across what look like permissions hacks, you will need to do some studying and some detailed investigation of each file and folder.
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 get Write permission to one folder, they can upload exploit scripts to it and run them.
7) Change 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.
8) Try to identify the hacker's IP address
Stats programs like Analog, Webalizer, or AWStats are not going to be helpful here because they generate aggregated statistics. You need detail.
cPanel > Web/FTP Stats > Latest Visitors is useful and easy. It is a good place to go when you first notice the hack, but it is only a start. You really need the full raw logs.
a) If you have never used your site's raw access logs before:
You website's raw access logs are stored and sent to you as gzipped files. If you don't have a program that will extract *.gz files, get the 7-Zip program from http://www.7-zip.org/. It is a command line utility that you run from a "DOS box" (aka "Command Prompt").
b) Get your logs from cPanel > Raw Log Manager
1. Go to cPanel > 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 best for viewing these log files as text. Set the font to a monospaced font, with word wrap Off.
10. You can import your HTTP (regular) log file into the Webstats.mdb Access database. It won't import your FTP log.
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.
12. The FTP log is probably best viewed as text.
Go through the logs carefully. If log archiving was on at the time of the hack, look for suspicious activity in the days prior to the hack. Keep watching the logs in case the hackers come back.
Your regular log will show HTTP accesses, your normal site visitors. Mixed in with all the visitors and legitimate robots, you could find a person or robot GETting pages in an abnormal browse sequence (not following links on your site) or trying to GET pages that don't exist on your site. They might be seeing if your site has particular pages that are part of widely used scripts that are known to have vulnerabilities. Look for HTTP POST activity. Not all POSTs are suspicious, though. If you use PHP, look for requests that attempt to inject code or variables into the page:
Your FTP log will show FTP accesses, one way that hackers 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.
In both logs, check the field called REMOTE_USER, User, or UserID. In the HTTP log, 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. Make sure the timestamps on the accesses match the times you were logged in.
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 hacker's 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. I have a 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.
9) Investigate what made the hack possible
It might be obvious or it might require detective work. The section below on hack prevention describes some common avenues of attack. It is important to identify how they got in so you can prevent the next attack. For example, if they got in through a vulnerable script, and you don't rewrite or update the script, all the work you've done to this point is useless because they can come right back and wreck your site again.
Three common avenues:
1. Old versions of third party scripts with known vulnerabilities. Make sure you are using the latest versions of software for forums, image galleries, blogs, and everything else.
If you do all your installations through Fantastico, you can check your versions at cPanel > Fantastico > Installations overview.
Otherwise, the version is usually shown on the pages generated by the script, so go to your gallery, blog, or forum, and look around. Then compare the version to the latest one being distributed at the website for that software.
2. The site password was easy to crack.
3. Homebrew PHP or CGI scripts were flawed and had security holes. Make sure the settings in your php.ini file are as secure as possible.
10) Report or go after the hacker legally?
You can try, but your chances of getting anywhere with it might not be great.
Hacking is a violation of the terms of service for any legitimate web host or ISP. If you can prove that someone is using a particular IP address for hacking, you could report the incident to the web host or ISP in hopes that they might shut the perpetrator down. The contact email is often abuse@ the company.
What to do BEFORE your website is hacked, so it doesn't get hacked
What is a hack?
A hack occurs when someone gets write access to your server so they are able to modify, add, or delete pages.
Many people ask, "How could my site have been hacked? The hacked page was 100% pure HTML."
The answer is that the modification of the page wasn't the hack. The hack was when they got write access to the server. Modifying the page was simply the thing they chose to do after they got in. Once they get in, they can do ANYTHING with your site that you can do, including alter static pages.
Why do they do it?
The goal of most site hacks is to use vulnerable sites to make money. It is a business enterprise. They can:
* Use your site's mail server to send spam.
* Insert links to their own sites, visible or invisible. The links from your site to theirs bring traffic and also boost their site's rankings in search engines.
* Insert their AdSense code onto your site's pages so clicks are credited to them.
* Put phishing pages on your site to try to obtain confidential information from your visitors.
* Use your server to host illegal content.
* Add viruses, adware, or spyware to your site so it's downloaded onto your visitors' computers to try to obtain their confidential information.
Fun, challenge, prestige, or malice
There are hackers who deface sites individually, but it's time-intensive to hack sites one by one. Occasionally a site is hacked by someone who dislikes the site or its owner. These are not the major threats.
How do they do it?
* Automated web crawlers cast a wide net, identifying websites with a specific security weakness. For example, if a popular script is found to have a vulnerable page called forminfo.php, the crawler will visit every website it knows about, issuing a request to GET forminfo.php. If the request returns a code 404 (Page Not Found), then it moves on. If the page returns a code 200 (Success), the website becomes a target, either by a human hacker or by a computer program that executes the steps to exploit the weakness and install the hacker's files onto the site.
* Crawl the web searching the source code of web pages for PHP or CGI scripts with names commonly used by email forms handlers. When one is found, an automated procedure starts sending it input to test whether the script can be tricked into sending spam to third parties.
* Automated password cracking programs hammer at cPanel logins until the correct user ID and password combinations are found. People who create their own passwords are remarkably predictable, and the algorithms used for password cracking are remarkably sophisticated.
Steps to prevent hacking
1) Always use strong passwords
If you don't know what a strong password looks like, go to https://www.grc.com/passwords.htm. The third row on that page ("63 random alpha-numeric characters") contains the types of characters to use for cPanel passwords. Pick the first, or any, 8 chars from that row. Any password that does not look like the ones you see on that page are bad.
* In cPanel, only 8 characters are significant, so use all 8. Use a mixture of upper and lower case letters and digits. Special characters (punctuation, etc.) do not seem to be allowed by cPanel.
The #1 threat to your website is internet attackers. There are thousands of them, and they will definitely try to damage your website if they get in. That is why you MUST use strong passwords that are difficult to crack. This must be the FIRST consideration.
Write down your strong password so you don't forget it. People sometimes avoid strong passwords because they've heard passwords should never be written down. That rule was for Defense Department workers who had to worry about Soviet spies. You don't. You have to worry about internet hackers. Writing down your strong password is only a trivial security risk. Using a weak password because that's the only kind you can remember is a huge security risk.
Keep your written passwords appropriately safe for your situation. Do you have mischievous children? Don't leave passwords lying around where they can find them. Malevolent coworkers? Don't leave passwords in your desk drawers. Do you habitually lose your wallet or purse? Well then, don't keep them there, either. Take whatever precautions are necessary for YOUR situation.
If you have a userID associated with your hosting account, keep that as secret as possible, too, because a hacker needs it to log in as you. Don't post it in forum messages.
About strong passwords: http://en.wikipedia.org/wiki/Strong_password#strong_passwords
2) Don't weaken your server's file and folder permissions
* Do not modify the file and folder permissions on your server until you know what you're doing. Study the permission settings carefully. Don't guess.
Each folder and file on your Linux server has a set of permissions that determine who can read or write that file, execute that program, or enter that folder.
One mistake in a file or folder permission can allow a hacker to get into your site, and they won't even need your password to do it.
3) Keep third party scripts up to date
If you use popular third party scripts like Coppermine, WordPress, SMF, vBulletin, phpBB, or any others, get on a mailing list or visit forums where updates are announced. When a security update is released, install it without delay.
When a vulnerability is found in a commonly used script, it is likely to be exploited soon by a lot of hackers because it gives them access to a large number of sites.
4) Write your own scripts securely
* Be aware of the potential security risks of each language you use.
* For PHP, use a php.ini file to block some common avenues of attack.
* Don't use potentially insecure features of any language until you've studied and understand them. There are lots of online resources for learning how to code securely.
A vulnerable script can give hackers access to your user database and financial or other confidential or data.
* All data that comes into your script from the outside world poses a potential security risk. If your script takes input from a user or from passed parameters in a URL string or from a cookie, the input needs to be checked for validity, tested to determine if it contains injection exploit code, and cleaned ("escaped") before you use it to include a file or access a database.
5) Block suspicious accesses with .htaccess
If you detect especially suspicious activity in your logs, you can block the IP addresses by using cPanel > Deny IP or with the appropriate code in your .htaccess file. Don't be overzealous, though. It takes experience to learn what's really suspicious and what's just unfamiliar, and accidentally blocking legitimate visitors is bad public relations. Besides, if your site is otherwise secure, the probes to find security holes will fail, anyway.
6) Keep spyware off your computer. Prevent password interception.
* If you use a wireless network, make sure it is not open to eavesdroppers.
* Keep your computer free of spyware such as keyloggers.
* If you're worried about your password being intercepted between you and your server, use encrypted https to log in to your server.
Preparations that will make hack diagnosis easier
1) Turn on log archiving in cPanel
Periodically delete the accumulated logs so they don't consume all your hard drive space.
2) Get a complete list of your site files while they are known-good
This will be a baseline list of all the files that are supposed to be in your website. After a hack, it will help you decide whether a file you don't recognize is related to the hack or is a required system file that you just 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. Get used to what is normal so things that aren't will catch your attention.
How to know if you've been hacked
1) Whenever you log into cPanel,
Make sure "Last login from:" at the top of the screen shows your IP address from the last time you logged in.
2) Be alert for anything unusual when reviewing your
* Access logs,
* Usage reports in Webalizer, AWStats, Google Analytics, ...
* Site data at Google Webmaster Central, (Google account and login required)
* Site data at Yahoo! Site Explorer. (Yahoo! account and login required)
Watch for occurrences of
* Unusual page names that you know you didn't put on your site,
* Referrals or backlinks coming from weird sites or bad neighborhoods,
* Any indications that your site has pages it shouldn't have, or connections to other sites that it shouldn't have any connection with.
3) If your position in Google falls suddenly or if you drop out of the index,
one possible cause is that an exploit made modifications to your pages. Google sometimes notifies webmasters when they suspect a site has been hacked: http://www.mattcutts.com/blog/how-google-handles-hacked-sites/. They'll try to contact you by any email address they can discover in their files or on your site. If Google discovers that your hacked site is now trying to distribute viruses or other badware, they sometimes also warn visitors about it when they try to go to your site from a search results page.
4) On search engine result pages (SERPs), make sure the text snippets for pages from your site consist of text you know is on those pages.
5) Use your browser's View Source feature occasionally to look for invisible links in the HTML of your pages.
6) Check your site's safety report and outlinks at http://www.siteadvisor.com/.
About the Author
Write admin description here..