During the Installation of Web sites we have found that clients fall into one of three general categories, confidential commercial, non-sensitive commercial or educational, and Internet Service Provider. Each category has differing requirements in terms of security required, data sources desired, and user access allowed. We examine three possible web server configurations: Confidential Internal Web Site, Public Web Site, and Provider Web Site. For each type of web server configuration the known risks are highlighted, and the methods that we have employed to eliminate these risks are examined.
In general, the ability of people on the network to intercept the data packets of another user are either ignored by the system administrators or thwarted through the implementation of better networking, such as switches and routers. The ability to segregate users is enhanced through the widespread introduction of twisted pair (10 base T) networking technology.
The public web server allows the user community to retrieve documents, but not to upload documents. Documents are placed on the server by the server administrator.
The Internet service provider who provides open access web to both customers, for content, and the general internet for consumption, has a unique set of problems. The web server is open to abuse from both the content providers and the content consumers. The population of users who have access to the server for the purpose of providing data is less defined than a system administrator. The users who publish are typically naive, inexperienced users, who can inadvertently destroy parts of the web site. The site must be protected from the public user, and also from either inadvertent or deliberate damage from a legitimate user.
An internal web server, although it may be holding sensitive data, is not generally open to as significant abuse as a public web server. Security focused administrators should, however, protect internal servers with the same rigorous attention as public servers. A web server for internal intranet use needs the same level of protection as company public file servers.
The procedures we use to harden a web server are the same procedures used to hardening any data server. The standard dictum: if it is not required, don't run it applies. If the web server is to be a UNIX box the machine is firstly stripped to a bare bones system, all programs not required to boot the system and the network are removed. In an extreme case the programs init and sh are removed for added security. All system network daemons are removed. The web server is placed into a chrooted environment with only those support programs required. If maintenance of the web server is required the machine is halted, and a more general UNIX system is booted from floppy disk. This allows administration of the server in a rich environment, but allows us to maintain strict control over the run-time environment.
CGI scripts pose the greatest threat to a web server. A badly written CGI script allows random programs to be executed. A standard firewall does not prohibit these types of attacks, as the requests appear to be legitimate web requests. We solve this problem by installing a web screen. This program sits between the web server and the network, filtering all vulnerable or suspect web queries. This allows the web server to be bound to a high port (blocked for direct access) and as such no root privileges are required by the server. The web filter can be installed as part of a firewall package, or if a third party firewall or no firewall is installed, the filter can run on the server machine. It is preferable to run the filter on the firewall, as it allows the server to be transparently moved, and does not involve additional overhead on the server machine. The figure below shows the arrangement of the firewall. The Web server sits on the secure network, which is protected from both the public and private networks by the firewall.
A web server can be carefully constructed to allow easy access by external users, whilst still allowing security of data. By inspection of incoming requests for suspect or dangerous requests, a whole class of problems may be eliminated, and by careful construction of the software in the server machine itself the likely damage that can be caused is minimised. All these actions are totally transparent to the user community, who still perceive full functionality for valid requests.
Problems arise when the CGI program is subverted, either due to a coding error in the program, or because the interpreter is subvertable. Examples of problems include:
Allowing the program interpreter, such as a shell, or perl, to exist in the document tree allows an attacker to execute the interpreter with any desired input. This gives the attacker complete freedom to your machine. This is performed by executing the interpreter as a CGI program, and posting the program to execute as input.
The World Wide Web Security FAQ [HREF2] details the dangers with CGI scripts.
The corporate web site was designed to provide both internal and external information. Due to the limited resources available only one machine was available for both servers. The available machine was designed as a firewall, implementing an application proxy gateway. The server was dual homed, so two IP addresses were available. A web server was built that had two separate document roots, the public root was in a sub-directory of the private root, allowing the public documents to be reached from the private web root without accessing the external server.
All authentication was performed through the IP address of the source of the request and the IP address of the destination server. Since the system was firewalled the internal web server could not be accessed through the external interface, prohibiting external users from obtaining sensitive information. A web proxy also ran on the machine, allowing selected external users to access the internal server.
The proxy that allowed external users access to the internal documents screened the requests, this allowed management to selectively provide external users access to portions of the internal document tree.
The Web server was configured to have a general document root, that provided access for company related pages, and to use the ~uname user root ability to allow users to have web pages, and a web root. To allow the users to upload their own pages the Wu-ftp Daemon [HREF3] was installed, and configured. The web server was configured to allow the users to have non-anonymous access, but only to the user's directory. This allowed the user to change their home pages, but not to interact with another users' pages. CGI scripts were restricted to system scripts, so users could not run CGI scripts. This was considered adequate for customers, as more sophisticated customers wanted their own web server.
External users could use the web server to obtain any page, both the providers' business pages, and the providers' clients' home pages. The clients were restricted in the type of information that they could publish on the web, as all CGI scripts had to be vetted before being used.
The filtering of web access for the internal users was selective. Students were divided into several categories, and the range of web sites available for each category differed. The first level students could only access the local web server, they had no external access whatsoever. Second level were allowed more freedom, Third level even more freedom, and a full level had unrestricted access. Staff also had unrestricted access.
The web server machine was coupled with the firewall to provide authentication for users when they logged into their workstation. As each workstation successfully logged into the system a level was assigned to that IP address, and requests from that IP address were filtered at that level by the web filtering software. The firewall also used the level information to filter electronic mail, and other network accesses.
The customisations required to the firewall and web server to achieve these goals were extensive, requiring integration of multiple systems with a central user database. The list of restricted web sites were maintained by IP address or by URL.
| Pointers to Abstract and Conference Presentation | |||
|---|---|---|---|
| Abstract | Papers & posters in this theme | All papers & posters | AusWeb96 Home Page |
AusWeb96 The Second Australian WorldWideWeb Conference ausWeb96@scu.edu.au