You build your Web server, installing all the latest patches and using available guidelines to lock down the system. But is your Web server really secure? To find out, regularly inspect your Web applications for potential vulnerabilities.
One way intruders might penetrate your defenses is through Web application misconfiguration. Another way is through Web application vulnerabilities. I'll discuss how you can prevent some vulnerabilities from the start and how you can use several free tools to collect vulnerability information about your Web site.
Guidelines for Web App Installation and Configuration
Anytime you obtain a software package—whether it's a component, application, or underlying subsystem—following some simple guidelines can make your job much easier over time. Begin by scouring the provider's Web site for all the information you can find about installation and configuration. Read the configuration information especially closely because configuration oversights often create vulnerabilities. Keep in mind that configuration settings and associated potential exploits for many components vary by Web server platform (e.g., Microsoft IIS, Apache).
In addition, search the Internet for relevant security information. For example, many people use PHP as an underlying script engine for Web application development. But not all PHP users are aware of the Hardened PHP Project (http://www.hardened-php.net), which provides a set of patches for PHP that makes the engine far more secure. The Internet offers many similar security information gems. To find hardening information for a product, use search phrases that include the product name with the words hardening, hardened, and secure.
You should also inspect your Web server and Web site directory mappings and look at what the directories contain. You might have installed software packages or components not yet in use on your Web site but which someone could access by entering the right URL. You might want to perform a back-end audit to ensure the security of your directories, which can provide privileged access to the entire file system and registry. (The tools I discuss in this article might discover such packages or components, but performing a direct inventory and audit ensures that nothing is overlooked.)
Scan Your Web Server
You should scan your Web server and its applications regularly. The interval between scans will depend on your server and its use, but I recommend that you perform a scan at least quarterly.
To perform the scan, you can use tools that probe your Web server and applications directly, including NT OBJECTives' NTOinsight and NTOweb (http://www.ntobjectives.com/freeware) and screamingCobra (http://samy.pl/scobra). You can also use search engines to discover potential problem areas. Tools that use search engines to discover Web site vulnerabilities include Massive Enumeration Tool (MET—http://www.gnucitizen.org) and Foundstone's SiteDigger (http://foundstone.com/resources/ s3i_tools.htm).
One reason to use search engines regularly for security scanning is that they index the linked content on your Web site. Some search engines, such as Google, also maintain a history and cache of your Web pages, which can be valuable. For example, you might have a script in use today that you unlink from your Web pages tomorrow. Search engines can reveal whether you deleted both the script and its directory path. (Note: Keep in mind that it takes some time for a search engine's spider to find your Web site and index its content. So if you're launching a new site, you can expedite that process by submitting your URL directly to search engines. You can find a link for submission on each search engine's site.)
Search engines are also a good way to locate vulnerabilities because they can look for URLs that vulnerable applications are known to use. For example, search engines can look at the URL suffix (the part of the URL that follows the Fully Qualified Domain Name—FQDN) to find sites with exposed administration screens. Intruders routinely use search engines to find such information; you should use them to discover in advance what intruders might find on your Web server and address any potential problems.
SensePost's Wikto (http://www.sensepost.com/research/wikto) is a third kind of tool—a hybrid that performs both direct and search engine scans.
All of these tools are valuable, but keep in mind that their effectiveness varies depending on your particular OS, Web server platform, and associated software packages and components. In general, however, you can probably use any of these tools to scan your platform because so many current Web applications are written in scripting languages (e.g., Perl, PHP, VBScript) that can run on nearly any Web platform in use today. That said, let's look at these different kinds of tools.
Direct Scanning
NT OBJECTives, a company that has long provided excellent security tools to the Internet community, offers the free tools NTOinsight and NTOweb. NTOinsight is a Web server analyzer capable of crawling any number of servers to identify all linked resources. NTOweb is a plug-in for NTOinsight that works in conjunction with the Nikto database, which is a publicly available database of more than 3000 URL suffixes known to be associated with vulnerable applications. Together, these two tools provide an intense audit of your Web servers, whether the servers are based on Microsoft IIS, Apache, or another platform.
NTOinsight and NTOweb are relatively simple-to-use command-line tools. After you install them, run NTOweb first without any command-line options to download the latest Nikto database. You're then ready to use NTOinsight.
NTOinsight provides a long list of possible command-line options, including the ability to scan multiple servers, to use NT LAN Manager (NTLM) authentication, to scan proxy servers, to define maximum page requests as well as the intervals between page requests, and to examine domain and server traversal behavior. The command below is a reasonable one to use for your first test of the tool. The -h parameter specifies the host to scan; -sn is the name of the scan and of the directory for the resulting report; -ntoweb tells NTOinsight to perform checks against the Nikto database by using the NTOweb plug-in; and -delay is the delay between requests (in milliseconds).
ntoinsight -h www.myhost.nul
-sn myhost -ntoweb -delay 1000
The scan process for NTOinsight (as well as for all the tools I discuss in this article) can take from a few minutes to several hours (to a day or more!) depending on how many Web pages your scanned servers contain. You can monitor progress as the scan takes place, as Figure 1 shows.
After the scan is finished, you can view a graphical report. By default, reports are stored in the \Reports\In sight\date\ directory, where date is the date of the scan. From the main report, you can link to more-detailed reports about discovered resources and potential vulnerabilities.
Prev. page
[1]
2
3
next page 
