Course protect your Web server against common attacks, tutoriel & technique en pdf.
1. Isolate the Web server from public networks and your organization’s internal networks.
2. Configure the Web server with appropriate object, device, and file access controls.
3. Identify and enable Web-server-specific logging mechanisms.
4. Consider security implications before selecting programs, scripts, and plug-ins for your Web server.
5. Configure the Web server to minimize the functionality of programs, scripts, and plug-ins.
6. Configure the Web server to use authentication and encryption technologies, where required.
7. Maintain the authoritative copy of your Web site content on a secure host.
8. Protect your Web server against common attacks.
Isolate the Web server from public networks and your organization’s internal networks
You have several choices for placing a public Web server on your organization’s network.
We recommend that you place it on a separate, protected subnetwork. This will ensure that traffic between the Internet and the server does not traverse any part of your private internal network and that no internal network traffic is visible to the server.
Why this is important
A public Web server host is a computer intended for public access. This means that there will be many people who will access the host (and its stored information) from locations all over the world. Regardless of how well the host computer and its application software are configured, there is always the chance that someone will discover a new vulnerability, exploit it, and gain unauthorized access to the Web server host (e.g., via a user account or a privileged account on a host with a multiuser operating system). If that occurs, you need to prevent these subsequent events, if possible:
• The intruder is able to observe or capture network traffic that is flowing between internal hosts. Such traffic might include authentication information, proprietary business information, personnel data, and many other kinds of sensitive data.
• The intruder is able to get to internal hosts, or to obtain detailed information about them.
Policy considerations
Your organization’s networked systems security policy should require that
• your public servers be placed on subnets that are separate from public networks and from your internal network
• servers providing supporting services for your public servers be placed on subnets separate from public networks, from your public servers, and from your internal networks
Other information
Alternative public Web server architecture approaches may mitigate the security risks mentioned above, but these approaches generate other issues that you need to address.
1. You may choose to place the Web server on an internal network and then use smart hubs or switches to separate it from internal network traffic. You could also choose to encrypt all internal traffic, so that even if the server is compromised, any traffic it sees will not be readable. However, neither of these approaches would prevent traffic from being sent from the Web server host to other hosts on your internal network.
2. You may choose to have your public Web server hosted by an external organization (such as an ISP) to accomplish the separation of your public Web site from your internal network, and to take advantage of external expertise. If you take this approach, require that your ISP establish a protected subnet for your Web server and any other services (e.g. email, directory, or database) if these are also provided.
Where to find updates
The latest version of this practice, plus implementation details for selected technologies, is available on the Web at URL: http://www.cert.org/security-improvement/practices/p075.html
……..
Si le lien ne fonctionne pas correctement, veuillez nous contacter (mentionner le lien dans votre message)Protect your Web server (Securing public Web servers) (930 KO) (Cours PDF)
