Introduction

Tutorial roadmap

Properly securing a Web server entails walking a fine line between accessibility and system security. A Web server, by its very nature, needs to be accessible to the "outside world." But the Internet can be a rough and tumble place. Viruses are rampant; hackers are constantly looking for ways to break into systems and use them for their own means; and "script kiddies" find amusement in defacing prominent Web sites. So system administrators must balance accessibility with system security.

This tutorial addresses this balancing act by examining the following three topic areas:

• Web server security: Understanding the httpd.conf file and its access directives.
• Authentication options: Using basic and digest authentication to control user access.
• Jailing your users: How to create a chroot environment for your Web server.

Upon completion of this tutorial you will understand both the whys of Web server security and the how-tos of tightening and/or closing potential security holes.

Back to top

Tutorial background

Examples and code listings used throughout this tutorial are based on the latest stable release of the 1.3.x series Apache Web server (which at the time of this writing is 1.3.26). All material discussed is also directly applicable to IBM WebSphere, as it is a derivative of the Apache codebase and employs the same program structure and configuration files. File locations may differ according to how your Web server was compiled, what modules were included in the configuration, etc.

In addition, this tutorial is based on a default "Server" installation of Red Hat 7.3. Again, file locations and initialization techniques may differ across distributions, but the underlying principles discussed apply to all *NIX-based systems running a Web server.

The material presented assumes you have a basic understanding of *NIX administration including user and group UIDs, user file permissions, program installation and maintenance, and editing configuration files. If you want to follow along with the examples provided, you'll need access to a system with an existing Apache installation or a system with enough disk space to install Apache on.

This tutorial also assumes you have secured your production system adequately, meaning, it's behind a well-configured firewall, system user permissions are in order, your Web server of choice is installed correctly, and filesystem permissions -- as a whole -- are in order. The Further resources section at the end of this tutorial lists several books on the topic of general system security.

One important issue this tutorial does not address due to space constraints is the topic of securing dynamic content (Common Gateway Interface, or CGI content, embedded scripting languages such as PHP, wrappers such as suEXEC, etc.). All Web server administrators need to be aware of the dangers inherent in all dynamic content, and the methods available to prevent their misuse. A good resource to check out is www.cgisecurity.com.

Questions, comments, and errata submissions are welcome; you can either e-mail the author directly (dwcomments@syroidmanor.com ) or use the rating form at the end of the tutorial.

Back to top

General security considerations

The following points are general security issues and considerations all system administrators should be aware of, especially on "front-line" production machines like a publicly accessible Web server:

• Log files are an administrator's best friend. Make a habit of scanning them for system or user irregularities on a routine basis. Ideally, log files should be sent to a separate system devoted to this one purpose. Doing so ensures that no one but an authorized administrator can view or tamper with these important files.
  
  
• Backups are a crucial component of any comprehensive security strategy. Make sure you have current system backups for all key systems on your network and that the backups can be restored without error.
  
  
• As noted in the previous section, Tutorial background, security begins at the physical level and moves outward in ever-increasing circles. Production servers should be physically secured in a locked room, and stringent password policies enforced. Non-essential services on the server should be turned off, and properly-configured network access control lists (ACLs) should be in place.
  
  
• Apache, by default, runs all child processes as user nobody (the main process controlling the child processes is under root control). All system services accessible to the public should ideally be run under a unique user ID to enforce complete separation between services. For example, Apache's webuser and webgroup directives (found in the httpd.conf configuration file) should be set to a unique user/group such as www/www.
  
  
• Finally, administrators should routinely scour their systems for files that are unnecessarily setuid and/or setgid. ( find / -type f -a \( -perm -4000 -o -perm -2000 \) -print ).

1 of 7 | Next

Comments

Back to top

Table of contents

• Introduction
• Securing Apache's default configuration
• User authentication
• Jailing your Web users
• Summary and further resources
• Resources
• About the author

---

1 of 7 | Next

Next steps from IBM

WebSphere Portal can help your small and midsize business achieve better website security, along with faster time to value with easily deployable and customizable example Web sites.

---

• Try: Download a free trial version of IBM WebSphere Portal Express V6.1, which offers collaboration, document management, and secure Web content management.
• Article: This article provides an overview of the WebSphere Portal security architecture, including internet security, and secure connections between clients.
• Tutorial: This tutorial take you through the steps to develop and test your first portlet WebSphere Portal Test Environment.
• Demo: These demos show Web 2.0 features available today within WebSphere Portal, as well as several features planned for the future.
• Buy: IBM WebSphere Portal Express

Dig deeper into Tivoli on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.