web notes - a blog

For the last year or so, I have a site that sends me an email listing all the new and modified files on the server.

This morning, these entries caught my eye:

/var/www/html/
/var/www/html/c99.php

The c99 file was not supposed to be on the server.

Listing the /var/www/html directory, I found:

-rw-r–r– 1 nobody nobody 7293 Aug 1 04:58 (at sign).php
-rw-r–r– 1 nobody nobody 162032 Jul 31 05:57 c99.php
-rw-r–r– 1 nobody nobody 0 May 23 01:36 index.html
-rw-r–r– 1 nobody nobody 44283 May 23 01:36 Dont.Touch.php

I went back in my email Inbox, and found that the May 23 email was never received - cron had stopped on the server, and a ticket was sent to restart it.

The hosting company recommended I update some file and directory permissions, which I did, with the following commands:

find -type f | xargs chmod 644
find -type d | xargs chmod 755

These set permissions for a files to 644, and all directories to 755.

Tarred up the files and sent them to the hosting company, along with some notes.

On the bright side - nothing was lost, and the cleanup was pretty straightforward.

The error log showed execution attempts, which failed, and that IP address has been blocked.

Hack was not on this server.

Cool scripts that are worth buying. The purchase price is far less than the cost of the time you’d have to spend to write them yourself, and, in my case, the code’s much better, too. :)

http://jetscripts.com/sanitizer.htm - This is a much improved version of script that’s been shared and used by many people. It protects your code, data, and server. I’m using this on several systems.

http://jetscripts.com/geotool/ - This script allows you to prevent people from various locations from visiting your site. If your target market is the United States, and you don’t sell to or serve other people, there’s no need to serve pages to the rest of the world. You can customize the interface so the message.

http://jetscripts.com/captcha/ - Most people don’t like CAPTCHA forms - the images are difficult to read, and the code can be bothersome to integrate. This one’s easy to read and easy to work with.

http://jetscripts.com/jetbanners.htm - Awesome. Check it out.

Anyone writing web-based applications should refer to the above link and audit their code.

This is one of the best ways to improve the security of the application, and to learn how to write more secure applications in the future.

Never assume that your application can’t be attacked or compromised.

Although existing open source software on publicly accessible servers is easier for malicious users to attack and defeat, custom applications are not immune.

Reasons you should always strive to build secure applications:

• Improved security protects the data, the code, the server, the network the server is on, and your job. It limits the time wasted cleaning up after compromises.
• Quality. Security, done well, usually improves quality. It requires greater care to write the code.
• Future use of the code. Many applications start with a particular goal and grow. Soon they are distributed, and a wide audience can look at the code, either with an eye to collaborate - or attack.

Another excellent resource is http://phpsec.org, they have an audit you can run.

Don’t discount vulnerabilities with ‘that threat would not apply.’ Assume all threats will apply, because, in all likelihood, if they don’t at launch time, they will in the future.

Invest in SSL/HTTPS at the beginning and learn about Web Application Firewalls like mod_security (http://mod_security.org). It is okay to use a self-signed certificate, instruct affected users to trust it, with instructions on how to verify it (a screenshot is good).

Most importantly, take the time to read and learn. Even if you can’t address every issue as well as you would like, strive to address as many as possible. Loop back to improve the code if you have time.

The link above is a link to Secunia, which tracks security issues for many products.

Interpreting the data is definitely subjective, for the following reasons:

• If an application is constantly being tested and reviewed for security issues, problems will be found more quickly.
• Applications with reports of many issues may simply be tested better than others.
• Applications which are very popular will also have a greater presence, as this implies greater testing.
• Development teams that are very concientious and report issues frequently will cause a greater quantity of reports than more reserved teams.
• Development teams that refrain from reporting security issues may consider that a valid approach, by reducing the information available for malicious users.
• Some applications have fundamental issues that make them more vulnerable than others.

After reviewing the reports for an application, there are several courses of action.

• Check if the application has been compromised on your server. Immediately apply any recommended upgrades or patches.
• Review the application documentation and the site/forum for additional tips on securing the application.
• Review any appropriate server security practices.
• Determine the value of any data or content involved, with an eye toward the cost of replacement or porting to a different application. Be sure to include the cost of training, learning curve (both for users and developers), administration issues, etc.
• Consider a web application firewall such as mod_security (http://modsecurity.org).
• If you have sensitive data or ecommerce, consider a hosted solution.
• Repeat

An application that can power multiple sites can greatly reduce maintenance.

Pay particular attention to the site visitor IP addresses in the web stats.

Any IP address that has a significant amount of requests for unknown reasons should be suspect.

Use the link above, or its overseas equivalent to determine who the IP address belongs to. If you don’t think they should be using your site heavily, use an .htaccess file to block them. Be sure to block the entire block reported by the whois system.

Apache allow,deny directives allow you to block requests: http://httpd.apache.org/docs/2.2/howto/access.html

These requests will show up as Forbidden in the stats later, and should eventually stop, since they aren’t being served.

In addition - if you are seeing alot of unexplained requests, from unknown sources, you should check your server for unauthorized content.