web notes - a blog

Here are some tips for cleaning up after your site/server has been hacked.

Look at the files that don’t belong - find a common pattern. Most have one.

Use grep -rl pattern * to find all the affected files. If you pipe the output to a file, you can turn it into a script that can automatically delete them. However - be careful to leave any files that are important. Those will have to be cleaned up manually.

If you run into permission issues, where the files were created by ‘nobody.nobody’ or ‘apache.apache’, you can use PHP’s system command to execute the rms - like so:

system('rm -f badfile.file');

Check your error logs and access logs, as well as your stats to find any additional files.

Avoid chmod 777 - although there are times when it is necessary. This is a hazard of administering a site through the web. An excellent alternative is to always chmod 755 after you edit those files, if possible. This won’t work for caches, template compilation directories, or file upload areas.

Don’t forget to escape the input, for both command lines and SQL statements, and validate on both the client and server side.

Be sure to identify how the hacker got in, whether it was an outdated application with security holes, SSH, your code, or some other failure. Resolve that issue.

Remember that there may be more than one symptom of the hack. My server was being used to distribute files, run a phishing scam (no page requests were processed when I found it), and links to other servers in hacked templates.

If you have a hosting company, it is good to contact them for help - especially if there is any sort of phishing or other financial scam involved.

Finally, sometimes it is better to delete a corrupted application, or reinstall it.

Good luck:!:

Template engine - Smarty (http://smarty.php.net)

Scripting language - PHP (http://php.net)

AJAX toolkit - dojo (http://dojotoolkit.org)

ACL library - phpGACL (http://phpgacl.sourceforge.net/)

Windows AMP server - XAMPP (http://www.apachefriends.org/en/xampp.html)

Audio Processor - SoX (http://sox.sourceforge.net/)

Content Management System - eZ publish (http://ez.no)

ecommerce - X-Cart (http://x-cart.com)

Blog - b2evolution (http://b2evolution.net)

Timecard - timesheet.php (http://freshmeat.net/projects/timesheet.php/)

Project Management - dotProject (http://www.dotproject.net/)

Browser - Firefox (http://mozilla.org) + Firebug plugin

Hosting Company - (http://hostforweb.com)

Map API - Google (http://code.google.com/apis/maps/)

PHP includes are only included if the logic in the script requires them.

I created three files:

top.php

echo 'start<br />';
if (true)
  include 'true.php';
else
  include 'false.php';
echo 'end';

true.php

$var=true; /* Valid, but meaningless statement */

false.php

false /* Deliberate syntax error to see if the file was included */

When top.php executes, it does not report the error from false.php. This means placing include and require statements directly before the code which requires them allows you to create scripts that process only the files required to deliver the page.

One note: the performance improvement may not be worth the slightly more complex architecture. You may see improvements by using an accelerator, or both an accelerator and this architecture. This also requires more files, and the code needs to be modular.

… but to build a robust site in a timely manner which is cost-effective to maintain requires a fairly high level of skill, and careful management.

• The best sites are built by teams.
• The best sites usually have powerful applications behind them.
• The best sites adhere to standards and coding practices.
• The best sites have complex architectures that allow them to be managed efficiently.
• The best sites meet the objectives of the customer and the results can be measured.
• The best sites are delivered on time and under budget, successful for all parties.
• The best sites mature and change, gracefully.
• The best sites are monitored for reliability and security.

If you have post data, the browser will alert you on Back/Forward buttons. Sometimes, this is inconvenient. An option is to calculate the length of the GET string, and if it is within your tolerance, whatever that may be, change the form method to “GET".

Works great. Very little effort. Code includes dojo.

/* Check to see if you can create a get string of less than 255 characters */
var aInputs=('id_of_first_input','id_of_second_input','etc');
var l=aInputs.length;
for (i=0;i<l;i++)
	if (dojo.byId(aInputs[i]) != null)	
		sD+=aInputs[i]+'='+dojo.byId(aInputs[i]).value+'&';
if (sD.length < 255)
	frm.method='get';

* Within your tolerance refers to the fact that different browsers and servers may function … differently.