Securing NetWare 5

Graham Mulholland



Novell NetWare 5 (and the Novell Directory Service on which it is based) is sold as being a secure operating system. For the most part this is currently true in practice too although it is never safe to be complacent. There are however a number of areas which warrant closer attention, depending on your particular environment and many apply to other operating systems as well. This article is primarily concerned with things you can do to NetWare to make it more secure and not its potential attackers. However, possible motives (e.g. financial gain or information gathering) and other "soft" considerations should play an important part in helping you design security in to all your systems.



The first aspect of security is common to many network operating systems including NetWare, is well known, sometimes dealt with sensibly and occasionally misused terribly - passwords. If you don't provide a valid combination of user name and password you won't be authenticated to NDS and so able to log on to access any protected material. If someone does, whether the legitimate user of an account or not, they will be able to gain access.  So, find a valid username, guess the password (or find it written on a sticky note near the workstation) and carry on. The subject of passwords has been widely dealt with both in this journal and elsewhere so only NetWare related issues are covered here in any depth.



Remember that anything to which the Public group has at least read access will be available before any authentication takes place. This access will include the ability to see from [Root], the root of the NDS tree, downwards and so gain potentially valuable information about the structure of the network including all the organisational units (which could provide useful information about the structure of the company) and usernames.  For an example of this, start a workstation without logging on (e.g. for Windows 95 just cancel the login dialogs) and open an MS-DOS Prompt. On the command line type CX . (including a space between the CX and the dot) which should report that you are at [Root]. Then type CX /A/T and unless your security has already been tightened you will see all the objects in your NDS tree. To stop this from happening launch NWAdmin, select [Root] and then view Trustees of this Object. . . from the Object menu. Select the [Public] object and clear the Browse setting.



The primary password problem to watch for is related to remote management of the server console. Being able to remotely connect to the server and see what is happening on the server console has been a useful feature of NetWare for a long time. NetWare 5 and earlier support RConsole which works using SPX or a modem. With NetWare 5 there is the addition of a Java version called RConsoleJ which supports both TCP/IP and SPX. By default it will allow connections using either protocol so if you don't need to support both you should disable the one that is not required. Both of these utilities are usually launched either directly or indirectly from the AUTOEXEC.NCF file and a password may be used which must be supplied to gain remote access to the console.



RConsole support may be loaded in a couple of ways. If done interactively at the server console you can just use RSPX to load RSPX.NLM and then (automatically) REMOTE.NLM which will prompt for a password. To load RConsole without any intervention you will need to have two lines in a .NCF file such as AUTOEXEC.NCF. The first should be REMOTE with a password specified as a parameter and the second should be RSPX. (In this case you don't want REMOTE.NLM to be loaded automatically as there would be no way to specify a password.) The problem here of course is that the password is stored in plain text.



To get round this problem there is a facility to encrypt the password used. The first step is to load REMOTE (and give it a password when it asks). Then use the command REMOTE ENCRYPT. You can either specify a password as an additional parameter or one will be prompted for. Once this password has been entered you will be shown the encrypted version and given the option to write the appropriate commands to use it to SYS:SYSTEM\LDREMOTE.NCF which you can then call manually or from AUTOEXEC.NCF. RConsole will now be loaded, just load RSPX and it is ready for use.



When NetWare 5 is installed an entry to load the Java RConsoleJ is created almost at the end of AUTOEXEC.NCF. This sample entry tells you to enter the password directly as a command line parameter. Don't. Instead you should encrypt the password first using a procedure irritatingly different from that for RConsole. First use UNLOAD RCONAG6 to make sure the RConsoleJ server NLM (NetWare Loadable Module) is not loaded (but make sure there isn't another Admin trying to use it when you do this!) Then use RCONAG6 ENCRYPT. This will ask for a password and also for the TCP and SPX port numbers to use. You will then be offered the chance to write the appropriate command to SYS:SYSTEM\LDRCONAG.NCF. At this point RCONAG6 is not loaded, if you want to use it you will need to load it manually, possibly by using the .NCF file you have just created.



These encrypted passwords are a good start. There are tools available which will attempt to decrypt the password but none currently seem to work with the versions of RConsole shipped with NetWare 5. In order to decrypt the RConsole password, a would-be attacker would first need to get hold of it. They could do this by attaching a packet sniffer to your network. Alternatively, they could try and get hold of the LDREMOTE.NCF and LDRCONAG.NCF files. These are normally written to SYS:SYSTEM so ordinary users will not have any access to them by default. Take care over who does get any access to this directory since it contains important configuration information for the server which could be subverted or corrupted. File system security is mentioned again later.

Controlling the console remotely has already been covered but what about using the console locally? This moves on to the subject of physical security. Keep your server somewhere safe. With earlier versions of NetWare you couldn't do that much in the way of user or file system administration from the server. NetWare 5 includes the ConsoleOne tool which gives access to NDS, allowing the creation or modification of users for example, and you can also access the filesystems on the server. To access NDS it is necessary to enter a valid username and password but this is not necessary for filesystem access. This means that files can be created, moved, edited or deleted without having to provide any authentication. If an administrator had been using ConsoleOne and not closed it when they finished, access to NDS could also be gained. If you can't keep the server somewhere physically secure and with restricted access, always close ConsoleOne if you use it and lock the server console.



Activity at the console prompt itself may be monitored using CONLOG. Load this NLM at the start of the AUTOEXEC.NCF file and it will write everything that happens on the system console screen to the file SYS:ETC\CONSOLE.LOG. Be aware that anyone who attacks the server console, either locally or remotely will probably want to subvert this file in order to cover their tracks. It is possible to specify a different filename for the log but it should still be watched carefully. Look out for the file being deleted, odd gaps between server messages and for messages about the Console Log being started when it should have been running already. One potential problem is that if an attacker generates lots of console messages, perhaps by launching a malformed NCP (NetWare Core Protocol) attack using Pandora (a suite of tools described later) then the console log file could cause the SYS volume to fill up which would in turn cause the server to stop functioning. This could represent a fairly effective denial of service (DoS) attack although a potential method of preventing it is described later. You'll know roughly what happened but not until too late.



Previously, the console was locked through MONITOR which also provided the red snake screen saver. With NetWare 5 this has been moved to a separate program - SCRSAVER. Use SCRSAVER STATUS and ensure that the screen saver is enabled, that it will lock the screen and that it won't unlock without a password. To activate the snake without waiting for the inactivity timer, use SCRSAVER ACTIVATE. To unlock the console it will then be necessary to provide a username and password combination that has the Supervisor right for the server object in NDS. Normal user accounts should only have the Browse right.



Typically, although you should be able to control the area the servers are in it will be much harder to control the rest of the network environment. It will probably be impossible to detect a competent person running a packet sniffer on the network. The degree of success they have will depend on the network topology since technologies such as switched Ethernet will stop a sniffer from picking up any traffic not on the same segment. It is possible to get tools which will watch for previously unknown workstations transmitting on the network since these may well be a cause for concern. By default users may log in from any workstation but NetWare allows you to restrict which workstations may be used. This may be done by specifying which network address (IPX, TCP/IP, Ethernet, etc.) the user may log in from. Remember though that some types of address, TCP/IP in particular, are very easy to reconfigure. It is usually harder but not impossible to change the Ethernet (MAC) address of a network card, whether this is supported will depend on the network card the attacker has available to them.



You will of course have your file system configured to prevent unauthorised access to any file. If you are one of the majority of organisations which keeps backups of its important data, do you also keep good physical control of the backup media you use? This is essential since it provides another method of gaining access to your data. Even if the software you use allows you to specify a password for the backup session the data on the tape probably won't be encrypted and so could be vulnerable.



File system security is managed through rights, inheritance and attributes. Files on the server are protected both by a requirement for users to be granted rights to files and directories so that they can use them and also by additional attributes on the file and directories.



Wherever possible, assign rights to groups or organisational role objects rather than to individual users. If there is no obvious group or role to use consider whether you should create one for the purpose. Organisational Roles are a particularly useful tool for simplifying administration.



Design for high security at the highest directory levels and then only relax restrictions further down the directory tree. Plan to use inheritance rather than explicit assignments as far as possible and avoid granting erase rights high in the directory tree. Remember always that the Supervisor file system right cannot be blocked by an inherited rights filter.

 

Auditing within NetWare allows people independent of the normal system administrators and users to check what auditable events or transactions have happened. Such events may include file or directory events such as the deletion or salvage of files. Server events include volume mounts and dismounts, security rights changes and the server going down. The final type of events audited are NDS events such as object creation or modification, security equivalence changes and user logins and logouts. All the events which are logged are added to an audit trail.



The audit trail is made up of an Audit File object in NDS and a number of audit data files. There is a current data file, up to fifteen previous online files and then any number of offline data files as required. The rights to the Audit File object determine which other NDS objects (primarily users) which can have access to the audit data files. You cannot access the properties of the Audit File object from within NWAdmin. Once the auditors account has been created it is normally expected that the auditor will be able to configure which events are to be logged and this is carried out using the AUDITCON utility (found in SYS:PUBLIC)



There are two types of audit record, audit history records which include viewing or configuring the audit trail and audit event records which contain user actions which were recorded by the server or a client. There are then volume, container and external audit trails, the latter providing a means for trusted clients to stored audit data on the server.



Remember that if you don't log something you can't go back and find out what happened afterwards. An audit trail may be of great use in identifying the damage done by someone to the network. In some circumstances it may be possible to use the audit trail to back out the changes made, at the very least it may be easier to repair damage if you know exactly what was done to cause it.



There are two ways of handling audit events which may be used independently but will normally be used together. Post-processing or filtering allows an auditor to select what type of events to view from the log, rather than having to trawl through them all. However, as previously mentioned, if something isn't in the log you won't be able to find it later. You can limit what goes in to the log using preselection to specify particular types of event which you do want to see, such as when a specific user performs an action on a file rather than when any user does something with it.



If you do have an independent person performing the auditing, make sure that the auditor reads the documentation too! Remember to use a more imaginative and less obvious name for the auditor user account than "auditor" otherwise you are providing a fairly obvious point to attack. This is also true if the auditor uses their own user account. You might consider creating an auditor Organisational Role object and using that to assign the appropriate rights. 

 

There are many tools available to attack NetWare 3 in a variety of interesting ways such as granting Supervisor rights to all users. Some of these also worked with NetWare 4 and there were a number of tools produced to attack NDS. By the time you get to NetWare 5 the number of tools available to mount an attack is reduced but they are still available. The most widely known and up to date is the Pandora suite. 



The Pandora suite, available from www.nmrc.org, is currently in up to version 4 (as a beta at time of writing). Two sets of tools are available, one for obtaining passwords offline and one to perform online attacks against a server. Both sets are available for the Windows platform, the offline tools are available for Linux with the offline tools being in development.



The offline tools allow you to crack passwords both from NDS and for RConsole. Remember earlier I described how to encrypt the passwords which RConsole uses? There is a function which will decrypt them. This makes it even more important that you prevent anyone from finding the password and could be taken to suggest that you shouldn't use RConsole. It doesn't currently decrypt RConsoleJ passwords but it is probably not unreasonably paranoid to expect that this will be added in due course.



To crack NDS passwords it is necessary to get hold of the NDS files in some form. This is dead easy if you (or an attacker) can gain access to the server console either remotely or locally. Simply run DSREPAIR, go to the Advanced Options menu and then select Create A Database Dump File. If the person doing this doesn't yet have access to an account which can read the SYS:SYSTEM directory they will need to save the file to somewhere other than the default location or use ConsoleOne to move it afterwards.



Once the dump file has been extracted to somewhere usable (and then preferably copied off on to a workstation) it can be loaded. The various DS files are extracted and you can start to look for passwords. Both dictionary and brute force attacks are supported. You will have to go and find a dictionary on the Internet but there are many available. On a 200MHz Pentium, the brute force cracking routine will try in the region of 200000 passwords per second under Windows 95 for a six character alpha-only password. Shorter passwords are found very quickly indeed, longer passwords and those with numbers and punctuation as well will obviously take a little longer but will still be found.



If an attacker cannot gain access to the server console (and they shouldn't be able to if your physical security is adequate and you don't use any remote console services) then they will have to resort to other means to get the NDS files. The easiest will probably be to get hold of a recent backup, restore it on to their own server and then extract the passwords at leisure. This might be difficult for an external attacker but might be easy for someone internal to the company.  Just because passwords can be cracked doesn't mean they are entirely useless. The steps which are required to crack passwords are not trivial and require a certain amount of time, expertise and access to order to carry them out. However, once your directory services database has been compromised you are effectively open to varying levels of damage until all the passwords can be changed. The only possible comfort might be if they obtained the NDS files from a server which did not hold an NDS partition containing any Admin or equivalent accounts. They way they could only gain the same levels of access as the users in that partition. 

For the moment, consider that attacks may come from one of four directions: physical, console, the network via. IP or the network via. IPX. The first two we have largely dealt with already. NetWare 5 supports an IP-only environment but many sites will still be using IPX or a mixture of both protocols to support legacy devices. 



The problem at the foundation of the network attacks is that the NetWare Core Protocol, the protocol used by NetWare to gain access to functions on the server, can be spoofed. This means that it is possible to pretend to be someone you are not. This technique can then be used by an attacker to gain more rights than they are supposed to have. Done properly, an administrator's session may be subverted so that some or all of the accounts on a server may be given supervisory rights. Most of the existing network attacks are based on IPX so moving to a pure IP environment with NetWare 5 is enough to defeat them. However the same NCP is used over both IP and IPX and combined with the  fact that the method of generating IP packet sequence numbers is very simple (just add one each time) means that it should be possible to migrate many attacks to use IP instead.



To try and minimise the possibility of hijacking a session over IPX a process called packet signing was implemented. There are four levels of packet signature which can be selected at both the server and the client. Both ends do not necessarily need to be at the same level to communicate.



Level 0: Do not use packet signatures

Level 1: Use packet signatures if the other end asks for them (the default)

Level 2: Use packet signatures if the other end will allow them

Level 3: Use packet signatures and don't communicate if the other end won't



Level 1 is the default for both the client and server. Setting both ends to level 3 is highly recommended and will protect against most forms of attack. Add the line 

SET NCP PACKET SIGNATURE OPTION = 3 to the beginning of the AUTOEXEC.NCF (or STARTUP.NCF) file. This must be done before DS.NLM (the Directory Services module) is loaded for it to be effective. You should make sure that DS.NLM is the latest version but since you will be keeping up to date with patches this will be the case anyway. . .  The SET option and the loading of DS.NLM should both happen before the network cards and protocols are bound together although this is the default behaviour so you should not need to take any further action for this to happen.



The online attacks may cause a denial of service, either by simply flooding the network with traffic (crude but possibly effective) or by sending packets to the server which get logged, filling the volume holding the log file and stopping the server. To prevent the log from growing that large, go to MONITOR, Server Parameters, Error Handling and then review the maximum log file size settings. Also check the Log File State is at the default of 1. This means that if the file grows past the size limit it will be deleted. This entails a compromise since an attacker could do something which was logged and then fill the log file so that it is deleted automatically, removing the details of what they had done.



Whilst checking SET options, look at Allow Unencrypted Passwords in the Miscellaneous section. This should be set to the default which is Off. If it is On this may be due to an old device somewhere on the network. If there is no documentation as to what device requires this setting (and no responsible person in the organisation can remember) consider turning it off and waiting to see what breaks. Not an ideal solution but at least you should find out where the problem lies. If you are using IPX, the NCP section includes a parameter called Enable IPX Checksums. Setting this to 2 which will require IPX packets to include a checksum. This does not increase security particularly but may make spoofing slightly more difficult.



A SET parameter which doesn't appear in MONITOR is SET CHECK EQUIVALENT TO ME. The default is OFF and should be set to ON (in AUTOEXEC.NCF). Settings this on slightly improves security but may possibly affect communications performance if many checks need to be done.



On the client side, modify the Client32 properties Advanced Settings tab so that Auto Reconnect Level is zero (do not auto reconnect) and Signature Level (effectively the packet signature level) is three. Unless you have additional software in place which can enforce such settings it is relatively easy for users to change these parameters however most will not even think of trying to do so. The ones which might try and make changes are possibly out to cause trouble anyway.





Many of the network attacks rely on a workstation or other device being able to "sniff" or obtain traffic from the network which isn't destined for it. The implementation of networking technologies such as switched Ethernet generally removes this possibility as well as providing an increase in network performance. An alternative method of reducing the risk of sniffing on a network is to isolate all administrative workstations on to a separate LAN segment and never allow an administrator to log on to a workstation connected to the untrusted network. This will probably require the installation of an additional network card in the server or it may be possible to use a router to suitably segment the network. What it may mean however is that a would-be attacker will just have to change their method of approach. 



As NetWare moves in to the IP world, a number of new attacks may start being at least a potential problem. The TCP/IP stack included with NetWare 5 is reasonably well protected against many of the more common DoS attacks. Some attacks cannot be prevented entirely since they involve simply throwing as many packets as possible at the server in the hope that it will fall over or at the very least that the network will be saturated and unusable.



One common TCP/IP DoS attack is to keep sending SYN requests to a server which to indicate that a client wishes to start a conversation but never actually continue the dialogue. On some systems this would have meant that the system would keep trying to accept new connections which would never be used until it couldn't open any more, making the system unavailable. If the TCP Defend SYN Attacks parameter is set to ON (the default is OFF), This won't be able to happen because once there is a certain level (configurable) of connection backlog as more requests for connections are received so unused connections will be dropped. Be aware that this feature may be prone to false triggering if the server is very heavily loaded and unable to process legitimate requests quickly enough. 



An attack tool called Land may sometimes be used to attempt to crash or hang a machine. It tries to do this by sending spoofed packets with invalid information to the machine such as the source and destination address both being the same. Setting TCP Defend Land Attacks to ON (the default) protects against this type of attack.



Another attack which is occasionally tried against systems is called Teardrop. This relies on problems which existed on some operating systems in the way that IP packet fragments were re-assembled when fragments that overlapped were received. Novell's TCP/IP stack has not been vulnerable to this for quite some time, if ever.



So, to pull everything together, what do you need to do? Make sure:

o  Passwords are used sensibly

o  Packet signatures are set to the highest level possible

o  Avoid using remote console management if you can, use RConsoleJ over IP if you can't

o  Unauthorised access to servers is prevented

o  Backups are kept securely

o  Systems are up to date with the latest service packs and patches



Remember that this is not an exhaustive list, new threats are emerging all the time and your own situation will dictate what steps you can take and what compromises you and your organisation will have to make and accept. Security should be about both availability and integrity. Protect against attacks which will prevent legitimate users from going about their business. Ensure that the data held on your servers is safe from unauthorised viewing or modification. Remember to do this every day. 



Be paranoid about threats before they happen not afterwards. Always be on the look out for information on new vulnerabilities and fixes for them. For general security information on a range of platforms keep an eye on www.securityportal.com. This site includes archives of a number of security-related mailing lists. Join the appropriate newsgroups and mailing lists for the platforms you have to support since a hole in another part of your network could potentially cause problems, directly or indirectly, for your NetWare servers too.



Graham Mulholland (grahamm@cix.co.uk) works in the IT training industry.