Advanced Security: CGI:

Taken from: http://www.closetnoc.org/help/security.html

There are some very sophisticated hackers out there looking for CGI programs with known vulnerabilities or easily accessible data files.

Without explaining PERL or other CGI language, I will give you some pointers to securing your CGI applications.

1. Deploy your CGI applications into directories that are unpredictable. For example, do not use /cgi-bin/ or any other commonly predictable directory. Some applications want you to create a directory that they have specified. Use your own name not theirs. You may have to modify the CGI application.

2. Most CGI applications have an entry point that all users enter the application through. Change the filename. You may have to modify the CGI application.

3. Move all data files to a directory above the web sites directory. Create a directory. Do not use any of the directories that exist. You may have to modify the CGI application.

4. Move any include files and configuration files to a directory above the web sites directory. Create a directory. Do not use any of the directories that exist. You may have to modify the CGI application.

5. Move all admin functions to another directory within the web sites directory. Create a directory. Do not use the directory that the application uses. You may have to modify the CGI application.

6. Use an .htaccess file to secure the CGI application where appropriate. You can use the .htaccess file to secure the application to known users, or just parts of the application such as the admin functions.

7. Secure your directory(s) to limit access to your files. See the section that follows.

Under no circumstances should you install a CGI application that acts as a server to provide services that the server does not already supply. This would be chat, IRC, SMTP, Proxy, or any other type of service. Slpatech and ClosetNoc.com strictly prohibits this activity and will shutdown your site immediately without warning. This may seem draconian but it is not. We are responsible for our own equipment and many other sites and refuse to allow applications that open ports and vulnerabilities that ultimately compromises the system. There are no exceptions to this rule even for ourselves.

Securing Your CGI Directories:

This is very important and can take some experimenting before you get it right. Here you will find a very simple explanation that should be enough to secure your CGI directory.

... add Unix security such as 777, 775, 755, etc. explain quickly.

Example:
-rw-r----- 1 jdoe users 0 Jul 17 16:17 myfile
drwxr-xr-- 2 ssmith users 1024 Jul 12 11:41 mydirectory/

Using this example, the first set of character contains file information.

The first character is the file type - (file), d (directory).

The next nine characters is the file permission broken into three groups of three character. The first set of three characters represents owner permissions, the second, group permissions, and the third is the permissions on non-owners. The character "r" represents read permission, "w" represents write permission, and "x" represents execute permission. The "-" character represents a place holder and holds no significance. Permissions always appear as rwx. In the case where the permissions appear as rw-, the permissions set would be read and write but not execute. Delete permission is based on the write permission. Following our example for the file myfile, the owner has read and write permission and the users group has read permission.

The number that follows the initial 10 characters represents the links to the file. The default is 1. Each file or directory can have more than one name using symbolic links. In our example, the directory has the default link, then name of the file and another name, a symbolic link.

You will next see the file owner and group. Each user belongs to a group. The file owner is the username of the user that created the file or took ownership of the file. The group name is the group of owners that own the file. Generally, the user that owns the file is a member of the group. This does not absolutely have to be the case, however, this is mostly true enough to make an assumption.

You will then see the file size in bytes, then last modified date, and the file name. File names are case sensitive and must be typed exactly as it appears in order to reference the file. Also know that any file beginning with "." is a hidden file and normally can not be seen by users without specifying a switch to show these hidden files.

Explanations regarding setting file permissions can get technical and thus any similar discussion can cause you a coronary or at least to go cross eyed. Fortunately, it is really not that complex. You can use the table below to understand file permissions and set the permissions you want.
Owner Group Other
Read 4 4 4
Write 2 2 2
Execute 1 1 1
Total

Looking at this semi-redundant table, you can simply total the numbers of the permissions that you want. For example, setting read and write permissions for the owner and group and read only for other, would be 664.

Okay. The reason why we go through all of this is because when CGI applications are deployed, you MUST secure the directory, the application and files accordingly. In your FTP client, there are equivalents to the chmod Unix command that sets permissions. Directory and file access do not have to be the same. For example, you may be able to set read permission for the directory while read and execute permission could be set for the CGI application.

I would not realistically be able to cover all scenarios. You will want to follow the install instructions that generally come with CGI applications for setting permissions. Sometimes the permissions are set too permissive. You will want to make access to your applications as tight as possible. Remember that web users are generally "other" users unless there is a corresponding user account.

Your Ad Here

http://improvemysite.blogspot.com