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

Section 12

For Administrators Only

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

12-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 <connection number> 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.1 -
------------------------

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.1, 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.

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

12-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. 

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

12-3. I have xxx setup and xxx version running. Am I secure?

This question has been coming up lately. A lot. Admins asking me if their
sites are secure. Here is an example from a post to one of the Netware
newsgroups with my comments, as it is generic enough to apply to a number
of locations (in other words, no you are not 100% secure):

>Here is the scenario:  A supervisor of a network suspects that he may
>be facing termination of employment in the near future.  He is embittered
>and aggravated.  As system administrator for the network, he oversees
>the computers that track all business actions.  Basically, he can bring
>the organization to it's knees in a heartbeat, and he knows it.  He has
>made comments in passing that it is possible that either time bombs have
>been set in the system, or that a possible "Dead-man's clutch" may exist
>(if he's not there to disable some mechanism daily/weekly the system will
>be compromised).  

Not nearly as easy to set up in the environment you've specified. However,
I'd let that rumor continue so as to waste your time looking for a
dead-man's clutch. In the meantime, I'd be stealing stuff from those
databases and selling them to the competition.

>Here is the tech specs: A Novell 3.12 server that serves databases, email
>and user files to 30 PC's running Windows 3.1.  The network is attached 
>to the Internet.  No OS's other than DOS/Windows and Novell.  The 
>network is attached to a larger network that is very accessible to the
>public (via physically attached machines, and the Internet).  There 
>are no firewalls.  The supervisor is the only person with supervisor
>password/privileges on the server, as well as the only person who knows
>the details of the network, the server disk layout, the server nlm's.
>Basically the only person who has been inside the server which is such
>a vitally mission critical system.  
>
>Here's what I have so far:
>        1. quarantine the 30 node network and server by physically
>           disabling it's Ethernet access to the outside world.

This is an interesting step. However your problem returns once you
re-attach.

>        2. make a full system backup of the server before touching
>           investigating or touching anything.

If a problem occurs and you restore your backups, any virii, trojans,
and other back doors will get back into the system.

>        3. "secure" the Novell server (see below)

Read my hack FAQ. ftp://ftp.fastlane.net/pub/nomad/nw/faq.zip

You see, if I were to leave a backdoor, I would leave several. 

1) I would run BINDFIX and then run a bindery cracker on ALL accounts
on the server against the .OLD bindery files. I would use
ftp://ftp.fastlane.net/pub/nomad/nw/bindery.zip to do this, along with
a huge word list. This should not only get me most passwords on the
system, but get automated passwords as well. For example, Arcserve
5.01g installs an account called CHEY_ARCHSVR with station restrictions
and a password of WONDERLAND. I'd remove the station restrictions and
either use SUPER.EXE to set up CHEY_ARCHSVR as a toggled Supe account,
or just make it plain old Supe equivalent. Most people do not check 
these kinds of accounts.

2) I would install the alternate LOGIN.EXE and PROP.EXE to give myself
a way to see new passwords that have been changed. These files can be
found at ftp://ftp.fastlane.net/pub/nomad/nw/nwl.zip, details in the
FAQ.

3) I would delete all zero length personal login files (see the FAQ for
why).

4) Any logins (such as the one possibly used by an SMTP gateway) which
would be normally restricted would be toggled with SUPER.EXE. GUEST
would be toggled.

5) Message files (such as the ones used in displaying error messages)
would be hacked so that security violations would display harmless
messages.

>        4. "secure" all PC's (see below)

I would install keystroke grabbers on a number of machines, like those
found at ftp://onyx.infonexus.com/pub/ToolsOfTheTrade/DOS/KeyLoggers/

>        5. erect a firewall disabling IPX passage into the network
>           but allowing TCP/IP (email services required).

I would use some of these "very public" machines and install a sniffer,
and I would use NetCat to redirect port 25 traffic to a particular
address to a different machine's telnetd, bypassing the firewall.
ftp://onyx.infonexus.com/pub/ToolsOfTheTrade/Unix/nc100.tgz for NetCat.

With the sniffer it could be possible to get the RCONSOLE password.
See ftp://ftp.fastlane.net/pub/nomad/nw/rcon*.zip for details.

I would make sure that IP is on my server, and make sure XCONSOLE is
running. Once past the firewall, I'd telnet to the server's IP
address and run either X11 or VT100 remote console sessions with the
server.

>        6. notify the supervisor that he is fired, and take whatever
>           actions are necessary to keep him from coming in physical
>           contact with the network.

If planned ahead, the supe will have his/her backdoors in place, and this
will not matter. In fact, s/he will probably MAKE SURE that they do not
even look at a machine.

>There's a gotcha,  getting the supervisor password.  It would be
>ideal to inadvertently get it, but thats a long shot.  The system 
>administrator will probably have to be asked for it at step 6, whether
>he gives it to us is IMHO unlikely.  

The FAQ tells how you can recover from this easily.

Remember, you've eliminated social engineering from your checklist. I'd
attach a modem to a PC for PCanyWhere and then call up stating, "I'm the
vendor your ex-employee hired to dial in and check blah-blah. If I were
you I'd change my dial-in password." Once in (in the middle of the night)
I'd activate a backdoor and proceed to make your competitor rich.

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