| Ensuring console security is the next important task in securing the server. If someone can obtain access to your file server's console, that person can copy the DS database files to a publicly accessible directory and take those files offsite for an offline attack (because in DS you do not store the actual password but its public/private key pair). Although the DS database files only yield the password hash, knowing the user ID and length of the password are enough to provide a starting point for a brute-force attack to determine the password. Unfortunately , when you use RConsole, XConsole, AConsole, and RConag6, passwords may be transmitted in clear text (XConsole) or you might be using an easily reversible encryption scheme (RConsole, AConsole, and RConag6). These problems can open you up to attacks on the console remotely. They provide enough access to obtain the Directory Information Base (DIB) files for such an offline attack. Evaluations of remote console security have turned up problems with using RConsole , even when using encrypted passwords (for example, using the REMOTE ENCRYPT console command and storing the password in LDREMOTE.NCF ). Several services that can be installed on the server grant access to the SYS:ETC directory, where the network configuration information is stored if you configure your system with INETCFG NLM . If you configure remote access to your system and use Unix Print Services, NFS, or FTP services, the possibility exists that access to your SYS:ETC directory is open. If you set up remote access with RConsole through INETCFG.NLM and if unauthorized users have read access to the SYS:ETC\NETINFO.CFG file, your console is not secure because the RConsole password is stored in that file in plain text. WARNING We will not go into the details here, but suffice it to say that from a packet capture of an RConsole session, one can easily determine the password, even when it is encrypted.
Unfortunately, the best policy for remote access is the one that is least feasible : Do not use it. Many system administrators depend on having remote console access to the server for various administrative tasks . A potentially better solution is to not load the remote console modules until you need them. It is possible to remotely load and unload NetWare Loadable Modules (NLMs) on the server console by using a tool such as Wolfgang's Remote utility (www.geocities.com/wstools). Setting up RConsole in this manner provides a little more control over who has access to the console and when. NOTE Using remote load/unload commands requires Console Operator privileges on the server you want to execute the command on.
TIP If you are running NetWare 6 and higher, you can use the RconJ module, which supports secured connection via Secure Sockets Layer (SSL). Using that module helps keep your remote access password from being sniffed, but it does not address the problem of finding the password from configuration files that store it in clear-text format.
Good security for the console is not easy to achieve, but it can be done. You can start by "locking" the console screen, using a password-protected screensaver, or "blanker" (so that the monitor screen does not get burned in). Many people rely on the security of MONITOR NLM's console lock (in NetWare 4.2 and earlier) and the screensaver SCRSAVER NLM in NetWare 5 and higher. The MONITOR console lock is based on either an entered password or the bindery Supervisor password for the server ”even if a bindery context is not present. MONITOR does not, unfortunately, prevent someone from unlocking the console through the NetWare kernel debugger. A password entered at the MONITOR console lock prompt is stored in memory in clear text. If you know where to look, you can read the password directly from memory, continue the server's execution with the G debugger command, and then work from the server console by entering the password discovered in memory. If you press Enter at the MONITOR lock option, however, the only password that unlocks the console is the Supervisor password, and it is stored like any other DS password ”after being passed through a one-way hash. Unfortunately, there is a problem with this as well: It is possible, through the NetWare kernel debugger, to completely bypass the security checks in MONITOR and cause MONITOR to think you entered the correct password when you did not. Someone who knows what he or she is doing can do this quickly enough that services hosted by the server are not interrupted . This demonstrates how dangerous it can be to have access to the kernel debugger. Breaking into the kernel debugger is a simple task: You simply press the left and right Shift keys, one of the two Alt keys, and the Esc key simultaneously ”the so-called four-finger salute. WARNING Do not attempt the four-finger salute on a production system. Breaking into the kernel debugger causes the system to stop responding to client requests . You can restart it with the G debugger command, but it is not recommended that you experiment with production systems.
NetWare 5 and higher remove the screensaver (affectionately referred to as "the snake" ”on servers with multiple CPUs, you get multiple snakes , one for each CPU) and console lock components from the MONITOR utility and put them in a separate NLM called SCRSAVER . SCRSAVER , however, requires that the person accessing the console have Supervisor rights to the NCP Server object in the NDS tree. This may not be practical in all cases, and the SCRSAVER NLM does not restrict access to the kernel debugger. TIP SCRSAVER depends on DS to verify and authenticate the user to unlock the screensaver. If the DS is locked (such as when DSRepair is running) when SCRSAVER activates, authentication for the admin user cannot take place, resulting in the screensaver hanging in activation mode. However, you can load SCRSAVER with the NO PASSWORD option, and it will allow you to unlock the screensaver with no password required when eDirectory is not available.
For better or stronger console security, you need to look at some third-party solutions. SSLock for NDS (see www.dreamlan.com/sslock.htm), runs on NetWare 4.11 and higher and is an alternative to SCRSAVER and MONITOR 's keyboard locking function. The following are some of the features that SSLock v6 offers: -
Sending of console status change alerts via SMTP email. For instance, when the console is locked or unlocked. -
Sending of intruder detection warnings via SMTP email. -
Disabling of access to kernel debugger via the four-finger salute. -
Requirement of a valid DS user login ID and password. -
Emergency access in case the DS database is locked or corrupted. -
Remote status information of SSLock and unlocking of the console via a Windows 32-bit operating system GUI client. -
Displaying of legal information and requirement of acceptance before the user is allowed to unlock the console. As with SCRSAVER , users who have Supervisor object rights to the NCP Server object can unlock and unload SSLock. In addition, you can define users to be members of a group ( SS_UNLOCK ) in order to unlock the console (but not unload the NLM). To unload the NLM (that is, to turn it off), the user needs to be a member of a different group ( UNLOAD_SS ). Therefore, when you use SSLock, the users no longer need to be given Supervisor object rights in order to access the server console. Figure 15.1 shows the login screen for SSLock. Figure 15.1. The SSLock login screen. 
If you need something more comprehensive than SSLock, you might try SecureConsole (www.protocom.com/html/secureconsole.html), which addresses many needs for console security and provides a high degree of console security. Among other things, SecureConsole does the following: -
Requires a valid NDS user login ID and password. -
Requires that the login ID be granted explicit access to the server's console. Having Supervisor rights to the server is not sufficient (much like having Supervisor rights is not sufficient to perform print queue operator functions). -
Is capable of creating an audit trail of all console commands. -
Has the capability to restrict console commands and access to special console functions, such as the NetWare kernel debugger and the fast restart key sequence introduced in NetWare 4.11. -
Has a configurable login screen. -
Can have multiple emergency users (non-DS users) in case the DS database is locked or corrupted. -
Provides encrypted remote access via IP or IPX. -
Supports the use of passwords that are available for a specified amount of time for emergency user accounts. In addition, SecureConsole can be configured through NetWare Administrator, ConsoleOne, or Protocom's server-based administration utility, SCADMIN.NLM . Figure 15.2 shows the login screen for SecureConsole. Figure 15.2. The SecureConsole login screen. 
| 