I'm continuing from this (closed) thread in Site Discussion about advice for securing your own websites and forums. Rob Carriere had some excellent advice, which I'm reposting. A key part of security is understanding the issues, even ifyou're not going to be doing the maintaining yourself!

Rob Carriere wrote: There are basically four types of attack you have to deal with:

1- Attacks against the network protocol stack. These are low-level attacks, they have nothing to do with what sort website you offer, or even whether you offer a website. They are possible against any machine that is connected to the Internet.

The defenses are:
. Keep your operating system fully patched.
. Run your machines from behind a firewall.
. If possible, select your operating system with security in mind.

In your case, these are probably the worry of your hosting provider. If you are concerned, check their policies in this regard.

2- Attacks against the webserver. These are mid-level attacks, that depend only on the fact you are offering some sort of website.

The defenses are:
. Keep your webserver fully patched.
. Do not activate any webserver modules/plugins/whatevers that aren't actually needed for your website.
. If possible, select your webserver with security in mind.

Again, this would probably be up to your hosting provider. I took a quick look and it seems that your website is running Apache (good) and it is configured to not publish its configuration (better than 90-odd % of websites out there). Based on that, I suspect you may well have a security-conscious hosting provider. However, you should check to make sure.

3- Attacks against applications running on the website (such as a bulleting board, a wiki, a blog, or even something as silly as a visitor counter.) These are high-level attacks, that will obviously only work if your website is actually running the targetted application. (This is the reason for the defense under 2 above--if it ain't there, they can't hack it.)

The defenses are:
. Choose your applications wisely. Some programs are much more prone to security flaws than others and some programs are much better known than others. Obviously, the worst case is a well-known, poorly-programmed application. Sadly, phpBB comes close to qualifying. It usually has several security problems per year and it is probably the best-known bulletin board code, so these problems are invariably exploited and usually exploited quickly (under a week, in the case of the Forge).
. Keep your application fully patched.
. Be very, very careful with customization and configuration. Far more security problems originate in poor configuration than in poor applications (and, considering the quality of some apps, that's saying a lot!) If you don't understand the configuration, talk it through with, or defer it entirely to, somebody who does.

Between these three kinds of attack, there are many, many possible technical approaches. The good news is: you don't really care how they hack, you just care what they are hacking for. Again, there are a number of classes of goals, but in the wild we really only see three:

- Denial of service. The attack causes your site to be unreachable or otherwise useless. Two examples would be generating such massive amounts of fake traffic that you webserver can no longer handle the real traffic and causing a crash of your webserver.

- Destruction of information. What happened with the Forge: somebody wiped all the data. A more subtle approach would be to introduce errors in the data (fake posts, for example)

- Theft of information. A favorite with sites that record sensitive data such as credit card numbers.

Recovery from Denial of Service consists mostly of waiting it out. Sooner or later the attack stops and life continues.

Recovery from destruction of information depends on having backups. Backups on the webserver are good, because they allow rapid recovery, but not sufficient, because a good hacker will destroy them as well (as happened with the Forge). So have a strategy to feed backups to a secure location...frequently.

There really is no good recovery from Theft of Information, other than waiting through the (usually long) period until the people whose information was stolen stop being mad at you and start trusting you again. For this reason, many sites transfer sensitive information off the webserver to somewhere more secure ASAP. (That means: within seconds.)

4- The fourth kind of attack is not against your site at all, but against your site's visitors via your site. The usual trick with a bulletin board is that I post something that contains code. Anybody who views my post will be running my (hidden) code in their browser. If this code is designed to exploit one of the many open security problems with Internet Explorer, I can do whatever I want on the computers of all your visitors...

The defense is to strip incoming posts of anything that even looks like it might be dangerous--the bulletin board code should be doing this work for you.

The most common problems with bulletin board sites are all input stripping related. Either type 3 or type 4 attacks may be possible if the input stripping isn't good enough in each every place the software ever asks for input (which is many places!)

I'm not sure if this is really on-topic for the Publishing forum, but...

My first recommendation is this: use the simplest thing that lets you do what you want to do. For example, if you just need a forum, don't necessarily go for something with calendars, portals, mailing lists, blogs and file sharing built in. If you have to go for something fancy, at least disable any extra features that you're not using.

My second recommendation: if you have an application with a good track record on security, don't jump at new versions right away. Give it a couple of weeks or months to see if other people find new problems and then upgrade once those problems have been fixed.

Third: make sure your web server restricts access to program files and directories as much as possible. It's amazing how many simple hacks are prevented by putting a blank index.html file in every directory (or denying directory lists altogether).

Fourth: make your stuff non-standard whenever possible. For example, I once used a web server that got hacked and the person replaced a lot of common files (like every index.html file) with hacked versions. While it still messed up some pages, I had renamed several of my forum's files and so the hacker's script didn't find or change them. Of course, by suggesting that you make things non-standard, I don't necessarily recommend changing code, where you can introduce more problems than you fix.