Security FAQs

Sambar Server Documentation

Security FAQs

What security holes should be plugged prior to putting up the demo server ?

The Sambar Server ships with the following security breaches:

security.ini Make sure the proxy accept/deny and directory security are tailored to your needs.
users Delete the sample users (anonymous and guest).
admin user Put a password on the admin user account. It is VERY important that you change your password before putting the server on a public network.
search.dll Users can use the search.dll to list all files within the Sambar Server document directory. Decide if the search functionality is desired for the server.

Is is "safe" to use FTP on the internet ?

FTP passwords are transmitted in the clear, so anyone monitoring the segment on which your server is running can discover the username and passwords used by the FTP server. For machines on the Internet, it is probably best to allow only anonymous FTP, or to permit read-only access to the FTP services of the Sambar Server; alternatively, you could set the Sambar Server FTP security policy (see security.ini) to only allow access from your private network.

Why can I re-enter the System Administration pages after leaving by using the back key ?

The Sambar Server uses two mechanisms for securing the System Administration pages and functions. The first is a valid login using the /session/adminlogin RPC command. Once entered, browsers cache this login information, so subsequent attempts to enter the System Administration forms will likely not require the user to input their name and password. The only effective way to clear the Administrator username and password is to shutdown the browser.

In addition to the username/password authentication, the server sets an encrypted cookie identifying the user as an administrator. This cookie is maintained until the user either explicitly logs out (using the Logout link on the administration page), or shuts down the browser.

Why can't I reference documents outside the document directory ?

For security reasons, only documents within the documents directory can be referenced by users of the Sambar Server, unless document aliases are used. With document aliases, you redirect requests to documents outside the document directory.

What are the basic steps to securing my Sambar Server on Windows NT ?

There are some obvious openings in Windows NT that should be closed before putting your server on the internet.

Disable the Guest account.
Enable Monitor Invalid Logins.
Rename the Administrator account (change in the config.ini and via User Management).
Set "good" passwords on all accounts, mixing numbers and characters.
Allow administrative access by local log-on only.
Remove the Everyone group from directories.
Allow the Sambar Server Administrator to access the server from the local machine only (this is the default configuration).
Remove all unused/unnecessary CGIs, especially: dumpenv.pl & upload.pl
It is especially important that upload.pl and "CGI Extensions" not both be configured.
Remove the entries for the config.ini parameters: ISAPI Extensions, Server Side Includes, CGI Extensions and WinCGI Extensions
These entries allow applications in the documents directory to be executed. If you allow users to upload files to the documents directory, all entries for these should be removed.

For a more comprehensive list of NT Security safeguards, see the NT Security documentation.

How can I secure the Sambar Server against external hacking ?

Most hacks to WWW sites result from unauthorized users gaining access to your machine via telnet, ftp, sendmail or some other utility that allows them to upload data. The Sambar Server supports two features that are succeptible: HTTP PUT and FTP. You can eliminate the possiblity of either of these features being exploited by:

Monitor Invalid Logins

Act as FTP Server = false

After these two steps, you will have to manually copy any new files you need up to your server.

The last security step to consider, is to secure the admin account so that someone can't re-open one of the above security holes and restart the server. You can provide "modest" security by setting a good password and having no other users configured -- definitely remove the "anonymous" user. The second, more secure mechanism is to remove users from the system altogether (simply remove the passwd file -- or rename it); you will need to manually edit the config.ini file for all modifications to the server -- or put the passwd file back in place prior to logging in as admin.

Important! These steps will help reduce the threat of system attacks but will not eliminate all vulnerabilities. Additional recommendations are welcome.

Is the Sambar Server secure from mis-behaved CGIs ?

There are no security mechanisms in place to prevent a mis-behaved CGI from performing unwanted activities. You should excersize caution before deploying any CGI script on the server.

In particular, no DOS batch scripts (*.bat) should every be deployed on Windows systems.

How do I require a username/password to access a directory ?

You can restrict access to a file or directory to authenticated clients by adding a restrict rule via the Security configuration. When you use authentication, no access is permitted unless a valid username and password are supplied.

Note: The Sambar Server only supports basic authentication. Basic authentication does not encrypt transmissions between the client and server; Intruders could use protocol analyzers to read the usernames and passwords.

Why can't I put the tilde (~) character in URL names ?

The valid characters associated with URL names is restricted by the Valid Characters configuration parameter in the config/config.ini file. By default, the tilde (~) character is on the list of restricted characters because of the CERT Advisory CA-98.04 (overview below). Many thanks to Boyd Johnson for bringing this to my attention.

When Win32 stores a file with a short name (i.e., 8.3-compliant), it
associates only that short file name with the file. However, when Win32
stores a file with a long name (i.e., greater than 8 characters), it
associates two versions of the file name with the file--the original, long
file name and an 8.3-compliant short file name that is derived from
the long name in a predictable manner.

Example:

   The 8.3-compliant short file name "Abcdefgh.xyz" is represented
                  (1) as is: "Abcdefgh.xyz".

   However, the long file name "Abcdefghijk.xyz" is represented:
                  (1) as is: "Abcdefghijk.xyz" and
                  (2) as 8.3-compliant: "Abcdef~1.xyz".

Some Win32-based web servers have not compensated for the two file name    
versions when restricting access to files that have long names. The web
servers attempt to restrict access by building an internal list of
restricted file names. However, for files with long names, only the
long, and not the short, file name is added to this internal list. This
leaves the file unprotected by the web server because the file is still
accessible via the short file name.

Why can I run executables outside the cgi-bin/cgi-win directories ?

Perl scripts that aren't in the cgi-bin directory, but that are in a directory off of docs are automatically executed by the server. For administrators who do not have complete control over the files on the server, this poses a security risk.

The functionality that enables this execution are the following configuration entries:

Server Side Includes = shtml
ISAPI Extensions = *.dll
CGI Extensions = *.pl *.cgi *.bat
WinCGI Extensions =

The above configuration entries are used by the server to determine what files "outside" the cgi-bin, cgi-win directories should be treated as executables. You should remove the values in these entries if you wish to remove the ability to run CGI scripts from any directory.

Has anyone evaluated the Sambar Server for security issues ?

I received mail from Howard Kirk at Data Protect in August, 1999. Howard performed an evaluation of the 4.2 beta 9 release and found several security problems. I have attempted to close the holes that were discovered, however, the following security issues remain:

Several CGIs and scripts (/cgi-bin/environ.pl, /samples/cgi.stm, /cgi-win/cgitest.exe and /samples/inline2.stm) show absolute path information for hard drive structure still persist. You should remove these scripts before putting the server into a production environment.
The perl script /cgi-bin/mailit.pl is vulnerable to intruders. I have modified the script to only be accessible to "localhost". I recommend consulting a security expert before deploying it on the internet.
The /cgi-win/pbcgi.exe executable can be used to launch a denial of service type attack or even crash a machine. It requires a tremendous amount of CPU to run, and should be removed from production machines.
The feedback.htm sample was modified in the 4.3 release so it could no longer be used for sending anonymous e-mail. The sendmail RPC only allows execution from within a script page; script-only execution limits the ability of spammers to utilize the server as a mail relay. However, unless needed, this RPC should be disabled. To disable this functionality, remove the following line from your config/config.ini file:

INIT = samples.dll:sendmail_init

I am very appreciative to the folks at Data Protect for providing their review.