***The continuing shift from centralized to distributed computing has brought a new vulnerability to computing systems. Users are given increasingly easier access to more data from more locations within both the LAN and the WAN. Modem access has the potential to extend the WAN to every point of the global telephone network. The potential for inadvertent or malicious loss of data and for unauthorized access to data has increased as the ease and scope of access has increased.
This chapter deals with the issue of controlling access to your network. It describes the forms that unauthorized access might take, how to protect the network and data in each case, and provisions for minimizing the impact of such unauthorized access. Finally, it describes the factors to consider when drafting a security policy and explains how you can use an auditing process to maintain the integrity of your network.
Security and Network Access
The security of a network can be considered as a number of objectives, including
These objectives can be met by implementing security procedures in the following areas: physical, electronic, and file.
The first item in the list should be self-evidentóyou obviously want to avoid the loss of network hardware. While this chapter will discuss those aspects of physical security that are directly relevant to the network, the more general issues involved in securing property against theft, fire, accidental damage, and so on are beyond the scope of this book. The consequences of such loss or damage in terms of disruption of services should be considered when formulating a security policy.
The remaining items in this list cover the broad thrust of security concerns. In a nutshell, people should not be able to see what they are not supposed to see and should not be able to alter what they are not supposed to alter. They also should not be able to pretend to be somebody else in order to view or alter things they're not supposed to access.
Unauthorized access to dataóviewing, modifying, and so onórefers to access either by a person who should not have access to the server or network or by a legitimate user of the server or network to some data that they should not be able to access.
Access to the network means different things in different contexts. It could mean the ability to change passwords on the server or the ability to divert network packets to an illicit connection. The various types of access can be divided into broad areas for convenience:
A user ordinarily uses a number of different types of access to perform even the simplest of tasks, like viewing a file stored on a server:
1. Physical access to a workstation by the user
2. Physical access to the network by the workstation
3. Electronic access to the server when logging on
4. File access to the file when the user views it
The broad areas of network access are defined and described in the following sections. The security risks are outlined in each case, along with steps you can take to eliminate or reduce the risks.
Eliminating all risks is, of course, not always possible and practical. The purpose of your network may preclude some security measures, and the cost of certain security solutions may be prohibitive.
For example, you can prevent unauthorized access to the network from outside the LAN by providing absolutely no means of external accessóno modems, WAN links, and so on. However, this might be completely unacceptable if you have users who require remote access to services for legitimate reasons or if you need remote access to the server console yourself.
As another example, suppose you wanted to eliminate the possibility of sniffer devices being attached to the network. These devices can collect network packets that are addressed to other locations on the network, allowing someone to read the data being transmitted on the network. You would have to physically secure all cables and devices, constantly monitor all cables and connections, supervise any repairs carried out by external maintenance personnel, and more. The cost in time and money for such operations would be prohibitive for most installations. It's far better to spend a lesser amount of time and money restricting the usefulness of any "sniffed" data.
Physical Access
A significant portion of the paths between users and their data is physical. This in itself is ample reason to carefully control physical access to the network. There is another reason: Unauthorized access to some of the physical components of the network could lead to a loss or disruption of service. Both of these aspects of physical access are covered in the following sections.
The types of physical access that need to be controlled are
Let's look at each of these in turn.
Access to Workstations
People need access to workstations to use the network, unless your network setup is very unusual. You can control the range of people who are allowed to use a workstation, the availability of workstations, the range of workstations that can connect to the server, the activities that can take place from a workstation, or a combination of these factors. The following sections describe how to implement this type of control.
Monitoring of Workstations
An unsupervised workstation is an easier place to carry out malicious deeds than a workstation that is watched over. Security cameras deter many unsavory activitiesóthey even inhibit people from playing computer games, which in some circles is an unsavory activity. If cameras aren't an appealing solution, consider a live supervisor, who can be useful in deterring theft and attack, and also serve as a source of accurate information, protecting users from themselves.
Availability of Workstations
One of the simplest steps you can take towards securing the network is to lock up all workstations when they are not (or should not be) in use. If offices are locked when the people who belong there are out, and if PC rooms are locked when no supervisory staff are present, the risk of illicit access should decrease.
In extreme cases, access to workstations can be prohibited outside supervised hours. This is often impractical, of course, since workstations might be installed in offices that you have no jurisdiction over, or there may be a legitimate requirement for availability of workstations to access the server at any hour. If you can, though, lock away any workstations that can be accessed casually.
Bootup Passwords
The CMOS setup utility of most 486 and later PCs allows the specification of a password that must be typed in before the PC can boot up. This password can restrict access to specific workstations to people who know the correct password. A variety of third-party utilities exist that provide similar functionality for other PCs.
In practice, this feature is useful only in a very limited number of cases. Unless people use the same workstation every day, they need to know the password for each workstation. This inevitably means lists of written passwords, a disaster in security terms. If every workstation has the same bootup password, the password is an open secret and therefore of minimal use as a security measure.
The following are a few cases when a bootup password can be of use:
Restricted Workstation Environments
In some cases a restricted range of applications or network services are made available to users on a guest basis, with no user authentication. Examples include the provision of information services or Internet access in some libraries. These services often are provided by having a staff member log the workstation on to a guest account with very restricted access rights before use by members of the public.
The necessary access restrictions on the file server may be implemented by using trustee assignments, but this will not protect the workstation. The boot configuration (unless remote booted) and essential operating system files may be deleted or damaged unless protected. Unrestricted access to the workstation's hard disk may also give an intruder an opportunity to connect to the file server using an account other than the designated guest account. A restricted workstation environment is required to protect against such unauthorized access.
Such a restricted environment can be set up using third-party products such as IronClad from Silver Oak Systems, StopLight from Safetynet, or PC/DACS from Mergent International. These products allow the system administrator to control the type of access permitted to different users on a file-by-file and directory-by-directory basis. The workstation can be configured so that all applications and configuration information are write-protected, preventing modification for malicious purposes. The user can also be prevented from running software that is not explicitly designated as permitted. If you are concerned about users booting from a floppy disk to bypass this security mechanism, you can use the workstation's BIOS setup utility to prevent booting from the floppy drive.
Alternatively, the applications or services can be presented in menu form or within a Windows environment. The user is prevented from exiting the menu or Windows, ensuring that the range of software that they can run is carefully controlled.
If the user can exit from the menu (or from Windows) without logging out from the server, they retain a valid connection to the server. Assuming you have been successful in restricting the access rights of the guest account to the bare minimum, there won't be a lot they can do, but it's best not to leave this to chance.
In a DOS environment, use a menu program that prevents the user from exiting to the DOS prompt. Some menu utilities allow the user to exit only if they enter a password.
In Windows, remove all icons for non-required programs. That includes File Manager, which can be used to run other programs, and Write and Notepad, which can be used to read text files. In addition, prevent the user from running other applications that they might bring on a floppy disk. To do this in Windows 3.1x, add a [Restrictions] section to the workstation's PROGMAN.INI. Valid entries for the [Restrictions] section are listed in table 20.1.
Table 20.1 [Restrictions] Settings for PROGMAN.INI
| Setting | Function |
| EditLevel=1 | Disallow creating, deleting, and renaming program groups |
| EditLevel=2 | Disallow creating and deleting program items |
| EditLevel=3 | Disallow changing command lines for program items |
| EditLevel=4 | Disallow changing any program item information |
| NoClose=1 | Disallow exiting from Windows |
| NoFileMenu=1 | Don't show the File menu |
| NoRun=1 | Disable the Run command on the File menu |
| NoSaveSettings=1 | Disable saving of settings |
As an example, the following [Restrictions] section prevents the user from changing any program information, exiting Windows, or running programs not available as icons:
[Restrictions]
EditLevel=4
NoClose=1
NoRun=1
Windows 95 gives much greater control over the user environment. The System Policy Editor allows you to specify restrictions for the workstation as a network client or separately for individual users. The individual user options that may be resticted include access to the Properties sheets, the ability to run programs, set passwords and so on. The System Policy Editor is easy to use and it may be used to confine the user to a narrowly-defined environment where only explicitly permitted programs may be executed.
These methods can provide a good deal of control over the range of activities that may be carried out from a workstation. If you install such a product on each workstation on the network, and if you make sure that no additional workstations can be connected to the network, you provide a layer of access security at the workstation level to supplement network and server security. From the point of view of restricting access to the network, however, the usefulness is significantly diminished if you do not have control over all client workstations.
Disabling Floppy Drives
An extreme method to secure data from being illegally copied from the network is to disable floppy drives on all client workstations. This also prevents users from introducing malicious or virus-infected software to the network.
In some cases, the floppy drives are removed completely. In others, a proprietary locking device is inserted in the floppy drive. This can be unlocked with a key and removed, allowing the floppy drive to be used by network administration staff when necessary. Another approach is to disable floppy drives using the workstation's CMOS setup utility. This is not a very robust measure, however, as any user with a copy of the CMOS setup utility will be able to bypass it.
The floppy drives on one or two designated workstations usually are left enabled. These are in a supervised area with anti-virus software installed; in many cases, they may be used only by network staff who will scan disks for viruses and malicious software or check that data is not being illicitly copied.
An alternative approach is found in StopLight, manufactured by Safetynet. Full disk access is allowed, but a data encryption mechanism prevents the data from being read on machines outside the StopLight domain where the data was written. The same system prevents protected workstations from reading data or programs from floppy disks brought in from outside the protected domain.
Disabling or removing floppy drives is of little use unless the network is hermetically sealedóthat is, unless al en have to go to a central location every time they want to copy a file to or from the network.
It might be appropriate, however, in networks where data is highly confidential or the network is mission-critical. It might also be appropriate in those cases where workstations are used to provide public access to information or network services, such as in libraries. In these cases, users can view information on-screen and perhaps print it, but they cannot copy data to disk and they have no way to introduce a virus or malicious program.
***
Disabling the floppy disk is of little use if the hard drive can be easily removed! Some PC cases snap open very easily, allowing the hard drive to be slipped out without difficulty. Someone stealing the hard disk can steal confidential data.
Moreover, if a troublemaker takes the hard drive to another workstation and introduces a malicious program to it, he can then reinstall it in the original workstation, circumventing the floppy disk lock.
The only solution is to lock the case securelyódon't rely on the simple lock that comes with itóand keep a close eye on users of your supposedly secure workstations.
***
Trusted Workstations
Another way to prevent unwelcome access is to distinguish at the server between trusted and non-trusted clients. Mergent International's NET/DACS allows the system administrator to limit network access to trusted workstations only.
Minimizing the Impact of Workstation Intrusions
In most normal installations there is a fair chance that someone, sooner or later, will gain access to a client workstation and try to do something you'd prefer they didn't do. This could be a malicious attack on data or applications, an attempt to steal valuable data, or perhaps a well-meaning attempt to "fix" a perceived software problem.
If you're protecting some highly prized data or a critical service, the more extreme of the measures previously listed may be approriate. If not, however, it's generally better to focus on how to minimize the impact of this type of intrusion. The "File Access" section later in this chapter describes how to protect the integrity of the files on the server from accidental or deliberate alteration and how to contain the writeable area for each user.
Workstation Summary
Most of the methods previously described for restricting access at the workstation level are of limited use. Unless you can afford one of the third-party, high-security solutions (and are sure your users will tolerate the extra hassle involved) it's best just to assume that there are unsupervised workstations out there, and that these will be used at some point by someone who wants to get access to data they shouldn't. Workstation access is an area that you might have little control over; server and network access, on the other hand, is where you call all the shots.
Access to the Server
The server is at the heart of the network. Unrestricted access to the server console brings with it complete access to user data, the ability to alter the server configuration, load or unload any server software, change any password, disrupt the service, and even to damage or steal some very expensive hardware.
Who Has Access?
Start by deciding who should be allowed to physically access the server console. It is generally not desirable for all users to be able to freely access the server, but even in those rare cases when it is, you need to take steps to keep non-users away. If some users are to be excluded, is it even necessary for all network personnel to have free access to it? If not, which staff members truly require access?
If your server is mission-critical or is used to store sensitive data, you should also consider restricting the possibilities for access by third parties. Security and cleaning personnel generally have access to locations where many others do not; consider whether you need to exclude them from your server room.
Service personnel are often given free rein with the server without having their bona fides adequately verified. If you care about your data, have all service calls supervised by a trusted staff member. This is expensive in terms of staff time, but it is far more expensive to recover from industrial espionage.
Excluding users or staff members from a room in their own building, or looking over a technician's shoulder while they carry out maintenance work, can easily offend people because they feel that they are not trusted. Minimize the offense by explaining that strict adherence to security procedures is essential for your auditing process (see the later "Auditing Network Security" section). This helps remove any hint of personal bias in the act of exclusion. If the person still takes offense, review the criteria you applied when you decided to exclude them. If the criteria are sound and they still don't meet them, that's too badófrom your point of view, the integrity of your network matters a lot.
Server Location
No matter where you draw the line in deciding who should be able to access the server, it will be necessary to lock the server behind a door at some stage. It is not uncommon to see mission-critical servers located in open-plan office areas, as easily accessed as any workstation. This is acceptable only if access to the office itself is very carefully controlled (see the later "Physical Security Measures" section) and if all legitimate users of the office are also people who should have access to the server console.
In nearly all cases, the server should be located in a room dedicated to housing network equipment, rather than in somebody's office. The room should be walled off from office or open-access areasódon't rely on partitionsóbut still close enough so that there is enough human traffic going past to deter intrusion. A clear glass panel in the door, or a large internal window, also can help deter intrusion.
If the server contains data that might be the subject of aggressive attackófor example, where an intruder might attempt to erase data using strong magnetic fieldsóyou need to take additional factors into account when choosing a location for your server. Those considerations are beyond the scope of this book; you need measures acceptable for protecting any precious commodity, a challenge best addressed by professional security consultants.
Physical Security Measures
Whether you place the server in an open office area to which access itself is very carefully controlled or behind triple-locked steel doors with armed guards, you must ensure that it is impossible for anyone to touch the server without some kind of verification of identity. This can consist of anything from possession of the appropriate door key to a retinal scan, depending on the level of security to which you aspire.
If the number of individuals with access is smallólike five or lessóa simple locked room is adequate protection. If the number of people with permission to enter is more than this, it can be hard to keep track of keys. Designate two or three keyholders and make them responsible for opening and locking the room. Combination locks save money on keys and eliminate the problem of keys being lost or stolen, but it is often easy for a would-be intruder to watch someone punching in the combination. There is the added risk that people often succumb to the temptation of writing down the combination or telling it to someone they shouldn't.
Motion detectors are relatively inexpensive and can be a sensible security measure for protecting servers. These are fitted to the server system box and can prevent theft as well as dismantling. They only make sense, however, if they are tied to a proper alarm system that can bring a prompt response from security personnel.
In some cases, a security guard at the machine room door is a worthwhile investment. If you can afford it, retinal scanning, voice recognition, or some other biological verification procedure may be appropriate. If you think you're ready for this type of security measure, consult security professionals.
Remember, scale your investment to match the resource you are trying to protect. What would the impact on your company be if your data were stolen? A few days of downtime? Try to come up with a realistic estimate of the cost of dealing with a breach in security before you decide how much you are willing to pay for security measures.
Securing the Console
One of the simplest steps you can take toward securing the server is to password lock the console. On NetWare servers, load MONITOR.NLM, choose Lock File Server Console, and enter a password. The server accepts no further commands until either the same password or the supervisor password is entered. Windows NT machines may be locked at any time by pressing Ctrl+Alt+Del to invoke the Windows NT Security dialog box and selecting the Lock Workstation option.
Apply the normal password selection rules when choosing a password for locking the console. Refer to the later "Password Cracking" section for details.
***
Enter a random password (type one without even looking!) to ensure that only a person with the supervisor password can unlock the console. Of course, if the supervisor password is ever lost or forgotten, you will need to reboot the server to regain control.
***
NetWare has a server command that implements a few extra security measures. The SECURE CONSOLE command entered at the console prompt does four things:
1. Prevents NLMs from being loaded from any directory other than SYS:SYSTEM. This eliminates the possibility of, for example, one of the many password-setting NLM utilities being loaded from the floppy drive.
2. Removes DOS from server memory. If intruders manage to get to the server prompt, they cannot bring down the server without forcing it to reboot.
3. Prevents the server date and time from being changed. Doing this could disrupt some services that are time-synchronized, and certainly would upset user accounting.
4. Disables the server debugger, thus blocking one possible mode of access to data for technically-minded intruders.
The second item is worth a closer look. It is a useful measure if, for example, the SECURE CONSOLE command is contained in the AUTOEXEC.NCF file. In that case, an intruder might try editing AUTOEXEC.NCF to remove the command, then bringing the server down and restarting it in an effort to get at an "insecure" console prompt. If DOS has been removed from memory, downing the server forces the machine to reboot.
Of course, this is quite satisfactory for the intruder, unless a bootup password has been set on the server. Disabling the bootup password would involve opening the machine to remove the battery, but that motion detector that you wisely fitted prevents them from doing that.
Despite its surface appeal, you should think twice before setting a bootup password on a server machine. If you set such a password, the server is never able to recover automatically after a power outage or a deliberate reboot carried out by the network administrator over a remote link.
Indirect Access to the Server
It may be possible to gain access to the server without physically touching it. Refer to the later "Electronic Access" section for a discussion of remote access to the server.
Minimizing the Affect of Server Intrusions
Assuming that an intruder manages to breach the physical security around the server and get past the console password, what damage can he or she do?
The answer depends on whether or not intruders can load their own NLMs. If you have not issued the SECURE CONSOLE command, they can load any of a number of utility NLMs that can alter passwords, including the supervisor password. This gives them free run of all data on the server. If you have secured the console, things are a little more difficult. If they can reboot the server, though, the SECURE CONSOLE command is easily bypassed.
In either case, your data can be compromised. If it is sensitive or confidential, you may not have any way to recover its value and the damage may be irreparable.
If you have secured the console, the intruder might not be able to access data on the server, introduce intrusive software, or alter passwords. In any event, with simple physical access to the server, a malicious intruder can damage your hardware and your data.
To minimize the effect of damage to the server or to your data, do the following:
Server Summary
The ability to access the server represents the ability to read, modify, or destroy data as well as hardware. Evaluate the true value of your server and the data it stores, the possible impact on your enterprise of the theft of data, and the cost of replacing hardware or restoring data from backup. Then design and implement a firm strategy to limit access to the server only to those who need it and can be trusted.
Access to the Network
Unauthorized connections to the network can represent a significant security risk, so the network administrator should be aware of each and every network connection and the details of what is connected. This is possible only if there is some system to prevent the use of unauthorized connections.
Since it is usually impossible to police every meter of network cable in the network, the best approach is to configure the network to allow traffic from recognized network addresses and to bar traffic from unknown or unrecognized addresses.
This can be done using a structured cabling system that has intelligent hubs with port-level security features. Such a system can be configured so that ports must be explicitly enabled before use, and individual ports can be restricted to a single MAC address. This means that a new workstation isn't able to send or receive any traffic until the network administrator has explicitly enabled that port. Also, if a port is enabled for a particular workstation's MAC address, connecting a different workstation automatically disables that port, so it needs to be explicitly reenabled for use by the second workstation. In both cases, the network administrator is kept informed of changes in network connections.
Refer to the "Firewalls" section later in this chapter for information on electronic access restrictions.
Electronic Access
The dangers of unauthorized physical access to the network are readily understood, even by those unfamiliar with how it works. The network is an expensive piece of equipment and a valuable resource, so it makes sense to protect it from physical intrusion. Electronic invasions often are harder to conceptualize, so it might be more difficult to explain the need for expensive security measures in this context.
This section deals with electronic access to the network or directly to the server and how to control such access.
Not all networks are subject to electronic intrusion. If your network is purely local, with no links to the outside world by network router or modem, then this section does not apply in your case.
Electronic access to the network can mean a remote console session, a workstation connecting across a WAN, or other forms of traffic from outside networks. The different ways to access the network by electronic means can be grouped as follows:
All these ways are discussed in the following sections.
LAN Access
Access to the server from within the LAN is normally limited to connections from workstations and from other servers. There might also be TCP/IP traffic from UNIX machines or AppleTalk traffic from networked Macintoshes. Each type of access carries its own risks.
In the normal course of events, a logon session from a workstation is what the network is all about. It becomes a problem when it is used to attempt to gain illegal access to data, as discussed in the following examples.
Masquerade Attacks
These occur when the password for a genuine user is discovered by an intruder and used in an attempt to log on. Protect against this type of attack by urging users to protect their passwords and by implementing regular password expiration using SYSCON (NetWare 3.x) or NETADMIN (NetWare 4.x). On Windows NT Server, use the User Manager to edit the Account Security Policy and set an appropriate value for the "Maximum Password Age."
Password Cracking
A password attack occurs when an intruder runs a program that generates a large number of random or dictionary-based passwords and tries to attach to the server using a particular user ID, and issuing each password in turn. An intruder may well be able to guess a correct password, particularly if users pick short or common words as passwords, but enabling intruder detection with a maximum number of logon attempts of three per fifteen minutes and a lockout time of an hour or more should easily defeat this type of attack. These values may be set using SYSCON under NetWare 3.x, NETADMIN under NetWare 4.x or User Manager under Windows NT (choose Policy, Account).
Of course, if your users have a lax approach to password security, an intruder may be able to access the server without needing an elaborate password cracking program. Passwords stuck to the monitor or written in diaries are a gift to such intruders. Advise your users of the importance of keeping their passwords confidential, and teach them how to choose a safe password. In general,
Packet Signature
A research team in Holland was able to demonstrate a potential security hole in NetWare, version 3.11 and earlier. They showed in a laboratory environment that it was possible for a workstation to fake network packets to look like they originated from a different workstation. If used while a supervisor-equivalent user was logged on, this method could be used to make requests to the server look as though they were made by the privileged user.
Novell released security patches for NetWare 3.11 that used a packet signature algorithm to prevent this type of security breach. If you use NetWare 3.11 or earlier, download the SEC*.ZIP files from NetWire and implement them. Versions of NetWare starting with 3.12 have incorporated this packet signature technique, but it must be explicitly enabled as explained later.
This potential security risk apples only to NetWare. Windows NT Server uses a system of "access tokens" to authenticate user requests for access to system resources. These are broadly similar in principal to the system used by Novell to overcome their security threatóa unique signature is defined at log on time to enable the server to confirm that all requests really come from the user account which appears to send them.
The client and server negotiate over packet signature at logon time. Each has its own "signature level" as shown in table 20.2. The decision as to whether or not packets should be signed for the duration of the logon session is based on a combination of these signature levels.
Table 20.2 Client and Server Packet Signature Levels
| Level | Meaning on Client | Meaning on Server |
| 0 | Don't sign packets | Don't sign packets |
| 1 | Sign if server requests it | Sign if client requests it |
| 2 | Sign if server can sign | Sign if client can sign |
| 3 | Insist on signed packets | Insist on signed packets |
For example, if both the client and the server use signature level 1 (the default), no packet signature takes place. If the server is set to level 2, all packets to and from workstations with a signature level greater than 0 are signed. A server with signature level 3 refuses logons from a client with signature leevel 0. A workstation with signature level 3 cannot log on to a server with packet signature level 0.
Set client packete signature levels using the SIGNATURE LEVEL option in the workstation's NET.CFG file:
SIGNATURE LEVEL = 2
On the server, add the following line to the STARTUP.NCF file to override the default value:
SET NCP PACKET SIGNATURE OPTION = 3
There is a slight CPU performance overhead on the server as packet signatures are added and checksums are computed and compared. This overhead is usually very slight, however, as packets are normally sent in burst mode. Each "burst" of packets is signed, rather than each individual packet being signed.
Print Server Piracy
When print servers service a job in a print queue, they take on the access rights of the user who submitted the print job. A print server is thus supervisor-equivalent while servicing a print job submitted by the supervisor. If a print server is down, another workstation could be used to act as the downed print server, diverting print jobs and their associated access rights from the print queue.
To prevent this, set a password for each print server on the network. Also, use the workstation restrictions field under SYSCON to limit the print server account to logons from the designated print server workstation only.
Remote Console Sessions
Networking technology has made great strides in providing remote access to all types of systemsóthe server is no exception. RCONSOLE can bring all the power of the NetWare server console to any valid workstation. XCONSOLE can bring the server console to any X-Server on the Internet. ACONSOLE extends the realm of console access to the entire public telephone network. This vastly increased accessibility obviously brings greater risk of intrusion.
What might not be immediately apparent is the qualitative rather than quantitative increase in risk when remote access is provided. Bringing in additional physical server consoles leads to commensurate additional risk, assuming that each extra console had the same access restrictions as the first. An intruder still needs to gain access to a secure location and guess a console password before gaining access to data, but now they have multiple opportunities to do so. Providing remote access, on the other hand, overrides the physical security measures described above. An intruder can achieve a high level of server access without physically approaching the server.
Direct physical access has more dangers than remote access: Remote access obviously does not allow the intruder to steal or damage hardware, and if you have secured the console, they are not able to load their own NLMs. They are able, however, to destroy data, bring the server down, and so on. If you decide to implement remote access to the server, you should be aware of the risks and take appropriate counter-measures.
RCONSOLE
The RCONSOLE utility provides access to the server console from any point on the LAN. It is enabled by loading REMOTE.NLM and RSPX.NLM on the server and by entering a remote access password. To start a console session from a workstation, log on and run RCONSOLE. You will be asked to choose the remote server to connect to and then to enter the remote access password for that server.
The remote access password is all that keeps an intruder from gaining access to the console!
Any workstation on the network can be used for this purpose. It is not necessary to log on to the particular server that you want to accessóin fact, it is not really necessary to log on to any server, as the required files can be executed from a local disk. All that is required is a copy of the files, a workstation on the network andómost criticallyóthe remote access password.
It might seem like a truism, but the best way to prevent illegal remote server attacks is to avoid loading REMOTE.NLM on your server. Consider whether it is really necessary. If you use it to save a short walk every time you need to issue a console command, is what you save worth the added risk?
Remember, RCONSOLE gives access to the server console in all details. It does not bypass the console lock password if one has been set. If you must use RCONSOLE, at least set a console lock password to provide an extra barrier against intrusion.
***
ACONSOLE, the asynchronous remote access utility, is more secure than RCONSOLE if used over a dedicated serial connection (not a modem) from a secure workstation. Read the following section and consider running a cable from a serial port on the network administrator's workstation to the server.
***
ACONSOLE
The ACONSOLE utility provides over asynchronous connections what RCONSOLE provides over the IPX network. A workstation can be used to view and control the file server console, allowing console commands to be issued. It is every bit as powerful as RCONSOLE, and if used over a modem, it can provide console access to any point on the telephone network.
ACONSOLE with modems can be extremely useful for managing the server while off-site. As always, however, you should consider whether the benefits of greater accessibility outweigh the increased risk. If the server and the data it holds are critical, it might be better to resort to the technologically inelegant alternative of issuing verbal instructions to a staff member on-site.
ACONSOLE can be used over any serial connection, not just modems or phone lines. A cable from the serial port of a secure workstation to the server's serial port might be useful in those circumstances where it is inconvenient to walk from an office to the server room whenever access to the console is requiredófor example, where the office and the server are separated by a flight of stairs.
XCONSOLE
XCONSOLE allows the server console to be accessed from any X Windows server on a TCP/IP network. It is analogous to the RCONSOLE and ACONSOLE utilities, but if used on a server with an IP connection to the Internet, the scope for illegal access to the server is enormous. Bear in mind that the password is transmitted over the network in plain text, so a sniffer device can easily pick it up, compromising server security.
Remote Access to Windows NT Servers using NT's Remote Access Service is more secure than access to NetWare in this regard: all user account and password information is encrypted using a secure algorithm.
WAN Access
If your network is connected to other networks via a WAN linkófor example, a router with a link to the Internet via a network service provideróyour network might become a target for attacks from computers on the other network. If you have control over activities on the entire WAN, you may regard it as an extended LAN from the point of view of access restrictions.
If, however, a portion of the other network is carried over a public networkóor another network over which you do not have jurisdictionóyou need to take measures to control the ability of outsiders to access your network.
Firewalls
The basic requirement is to insert a control layer between your network and the outside. This layer, known as a firewall, allows some traffic through and prevents other traffic from passing through. The function of a firewall is illustrated in figure 20.1.
Figure 20.1 This is how a typical firewall operates.
The administrator of the local network configures the firewall based on the security policy of the local network. It's possible to block traffic of a particular kind, traffic from certain addresses, or traffic from all but a predetermined range of addresses.
Firewalls are rule-based entities. The network administrator decides on a series of rules that, when applied to a given network packet, decide whether or not the packet should be passed. The type of rule system varies depending on the form of the firewall. In general, more secure systems operate on the principal that no traffic is allowed unless the rules explicitly allow itóthere are no permissive default rules.
Types of Firewalls
A firewall is a conceptual model for the protective layer between internal and external networks. In reality, it can be implemented in any number of ways. There are two classic types of firewalls:
ï A screening router is a router connected between an internal and an external network, configured to permit only certain types of traffic. For example, it might permit packets of designated types or packets traveling between designated addresses.
ï A proxy server is a carefully secured UNIX machine that runs a range of proxy network applications such as FTP, WWW servers, and so on. External users connect to the proxy server, which decides, based on rules set by the system administrator, whether to allow them to access the system. If so, the proxy server passes traffic between the external user and the genuine application serveróFTP, WWW, or whateveróthat is on the local network. To the external user, it appears that they are connecting directly to the local machine.
Implementing a screening router using an existing router may be quite simple, depending on your security requirements. If you want to allow traffic only from designated addresses, simply screen out all others. More complex requirements need more time and thought to sort out, but it may well be possible to adequately protect the internal network without purchasing additional hardware or software.
A proxy server also can be developed at low cost using a range of public-domain software, but this is not an out-of-the-box solution and you should be prepared to invest a significant amount of time in setting up the system, recompiling applications, and testing the security of the system. If you can afford it, a third-party solution such as the Gauntlet Internet firewall from Mergent International is closer to the ideal of a plug-in solution. It still needs a certain amount of configuration, of courseóa firewall is a mechanism for enforcing your security policy, so you need to formulate that policy and enter the rules that define it.
Firewall Costs
At $10,000 or so for the software alone, systems such as this represent a significant outlay. The only way to decide whether such a system is worthwhile in your situation is to assess the value of what you are trying to protect, the complexity of the balance between permitted and denied access, the time and effort required to roll out your own solution using router configuration tables, and the likely maintenance effort as your labor-intensive solutions must adapt to meet changing user requirements or an updated security policy.
Don't let the firewall brochures tempt you into throwing money at your security problems to make them go away. There is no such thing as a sure-fire firewall without a comprehensive and rigidly-policed security system to accompany it. A firewall cannot do its job unless all external network traffic passes through it. Any machine-readable data can be taken outside a firewall; magnetic tapes and floppy disks may seem arcane in a world of high-speed internetworks, but they are quite efficient carriers of data in their own right.
The purpose of a firewall system is quite specific. It is meant to allow limited access between two networks. If you don't really need external network access from the entire network, don't connect it to the external network.
Some products (such as Gauntlet) provide data encryption at the IP level. Two firewalls using this type of system can transmit data across a public network with a high degree of confidentiality.
Dial-Up Access
A modem link can provide access to the server console as described in the earlier "ACONSOLE" section. It also can be used to provide remote workstations with access to the network as clients. Chapter 25, "Adding Network Modems," has plenty of details on remote access implementations, but for the purposes of this section there are two broad categories of client dial-up access:
1. A workstation is set up with a network adapter connected to the LAN and a modem connected to an external telephone line. It runs a remote control package such as PC Anywhere or Carbon Copy. A user running the same software (or the client end of the same package) dials in over the telephone line, takes control of the workstation, and uses it as a network client in the normal way.
2. A dedicated remote access box such as 3Com's Access Builder is connected to the LAN. It incorporates several modems, into which a number of external users can dial at any time. The user's workstation is configured as a normal network client except that it runs a special driver that communicates with the remote access box over the modem link. The access box repackages network packets for transmission over the modem link and vice versa, giving a relatively transparent modem-to-network link.
In both cases, the external workstation should be considered in a similar light to an unverified workstation on the network. Refer to the earlier "Access to Workstations" section for information on the relevant issues. The significant difference is that you may have a degree of control over the workstations which connect to the LAN, but you have no say over modem connections to the public telephone network.
Configure remote control PCs to reboot automatically when the calling modem hangs up. This ensures that if a privileged user looses their connection or forgets to log off when finished, the next user does not inherit the privileged connection.
File Access
This chapter has focused until now on access to the server as an absolute; a given user either has access or does not, depending on the efficacy of your security measures. In reality, of course, no user should have complete access to all data on the server. This section looks at the NetWare tools for selectively controlling access to data on the server.
NetWare uses a combination of rights and attributes to determine the type of access allowed to a user for a particular file. Broadly speaking, rights are concerned with default access permissions, while attributes generally are used to explicitly override the defaults. Both are discussed in detail in the following sections.
Rights
When a user tries to access a file or directory on a Novell server, NetWare must determine whether the user has permission to do what they are trying to do. The access properties of files, the directories that contain the files, and the user accounts that might attempt to access the files all come into play in deciding the fate of a user's request for access.
It can be confusing trying to distinguish between these different factors. NetWare distinguishes between trustee rights, which pertain to specific user accounts and user groups (NetWare 3.x) or user objects (NetWare 4.x), and inherited rights, which pertain to files and directories. These are explained in the following sections.
Trustee Rights
The trustee rights of a user are the set of permissions which that user has to access specific files and directories. Trustee rights are associated with a user, not with files or directories.
Under NetWare 3.x, file and directory trustee rights are assigned to user accounts. Each trustee right granted to a user gives them permission to perform a particular class of operation on the designated file or directory.
There are four types of trustee right under NetWare 4.x. Object and property rights pertain to objects rather than to the file system:
File and Directory rights behave in the same way as under NetWare 3.x as explained later.
User groups also have trustee rights, and users inherit the rights of any groups that they belong to. This means that individual users need not have any explicit trustee rights; they can inherit all they need from a group that they belong to. By default, NetWare gives Read access to SYS:PUBLIC to members of group EVERYONE. In practice, users generally also have explicit trustee rights to their home directory.
***
Use the access rights of user groups to assist in implementing your security policy. Create a number of groups with different access levels, and assign privileges to users by assigning them to the relevant group. This makes the administration of rights much simpler than assigning rights on an individual user basis.
***
The trustee rights which may be assigned are listed in table 20.3.
Table 20.3 NetWare 3.x File and Directory Trustee Rights
| Right | Letter |
| Supervisory | S |
| Read | R |
| Write | W |
| Create | C |
| Erase | E |
| Modify | M |
| File Scan | F |
| Access Control | A |
The meanings of the various rights are as follows:
Inherited Rights
Trustee rights that apply to one directory automatically apply to any subdirectories of that directory. This makes sense; granting user SMITH full read and write access to HOME:SALES/SMITH means that she should have the same access in any subdirectories that she creates there.
It is often necessary to delimit the extent of this inheritance of trustee rights. You might want to grant access to a top-level directory but not to a particular subdirectory. That's where inherited rights masks (IRMs) and inherited rights filters (IRFs) come inóthey act as selective filters on the trickling of rights from one directory level down to the next.
NetWare 3.x: Inherited Rights Mask
The IRM is usually represented as a list of the rights set out in table 20.3, in the sequence
[SRWCEMFA]
with blanks representing rights that are not to filter through. The default IRM has no blanks and therefore has no effect on inherited rights.
Suppose SMITH grants Read, Write, and File Scan access for her directory to JONES. The directory HOME:SALES/SMITH/BACKUP has the default IRM, so JONES can read and list files there, too. If SMITH runs FILER and deletes W from the IRM for the BACKUP directory, so that it now appears as
[SR CEMFA]
JONES will still have Read, Write, and File Scan access to HOME:SALES/SMITH but will no longer have write access to HOME:SALES/SMITH/BACKUP. If SMITH creates a new directory named SAVED below BACKUP, JONES will have Read and File Scan access there, also. This trickling and blocking of rights is illustrated in figure 20.2.
Figure 20.2 This is the flow of trustee rights through IRMs.
HOME:SALES/SMITH Jones' rights: SRWCEMFA
New IRM: [SR CEMFA]
HOME:SALES/SMITH/BACKUP Jones' rights: SR CEMFA
Default IRM: [SRWCEMFA]
HOME:SALES/SMITH/BACKUP/SAVED Jones' rights: SR CEMFA
IRMs are properties of files and directories, not of user accounts.
NetWare 4.x: Inherited Rights Filter
The IRF extends the idea of the IRM to NetWare 4's concept of objects and their properties. Rights filter by default from one directory level to the next, as under NetWare 3.x. They are selectively blocked by IRFs rather than by IRMs.
IRMs (NetWare 3.x) apply only to the file system. IRFs (NetWare 4.x) apply to either the file system or the NDS directory tree. When applied to the files system IRFs are represented in the same way as IRMs, as a list of the rights set out in table 20.3 in the sequence
[SRWCEMFA]
with blanks representing rights that are not to filter through. The default IRF has no blanks, and therefore has no effect on inherited rights.
Rights Summary
Rights accumulate as you move down the directory tree. IRMs block specific rights from a designated level in the directory tree, all the way down to the lowest level. Successive granting of rights and blocking of their progression through the directory tree can be used to exercise a high degree of control over file and directory access.
Attributes
NetWare extends the DOS file attributes with several specialized attributes to provide a greater degree of control over access permissions for network files and directories. The NetWare file and directory attributes are listed in table 20.4. Note that some of these apply to NetWare 4.x only, as they pertain to features of the NetWare 4.x file system not present under NetWare 3.x.
Table 20.4 NetWare File and Directory Attributes
| Attribute | Symbol | File/Directory | NetWare 3/4 |
| Archive | A | File | Both |
| Copy Inhibit | C | File | Both |
| Delete Inhibit | D | Both | Both |
| Don't Compress | DC | Both | NetWare 4 Only |
| Don't Migrate | DM | Both | NetWare 4 Only |
| Hidden | H | Both | Both |
| Immediate Compress | IC | Both | NetWare 4 Only |
| Indexed | I | File | Both |
| Purge | P | Both | Both |
| Rename Inhibit | R | Both | Both |
| Read-Audit | Ra | File | Both |
| Read-Only | Ro | File | Both |
| Read-Write | Rw | File | Both |
| Shareable | Sh | File | Both |
| System | Sy | Both | Both |
| Transactional | T | File | Both |
| Execute Only | X | File | Both |
The following list explains these attributes:
Combining Rights and Attributes
You've seen that there are three separate mechanisms for controlling access permissions on Novell servers:
All of these serve different functions. Trustee rights are granted to individual users or groups to give them access permission for specific files and directories. IRMs and IRFs control the propagation of these rights to subdirectories. File attributes set particular properties of files and directories for all users.
A combination of these different features can be used to greatly fine-tune access rights on your network. Use a structured approach when determining the net result of the different layers of access control. For a given user and a given file, the following hold true:
In other words, file and directory rights are evaluated first using trustee rights and IRMs/IRFs. If the user is entitled to access the file on the basis of that evaluation, the relevant directory and file attributes are also evaluated.
So for example, since everyone has R and F access but not W access to the SYS:PUBLIC directory, everyone can read and execute MAP.EXE but not delete or overwrite it. This is true even if the file is flagged Rw rather then Roóthe trustee rights dictate that the user does not have write access, and file attributes cannot override this.
Appropriate Access Levels
Deciding what level of access certain users should have to network files and directories can be more complicated than implementing the necessary access restrictions. You need to evaluate the requirements of your users and the applications they use in light of your particular security policy.
The following set of rules is fairly typical:
Remember that the effectiveness of this degree of access control depends on the security of user accounts and workstations. Don't use shared logon accounts or workstation-based accounts. Also emphasize to your users the importance of password secrecy, and monitor and review security on a regular basis.
Formulating a Policy
Now that we have covered the implementation details of access restrictions, we can look at the issues involved in formulating a coherent and appropriate security policy. Of course, in real life this stage must come before implementation. It's discussed at the end of this chapter only in the hope that certain issues were made clear through the discussions of implementation earlier in the chapter.
Responsibility
The first factor to consider is the responsibility for security provision. To what extent are you responsible for security on the network? Should you protect only the server and the data it holds, leaving the owners of workstations to fend for themselves? Do laptops, desktop machines, and other equipment also fall within your domain?
Insecure workstations do not make for a secure network. The issue here is to determine where the responsibility for security lies. The security policy should take this into account. For example, if workstation security is not under your control, then you may need to enforce strict criteria when allowing connections at the server.
Risk Assessment
The next stage is to assess the value of what you are trying to protectóyour network hardware, user data, and possibly even the prestige of your organization. It might not be possible to evaluate everything in monetary terms. At the very least, make a list of the items at risk and quantify the following in each case:
The last item in the list can be hard to quantify, but it must be considered. Is your data of commercial value? Is your enterprise likely to be the subject of hostile attack? Even the most benign enterprise with worthless data might be attacked by someone with nothing better to do, but if you are likely to attract more attention than an average installation, you should secure your system more strongly.
Try to evaluate the costs of loss or damage objectively. A break-in might be embarrassing, but will it harm your company's objectives? If so, to what extent? If you think it is possible that a break-in might put your company out of business for good, you might need to consider expensive security measures.
Authorized Access versus Unauthorized Access
The difference between "authorized" and "unauthorized" access is often a matter of interpretation. You must clearly define, in consultation with your users, what you mean by authorized access, and what type of access constitutes a breach of security policy.
One important matter to be clarified is the ownership of accounts. People often regard their accounts as their personal property, to be shared with others if they choose. If this is indeed the case, you need to protect the server from the attentions of a wide range of potential users. If, on the other hand, the account is the property of the companyóand the password merely represents permission to use itóthe users should be made aware of this before you attempt to impose restrictions on their actions.
Users' Expectations
Heavy security can impose a burden on users. People are becoming accustomed to greater ease of access to computer systems from across the Internet or over dial-up lines. If you impose restrictions on this type of access or completely disallow it, be prepared to explain why.
It helps if you can apply restricted access from the start. Introducing users to a secure system is much easier than imposing restrictions after users have become accustomed to a more relaxed approach. Strive to create a culture of security awareness, where users know the risks of unsafe practices. They might respond positively, policing the system themselves because they appreciate its value to them.
You might find that users are simply unwilling to accept the hassle of stringent security measures. If so, review the value of what it protects, as well as the issue of responsibility for security. If you find that it is both necessary and your responsibility, then users simply will have to accept it as part of the price of using a secure network. It is often possible, however, to implement security measures in a less intrusive way. This may involve paying more money for third-party security products with smooth user interfacesóanother price your enterprise could have to pay for a secure network.
Finding an Appropriate Security Level
Taking all these factors into account, you need to find the level of security that is most appropriate for your needs. Consider the following factors:
The last factor is extremely important. You may be able to implement a set of measures that provide a good degree of security, using only your own time and expertise. The cost of maintaining this system, though, including future revisions to meet new external demands, may be quite high. Consider the cost of the manpower it takes to maintain the security system over time, and compare this with the cost of a purchased system.
Auditing Network Security
Finally, you need to know that your security solution is working. The best way to do this is to have someone carry out an extensive security audit at frequent (but not necessarily regular) intervals.
Security audits help to raise awareness of security issues among users and administrators alike. There is a need for procedures and standards to be seen being publicly enforced. Awareness of the possibility of an imminent security audit should help to focus the minds of all concerned on their respective roles in protecting the integrity of the network.
The person conducting the audit should be a trusted security professional who understands your work environment and your security policy. The auditor should look at your network from the point of view of a hostile outsider, trying to locate weaknesses in your defenses. She should also look at the security system from within, verifying that all users and administrators are adhering to the standards necessary to maintain a secure system.
Summary
This chapter explained some of the security problems associated with network use. In particular, the growing use of external access to networks raises new issues of user authentication and data security. These issues are in addition to the factors to be considered in the case of a strictly local network, where access rights and restrictions are also crucially important.
The time and money that you spend on security measures should reflect the value of what you are attempting to protect. If unauthorized access has a commercial impact rather than just a nuisance value, it makes sense to invest heavily in a comprehensive security system. In all cases, it is vital that a structured approach be taken to the issues raised and that a formal security policy be agreed with users and policed appropriately.
