As with Web server operating systems, “The more complex the Web server software is, the greater is the chance that something will go wrong.” Generally speaking, the more functionality and features that are provided by a Web server, the greater is the likelihood that there are security holes in the software.
Basic Web server software that merely provides access to static files is more secure than sophisticated server software that provides functions such as the execution of CGI scripts, the processing of server-side includes, the handling of scripted errors, and the dynamic listing of directories.
Web server software also differs in the degree of control accorded to browser users. Certain servers allow users access to only certain documents or directories or sub-directories, while some allow full access to everything. Some can be configured to allow access to certain directories according to the IP address of the client machine, or to individuals who know the right password. There are a few Web servers that offer data encryption, a necessity for e-commerce web sites. These are mainly commercial Web servers.
Here is some advice on how to make a Web server more secure:
– By their nature, Web servers have security holes. One of the most common causes of a breach of security is the CGI script. If you cannot get a CGI programming expert to check the scripts’ code, at least test the scripts to ensure that they verify the data entered by a browser user before granting access to confidential documents or any services provided by the server’s operating system.
– Configure the Web server carefully:-
— Executable files should be allowed to run only in certain directories that you specify.
— Source code should not be stored anywhere where it can be downloaded.
— Automatic directory indexing should be switched off. If you use an external Web hosting company and you cannot switch it off, ensure that all accessible sub-directories contain a default file such as ‘index.html’ that redirects the browser to the home page.
— If you do not need them, disable Content Management Systems and other features that allow browser users to edit and manage files on remote servers, such as WebDAV, SMB, SharePoint, etc.
— Identify potential weak points by utilizing the security tools that come with the server software and the Operating System, such as the Microsoft Internet Information Services (IIS) Lockdown Tool and the URLScan security tool.
– Private and public information should be kept physically well apart. Confidential or sensitive data should not reside on the same machines as publicly accessible Web servers. Intranets should always be protected by a firewall, but extranets can be tricky, if you want to allow certain outsiders to have access to some private data. An extranet Web server should be located outside the firewall. (This is known as a “sacrificial lamb” configuration.) A variation is to set up paired “inner” and “outer” servers. Another possibility is to use a proxy, which intercepts requests and forwards them to the Web server, and then does the same in the reverse direction. Ideally, any publicly accessible Web server should be located on a machine other than that on which the firewall resides.
– A Web server logs all requests. Log files should be checked regularly for any unusual entries, and anything suspicious should be investigated.
– Users’ and user groups’ access should be restricted to only what they need. Set access levels and permissions accordingly by means of the operating system’s security software. For Unix systems, the Computer Oracle and Password System (COPS) checks for many common misconfigurations. (Network Administrators often create a user group called “www” for trusted users, such as Web authors, and only members of this group have ‘write’ permission for the document root directory and its sub-directories. For maximum security of the server root directory, which contains the system configuration files, the Network Administrator sometimes gives the Web Master a special “www” user status, the only one with ‘write’ permission for it.)
– Keep an eye on what users are doing on the network. Security holes can be created innocently by uninformed users if they install one of the many free Web servers that are readily available.
– Password policy should be sensible and adhered to. Simple passwords, based on birthdays or family names, etc., should be taboo. At the other extreme, the rules should not be so strict that passwords need to be written down in order to remember them. Passwords should be changed regularly, and default passwords should be changed immediately. Default accounts, e.g., “guest log-in”, should be eliminated. Extra care should be taken with privileged accounts, such as for administrators. Confidential documents, sensitive areas and administrative functions should always be password-protected.
– Security updates and patches should be installed immediately. This applies equally to the Operating System as to the Web server software. Automate these processes if possible, but, at least, be on the look-out for security alerts from the software suppliers.
– Any feature, server or interpreter that is not actually used should be uninstalled, or at least disabled. For example, remove the File Transfer Protocol (FTP) server that Web servers usually provide, if you are not going to use it. Likewise, Trivial File Transfer Protocol (tftp), Network Information Services (NIS) clients, systat, finger, Networked File System (NFS), gopher, sendmail, and unneeded scripting languages and example scripts should go. For example, if the Web site does not use CGI scripts written in Perl, remove the Perl interpreter. Such items are just another security risk.
In summary, as can be seen clearly from the foregoing, whatever is not actually needed should be removed or disabled.