pitter patter on the keyboard

One of the oldest and simplest ways to back up UNIX-like systems is with rsync. Automated remote backups are a simple matter of setting up rsync as a daemon on the system you want to back up and running an appropriate rsync command as a cron job on the backup target.

Let’s create /etc/rsyncd.conf on the machine to be backed up:

[etc]
  path=/etc
  read only=TRUE
  hosts allow=192.168.0.0/24
  hosts deny=*
  uid = 0
  exclude = ssh/

Any number of modules can be defined with the [module_name] convention so different settings can be applied to different locations on the file system. Module names are used in the rsync:// protocol format insted of full path names. This block says, in English: Serve the contents of /etc/ except /etc/ssh/ to any host on the 192.168.0.0 subnet at the location rsync://localhost/etc as though root was reading the files but don’t allow any modifications to the local file system.

Read the rsyncd.conf man page for more configuration options. Your rsync package probably comes with a compatible init script, be sure to enable it for your default runlevel.

On the backup server we’ll drop this little bash script into /etc/cron.hourly:

#!/bin/bash

rsync -a -u --delete rsync://192.168.0.10/etc /mnt/backups/serverxyz/etc

Now every hour the backup target will connect to the rsync daemon and download any files which have been changed or do not already exist in the backup tree, also deleting files which no longer exist on that server to preserve space.

Please skip to Part 6 for advanced vhost configuration with database-backed flat files.

mod_vdbh is a relatively obscure gem of an Apache module. It doesn’t look like it has been maintained in years and its website is gone so Google (at present) won’t give you much on it except the usual package list results and odd blog post like this. Despite living in a day of quadruple-digit version numbers, some software reaches a point where it’s “just done.” (if you don’t believe me look at qmail). I’m hoping that’s the case here, because if there’s any 0day or problems with future versions of apache we’re SOL. FreeBSD and Gentoo keep it in their package managers and that’s more or less good enough for me.

The README is hard to find so I’m posting it below for your viewing pleasure:

Configuring mod_vdbh in Apache Configure Files

In order to use mod_vdbh with Apache Web Server server configuration blocks will need to be configured with mod_vdbh configuration directives described in the table below. mod_vdbh configuration directives must be located in a server configuration block (ie <VirtualHost></VirtualHost>).

vdbh    This switch makes mod_vdbh active for the specified server.
vdbh_CLIENT_COMPRESS    Enables the CLIENT_COMPRESS option with a MySQL server allowing the connection data to be compressed. Using this option will likely require more cpu time and less network bandwidth.
vdbh_CLIENT_SSL Enables the CLIENT_SSL option when communicating with a MySQL server.
vdbh_MySQL_Database     Sets the database name to use when running a query for file name translations.
vdbh_MySQL_Table        Sets the table name to use when running a query for file name translations.
vdbh_MySQL_Host_Field   Sets the name of the host field in the table specified by vdbh_MySQL_Table.
vdbh_MySQL_Path_Field   Sets the name of the path field in the table specified by vdbh_MySQL_Table.
vdbh_MySQL_Environment_Field    Sets the name of the environment field in the table specified by vdbh_MySQL_Table. This optional field contains data that will be set to the VDBH_ENVIRONMENT variable.
vdbh_MySQL_Host Sets the internet hostname where the MySQL server is located at. This option is not required and defaults to localhost.
vdbh_MySQL_Port Sets the port number to connect to when making a connection to a MySQL server. This option is not required and defaults to 0 for using a UNIX domain socket.
vdbh_MySQL_Username     Sets the username required to gain access to the MySQL server. This option is not required.
vdbh_MySQL_Password     Sets the password required to gain access to the MySQL server. This option is not required.
vdbh_Path_Prefix        Sets an optional location to prefix translations by. This option is not required.
vdbh_Default_Host       Sets the default host to use if a non-HTTP/1.1 request was received. This option is not required and usually won’t do anything because the Apache Web Server by default catches these errors.
vdbh_Declines   Sets a list of glob patterns to match URIs against. If any match occurs then the URI is declined to the next translate phase.

The vdbh_MySQL_Host_Field and vdbh_MySQL_Path_Field along with vdbh_MySQL_Environment_Field are available as environment variables and can be included in logs if a LogFormat is defined for them. The environment variables are labled VDBH_HOST, VDBH_PATH, and VDBH_ENVIRONMENT. Information on how to use LogFormat is available at http://httpd.apache.org/docs/mod/mod_log_config.html. An example configuration may look something like this.

NameVirtualHost 206.9.161.29

<VirtualHost 206.9.161.29>
vdbh On
vdbh_CLIENT_COMPRESS On
vdbh_MySQL_Database virtual_hosts
vdbh_MySQL_Table virtual_hosts
vdbh_MySQL_Host_Field server
vdbh_MySQL_Path_Field path
vdbh_MySQL_Environment_Field environment_variable
vdbh_Default_Host julia.fractal.net
vdbh_Declines .htpasswd *.txt
</VirtualHost>

The corresponding database schema would look like this.

CREATE TABLE virtual_hosts (
server char(255) NOT NULL,
path char(255),
environment_variable char(255),
PRIMARY KEY (server)
);

INSERT INTO virtual_hosts VALUES (‘julia.fractal.net’,'/export/home/mlink/public_html’,'julia.fractal.net’);
INSERT INTO virtual_hosts VALUES (‘visualphixation.com’,'/export/home/carlosp’,'visualphixation.com’);
INSERT INTO virtual_hosts VALUES (‘www.visualphixation.com’,'/export/home/carlosp’,'www.visualphixation.com’);
INSERT INTO virtual_hosts VALUES (‘www.fractal.net’,'/export/web/www.fractal.net’,'www.fractal.net’);
INSERT INTO virtual_hosts VALUES (‘fractal.net’,'/export/web/www.fractal.net’,'fractal.net’);

Other handlers should still work accordingly.  mod_vdbh declares its translate_name phase as AP_HOOK_FIRST so it can run before other translations.  An example configuration allowing mod_tcl in specific directories follows.

<VirtualHost 206.9.161.29>
vdbh On
vdbh_CLIENT_COMPRESS On
vdbh_MySQL_Database virtual_hosts
vdbh_MySQL_Table virtual_hosts
vdbh_MySQL_Host_Field server
vdbh_MySQL_Path_Field path
vdbh_MySQL_Environment_Field environment_variable
vdbh_Default_Host julia.fractal.net
vdbh_Declines .htpasswd *.txt

<Directory /export/web/www.fractal.net>
AddHandler tcl-handler tm

Tcl_ContentHandler content_handler
</Directory>

<Directory /export/web/www.fractal.net/images>
SetHandler default-handler

Options Indexes FollowSymLinks

AllowOverride None

Order allow,deny
Allow from all
</Directory>

<Directory /export/web/www.fractal.net/files>
SetHandler default-handler

Options Indexes FollowSymLinks

AllowOverride None

Order allow,deny
Allow from all
</Directory>
</VirtualHost>

Additional Information

mod_vdbh assumes that its connection to the MySQL server is persistent. If there are excessive disconnections try setting the wait_timeout variable for MySQL to a larger value. Apache Web Server 2.0 is required, and at least MySQL 3.23 is required.

References

mod_vdbh is an Apache 2.0 module using MySQL libraries, more about Apache Web Server can be found at http://www.apache.org/. Documentation regarding MySQL can be found at http://www.mysql.com/

That’s right. That’s all there is to it. If you’ve been following the other parts in this series on Mass Virtual Hosting you should have a keen eye for the ways MySQL-backed services can be used (sexually?) to integrate into your custom web hosting front-end – or anything that interfaces with MySQL/ODBC!

Plain FTP suffers from a number of problems, foremost is transmission in cleartext. Unless SSL is used (I have come across very few occurrences of its use in the wild) usernames and passwords, as well as the files being transmitted, are sent over the wire unencrypted. This means anyone with a well-placed sniffer or man-in-the-middle setup between the client and server can intercept or mutilate the data without much skill or resource cost. FTP also suffers from NAT issues, in that some users must forward ports or use passive transfer mode – words most of the users who will be using your hosting service have probably never heard, don’t want to hear and have no idea how to implement.

Enter SFTP: file transfer over Secure Shell. Not to be confused with FTPS, or “FTP Secure” (FTP with SSL), SFTP shares nothing in common with FTP other than its purpose: moving files around the network. SFTP uses a single, wholly encrypted tunnel from the client to the server to send and receive files. This avoids the problems associated with NAT and FTP’s dual-connection implementation, provides a relatively secure means of authentication and prevents third-party manipulation of the data in transit. SSH also warns users when a server’s RSA keys change so diligent users can identify and avoid potential man-in-the-middle attacks. SFTP is not, however, a perfect solution. OpenSSH, the implementation which we will be dealing with in this article, can be found on most Linux and BSD servers. Due to its ubiquity it is a prime target for 0-day exploits on one hand, and well hardened against known exploits on the other (you do keep your software patched and up-to-date, right?).

SSH, like any service that uses a username-password authentication scheme – including FTP, is vulnerable to brute-force or dictionary cracking attacks. This problem can be virtually eliminated by disabling user-pass authentication altogether and using on shared keys (please my article Passwordless or Single Password SSH with Key Exchange for instructions on implementing this configuration) however this is probably not an appropriate solution for your public hosting project as the process is difficult for regular users to implement, particularly if they are using a Windows client such as FileZilla. One solution which I highly recommend is fail2ban, it will read your sftpd logs and temporarily block an IP address associated with a specified number of failed attempts over a given period of time. I have provided simple instructions for implementing fail2ban for SSH in my article Stifling Brute Force Attacks with fail2ban. Because we are dealing with a situation where users are prone to forget their password you may wish to use fairly loose criteria in configuring fail2ban, enough failures should be tolerated that a forgetful user won’t be quickly blocked but an automated attack should be picked up. You might also wish to block access to sftpd rather than all ports as affected users might understand sftp disappearing after several failed attempts but could think the server is down if they are unable to access their website (assuming it is hosted from the same server).

The “chroot jail” concept is as old as the hills and has provided a way for us to separate vulnerable services from the filesystem-at-large by faking them into thinking a certain directory is the absolute root (/) of the filesystem. In this article we’re going to apply this concept to regular users using OpenSSH’s built-in functionality available since version 4.9. Before then it was a royal pain to implement whereas most popular FTP daemons had supported the feature out-of-the-box for years, now SFTP can finally be considered a complete and suitable replacement.

One probably does not wish to restrict SSH access for ALL user accounts, since one probably needs remote administrative access to the machine. Therefore one shall create a group to which users who must be chroot jailed will be added. For the purposes of this article we shall call the group hosted but you may call it anything:

# groupadd hosted

Next add users to the group, if you want to make sure these users do not get regular shell access (the ability to log in and run commands etc) be sure to specify a dummy shell, such as /bin/false or /sbin/nologin (Gentoo):

# useradd -G hosted -s /bin/false demo-user
or
# usermod -G hosted -s /bin/false demo-user

Don’t forget to give your test account a password if it is a new account.

# passwd demo-user

Now open your sshd config file (most users: /etc/ssh/sshd_config) and go to the very bottom. If there is a Subsystem sftp line already delete it. Add the following:

Subsystem       sftp    internal-sftp

Match Group hosted
        ChrootDirectory %h
        ForceCommand internal-sftp
	AllowTcpForwarding no

The Match Group directive tells sftpd to use the proceeding settings for any user in the group hosted. Now you must change the owner (and optionally group) of the user’s home directory to root:

# chown root: /home/demo-user

Due to these permissions the user will not be able to create new files at the top level of their directory tree, which to you looks like /home/demo-user and to them /. That’s fine because we’re going to give them a directory for the site they want to host with appropriate ownership, then they can do whatever they want in that. I typically set users up thus:

# mkdir ~demo-user/demo-site.com
# mkdir ~demo-user/demo-site.com/htdocs
# mkdir ~demo-user/demo-site.com/log
# mkdir ~demo-user/demo-site.com/cgi-bin
# chown demo-user: ~demo-user/demo-site.com/ -R

Restart your sshd (/etc/init.d/ssh(d) restart) and try logging in as your jailed user via sftp. If it works, congratulations. If you chose to restrict regular SSH access you may need to include /bin/false (or /sbin/nologin etc) to your /etc/shells valid shells list or the user may not be able to log in at all. Try logging in via SSH to ensure access has been blocked.