Since I have become a member on December 31st, 2001 here on the community it was clear from day one when I installed my own first vB instance .. abuse from malicious users is a given.

And it is up to you to protect yourself.

This means that once in a while a security release for your web server software, third party plugins from, or Wordpress, Joomla, etc, or vBulletin products is inevitable. This doesn't mean you can't take measures to prevent getting exploited. Nor does it mean you can't take measures to help get yourself back online quickly after the fact.

This blog entry points out a few handy tips for vBulletin owners who want improve their online security.

The most important thing is that you have something to fall back on. A back up. Not just a simple quick dump of some database, or a config file download. No. A complete web site backup.

So at any time, regardless what happens, you can just get a new hosting account, upload the files, the database, and edit the config file. And keep running the site.

To achieve this it's recommended to have control over your own domain name(s). So make sure they are a) in your own name, and b) you can manage them without being a member at a hosting provider. For example, register them yourself at so you can update the dns entries when needed.

And I also recommend to not do long-term hosting. Don't purchase a hosting account for more than a year ahead in time and make sure you have a money-back-guarantee. This way if you learn the host doesn't take security and/or performance seriously. You can just complete the current contract and move to a better one without losing a 3-12+ months investment.

This allows you to stay flexible and in control of your site, and your data. Restoring your web site can be done within hours.

If you are considering a host, for best performance go with a host that is at least 5 years in the business, has the experience, doesn't oversell, and offers up to date software. If they're willing to upgrade to the latest stable releases as they come out, that's a lot better than a host that's still running PHP4 and MySQL3.

Don't forget, vBulletin has a file you can use to test the hosting account to see if vBulletin runs on it. Very handy for novice users.

Additionally I recommend to get SSH2 Shell access to your hosting account. Console access over SSH seriously improves the quality of your back ups. You can make automated backups using the crontab system, and you do not have the limitations of the PHP/MySQL/Apache configuration. Ensuring your .sql dump over SSH is complete, and easy to download over FTP, rsync, wget, or otherwise in a non public and secured environment.

If you have a shared hosting solution without ssh, you're on an end user account. If for a few bucks more a month you could upgrade to a VPS that does offer shell access, you most likely end up as a root user account (admin). Those few bucks more could result in hardly any downtime, better backup results, more control over your system, and more system resources (cpu/ram/quota) available to your account.

Those are a few things to consider to help you get your site backed up properly, frequently, and easy to move and restore. Site hacked? No problem .. change host, restore account, and walk through the below tips to improve the vBulletin security to prevent it from happening again.

To prevent getting abused by malicious users, you can take a few simple steps to improve security dramatically. Choose your staff wisely, don't give them access to what they don't need. Change your email / ftp / mysql / forum login accounts frequently, say every quarter of the year. Use hard to remember and hard to guess, strong passwords - a unique one for each individual login. If they hack the forum login, they won't get into the admincp, if the .htaccess password is different. Nor will they get into the MySQL database or FTP .. etc.

Remove files that are outdated, uninstall plugins you no longer use. Remove ImpEx if you're not using it and are done with an import. Make sure you're running the latest stable version of vBulletin. And keep an eye on your account. Look for suspicious files. Do the same for add-ons you might have installed from Or other third party scripts like Wordpress or Joomla, PhotoPost or whatever you run alongside your vB instance.

Talking about removing files, don't run in debug mode, and remove tools.php, install.php and impex/. And add .htaccess password protection to your admincp/, modcp/, install/, and includes/ directories. And of course, rename the admincp and modcp directories to something unique and harder to guess.

And if you are storing media (attachments, album images, etc) in the file system, do it outside the public html directory. This way they can only be included through the proper way, but not directly called. Nor do you have to keep any 777 chmodded public directories.

Also go through your global vBulletin options and make sure you have HTML in signatures, private msgs, visitor msgs, blogs, posts, etc turned off.

The Quick Tips forum on has a few threads about improving your vBulletin security, it is worth to read it, it has all the tips with instructions.

If you have a hosting account please contact your hosting company and ask them where you can find your access_log and error_log files. And download them when you're making your daily backup. If you get exploited you can quickly find out their IP address, the timestamp when it happened, and hopefully how; and through which program. This also helps you determine how far back you have to go when restoring a backup. Most VPS and Dedicated Hosting solutions offer access to these files. Some shared hosting offer these through 24 hour rolling .log files. It's worth having them for reference.

As you can see, there are a few things you can do to make sure your vBulletin runs smoothly. And if there are users with bad intentions they will run into a wall trying to exploit your site. Because you are using up to date software. You have a good backup. And you're using a good hosting provider. This all helps you stop automated hack scripts, who will move on to someone else who did not take the appropriate steps.