Recommended Columbia University Web Environment

The purpose of this page is to provide people running their own Web servers with guidelines for establishing and maintaining a secure web environment.

CUIT's standard web environment is Apache running on Red Hat Linux. If you use different web server software or a different operating system, you should still follow these guidelines, but of course the specifics may vary.

Stay Up to Date

You should keep all software components of your system patched and as up to date as possible. You should also stay informed about patch releases and vulnerability discoveries so that you can protect your systems as quickly as possible.
You should regularly check your secure sites for vulnerabilities. Here is a handy tool for doing this: https://www.ssllabs.com/ssltest/index.html

Limit Access to Server

Access to a web server should be limited to the minimum required by business needs. This includes physical, network, login, and server configuration. For example, unneeded services should be disabled, logins limited to authorized personnel, and network connections restricted to defined network ranges where appropriate.
In some cases, additional web server modules or extensions can be deployed to prevent against certain types of known attacks.

Limit Unwanted Automated Crawling

If you do not want the content of a web server to be indexed, use a highly restrictive robots.txt file.

# Disallow all crawling
User-Agent: *
Disallow: /

Most reputable search engines and other content indexers will respect a robots.txt file.
If you want the content of a web server to be indexed, go ahead and allow crawling, but limit it to areas that contain public-facing content.

CGIs and Other Scripting

Modules that enable CGI, PHP, and other scripting languages should be used only when the business rules of the system require it. The modules should be invoked only in areas of the system where these programs are permitted to be run.

Restrict Information Leakage

In general, you should restrict the amount and nature of the information about your system that is exposed to visitors without authentication or authorization. For example, standard error pages frequently display operating system, web server, and application version information; such information can be used by malicious parties to attack a system.
For example, in Apache 2.2 and above, server information can be restricted with these configuration directives:

ServerTokens Minimal
ServerSignature Off

Applications running on a web server should also be carefully checked for information restrictions. For example, Tomcat can be configured to remove its version number from error pages.

Additionally, some web servers provide special URLs to display specific server information and status (e.g., Apache /server-info and /server-status). Access to the URLs should be restricted or disabled to prevent disclosure of this information to potential attackers.

Server-Side Includes

If you allow server-side includes, you should restrict arbitrary code execution. For example, in Apache, use IncludesNoExec as one of the directory directives.

Defend against Cross-Site Attacks

You should take steps to limit exposure to cross-site scripting and similar attacks. In many cases, this is an application-development and architecture issue, but some measures can be taken in the web server configuration.
For example, you should disable the HTTP Trace method. In Apache, use this configuration directive:

TraceEnable Off

Strengthen SSL Configuration

If you are using SSL, you should use the most recent versions of your Web server software and its secure components.
Further steps to further secure environments:

Disable old SSL versions

SSL v2 should be disabled. This is an old version of the SSL protocol and has been superseded by newer, more secure versions. For example in Apache, you can disallow SSL v2 by using this in your configuration file:

SSLProtocol all -SSLv2

Use Strong Ciphers

Only strong ciphers (at least 128 bits) should be allowed, and cipher preference order, if available, should be enforced to prefer the strongest ciphers. For example, in Apache 2.2 using mod_ssl

SSLCipherSuite HIGH:MEDIUM:!aNULL:+MD5

Some SSL attacks can be mitigated by carefully choosing the cipher order. For example, vulnerability to certain attacks can be mitigated by preferring certain ciphers over others, and by turning off data compression:

  • BEAST vulnerability (choice of cipher suite)

  • CRIME vulnerability (compression)


It is imperative to keep up abreast of security developments and deploy preventative measures to prevent damage from future attacks.

Directory Restrictions

Your web server's root directory should always have the most restrictive configuration enabled to reduce the likelihood of security breaches. For example, in Apache, you might include this in your configuration:

<Directory / >
Options None
AllowOverride None
Order allow,deny
</Directory>

Many web servers allow directory listings (displaying the list of files in a directory if no index file is present) and will follow symbolic links (aliases). You should disable these options globally.

If either setting is required for business reasons, it should be enabled on a case-by-case basis.

In Apache, the AllowOverride directive can be used to allow delegated management of web files where appropriate:

AllowOverride AuthConfig FileInfo Limit

Similarly, linking to other files owned by the same user can be enabled by:

Options SymLinksIfOwnerMatch