06-1. Where can I get the Netware APIs?
06-2. Are there alternatives to Netware's APIs?
07-1. How do I secure my server?
07-2. I'm an idiot. Exactly how do hackers get in?
Section 06
Stateside call 1-800-RED-WORD, it's $50 USD, and includes a 2-user license of Netware 4.1. Most brand-name compilers will work, but if you're writing NLMs you'll need Watcom's latest. It's the only one I know of that will do NLM linking.
Visual ManageWare by HiTecSoft (602) 970-1025
This product allows development of NLMs and DOS EXEs using a Visual Basic type development environment. Runtime royalty-free development without C/C++ and without Watcom. However links are included for C/C++ programs. The full SDK including compilers is USD$895.00. Pricey but looks good, I have not used this product.
Here is Teiwaz' edited report on the other -
Here is another source for 'c' libs for Netware. He sells both DOS / Windows style libs. The Small memory model size for DOS, a bit of source is free.
FTP
oak.oakland.edu/SimTel/msdos/c/netclb30.zip
Public Domain Small Mem Model Lib
Author
Adrian Cunnelly - adrian@amcsoft.demon.co.uk
Price
the current price in US Dollars is:
38 Dollars - All model libraries + windows DLL
110 Dollars - Above + Source Code
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.
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.
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.
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.
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
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"
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.
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.
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.
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.
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.
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.
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.