Web Site Anti-Defacement

what are the best practices, policies, tools/utilities for monitoring & barring website defacement

From serverfault Eros

• This is an extremely open ended question, and the best answer is really "It depends." What you do to protect your site depends on a lot of factors.

  Are you on a shared hosting plan, VPS, or dedicated host? If you're on a VPS or dedicated host you're responsible for that machine's security - meaning configuring a firewall, host based IDS, locking down any open ports and using strong authentication, keeping your patches up to date, etc. If you're on a shared host - do they have a good record for security?

  Do you have a brochure-ware static HTML site that's only updated through FTP transfers of the latest revs of the files? Then you need to stop using FTP, use SFTP/SCP and key-based authentication and disable password authentication.

  Are you hosting a site that is more dynamic and allows user content, like a blog, wiki or forum? Then you have a lot more to be concerned about - picking a software package that has a good record for security, keeping it up to date when patches are released, and following guides for configuring it securely. Rename the administrator account and use strong passwords to start.

  You really haven't provided enough information for someone to give you details on how to specifically help you, though.

  From cji

• Don't run a webserver.

  Seriously, though? Use the latest up-to-date software that has at least been run though an external code auditing review, keep it up-to-date as new releases are released. Don't use unauthorized, un-audited third party software for above software. If you run php/perl/python/ruby run it through the same process as above. Static pages can't be exploited, but the server still can. If you have remote access to this server, limit it as best as possible via firewall rules. You could also setup with a company that does remote website scrapping and compares your current page to last known good one. There are several free and several commercial.

  You have to understand that there is no such thing as security, just like in real life. Everything breaks, everything can be exploited, an attacker just has to be smarter than the code author(s). The idea is to layer your approaches that it makes the attack infeasible to the attacker without outspending what the data is worth.

  From freedom_is_chaos

• Like the cji has said, there are so many variables that it is hard to know what level you are speaking about.

  If you only have access to the actual site files, then it is important to keep it up to date with the latest patches and keep an eye out for any security updates. You can also run tests using Nessus or another website scanner to look for the most common vulnerabilities. This can also be outsourced but gets expensive fast. Depending on the plugin you pick, you can check for certain vulnerabilities or even weak passwords.

  As far as "monitoring" goes, you can use a service like ChangeDetection which will show any changes to the site. If you are expecting it to be static and it changes all of a sudden, this could be a sign of a hack. If your site changes a lot because it is a news site or similar situation, this method does not work very well.

  If you do have access to compiling apache, I highly recommend mod_security. It will run anything that is POSTed or GETted (is that a word?) to Apache to check for hacks. It has saved my butt a few times on applications that we need to run but are not necessarily secure.

  Finally, if you are really serious about web app security, you need to hire a firm to take care of this. However, if you are doing this on a personal project or for a low-profile, no budget site the above steps should help you start out. There are whole careers based on your topic, so any response to your answer is not going to be a definitive solution.

  From Dave Drager

• Some time ago for a small static website we used a fully readonly filesystem: CD-ROM. It was highly cached by the kernel, so the speed was sufficient.

  warren : that is definitely a different approach! I like the alternative thinking :)
  From liori