Web Site Security
Andrew Cormack, UKERNA

Abstract: Web sites are the public face of the organisation on the Internet. As everyone from the Department of Justice to the Conservative and Labour parties now knows, that makes them both an obvious target for others with different views and a great potential embarrassment when things go wrong. This talk will consider how web services can be compromised and what you can do to prevent the worst happening.

Biographical Details: Andrew Cormack has been Head of CERT at UKERNA, responsible for advising and assisting UK educational institutions on computer security, since March 1999. Before that he was a Unix systems manager at Cardiff University, responsible for the web servers and caches.

Successful attacks on websites can result in a great deal of bad publicity, especially when an official site is replaced by pages presenting the host organisation in an unflattering light. Damage to political and government web sites has made the national news, but defacing any website is likely to harm its owner. Internet image increasingly influences attitudes in the real world too, especially for organisations with customers around the world. For many prospective students or sponsors your web site will be their first, and in some cases only, contact with your institution. All web managers should therefore be concerned with security to ensure that the content and conduct of their site remains under control.

Attacks against web servers are not usually motivated by dislike of the owner organisation. Some people just wish to publish their own views and will use any well-connected server for this; others are simply looking for powerful computers with good connectivity to distribute pirated software or to mount attacks on other Internet sites. A web server on a high-speed network like JANET is likely to be a good choice for either type of activity.

Although running a web server may make a machine a more attractive target for attackers, it is unlikely to make it significantly easier to break into. Web server software is generally reasonably secure already: successful attacks are usually achieved through errors in configuration or vulnerabilities in the underlying operating system. There is no point in securing the web function if the rest of the machine offers open doors to intruders. There are three basic rules for securing any system:

1.      Offer as few services, to as few people, as possible. Extra services will, in any case, affect the machine’s performance as a web server as well as providing possible routes for break-ins.

2.      Keep the system up to date. New vulnerabilities are discovered every week, and are exploited soon afterwards.

3.      Check log files for warning signs.

Each of these should continue throughout the life of the server. Although this requires effort, the procedures are well known. Few people have the ability to discover and exploit new vulnerabilities so the vast majority of security breaches result from well-known problems that could have been avoided. Prevention may seem expensive until you consider the alternative cost of repairing the damage after a breach has occurred.

There are three categories of damage that may result from a security breach: loss of service, loss of information and loss of control. Loss of service generally happens either by accident or through hostile intent, and is usually caused by overloading the server with requests. Unfortunately it is very hard to protect a public web server against this kind of “denial of service” attack: a web server’s function is to respond to requests from browsers and it is almost impossible to distinguish between a busy day and an attack. No vulnerability is being exploited except the finite capacity of any system, so no amount of preventative work can help. The best solution is to ensure that your system still has spare capacity when “normally” loaded and hope you can handle requests faster than your attacker can generate them. An attack at this level will be highly unpopular with the originating network, as well as your own, so should be stopped at source before too long. JANET-CERT can help in tracing the origin of attacks, and can also advise on blocking problem hosts.

Loss, or strictly leakage, of information is, in one sense, a rather paradoxical concern on the web. The web was, after all, designed as a publishing medium for public content. As a result there are few effective controls on who can read your content from the server: passwords and restriction by source address can both be defeated by a determined thief. Beware especially of using the same password on a web site as on other, more secure, systems. Before you put truly secret information on a public web site, consider first whether this is really appropriate and if so protect it with some off-line encryption method such as PGP. There is, however, a serious concern that a web server may give away information about the system it runs on such as usernames, configurations or password files. These could be useful to a hostile person planning an attack on the machine. Such leaks are usually caused by bad design, either in the server program or, more usually, in its configuration. CGI scripts which allow readers to fetch any file from the server are a long-standing favourite with the hacker community, still being actively and successfully exploited. Any program to be installed on a server should be checked very carefully by someone other than the author. Writing safe scripts is hard and even commercial examples have been known to have problems.

The most serious consequence of a security incident is loss of control. Once an intruder has gained the ability to run commands on the server it is usually impossible to determine what changes have been made. In particular most intruders take the precaution of installing another method for gaining access to the system, so that even fixing the original problem does not prevent them coming back. In this situation the owner can no longer to be sure what the machine contains or what it may be doing. At any time the web pages may be replaced or the server launch an attack on a US corporate target, for example. With meticulous preparation before the event it may be possible to repair a compromised server but more often the whole system needs to be re-installed. Either option will involve a lengthy period of down time, considerable inconvenience and possibly lost work for publishers, readers and administrators. Such incidents can only be prevented by careful design, maintenance and use of the system. Users too must be involved, especially if they can log in to the server from remote locations to maintain their pages. “Borrowing” the account of a legitimate user is one of the easiest ways to gain access to any computer. Some sites have decided that maintenance and publishing should be separated: the public machine then becomes a secure “read-only” site which can be tightly secured. Pages and scripts are developed on another server, which is not exposed to the Internet, and copied to the public site under strict control. This design can also isolate internal readers from the consequences of an external denial of service attack, though it does not protect against hostile or careless users within the organisation.

In conclusion, it is possible to keep a web site secure but it is not easy. The design, maintenance and use of the server must all be carefully planned and executed to reduce the risk of incidents. In particular, claims of “ease of use” should be treated with caution in case they make life easier for the intruder as well. A web site can be a major asset for an institution and should be protected according to its value. Protection is not easy, but a reasonable level of security is not impossible. There is ample advice available on the web and among the community: some useful documents are listed below. Finally, for JANET customers, remember that the CERT is available to help in preventing incidents as well as curing them.

For more information

CIAC bulletin J-042 is a useful guide to best practice in designing and operating a web server. http://www.ja.net/CERT/CIAC/j-fy99/j-042.web.security.txt

The W3C’s web security FAQ maintained by Lincoln Stein http://www.w3.org/Security/Faq/, especially for its links on secure CGI programming.

Security hints for the particular web servers:

·        Apache http://www.apache.org/docs/misc/security_tips.html

·        Microsoft IIS http://www.microsoft.com/security/products/iis.asp

·        WebStar http://www2.starnine.com/support/faq.tmpl?thisproduct=WebSTAR&thisheading=Security

JANET-CERT web site at http://www.ja.net/cert/ or e-mail cert@cert.ja.net. A page listing manufacturers’ sites for security patches is at http://www.ja.net/cert/JANET-CERT/prevention/patches.html