I have found a great new tool for helping to detect intrusions on servers connected to the web. It's name is OSSEC, and is like a tripwire on steroids. It also provides virtually realtime information.

OSSEC is a HIDS ( Hostbased Intrusion detection system) which means that it lives on the host it is monitoring, either as a server or an agent. More on agents a little later.

OSSEC is highly configurable , just a matter of editing xml files that are laid out iin an easy to understand way. What I like most about OSSEC is that it is usable and effective with a default install. It monitors your logs, and when a rule is triggered sends an email to let you know. It checks for various access attempts, as well as, changed files, and even root kits.

OSSEC includes a large built in rule base that can be extended or added to. Granular email controls can be set to limit what is sent to your inbox, as well as a nice web interface for a complete view of alerts.

Another great feature of OSSEC is active responce. Say for instance you want to limit bad logins from ssh to a maximum of 6 in a 1.5 minute period. OSSEC can be set to block attempts after the trigger with either tcpwrappers or firewall rules for a specified period of time (default is 600 seconds or 10 minutes).

Now as I said before, installs can be either server or agent installs. The server install is for either standalone machine you are monitoring, or can be a central server to monitor all agents if you have multiple machines to monitor. For a server install, the OS must be of a Unix/Linux nature. Windows is supported, but only as an agent.

In the previous segment of this series of articles we discussed the backing up of the MySQL database with mysqldump and cron. I have since (through testing the restore process) revised the script slightly in that article. Please re read the article and add the change to your script.

Now we will discuss the restoring of our database backup. The good thing about using mysqldump to backup a database is that it uses native SQL language, and as such makes it easy to import via the MySQL CLI. With the previously discussed script, the database as well as all tables can be created from scratch.

Now as with mysqldump, if access to the command line is not available, the command can be run through cron. All that would need to be done is to enter the command, set the script to be run one time, that you specify, then delete the job from cron when finished. And of course with command line access, it is just a matter of running the script from the CLI itself.

The syntax to restore a database from within the CLI or cron is:

mysql --host=database host IP --user=username --password=password --database full_database_name < filename.sql

Lets go through these commands:

1. mysql - The program to be run from the command.

2. --host - The host name of your database server.(Can be omitted if the database is on localhost. Localhost is default.)

3. --user - The username used to connect to the desired database.

4. --password - The password for the database user.

5. --database - The full name of the database including any prefix.

The most important item to backup with any CMS with dynamic content is the database. Almost all data for these sites are stored in the tables within the database. Because of this it is good practice to backup the database reliably and often.

I have recently chosen to do a complete database backup everyday. Depending on the activities of your web site this may be too often or not enough. Some very heavily used sites, with lots of purchasing activities may do a full backup once a day, and incremental backups every 30 minutes or so. In this model the most that could be lost due to a catastrophic failure is 30 minutes worth of information. For me, 24 hours is enough to recover my site almost fully.

My favorite type of hosting package offers cPanel for the control panel. After using this for a while I will never go back to Plesk hosting or others. They do not give me the control I have with cPanel.

In cPanel there is a section for creating Cron jobs. Cron runs a command at your defined intervals. So to create a Cron Job for a MySQL database backup, we must first create a command to be run. I chose the mysqldump command because it is a native MySQL command and runs fast and clean with the database. Plus I can add options to make for an easy full restore. This is also helpful with large databases as it is run from the command line instead of from phpmyadmin and limited with a PHP 300 second time-out.

The structure of the script looks like this:

mysqldump --host=IP of Database --user=username --password=Password --database database_name --opt --add-drop-table -Q >filename.sql

Lets go through each section of this command.

1. mysqldump - This is the application that this script runs.