This how-to will show you how to configure:

• MySQL as a secure and performant database server
• Create new databases
• Additional MySQL users with restricted privileges

Installing MySQL

Adding a new database+user

Execute in MySQL:

The new user will only have privileges on the newly created database.

You can choose anything you'd like for username_purpose, username and new_password but to make maintenance easier, name your database users after the corresponding system user for that site. Database names have a relatively small maximum length, so often you can use a shorted version of the system username followed by the purpose of that database. For example, with a system user of foobar_baz then you could create the database foobar_websites to host the tables of user foobar_baz's CMS. At a glance, it's clear who's database it is and what it is used for.

As well, remember that most of your users will simply need to enter the password once at installation time of the CMS or other software. It's in your best interest to set a long, random alphanumerical password.

This how-to will show you how to configure:

• Remote access over SSH via OpenSSH
  • Secure, password-less authentication
  • Optional: OpenSSH 5.4p1 to allow restrict shell access and jail users by group
• Secure file transfers over SFTP

Configuring OpenSSH

openssh-server is already installed by default, it just needs to be configured. We will disable root logins as well as all password-based logins in favour of the more secure public key authentication. If you do not already have a SSH key, you should take the time to create one now by running ssh-keygen on the computer you will be using to access the server remotely.

The following will configure SSH as described above:

Let's make sure SSH starts on boot, restart the service immediately and finally add the firewall exception for port 22:

Because we have disabled root access over SSH, it is time to create a regular user that you can used to login over ssh and then gain root access:

Now add the contents of your ~/.ssh/id_rsa.pub file to .ssh/authorized_keys on the server.

Optional (but recommended): Rebuilding OpenSSH 5.x

Although SSH will function perfectly fine with this bare configuration, it is not the most secure possible. CentOS 5 comes with OpenSSH version 4.3p2 which is rather outdated. Instead of using 4.3p2, OpenSSH version 5.4p1 (from Fedora 13) can be rebuilt which offers a slew of new features such as access control via user/group matching and SFTP jailrooting.

Before the package can be rebuilt, a few changes need to be made to make it work on CentOS 5. Edit openssh/F-13/openssl.spec and find the line BuildRequires: tcp_wrappers-devel at approximately line number 142. Simply remove the -devel so that the line now reads BuildRequires: tcp_wrappers. Just below, you will also notice a statement BuildRequires: openssl-devel >= 0.9.8j.
Remove the version requirement so that the line reads BuildRequires: openssl-devel. Lastly, near line 178 find the line Requires: pam >= 1.0.1-3 and once again, remove the version requirement so that the line reads Requires: pam.

Now that the RPM spec file has been modified, we also need to change the PAM configuration file as the one from Fedora 13 uses some modules that are not present in CentOS 5:

The package is ready to be rebuild for CentOS 5. Execute the following to rebuild and install OpenSSH 5.4p1:

Remember to replace [arch] in the second to last command with the appropriate value (most probably i686 for 32-bit machines or x86_64 for 64-bit machines). We can take now advantage of the new features to harden SSH! The configuration segment below will restrict access for members of the serv_sftponly group such that only SFTP access is permitted and those users are jailed to the "web" folder in their home directory (so that they can only upload/download files from their website). Members of the serv_sshall group have full SSH and SFTP access, as well as X11 and TCP forwarding.

The /srv/sftp/username folder is used instead of the user's entire home because it prevents the user from making any potentially unwanted configuration changes (such as authorizing additional ssh public keys) as well as accidentally deleting files, such as the mail folder which holds all of that domain's emails. One now simply needs to link /srv/sftp/username to the appropriate web folder to jail the user there. For example:

You do not need to do this manually, as the user setup script will run this for you.

As well, note that the configuration includes the commented line #PasswordAuthentication Yes in the serv_sftponly MatchGroup section. If you so wish, you can uncomment this line to have password authentication enabled ONLY for users of the serv_sftponly group. While password authentication is less secure than public key authentication, it is much more convenient for your clients if you are building a shared hosting machine and if a hacker does gain access because a user had an easy to guess password, they only gain access to a single jailed SFTP client.

Denyhosts

You may be wondering why I haven't included any information about software that can block repeated SSH intrusions such as denyhosts... I have placed this information, along with other server security tips, in the security tutorial (coming soon). Please see it for more information.

Administering the server

Setting up the scripts

The following code will setup the "hosting_user_add" script which can be used to add new hosting users on your server:

You will need to edit /root/bin/hosting_user_add later and replace your_key_here with your own SSH key so that you can login to the account should you ever need to test or do administration work.

Adding a new system account

If you are adding many accounts, you can optionally specify more than one username to have each account be created at once. For each user specified, you will be prompted if for both their password and restricted status. Passwords can and should be set randomly because with key-based authentication, they should never have to enter it anyways.

Resources and further reading

• DenyHosts homepage
• Debian Administration article titled "OpenSSH SFTP chroot() with ChrootDirectory"

After much research, experimentation, testing and tweaking I'm happy to announce that I have completed the first part of my CentOS 5 server setup howto series!

As of today, you'll notice a new CentOS 5 Howtos link on the where I have listed the first two parts of the howto series, the getting started howto which will help you setup a basic system environment and more importantly, the mail server howto which documents how to setup a secure mail server offering POP3/IMAP/SMTP with virtual users stored in a MySQL database.

I'm very happy with this setup because it uses virtual users that cam be mapped to system users and also keeps the software set relatively small; Dovecot is used for SASL authentication (both for POP3/IMAP and SMTP) and for postfix's local delivery agent, so with only 2 servers we've got it all covered (of course technically it's 3 servers with an extra transport if you take amavisd and response-lmtpd into account).

The virtual user database is currently only used in this tutorial for the mail server, but I have plans to introduce (with an upgrade path) a new database structure that will unify several authentication data pools and make managing clients for a shared hosting server easier... But I'll talk more about that later once I've finished posting my other guides. I plan on adding ones for other services such as DNS & Web, although I cannot promise when those will be finished. The mail server tutorial alone is 16 printed pages (!) so it does take me quite some time to ensure that the tutorial is well documented and that the configurations listed work properly.

I still have to add some notes here and there about the implementation, but the core material is there. Enjoy!

Preface

As of writing, the most recent version of CentOS available is 5.6 so I will be using it as the basis for this howto. If a newer version is available, I recommend you use that version instead. Much of these instructions should still apply, especially if it is only a newer 5.x release.

This series of tutorials will help you set up a shared hosting server using hardened CentOS 5. The server will:

• Run hardened CentOS 5
• Use the Apache HTTPD daemon to serve webpages (optionally with SSL) using the ITK MPM
  • Have PHP 5 installed with the gd, mhash, mcrypt and suhosin extensions
  • Use mod_evasive installed to avoid DDoS attacks and mod_security to prevent hacks
• Use dovecot to serve email to clients over IMAP and POP (both with SSL)
  • Dovecot looks up virtual users in the MySQL database and performs the SASL authentication
  • Dovecot is responsible for delivering all mail to each user's inbox
  • Each virtual user can be mapped to a system user and group
  • Roundcubemail configured for easy web access on all email accounts
• Use Postfix MTA to accepts mail on ports 25 and 26 (for ISPs who block port 25) as well as 465 and 587
  • Relay access is denied without prior SASL authentication (which is handled by Dovecot)
  • User administration is easy; a change in the MySQL database will affect Dovecot and Postfix simultaneously
  • All incoming mail is scanned for spam (SpamAssassin) and viruses (clamd) with amavisd-new
  • Mail is rejected with an error instead of mail notices to prevent backscatter spam
• Allow you to host multiple websites easily
  • Email addresses & passwords are stored in a MySQL database
  • Email aliases and domain-wide aliases (forward each user and alias in one domain to another) are supported
  • Each website gets its own system user making permission control easier and limiting damage in the event of a break-in or site hack
  • Flexible SSH configuration: each system user can independently be granted full SSH addess or be jailed to their ~/web folder

Before starting

When writing this tutorial, I assumed that you:

• Have installed a Red Hat-based Linux distribution (RHEL, Fedora, CentOS, etc) before
• Have a basic knowledge of how to use the command line (how to create/edit files, executing commands)
• Have an extensive knowledge of the various security problems you will need to deal with while adminstering the server, including:
  • Rootkits and malware
  • Intrusion detection & prevention
  • Denial of service (DoS/DDoS) attacks
  • Spam prevention and backscatter spam
• Are familiar with editing configuration files
• Know how to add/remove software on the system using Yum
• Are familiar with the basics of RPM rebuilding

Legal Disclaimer

Please note that this guide is provided on an informal, as-is basis. Although I have done my best to research, test and secure this setup, I am not responsible for any damanges you suffer as a result of using this configuration. Remember that you need to thoroughly test any setup before implementing it on a live server!

Installing CentOS 5

Visit the CentOS project website and download the latest 5.x netinstall ISO image from a nearby mirror. You will be installing the bare minimum set of packages, so there is no need to spend hours downloading all 7 CDs or the large DVD - you will only need the netinstall image. However, because we will be installing from the network, please be sure to mark down a mirror URL that you wish to use for the installation from the list of CentOS mirrors. You will need to enter this mirror's hostname and the path to the CentOS RPMs later on in the installation process.

Once you have started the installation process, choose the HTTP install method and enter the URL and path that you noted earlier. In the example below, I am using mirror.iweb.ca.

For more information on this process, see section 12.11 of the Red Hat Enterprise Linux installation guide, Installing via HTTP.

When promted for choosing a disk partition layout, choose the option that best suits your needs from the drop-down menu. However, ensure that Review and modify partitioning layout is selected before clicking Next.

Although not strictly nescessary, it is also wise to create a separate /home partition for your user's data. Keep in mind when allocating space to partitions that by the time you have finished configuring the server, all of the user data except MySQL databases will be stored on the /home partition (MySQL databases are stored under /var/lib/mysql instead).

After selecting the root password, you will find yourself at the package group selection step. Unselect all groups, click Customize now at the bottom of the screen and then click Next.

Browse in every section and unselect all groups, including the Base group. A server is only as secure as its weakest component, and so there is no sense in running or even installing any unnessesary software that can provide hackers with potential attack vectors. By installing a smaller software set, your server will be more secure.

Now that you've unselected all package groups, hit Next again to start the installation process. After a reboot, you will be running a bare-minimum CentOS 5 system!

Repository setup

The first step after installation is to install a few extra repositories. These will be used to install additional packages that are not included by default in the official CentOS repositories.

EPEL

EPEL (Enterprise Packages for Enterprise Linux) is a community-run repository as a part of the Fedora Project that contains many additional packages that we will find useful during the server configuration.

Note: this command works at the time of writing. However, in the future the release of the epel-release RPM may change. If this command fails, please see the FedoraProject EPEL page for the most up-to-date instructions.

CentOS test repositories

The CentOS test repository contains packages that are on their way to CentOS Plus and/or CentOS Extras. Currently, it holds PHP 5.2 which we will use in the web server tutorial and it may contain other package upgrades that you find useful.

CentOS source repositories

Over the course of the server setup howto series, you may need to (re)build a few RPMs. Because of this, we will need to configure the CentOS source repositories so that the original CentOS SRPM packages can be downloaded and rebuilt.

64-bit users only

If you are running a x86_64 system, yum will install the x86 (32-bit) alongside the x86_64 version of any package you install. This is rather pointless, so we can start by blacklisting all 32-bit packages. To do so, add the following line to the [main] section of /etc/yum.conf:

Then we can proceed to remove the x86 packages that are preinstalled by the CentOS installation process.

WARNING: DO NOT run this if you are running a 32-bit CentOS 5 system (for example i686). Accepting the removal confirmation on a x86 machine will essentially remove your entire system.

Additional packages

The following list of packages are either used by the tutorials or are good general-purpose/troubleshooting utilities to have:

Also, let's replace the rather old syslog daemon with the much more modern syslog-ng:

Basic firewall & SELinux configuration

Because all groups were deselected during installation, iptables has not been installed yet. Let's install it now:

Next, the system security configuration utility can establish some basic firewall rules and put SELinux into permissive mode so that you may test your server setup and then configure SELinux based on the denials logged (more on that in the security & reliability guide).

Press the Tab key twice and select Permissive from the menu, then Tab twice again to select Customize.

Because we only want to establish the base firewall rules, do not select any exceptions (they will be added later) and just press Tab until you can choose OK. Finally, select OK again to close the configuration utility and save the system security settings. Your /etc/sysconfig/iptables file should now look something like this:

If you wish, you may remove the rules for corresponding to ICMP (ping among others), ports 50, 51 (VPN), 631 (shared printing via CUPS) and 5353 (Multicast DNS).

RPM building environment

Note that you may wish to rebuild the package in another virtual machine/test CentOS environment, as the build process will require the installation of many additional developer packages that are not required on a server machine.

Building RPMs as root is highly discouraged, as a simple typo in the spec file could damage your system. Thus if you do not already have a normal user account created on the server you should take the time to create one now:

Next, switch to your regular user and setup the RPM building environment:

System Updates

Before configuring any services, make sure the system is up to date:

Now, let's move on to the more interesting part, installing and configuring the services!

• SSH+SFTP for remote access and secure file transfers
• Server security & reliability
• SQL database server
• POP3/IMAP/SMTP mail server
• HTTP/HTTPS web server
• DNS server

I have been working with a client to setup an Ubercart store customized to their needs and one of the things we came across as we launched the store is that because of the nature of the items being sold, it was very difficult to give a accurate shipping estimate. Thus, I set off to find a way to enable customer payments after checkout and to enter the shipping quotes manually.

These two modules, uc_manual_shipping and uc_payafter, are the fruit of these efforts. I hope you find them useful!

Note that this is my first release of these modules and the code should be considered a beta and work in progress. They are untested so far and not recommended for use on a production site just yet. All information about installation, configuration and further development is available in the README.txt file, DEVELOPERS.txt file and/or source code comments. If you have made some changes or improvements, please let me know in the comments! I would love to hear about your changes and I would be more than happy to apply any patches or bugfixes.

uc_manual_shipping enables the store administrators to manually enter shipping quotes on orders after a user has passed through checkout. It can be used in combination with uc_payafter to have users create go through regular checkout without paying, and then pay later once a shipping quote has been submitted by a store administrator.
Download uc_manual_shipping-6.x-1.0.tar.gz

uc_payafter duplicates the checkout process and allows users to perform payments on their orders after checkout at the URL cart/checkout/pay/$ORDER_ID. Store administrators can email users different invoice templates after payment.
Download uc_payafter-6.x-1.1.tar.gz

Update 2011-06-08: A user in the comments, Moises, has pointed out that in the 6.x-1.0 release of uc_payafter there was a typo that would prevent users from being able to select the request shipping invoices in the conditional actions configuration. I have updated uc_payafter below to fix this bug.

Update 2011-11-08: uc_payafter has a new home! I have created a Drupal Sandbox project for the code here. Once I have the chance to work on the code a bit more, I will promote it to full project status and update the download links in this post.