NATkit 2.0 Security

NATkit 2.0 provides two levels of security:

Server security that is partially implemented by the server components of NATkit 2.0 and by the system administrator.
Application security implemented by the client and server components of the NATkit 2.0 applications

This appendix describes both of these security levels.

Server Security

There are two aspects of NATkit 2.0 server security:

Security imposed by the server components
Security imposed by the system administrator

NATkit 2.0 uses the security mechanisms of the UNIX system to protect the code and data files that reside on the server.

Server-Imposed Security

The NATkit 2.0 server provides the following security mechanisms:

Files, File Ownership, and Permissions---NATkit 2.0 must be installed by a user with root privilege and is installed as the user bin. All files and directories are owned by bin with group also equal to bin. Temporary files are created as the user bin with permissions set to read-write for the user bin and read for members of group bin. The only exception to this rule is the log files created by the NATkit 2.0 web server. The NATkit 2.0 web server must be started as root; therefore, its log files are owned by the user root with group equal to other.

: All back-end processes are executed with a umask value of 027, which means that all files created by these programs are created with permissions equal to rwxr-x, with an owner and group of the user ID and group of the program that created it. Typically this will be bin and bin.

Runtime ---Typically NATkit 2.0 backends are executed with permissions set to the user id of the binary file (for example, if an executable file is owned by user "Joe," it will be executed by the NATkit 2.0 daemon manager under the user ID of "Joe"). The exception is the root user ID. To prevent a potentially harmful program from being executed by the Daemon Manager with root permissions, the Daemon Manager will execute only a limited set of NATkit 2.0 programs that need root privilege. This list is not documented to preclude any user from trying to impersonate these programs.

: NATkit 2.0 foreground processes (typically cgi-bin programs written in perl or TCL) are executed under the control of the web server's children processes, which all run as the user bin.

Off -machine connectivity---The NATkit 2.0 Daemon Manager will not respond to requests to start, stop, register, or show status for NATkit 2.0 back-end processes from computers other than the NATkit 2.0 server.

Because the UNIX user bin is not a user id that is typically enabled for login, the UNIX system administrator can more easily protect the NATkit 2.0 data and program files. The telnet ID for NATkit 2.0 is "nsalogin". The user must login as "nsalogin", and SU to "root", then to "bin" before manipulating files in NATkit. In other words, the user must know both the "nsalogin" password and "root" password to gain control of the NATkit 2.0 files remotely.

System Administrator-Imposed Security

To maximize NATkit 2.0 server security, follow these system administration guidelines:

Do not allow users who are not responsible for managing the NATkit workstation to have the passwords for "nsalogin" or "root".
Remote access (i.e. FTP, RCP, RSH) to the NATkit server is limited during configuration. Do not add access without consulting with NATkit support (natkit-support@cisco.com) about the change. These limits are an important part of NATkit's security package.

NATkit 2.0 provides application-level security that allows the NATkit 2.0 administrator to dictate which applications a NATkit 2.0 user can access. NATkit 2.0 provides this security through a set of five built-in roles:

Help Desk
Approver
Network Operations
Network Administration
System Administration

When you create a NATkit login (every NATkit 2.0 user must log in to the application to use its features), you assign one or more roles to the login. The role or combination of roles dictates which NATkit 2.0 applications are available to the user in the NATkit 2.0 navigation tree (refer to the "Setting Up NATkit 2.0" chapter for an explanation of the navigation tree).

Only the system administrator user can assign roles to NATkit logins. NATkit 2.0 users can use the administrative tools to change their own password or other aspects of their login.

NATkit 2.0 comes with two predefined logins:

guest (no password required, user role = Help Desk)
admin (password = admin, user role = super user)

Note The login named admin is the equivalent of the superuser login for NATkit 2.0. This login provides access to all NATkit 2.0 tasks.

To prevent anyone from typing a full path to a NATkit 2.0 URL in attempt to avoid the security system, NATkit 2.0 applications will run only in the presence of an authenticated session between the server and client. The session is authenticated as a part of the login process so attempting to avoid the login by entering a URL will fail and the user will be returned to the NATkit 2.0 Login Manager dialog box. The NATkit 2.0 desktop terminates a login session after a period of no use. After termination, attempting to perform any operation returns the user to the Login Manager dialog box.

Table of Contents