secure my server

13-1. How do I secure my server?

This question is asked by administrators, and I'm sure no hackers will read this info and learn what you admins might do to thwart hack attacks ;-)

One thing to keep in mind, most compromises of data occur from an employee of the company, not an outside element. They may wish to access sensitive personnel files, copy and sell company secrets, be disgruntled and wish to cause harm, or break in for kicks or bragging rights. So trust no one.

Physically Secure The Server -
------------------------------

This is the simplest one. Keep the server under lock and key. If the server is at a site where there is a data center (mainframes, midranges, etc) put it in the same room and treat it like the big boxes. Access to the server's room should be controlled minimally by key access, preferably by some type of key card access which can be tracked. In large shops, a man trap (humanoid that guards the room) should be in place.

If the server has a door with a lock, lock it (some larger servers have this) and limit access to the key. This will secure the floppy drive. One paranoid site I know of keeps the monitor and CPU behind glass, so that the keyboard and floppy drive cannot be accessed by the same person at the same time.

If you only load NLMs from the SYS:SYSTEM directory, use the SECURE CONSOLE command to prevent NLMs being loaded from the floppy or other location.

A hacker could load a floppy into the drive and run one of several utility files to gain access to the server. Or they could steal a backup tape or just power off the server! By physically securing the server, you can control who has access to the server room, who has access to the floppy drive, backup tapes, and the System Console. This step alone will eliminate 75% of attack potential.

Secure Important Files -
------------------------

These should be stored offline. You should make copies of the STARTUP.NCF and AUTOEXEC.NCF files. The bindery or NDS files should be backed up and stored offsite. All System Login Scripts, Container Scripts, and any robotic or non-human personal Login Scripts should be copied offline. A robotic or non-human account would be an account used by an email gateway, backup machine, etc.

Compile a list of NLMs and their version numbers, and a list of files from the SYS:LOGIN, SYS:PUBLIC, and SYS:SYSTEM directories.

You should periodically check these files against the originals to ensure none have been altered.

Replacing the files with different ones (like using itsme's LOGIN.EXE instead of Novell's) will give the hacker access to the entire server. It is also possible that the hacker will alter .NCF or Login Scripts to bypass security or to open holes for later attacks.

Make a list of Users and their accesses -
-----------------------------------------

Use a tool like Bindview or GRPLIST.EXE from the JRB Utilities to get a list of users and groups (including group membership). Once again, keep this updated and check it frequently against the actual list.

Also run Security (from the SYS:SYSTEM directory) or GETEQUIV.EXE from the JRB Utilities to determine who has Supervisor access. Look for odd accounts with Supervisor access like GUEST or PRINTER.

It is also a good idea to look at Trustee Assignments and make sure access is at a minimum. Check your run from Security to see if access is too great in any areas, or run TRSTLIST from the JRB Utilities.

Security will turn up some odd errors if SUPER.EXE has been run. If you are not using SUPER.EXE, delete and rebuild any odd accounts with odd errors related to the Bindery, particularly if BINDFIX doesn't fix them yet the account seems to work okay. If a hacker put in a backdoor using SUPER.EXE, they could get in and perhaps leave other ways in.

Monitor the Console -
---------------------

Use the CONLOG.NLM to track the server console activity. This is an excellent diagnostic tool since error messages tend to roll off the screen. It will not track what was typed in at the console, but the system's responses will be put in SYS:ETC\CONSOLE.LOG. When checking the console, hit the up arrow to show what commands were last typed in.

While this won't work in large shops or shops with forgetful users, consider using the SECUREFX.NLM (or SECUREFX.VAP for 2.x). This sometimes annoying utility displays the following message on the console and to all the users after a security breach:

"Security breach against station DETECTED."

This will also be written to an error log. The following message is also written the the log and to the console:

"Connection TERMINATED to prevent security compromise"

Turn on Accounting -
--------------------

Once Accounting is turned on, you can track every login and logout to the server, including failed attempts.

Don't Use the Supervisor Account -
----------------------------------

Leaving the Supervisor logged in is an invitation to disaster. If packet signature is not being used, someone could use HACK.EXE and gain access to the server as Supervisor. HACK spoofs packets to make them look like they came from the Supervisor to add Supe equivalence to other users.

Also, it implies a machine is logged in somewhere as Supervisor, if it has been logged in for more than 8 hours chances are it may be unattended.

Use Packet Signature -
----------------------

To prevent packet spoofing (i.e. HACK.EXE) enforce packet signature. Add the following line to your AUTOEXEC.NCF -

SET NCP PACKET SIGNATURE OPTION=3

This forces packet signature to be used. Clients that do not support packet signature will not be able to access, so they will need to be upgraded if you have any of these clients.

Use RCONSOLE Sparingly (or not at all) -
----------------------------------------

When using RCONSOLE you are subject to a packet sniffer getting the packets and getting the password. While this is normally above the average user's expertise, DOS-based programs that put the network interface card into promiscuous mode and capture every packet on the wire are readily available on the Internet. The encryption method is not foolproof.

Remember you cannot "detect" a sniffer in use on the wire.

Do NOT use a switch to limit the RCONSOLE password to just the Supervisor password. All you have done is set the password equal to the switch. If you use the line "LOAD REMOTE /P=", Supervisor's password will get in (it ALWAYS does) and the RCONSOLE password is now "/P=". Since the RCONSOLE password will be in plain text in the AUTOEXEC.NCF file, to help secure it try adding a non-printing character or a space to the end of the password.

And while you can use the encryption techniques outlined in 02-8, your server is still vulnerable to sniffing the password.

Move all .NCF files to a more secure location (3.x and above) -
---------------------------------------------------------------

Put your AUTOEXEC.NCF file in the same location as the SERVER.EXE file. If a server is compromised in that access to the SYS:SYSTEM directory is available to an unauthorized user, you will at least have protected the AUTOEXEC.NCF file.

A simple trick you can do is "bait" a potential hacker by keeping a false AUTOEXEC.NCF file in the SYS:SYSTEM with a false RCONSOLE password (among other things).

All other .NCF files should be moved to the C: drive as well. Remember, the .NCF file runs as if the commands it contains are typed from the console, making their security most important.

Use the Lock File Server Console option in Monitor (3.x and above) -
--------------------------------------------------------------------

Even if the RCONSOLE password is discovered, the Supe password is discovered, or physical access is gained, a hard to guess password on the console will stop someone from accessing the console.

Add EXIT to the end of the System Login Script -
------------------------------------------------

By adding the EXIT command as the last line in the System Login Script, you can control to a degree what the user is doing. This eliminates the potential for personal Login Script attacks, as described in section 03-6.

Upgrade to Netware 4.11 -
-------------------------

Besides making a ton of Novell sales and marketing people very happy, you will defeat most of the techniques described in this faq. Most well-known hacks are for 3.11. If you don't want to make the leap to NDS and 4.x, at least get current and go to 3.12.

Check the location of RCONSOLE.EXE -
------------------------------------

In 3.11, RCONSOLE.EXE is located in SYS:SYSTEM by default. In 3.12 and 4.1 it is in SYS:SYSTEM and SYS:PUBLIC. You may wish to remove RCONSOLE.EXE from SYS:PUBLIC, as by default everyone will have access to it.

Remove [Public] from [Root] in 4.1's NDS -
------------------------------------------

Get the [Public] Trustee out of the [Root] object's list of Trustees. Anyone, even those not logged in, can see virtually all objects in the tree, giving an intruder a complete list of valid account names to try.

Don't use Novell's FTP NLM until it is fixed, or use NFS namespace -
--------------------------------------------------------------------

Since Novell's FTP NLM has some problems, only use the FTP NLM if you can use NFS namespace. For the extra paranoid, use a third party NLM. Novell's is the only one I've found with this problem.

--------------------------------------------------------------------------------

13-2. I'm an idiot. Exactly how do hackers get in?

We will use this section as an illustrated example of how these techniques can be used in concert to gain Supe access on the target server. These techniques show the other thing that really helps in Netware hacking - a little social engineering.

Exploitation #1
---------------

Assume tech support people are dialing in for after hours support. Call up and pose as a vendor of security products and ask for tech support person. Called this person posing as a local company looking for references, ask about remote dial-in products. Call operator of company and ask for help desk number. Call help desk after hours and ask for dial-in number, posing as the tech support person. Explain home machine has crashed and you've lost number.

Dial in using the proper remote software and try simple logins and passwords for dial-in software if required. If you can't get in call help desk especially if others such as end users use dial-in.

Upload alternate LOGIN.EXE and PROP.EXE, and edit AUTOEXEC.BAT to run the alternate LOGIN.EXE locally. Rename PROP.EXE to IBMNBIO.COM and make it hidden. Before editing AUTOEXEC.BAT change the date and time of the PC so that the date/time stamp reflects the original before the edit.

Dial back in later, rename PROP.EXE and run it to get Accounts and passwords.

Summary - Any keystroke capture program could produce the same results as the alternate LOGIN.EXE and PROP.EXE, but you end up with a Supe equivalent account.

Exploitation #2
---------------

Load a DOS-based packet sniffer, call the sys admin and report a FATAL DIRECTORY ERROR when trying to access the server. He predictively will use RCONSOLE to look at the server and his packet conversation can be captured. He will find nothing wrong (of course).

Study the capture and use the RCON.FAQ to obtain the RCONSOLE password. Log in as GUEST, create a SYSTEM subdirectory in the home directory (or any directory on SYS:). Root map a drive to the new SYSTEM, copy RCONSOLE.* to it, and run RCONSOLE. Once in try to unload CONLOG and upload BURGLAR.NLM to the real SYS:SYSTEM. Created a Supe user (i.e. NEWUSER) and then typed CLS to clear the server console screen.

Log in as NEWUSER. Erase BURGLAR.NLM, new SYSTEM directory and its contents. Run PURGE in those directories. Turn off Accounting if on. Give GUEST Supe rights. Set toggle with SUPER.EXE for NEWUSER. Run FILER and note SYS:ETC\CONSOLE.LOG (if CONLOG was loaded) owner and create date, as well as SYS:SYSTEM\SYS$ERR.LOG owner and create date. Edit SYS:ETC\CONSOLE.LOG and remove BURGLAR.NLM activity, including RCONSOLE activity. Edit and remove RCONSOLE activity from SYS:SYSTEM\SYS$ERR.LOG as well. After saving files, run FILER and restore owner and dates if needed. Run PURGE in their directories. Logout and login as GUEST and set SUPER.EXE toggle. Remove NEWUSER Supe rights and logout. Login as NEWUSER with SUPER.EXE and remove GUEST Supe rights. Finally logout and login as GUEST with SUPER.EXE and turn on Accounting if it was on.

Summary - You have created a backdoor into the system that will not show up as somthing unusual in the Accounting log. Login as GUEST using SUPER.EXE and turn off Accounting. Logout and back in as NEWUSER with SUPER.EXE, do what you need to do (covering file alterations with Filer), and logout. Log back in as GUEST and turn on Accounting. The NET$ACCT.DAT file shows only GUEST logging in followed by GUEST logging out.

Exploitation #3
---------------

You do a web search and find DSMAINT.NLM on a Novell web site. You download it.

Using Fetch, you access ftp.nmrc.org's Novell InterNetware server. You discover that you can gain access to everything on the SYS volume. You upload DSMAINT.NLM to SYS:SYSTEM, and upload an edited LDREMOTE.NCF file. This NCF file unloads CONLOG.NLM, unloads and reloads the REMOTE.NLM with a password of YOUR choosing, and loads XCONSOLE.NLM.

After a reboot of the server (which you assisted with a SYN flood to overload buffers), the remote console password has been reset to one of your choosing. Telnet to ftp.nmrc.org and use your password. If your machine supports X Windows, you could choose that, but you use VT-100 instead since it creates less network traffic.

You load DSMAINT.NLM and choose the Prepare for upgrade option. It looks nasty because of the VT-100 representation of the color screen, but in a few minutes, it is complete. An offshoot of the DSMAINT process is the creation of BACKUP.DS in the SYS:SYSTEM directory. Within a few minutes, Fetch is used to retrieve BACKUP.DS. This file contains all of the account names and passwords. The passwords are in encrypted form, but this is enough to log in. So you start writing an exploit to do just that, plus a brute force attack to get ALL of the passwords, including Admin's....

--------------------------------------------------------------------------------