Chapter 4: Security Considerations

Security at the operating system level consists of the following general areas:

Keeping the system up to date

This simply means applying patches provided by your operating system vendor. Appropriate preparations should always be done first to ensure that patches don't break running applications and services. We prefer Debian-based servers and use the apt-get tools for managing our own servers.

Keeping installed software up to date

Software providers will provide updates and security patches from time to time, which should be applied to the server regularly. On Debian, apt-get helps make this a highly manageable process.

Controlling access to the server

There are several ways to restrict access ot the server. For starters, services that are not in use should be disabled. Services that are in use usually allow you to control who has access to them. For example, you may want to restrict MySQL access to the server itself only, if it only needs to be accessed by the web applications themselves. Or if you do need remote MySQL access, you can enable it on a per-IP basis.

The other way of controlling access is by using a firewall. A firewall can be a good secondary way of ensuring that services that shouldn't be accessible are indeed inaccessible. iptables is another popular tool for configuring access to a server.

Apache is a highly configurable web server, which can make it a challenge to secure. The general rule of thumb in configuring Apache is to turn off any features you don't need. For example, if you're not using WebDAV for anything, it is a good idea to not only disable the mod_dav extension, but to simply not install it at all. And if all your applications are in PHP, then there's no need to also enable CGI support. This way, there are less places a potential security flaw can occur.

Another option that can add a little security-through-obscurity (STO) to your environment is to hide the fact that you're using Apache. You can do this by not specifying your web server at all, or by specifying a different web server altogether (ie. lying). While it's not something to depend upon in and of itself, STO is a good idea as an extra measure of defense. STO makes it more difficult for potential hackers to accurately profile your web site. Profiling a site is the process of discovering and documenting everything they can find out about your server environment so that they can go back and formulate an attack plan.

To hide your web server from web clients, see the following settings in the Apache documentation:

• http://httpd.apache.org/docs/mod/core.html#serversignature
• http://httpd.apache.org/docs/mod/core.html#servertokens

For more information on the ErrorDocument setting:

• http://httpd.apache.org/docs/mod/core.html#errordocument

Another Apache security consideration is encryption. Ordinary HTTP web site requests are sent across numerous relays on the Internet with no prevention of any one of those relays from snooping in on your communication. Configuring Apache's mod_ssl module to enable Secure Socket Layer (SSL) support allows you to encrypt communication sent between your browser and the server, preventing the possibility of snooping (or at least making it much more difficult). For more info, check out the official mod_ssl web site:

• http://www.modssl.org/

It's also a good idea to disable directory listings, so that directories without index files show a 403 Forbidden notice instead of a list of available files. This can be changed via the following setting:

• http://httpd.apache.org/docs/mod/core.html#options

Additional Apache security tips are available here:

• http://httpd.apache.org/docs/misc/security_tips.html

PHP has had a mixed track record of security. Several of its early features, such as the register_globals setting, turned out to be security hazards and are now disabled by default (and some are slated for removal entirely in upcoming versions).

Another reason PHP has historically had a bad reputation for security is that it drastically lowered the bar for web application development, enabling many inexperienced people to create web apps they couldn't before. This lead to many apps becoming popular that were written essentially by amateurs and hobbyists, who didn't have any background in security.

Many security issues also arose after the fact as new techniques in web development created new possibilities for attackers as well, such as cross-site scripting attacks.

But both PHP and its developer community have matured over the years and in the right hands PHP can now be considered to be just as secure as any other language or platform. It simply depends on the software you run on it, the server environment its run on (e.g., shared versus dedicated hosting), and the experience level of the developers writing software for it.

Shared hosts will always be inherently less secure than properly managed dedicated servers, simply because you don't control the entire machine. While there are steps a host can take in minimizing the possible issues, security in a shared environment can never be 100%.

Instead of highlighting one or two individual configuration options such as open_basedir, expose_php or safemode, it would be better to simply point you to some resources for further research into securing PHP:

• http://www.php.net/security-note.php
• http://www.php.net/manual/en/security.php
• http://phparch.com/c/books/id/0973862106
• http://phpsecurity.org/
• http://phpsec.org/library/
• http://phpsec.org/projects/phpsecinfo/

The general principles of limiting access to applications and services on the server are one of the key MySQL security consideration. This is done in two ways with MySQL.

If you are not rejected, you need to set the root password. Additionally, you can restrict user accounts based on hostname and which database(s) they can access. For more info, see:

• http://dev.mysql.com/doc/mysql/en/Default_privileges.html
• http://dev.mysql.com/doc/mysql/en/Privilege_system.html

A second MySQL security consideration is to ensure that MySQL is running as the recommended "mysql" system user, and not as "root". This is similar to Apache running as "nobody", and is a common security precaution used to prevent server-side daemons from becoming loopholes for hackers to gain access to the rest of the server.

For complete MySQL security information, see:

• http://dev.mysql.com/doc/mysql/en/Security.html

A general rule for managing file ownership is to grant only as much ownership as necessary, and no more. For example, if you need permission to write to the cache and inc/data directories of your Sitellite installation, don't simply execute a "chmod -Rf 777 *" from the web server root.