•
remote logon
•
secure shell SSH
•
security domain
•
share
•
shell
•
single signon
•
smart cards
•
spam
•
TCP Wrappers
•
terminal
•
ticket
•
Ticket Granting Ticket TGT
•
user context
•
yellow pages yp
Chapter 13: Web Server Security
Overview
This chapter discusses the best practices used to keep web servers secure when they are publicly available. Web and e-mail servers are the two most difficult security problems you
will encounter, because in most cases they must be open to the public in order to fulfill their purpose.
With the exception of exploits based on specific bugs, most web server security problems are generic in nature. Most of this chapter deals with practical security measures for any web
server. Because 90 percent of the Internet is run on Apache and IIS, those two web servers are covered specifically.
You’ve probably heard about security problems with cookies, ActiveX controls, Java applets, and multimedia plug-ins like Real Player. These technologies are problematic, but they only
affect the client side—they are not a problem for servers that inspect them or provide them. Serving ActiveX or Java applets is not a security problem for servers, and can frequently be
used to provide enhanced server-side security by creating a proprietary interface to your web application that would be far more difficult to hack than a typical HTTP-based interface, if
you can entice users to actually download your controls. This chapter doesn’t discuss the security ramifications of web browsing—that problem is well covered in the rest of this book.
Web Security Problems
Bugs in the web server application are the most threatening security problem you will run into when securing web servers. Flaws in the operating system and web server applications are
routinely exploited by hackers, and no matter how well you’ve secured your server, there’s very little you can do to prevent these sorts of attacks. In closed-source operating systems,
only vendors can repair their code, and the level of support varies widely. Microsoft has been very proactive about patching their web server, Internet Information Server IIS; in fact, a
constant torrent of patches flows from them on almost a weekly basis. Novell, on the other
hand, has allowed known flaws in their web server to go for many months without being patched.
In open-source operating systems, theoretically anyone can fix the flaw, but only the writers of the code are familiar enough with it to actually fix the problem in a short period of time.
For this reason, you have to stick with open source solutions that are being actively maintained and developed by its community. Many older or less popular open-source
solutions languish in near-abandonment, and security flaws in them may take a long time to be repaired.
Note Washington University’s wu-ftp daemon, the most popular FTP daemon, contained a flaw that went six months between exposure and repair, because the University did not
have an active development effort for the software. This flaw was widely exploited. In contrast, the longest IIS has gone between the exposure of a serious flaw and the release
of a patch is three weeks.
Administrative and author access to the server is the next major web security problem. If your web server is outside your network and you’ve included some file transfer service to allow the
website to be updated, hackers can attempt to exploit that service to gain access to the server.
Finally, poorly secured web servers will be exploited. Fortunately, securing a web server is relatively easy to do. This chapter will cover the basics and provide direction to more
information.
Implementing Web Server Security
