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 assword 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 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 sy stem 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 hav 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 ble 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 shoul d be protected according to its value. Protection is not easy, but a reasonable level of security is not documents are listed below. Finally, for JANET customers, remember that the Cert is available to help in preventing incidents as well as curing them 4.3 Website Content design 4.3.1 Domain Names Because most people have trouble remembering the strings of numbers that make up IP ddresses, and because IP addresses sometimes need to change all servers on the Internet also havehuman-readablenamescalleddomainnamesForexamplewww.howstuffworkscomisa permanent, human-readable name. It is easier for most of us to remember www.howstuffworkscomthanitistoremember209116.6966 Thenamewww.howstuffworks.comactuallyhasthreeparts (1) The host name("www") (2)The domain name("howstuffworks") (3)The top-level domain name("com") Domainnameswithinthe".com"domainaremanagedbytheregistrarcalledVerisi VeriSign also manages "net"do Other registrars(like Registry Pro, NeuLevel and Public Interest Registry) manage the other domains(like pro, biz and. org). VeriSign creates theLoss, 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. 4.3 Website Content Design 4.3.1 Domain Names Because most people have trouble remembering the strings of numbers that make up IP addresses, and because IP addresses sometimes need to change, all servers on the Internet also have human-readable names, called domain names. For example, www.howstuffworks.com is a permanent, human-readable name. It is easier for most of us to remember www.howstuffworks.com than it is to remember 209.116.69.66. The name www.howstuffworks.com actually has three parts: (1) The host name ("www") (2) The domain name ("howstuffworks") (3) The top-level domain name ("com") Domain names within the ".com" domain are managed by the registrar called VeriSign. VeriSign also manages ".net" domain names. Other registrars (like RegistryPro, NeuLevel and Public Interest Registry) manage the other domains (like .pro, .biz and .org). VeriSign creates the