It can be tempting to get the application running and leave it at that, but if the time is available going through a few simple steps can pay serious dividends in performance and stability. System administration is a huge area, but even a bit of effort can help tighten a system up.

Before doing anything, it's worth becoming familiar with the Linux distribution being run on the server, particularly it's package manager. For example:

RHEL/Centos - Yum
Gentoo - Portage
Debian/Ubuntu - Apt
SuSE - Yast

Secondly, every change should be documented, ideally on the project or company wiki so that it's reproducible and there is a history in case of a problem. At the very least, there should be a document on a company shared folder that can be used to track the process.

Modules

First is working out what the application absolutely needs. This means which Apache modules, which PHP modules and what other services are required to run properly.

php -m on the command line, phpinfo() or get_loaded_extensions() will return a list of which PHP modules are being included. They can be disabled in the php config files, but there are several distribution dependent differences in how the configuration is put together.

Some will include the PHP modules in the main php.ini, usually in /etc/ or /etc/php. Some will include multiple configurations for different environments, so the command line version may not show every module available to the CGI or mod_php versions. Some will include a directory, such as /etc/php.d, which contains automatically loaded .ini files, which enable the modules. Finally the modules may have been compiled in, especially if using a system like Gentoo which compiles all it's packages by default.

Once armed with the list of what's installed, it's just a case of paring the extensions back until the minimal set is found. In practice, it's usually fairly obvious what the various modules are providing. Unnecessary database drivers and unused protocols, such as FTP and IMAP, are regular candidates for removal.

Apache modules are loaded with LoadModule statements in the main Apache httpd.conf, in a separate module directory, or in both. Other configuration directories tend to be close to the main configuration file, for example /etc/httpd/conf/httpd.conf and /etc/httpd/conf.d/*.conf in CentOS or /etc/apache/httpd.conf and /etc/apache/modules.d/*.conf in Gentoo. In some cases apache2ctl -t -D DUMP_MODULES or apache2ctl -M will return a list of included modules.

It's the same process as with PHP of removing likely candidates and testing the server. Any extraneous Virtual Hosts or directives for default locations or similar should be removed at the same time. Some distributions come with better default configurations than others, so there isn't always much to do in this area.

Packages

The next step is to get rid of all extraneous packages. Dedicated servers and default installs are often designed to allow people to get going right away on a range of tasks, so it's not uncommon to find domain name services, email services, multiple RDMS, ftp and a whole heap of other processes running by default.

These should be uninstalled using the package management system. If the server is running a control panel like Cpanel or Plesk, get rid of that too, if it's organisationally acceptable. It's worth getting explicit approval on this point though - it's easy for someone to feel out of control if the familiar method of administering their server disappears.

Network

SSH should be the main method of access to the server, and is worth securing. "SSH Tips and Tricks" on Linux.com has some good suggestions, particularly disabling root login with PermitRootLogin in your sshd_config. This is always worth doing, but there should always be a working user that can sudo or su to root. Often it's an worthwhile idea to additionally create a user that cannot su or sudo that will own any project files and can be used whenever adding or modifying them.

Databases in a one-box solution shouldn't be listening for connections via the network. This is default on many databases setups, but if not it can usually be changed with in the main config. For example, in MySQL add 'skip-networking' in /etc/my.cnf.

The web project should be accessing the database with a specific user, rather than the default "root" or "admin". If the database came with a "root" user that had a blank password, that should be set and stored with the organisation's other passwords. Any anonymous logins should be disabled. Again, in MySQL:

UPDATE user SET password = password('pass') WHERE user = 'root';
DELETE FROM user WHERE user = '';
FLUSH PRIVILEGES;

Finally, netstat -l on the command line will show all listening processes, which should serve as a check that only the expected services are running. IpTables or another software firewall could be used to limit access, usually to ports 80 and 443, and to IP restrict the SSH port. Tech republic have a good introduction.

Maintenance

As a final point while this should reduce the surface area of the server, security issues arise all the time, so it's important to find the security updates mailing list for the distribution and make sure that there is some one to receive and action the bulletins.