LinkScan for Windows. Reference Manual.

Section 27

LinkScan and Various Web Servers

This section discusses the use of LinkScan in conjunction with various web servers and the associated security implications:

1. Web Server Requirements
2. LinkScan and IIS/PWS
3. LinkScan Access Controls
4. LinkScan Security Considerations

27.1 Web Server Requirements

When LinkScan is used to scan a website, the results are stored in the LinkScan database. Reports are created by executing queries against that database with several CGI programs that are supplied with LinkScan.

Hence, LinkScan will normally require that web server software be installed, configured and running on the installation computer. Note that LinkScan doesn't require access to a local web server in order to scan a web site. But a local web server is usually required to view the results of that scan.

On Windows Systems the LinkScan WebServer is installed automatically. This small web server is highly effective and requires almost no configuration. By default it runs on http://localhost:83/ to avoid conflicting with any other web server using Port #80.

The remainder of this section describes the use of LinkScan with various web servers and discusses the associated security considerations.

27.2 LinkScan and IIS/PWS

When using LinkScan with the Microsoft IIS or PWS web servers, two sets of considerations must be addressed:

IIS/PWS Requirements

IIS/PWS normally requires that several conditions be satisfied before it will execute the LinkScan CGI programs -- or any other CGI program, for that matter:

1. The CGI programs must be installed in a folder that is configured to permit CGI executions.
2. You will need to associate the .cgi file extension with Perl on your computer.

To associate the .cgi file extensions with Perl:

1. Open the Internet Service Manager.
2. From the tree display on the left, select the level at which to apply the mappings. You can choose an entire server, web site, or a given virtual directory. Select Properties from the Action menu.
   • If you chose to administer the properties for the entire server, the Server Properties dialog will appear. Select WWW Service from the Master Properties pull-down menu and click the Edit button under Master Properties. This opens WWW Service Master Properties. Select the Home Directory tab and proceed to step 3.
   • If you chose to administer the properties for an entire web site, the Web Site Properties sheet appears. Select the Home Directory tab and proceed to step 3.
   • If you chose to administer the properties for a virtual directory, the Virtual Directory Properties sheet appears. Select the Virtual Directory tab and proceed to step 3.
3. Click the Configuration button. This opens the Application Configuration dialog.
4. Select the App Mappings tab and click the Add button. This opens the Add/Edit Application Extension Mapping dialog.
5. Enter the full path to Perl.exe followed by %s %s. In the Extension field, type .cgi.
6. Save/Apply the changes and close the Internet Service Manager.

Unless all of the above are satisfied, IIS/PWS will refuse to execute the CGI program and you will likely receive a 500 Server Error or 403 Forbidden response.

LinkScan Requirements

LinkScan imposes certain additional (minimal) requirements:

1. In the linkscan.sys configuration file, the Cgibinurl setting must be configured to point at the folder into which the LinkScan CGI programs have been installed. This is required in order that the LinkScan CGI programs can link to each other. For example: Cgibinurl = http://www.example.com/cgi-bin/
2. In the linkscan.sys configuration file, the Docsurl setting must be configured to point at a folder containing the LinkScan documentation and associated images. For example: Docsurl = http://www.example.com/linkscan/docs/
3. An additional requirement is imposed if (and only if) the LinkScan CGI programs are installed in a folder other than the main LinkScan folder (for example, if you moved them to a cgi-bin folder). In this case, the LinkScan CGI's will need to know where to find the rest of the LinkScan configuration files and databases. LinkScan will look for the file .linkscan This file needs to contain a single line entry with the full pathname to the main LinkScan folder. For example:
   
   C:/linkscan/

   Be sure to include the leading and trailing forward-slash characters.

   However, the fun part is figuring out in which folder to place the .linkscan file. The LinkScan CGI programs will look in the current folder. But sadly, different versions and installations of IIS will launch CGI's with different starting folders. The chances are the .linkscan file will need to be in the IIS root folder. However, you may need try placing it in the same folder as the CGI's or the parent folder of the CGI folder.

4. Finally, you will want to disable the LinkScan WebServer that is installed by default on Windows systems and activate an IIS fix associated with cookies and redirections. Simply start LinkScan and click Configure. Then:

   • Uncheck the option Use LinkScan WebServer
   • Check the option Apply Microsoft IIS Fixes
   • Click OK to save

27.4 LinkScan Access Controls

LinkScan includes some basic Access Controls that may be configured using the Access command in the configuration file linkscan.sys in the LinkScan directory. These access controls apply to CGI access only. It is assumed that standard operating system features will be used to control access by shell (command line) users.

Access username : password : project-list : owner-list : menu-options

• username: The username by which a user may access the LinkScan CGI scripts to create reports
• password: The password associated with username
• project-list: A comma delimited list of configured Projects that this user is allowed to access
• owner-list: A comma delimited list of configured Owners that this user is allowed to access
• menu-options: A string of characters defining which of the available LinkScan functions are available to username. Valid characters are:

  x = Project Summary Report
  e = Problem Documents Report
  s = Document Detail Report
  k = Critical Errors Report
  d = Detailed Errors Report
  b = Changed Documents Report
  u = Search Documents Report
  v = Search Links Report
  m = SiteMap Report
  y = Summary of All Projects
  c = Selected Status Codes Report
  a = All Pages Linking To ... Report
  o = Orphaned Files Report
  h = External History Report
  r = Redirections Report
  p = System Configuration Report
  q = LinkScan/QuickCheck
  t = LinkScan/TapMap
  

An asterisk character may be used as a wildcard for any or all of the above parameters.

Indeed, a default LinkScan installation will create the following entry in linkscan.sys file providing unrestricted access:

Access = * : * : * : * : *

Facilities are also provided to integrate with HTTP Authentication Schemes. LinkScan will check for the Environment Variable specified by the Httpauth parameter in linkscan.sys (normally REMOTE_USER). If this variable is present, it will be used to set the current Username. LinkScan will assume that the user has already authenticated with the HTTP server and it will not check the password field in linkscan.sys.

Example: In the following example, we have configured two users with different passwords. User 'admin' has unrestricted access, but user 'webmaster' may only access the two Projects specified. Also the "Site History" and "System Configuration" Reports are not available to 'webmaster'.

Access = admin : root : * : * : *
Access = webmaster : html : www.example.com,devel.example.com : * : sxdcmoaqt

27.5 LinkScan Security Considerations

LinkScan incorporates some simple access controls on the various Reporting options and selections when run as CGI scripts. No LinkScan-specific access controls are applied when accessing LinkScan via a shell (command line) interface; it is assumed that normal operating system access controls apply. The LinkScan access controls are subject to the many and varied limitations inherent within the CGI protocol (see the WWW CGI Security FAQ and other sources for further discussion). In summary, if your HTTP server can access any specific file, then, any user with HTTP access to your server may be able to access that file. The LinkScan security features are provided as a convenience but they are no substitute for other more robust system-level security controls such as:

• Firewalls
• Appropriate access controls to the shell (command line) interface
• Appropriate File System access controls, User Id's, Group ID's, Directory and File permissions etc.
• Appropriate HTTP Server and CGI Access Controls
• Secure HTTP and shell access Authentication schemes

We highly recommend that you configure HTTP Authentication of the LinkScan directory. Other measures you may wish to consider include:

• Ensure that the LinkScan directory permissions are configured so that public browsers cannot obtain directory listings.
• Do not create hyperlinks to the LinkScan files from your other documents.
• Exclude the LinkScan directory from your httpd log file and/or published access statistics
• Exclude the LinkScan directory from any local search engine indexing schemes such as Excite, GLIMPSE, SWISH, WWWWAIS.
• Configure a Robot Exclusion file to prevent public Search Engines from indexing the LinkScan directory.

LinkScan for Windows. Reference Manual. Section 27. LinkScan and Various Web Servers
LinkScan Version 12.3
© Copyright 1997-2012 Electronic Software Publishing Corporation (Elsop)
LinkScan™ and Elsop™ are Trademarks of Electronic Software Publishing Corporation