The 7318 provides three variations of password protection. The first is a simple password-protection system based on user names similar to that found on most UNIX systems. It is relatively easy to administer and is entirely self-contained on the 7318.
The second variation is a remote user/password system where the password database is located in a central location to service a collection of 7318 units on the network. This allows users to login to any of the 7318 servers and use the same password. This simplifies system administration as well, since there is only one place the system administration activities need to be performed.
The third variation is based on the Kerberos security system. This system is more complicated to administer but supports encrypted rlogin sessions for secure communications with a host. The encrypted rlogin version of the Model S20 software is not available in all countries.
These three variations are all enabled and disabled in the configuration file. All three variations are mutually exclusive.
To use the basic and remote password systems, users and system administrators need to perform certain tasks. These tasks are documented in the following sections.
When local password protection is enabled, the command shell requests the user's login ID and password before it accepts any other commands.
The administrator must have enabled password protection in the configuration file and added user names to the system.
login:Type the user name that you have been assigned by the system administrator and press Enter.
password:Type your password and press Enter. The password will not be echoed to your screen. If you type the correct password, the system will return with the >> prompt. If you type an incorrect user name or password, the 7318 will report an error and request your login ID again.
When you are finished using the 7318, you should end your session. You can do this in several ways:
Users that are logged in to the 7318 can change their passwords at any time. The passwords are stored in nonvolatile storage on the 7318 and never go out on the Ethernet. They cannot be read by anyone, including the system administrator. If you forget your password, the system administrator will have to delete your user name from the 7318 and add it back again with a new password.
password
Password:
Retype password:
To use local password protection, the system administrator must enable passwords by modifying the configuration file. Prior to enabling password protection, the password command reports an error if it is used.
passwords=1
Note: If you are using Kerberos password authentication, the passwords entry should be set to 0 . Local password protection is incompatible with Kerberos password authentication.
The command shell admin password is the same password as the BIOS admin password. You can change it using either the BIOS commands or the following command shell procedure.
Note: When you change the command shell admin password, you simultaneously change the BIOS admin password.
password:
If you type the correct password, the command shell prompt will change to #>> (pound sign, double redirect). If you do not, it will report an error and you will need to repeat the admin command.
password -a adminThe system will return with a password prompt:
Password:
Retype password:Type your new password again exactly as before and press Enter.
Note: If you forget your admin password, contact your technical support for a procedure that will completely reset your 7318.
After local password protection is enabled, the administrator will have to add user names before users can log in. The user name admin is always available and cannot be deleted. To add new users, the administrator uses a variant of the password command that can only be executed in administrative mode
password -a Userwhere User is a user name, such as mary , to be added to the system. User names can be up to 12 characters long and can contain any ASCII-printable characters but should not contain spaces or control characters.
The system will return with a password prompt:
Password:
Retype password:Type the initial password again exactly as before and press Enter.
If the passwords did not match, the system will report an error and the user will not be added to the database. If the user name was already in the database, the system will also report an error and the existing password will not be changed. Similarly, if the password database is full, an error will be reported and the user will not be added.
If you want to remove access to a 7318 by any users, remove their names from the password database. Again, this can only be done from administrative mode.
password -r Userwhere the User parameter specifies a user name such as mary to be removed from the system.
The number of users supported in the local password database depends on the length of the names used but may be as few as 48 users. The system administrator should remove users when they no longer need access to the 7318. To keep track of who is currently in the database, the system administrator can list the users.
If remote passwords are used, and the 7318 cannot reach the password servers, the 7318 will notify you of this and ask for a login again. You should contact your system administrator if this happens.
At the #> prompt in a command shell, type the following command and press Enter:
show Users
Unauthorized access to systems, especially for those systems with modems, should be discouraged. The public telephone network is a prime entryway into many systems with modems. With some automation, trial and error can often allow access to computer systems. To discourage this activity on the 7318, the logintime and loginretries parameters can be set so the 7318 hangs up after a predetermined number of retries or when a timeout value is reached without a successful login attempt. These parameters are placed in the [PortNN] section for each port that requires them.
[Port03] ... logintime=120 loginretries=3 ...
This entry restricts the time to login to 2 minutes, after which the 7318 also disconnects from the mode.
To use remote password protection, the system administrator must enable passwords by modifying the configuration file. Prior to enabling, the password command reports an error if used.
Passwords=remotex
PrimaryServer=204.30.137.99
PrimaryPort=5400If you use a port other than the default port, you must supply that port number when you start the remote password server program on your host.
BackupServer=204.30.137.104
PrimaryPort=5400
rpasswdYou get a message:
Base Password Table Created Usage: rpasswd -a/r/i userThis step initializes the password database.
passserv&By entering passserv& , the password server daemon listens for requests on the default TCP port of 5400. To start the daemon on a different port, specify it as the first parameter.
passserv 8899 &
rpasswd -a fredThe system returns with the password prompt.
Password:
Retype password:
password:
retype password:
At the host command prompt, type the rpasswd command with the -r flag and the user name of a single user.
rpasswd -r fred
To remove all the users in the database, enter:
rpasswd -i
This command resets the password database to its original start.
This command runs as a daemon and listens on a TCP port for password authentication requests. When received, it authenticates the password and returns a response. The database of userids and passwords is maintained by the rpasswd command. The only parameter is optional:
| TcpPort | Specifies the TCP port on which this daemon listens for remote password authentication requests. If the parameter is not specified, the default port is 5400. |
For more information, see "[PasswordServer] Section".
The rpasswd command has three options for initializing and maintaining the remote password database. All the parameters require root authority to operate but can be invoked by a general user to change the password. The parameters are as follows:
Kerberos is a network authentication system for use on physically insecure networks. It allows entities communicating over networks to prove their identity to each other while preventing eavesdropping or replay attacks. It also provides for data stream integrity (detection of modification) and secrecy (preventing unauthorized reading) using cryptography systems such as Data Encryption Standard (DES).
Kerberos works by providing principals (users or services) with tickets that they can use to identify themselves to other principals and secret cryptographic keys for secure communication with other principals. A ticket is a sequence of a few hundred bytes. These tickets can then be embedded in virtually any other network protocol, thereby allowing the processes implementing that protocol to be certain of the identity of the principals involved.
Before you attempt to enable Kerberos security, you need to be fully familiar with the concepts involved and with the overall layout of the secure network into which the 7318 is being installed. It is strongly recommended that you get a copy of the Kerberos Version 5 documentation that comes with your host system and study it before attempting to turn on the Kerberos security feature.
Kerberos functionality is enabled by modifying entries in the [Kerberos] section in the configuration file. The enable , realm , and authorizedServer entries are all required. If the 7318 is already running, you can enable Kerberos using the set kerberos on command in the command processor. Refer to "7318 Command Session" for more information on the command shell set command.
The [Kerberos] section defines parameters needed for the Kerberos security feature. The entries are:
The [Kerberos] section of the configuration file might look like the following:
[Kerberos] enable=1 realm=rnd.bigcorp.com authorizedServer=128.219.24.140 clockSync=480 serverPort=750 kloginPort=543 ekloginPort=2105 ticketLife=480 renTicketLife=7200
When the Kerberos security feature is enabled, the terminal commands available to the user are restricted. These restrictions are intended to provide a secure networking environment. Such an environment prevents anyone who is not properly authorized from accessing the host computers that are connected to the local area network to which the 7318 is attached. In addition, the Kerberos security feature provides the capability to encrypt all data that is passed via the rlogin session using DES encryption.
In Kerberos security, every participating application must obtain a security ticket to authenticate a user who requests services before allowing network activity. These tickets are time-based and have an expiration date. Before any network applications can obtain tickets, a master ticket called the ticket-granting ticket (TGT) must be obtained. The command shell is responsible for obtaining the TGT.
Since Kerberos security tickets are time-dependent, it is very important that the clocks on the 7318 and the Kerberos authentication server are synchronized. If the two system's concept of time varies more than one or two minutes, Kerberos will not work and all network resources will become unavailable to the users.
To prevent the preceding situation, the 7318 sends Internet Control Message Protocol (ICMP) time stamp requests to the Kerberos authentication server and updates the 7318 system clock to match the time stamp sent back by the Kerberos server. These ICMP time stamps are sent to the server every 8 hours to keep the 7318's system clock from drifting too far out of sync.
This process of synchronizing the system clock is performed at boot time and every 8 hours thereafter. The period of 8 hours is used because most Kerberos tickets have a maximum life span of 8 hours; however, the frequency of time synchronization may be changed by the system administrator.
Before a user can access any network applications or resources, a TGT must be obtained. Ticket-granting tickets are obtained during the login process in the command shell. When a user logs into a command session, the user name is used to obtain a valid TGT from the Kerberos authentication server and that TGT is validated with the user's password.
Once a TGT is obtained, the user is logged in. The TGT is passed to any application the user starts so that the application may obtain its own ticket. Ticket-granting tickets have a maximum life span of 8 hours, after which the user must log in again.
When a user starts an application, the application must obtain an application ticket from the Kerberos authentication server before any network activity can be performed by the user. In order for an application to obtain its own ticket, it must have the user's TGT. This is passed to it by the command shell when the application starts up. The application must then send the TGT to the Kerberos authentication server to obtain its own ticket.
If either the server is down or the server denies the application a ticket, then the application must either quit or refuse any network access to the user. Application tickets have a maximum life span of 8 hours, after which the user must restart the application.
The Kerberos remote login is very similar to the standard rlogin command except that instead of the $HOME/.rhosts file, it uses Kerberos authentication to determine the authorization to use a remote account.
Users may have a private authorization list in the .klogin file in their login directory.
Each line in this file should contain a Kerberos principal name of the form Principal_Instance @ Realm . If the originating user is authenticated to one of the principals named in the .klogin file, access is granted to the account. The principal AccountName .@ LocalRealm is granted access if there is no .klogin file. Otherwise a login and password will be prompted for on the remote machine as with the login command. To avoid some security problems, the .klogin file must be owned by the remote user.
If there is some problem in gathering the Kerberos authentication information, an error message is printed, and the standard nonsecure rlogin is run in place of the Kerberos rlogin.
When Kerberos is enabled, the rlogin command supports the following additional command line options:
For a discussion of the PAP security mechanism, see "PPP Security".
The 7138 allows an audit trail to be placed into the system log area. This log can be examined either using the cnsview command or by having a host initiate a TCP/IP connection to a special logging port on the 7318.
The audit trail is enabled by setting the Log parameter in the [Command] section of the configuration as follows:
Log= EventList
Where EventList is a comma-separated list of the user events that are to be logged. The events that can be logged are:
The log entries that are generated appear in the following format:
Type Timestamp Module Flags String
Additional message text may follow the initial event entry providing more detailed information.
For example, the following configuration file entry turns on the audit trail and logs events for all login and logout activity:
[Command] log=logins,admin
With this entry, the log would contain entries like:
E 0001:10:22.44 0000000003 cmd023 0 User logged in.
logid: uid=johndoe, port=03
E 0001:10:22.44 0000000003 cmd023 0 User logged out.
logid: uid=johndoe, port-03, connect=560
E 0001:10:22.44 0000000003 cmd023 0 Invalid password entered.
logid: uid=johndoe, port=03, (bad password)
The log entries can be read in one of three ways:
show Log
cnsview -c 'show Log' /dev/cns03
device=LOGCOM port=0 tcpport=ppppWhere pppp is the TCP port number for this connection.
tcpport=5500From the host, you can now connect to this TCP port. The stdout from the telnet command contains the original content of the 7318 log, as well as real-time entries for the duration of the connection.
For example, the following command would cause the output of the log to be printed, as well as placed into a disk file:
telnet 33.44.55.66 5500 | tee /tmp/cns01.log
Internet security is implemented using the concept of a security filter. There are two types of security filters supported on the 7318. The first involves address filters for the internet addresses. The second is a switch to disallow telnet access to nonstandard TCP ports.
Address filters are either globally enabled or disabled. When enabled, the filter applies to all usages of IP addresses, including application connection establishment and ping.
Note: SLIP, CSLIP, and PPP are not affected by address filters. Only commands run from s20 command sessions are affected.
Filtering can be done by only allowing access to host addresses or subnets on the "allowed host" list, or by denying access host addresses and subnets on the "disallowed hosts" list. The access lists are placed in the 7318 configuration file in either the [Allowedhosts] section or the [Disallowedhosts] section.
You can specify either the IP address of the host, the name of the host, or both. If only one item is supplied, the 7318 will go to the network nameserver to complete the access tables.
Note: If the 7318 requires resolution of the access tables, you will not be able to access the network until resolution is completed. Normally, this happens very quickly; however, if the nameserver is unreachable and the 7318 is rebooted, you will not be able to gain access to the network until the nameserver becomes available again.
The security filters allow two extensions to normal internet addressing. The first extension is to put an entry in the allowed host list of 255.255.255.255 . The address will never match a valid host or internet address, thereby making access to all hosts illegal. If the desired S20 configuration is for SLIP or PPP only, you can make telnet/rlogin not work at all by disallowing all hosts in this manner.
The second extension is to regard the use of 0 for part of the host address as a wildcard, which will match any value for that segment of the address. This is useful for allowing access to an entire subnet. Any specific hosts may be disallowed by placing their specific address in the [Disallowedhosts] section. This is the only situation where having an entry in both the [Allowedhosts] and [Disallowedhosts] sections makes sense.
Allowing telnet access to TCP ports other than the default port can be a security exposure. To disable to the Port parameter on the telnet command, place the following entry in the [TCP] section of the configuration file:
allowportswitch=0
The 7318 must be rebooted for the change to take effect.