Welcome to Volume 3, Issue 14 of The Internet Security Conference Newsletter, Insight. Insight provides commentaries and educational columns, authored by some of the best minds in the security community.
TISC is about sharing clue. So is the newsletter. We promise to provide something useful each issue. If we don't, flame me. But wait until August 1st, as I'll be on vacation, away from (cellular) telephone, television, Internet, radio, and possibly electricity.
Enjoy, and be safe,
Dave
Don't you just hate when Internet newbies and our Esteemed 4Th Estate say "IP protocol?" The inability to consider the expansion of an acronym in the written word is epidemic, with some rather embarrassing or at least humorous examples.
I recently bought a new laptop with Windows 2000 Professional installed. When it boots, my screen tells me that Windows 2000 is "Built on NT Technology".
Someone should remind Microsoft that the "T" in "NT" stands for Technology?
No matter. I've been receiving comments that Insight talks more about network than application security issues. My good friend and colleague, Rik Farrow, recently wrote a column for WatchGuard's Live Security Service for *NIX heads who run Apache, and WatchGuard has granted TISC permission to redistribute as an Insight feature article.
Happy Reading!
Your Web server presents your company or organization to the rest of the Internet. It also presents the juiciest target imaginable to many attackers, because if it is going to serve up Web pages to the public, your Web server must be partially exposed to attacks. If someone can attack it successfully, you will be embarrassed -- at best.
The Web site www.attrition.org tracks Web site defacements, with mirrored examples numbering in the tens of thousands. Note that over half of the defaced sites were running Windows-based Web servers, more than twice the next nearest category, Web servers running Linux. You might guess that this is because more Web servers run Windows than any version of UNIX -- but you would be wrong. By visiting Netcraft you can see that Windows-based Web servers make up only 21% of all Web servers worldwide. Apache claims the lion's share.
Rather than focusing on reasons why Apache is so popular, let's consider how to make any Web server running Apache more secure. Hopefully, you have already done one of the most important things you can do to secure any Web server: place it on the Optional (DMZ) interface of your firewall. The firewall can be configured to allow nothing but Web traffic to your Web server, shielding it from potential attacks. The firewall also, by default, blocks all network communication initiated from the Web server that tries to reach the internal, or Trusted, network. That default behavior protects your internal network in case something bad happens to your Web server.
Protect the Operating System (OS)
The current version of the Apache Web server is 1.3.19, and can be downloaded from apache.org. Older versions have minor bugs, including a problem in 1.3.17 that can reveal the contents of directories outside of the Web server's document root. By comparison to Microsoft IIS, which has had many serious bugs exposed, Apache security has been, and continues to be, remarkable.
That said, there are things you can do to increase the security of your Web server. When Apache Web servers get exploited, it is usually for two reasons:
Let's look at both of these problems, and consider some countermeasures.
Secure Setup of a Server OS
Although your firewall shields your Web server if you have set it up correctly, proper configuration of the server OS adds another layer of protection, in case something goes wrong with your firewall configuration.
The simplest way to secure an operating system is to install as little of it as possible. Many UNIX operating systems allow you to choose a Custom installation, and if you can do so, only install Core and Network software. You won't need things like X windows, or games, or typesetting software, or even documentation. Ideally, your Web server should be dedicated to being a Web server, and nothing else.
Disable all network services other than httpd, the Web server, and whatever network service you use for remote administration. I use SSH, the secure shell, which you can download for free from OpenSSH. SSH provides you with a strongly encrypted link between your management station and your Web server, and can use certificates for authentication. Another free software tool, rsync, provides fast file transfer, and will work inside of SSH's encryption. (Rsync comes with Linux, and can be downloaded and used with other versions of UNIX.) SSH and rsync will allow you to administrate your server securely.
Linux systems provide an admin interface, as do some other systems like Solaris, that make it easy to disable network services. Once you have done this, reboot your Web server, and use the netstat -an command to see what services are still running. This step allows you to verify that you actually changed what you thought you changed. The -an command will display TCP services that show LISTEN in the last column, or UDP services that have *.* in the Foreign Address column. If you find loads of services listening, see what you can turn off -- remember, the goal is to have this box serving Web pages, and doing little else.
Another way to secure a Web server is to start with a secure version of the UNIX OS. OpenBSD comes with all network services disabled. Engarde Linux and Immunix are both versions of Linux with additional security enabled. Also, use file ownership and permissions so that the Web server user, usually the "nobody" user, cannot write to any Web page or CGI script. Making files owned by root, and readable by all, is a simple way of doing this.
Don't Let CGI Stand for "Can Get In"
The second big weakness in Apache rises from the ability to execute scripts or programs, known as CGI (Common Gateway Interface). Attackers commonly exploit weaknesses in CGI scripts that contain bugs.
CGI scripts are often used to process Web page forms where users input information you want to collect. Any time you open your system to user input, you need to keep your defenses up. Not all users provide the type of input you want or expect. In fact, you might be surprised at how many things on your public Web site are under the control of the remote user when you accept his or her input.
For example, your Web server might display a form requesting an e-mail address. Suppose the remote user responds with:
zen@evil.com;`rm -rf \*`.
Your script expected the e-mail address. But the user has appended extra characters that form a command to delete all files on your Web server. What will your CGI script do with those characters? The manner in which your script is written controls whether that command succeeds or not.
The most popular CGI script programming language is Perl, and Perl makes it easy to do the right thing. The "right thing," in this case, is not to trust character strings the script gets from the user, but to filter them. Don't try to filter out everything harmful -- people have tried that and gotten hurt. It is much safer to allow only the input you expect, than to attempt to filter out everything that is dangerous.
For example, if the script expects an e-mail address, the response should contain something like "user@some.where.com." Your script can test for permitted characters in a well-formed e-mail address with:
$email =~ /^[\w.-]+\@[\w.-]+$/ || die "Illegal characters in address!";
The beginning of this string means, essentially, "e-mail addresses must match the following." The \w pattern represents any letter or numeral; the . and - allow for periods and hyphens in names. The ^[\w.-]+\@ means accept any set of permitted characters starting at the beginning of the line and ending with the @ sign. The same characters are permitted after the @ sign. The $ means "when you finish this match, you should be at the end of the line." That prevents an attacker from using commands or meta-characters at the end of an e-mail address.
Another safety tip while scripting: if you've chosen to hide your variables (for example, an e-commerce site might hide product identifiers or prices), don't count on that as a security measure. While you can set variables in HTML forms to the "hidden" attribute, the remote user can still manipulate them even though they are not displayed within the Web browser. The remote user could save the form as a text file, which unmasks the variables. The user can edit the file to change the values of the "hidden" variables, and then bring the modified form up in a browser window and submit it.
Environment variables are another area of potential vulnerability. "Environment variables" include values that Apache extracts from a browser request, and passes to your script. Some environment variables come to your script from the remote user; for example, HTTP_USER_AGENT indicates what browser the person is using; and HTTP_REFERER shows what link the user clicked on to link to your page. Here's an example of values Apache would extract from a browser request if you clicked a link from WatchGuard's Web site to mine:
GET /Network/net1099.txt HTTP/1.0
Connection: Keep-Alive
User-Agent: Mozilla/4.75 [en] (X11; U; BSD/OS 4.2 i386)
Host: www.spirit.com
Referer:
http://www.watchguard.com/lsac/may01/apache.html
Accept: image/gif, image/x-xbitmap, image/jpeg,image/pjpeg, image/png, */*
Accept-Encoding: gzip
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8
Browser requests are actually just formatted text, so these variables can easily be faked in HTML. These are really under the control of a remote attacker, so your script should not blindly accept them as always valid. Place appropriate filters in your script.
To Learn More
These tips just scratch the surface of the topic, so I'll end by listing more resources:
Here's wishing you secure serving!