ProfitPress Mega CDROM2 …eeware (MSDOS)(1992)(Eng)/ProfitPress-MegaCDROM2.B6I/MISC/NETWORK/NETLOC11.ZIP/NETLOCK.DOC

Text File | 1991-07-29 | 26.2 KB | 573 lines

                                    NETLOCK
                                    -------
                                  Version 1.1
                  Copyright 1st July 1991. All rights reserved.
                                 Julian Byrne

Introduction
------------

NETLOCK enhances the security features of a Novell Netware network, on an
MSDOS/PCDOS workstation, to include:

- Restricting an application to run only when the user is logged in to a
  nominated file server.
- Limiting the number of simultaneous users of an application.
- Broadcasting a message to a nominated user when an application is run.
- Logging to file an application's usage.
- Password protection of an application.

It does this by modifying a copy of the binary of an application and making it
execute-only. NETLOCK is run once and thereafter whenever the application is
run the above actions will occur. Features of the program include:

- As secure as a local area network allows. The user must break network
  security to stop the above actions occurring.
- No extra memory occupied while application is running.
- Works in a complex multi-server environment where network drives are
  arbitrarily assigned to file servers.
- Can be placed in a batch file to make application upgrades easier.
- User's environment (LOGIN name, MAPped drives, access privileges and
  environment variables) is not affected.
- Password protection does not require network access.

Restrictions
------------

NETLOCK cannot be applied to applications which place overlays in the
executable binary itself. NETLOCK will tell you if this is the case.
See below for an alternative. Applications which place overlays in a separate
file CAN be protected. ".COM" files cannot be protected but by using the
public domain utility COMTOEXE they can be converted to ".EXE" form which can
be protected. The size of an application on disk is increased by about 2K but
by using the public domain utility LZEXE space can frequently be reduced to
half that of the original application. Only MSDOS (not Windows) applications
can be protected when running under Microsoft Windows. Windows support is
planned for a future release.

Requirements
------------

NETLOCK has been tested under MSDOS 3.30A with Novell Netware 2.12, 2.15 and
3.10a. It should work with MSDOS 2.00 (or PCDOS equivalent) or greater and
Novell Netware 2.0 or greater. It checks all system result codes and will let
you know if there is an error. It makes a strong effort to not silently cause
problems.

Usage
-----

The one NETLOCK program can lock an application, unlock an application, and
list an application lock log file. It determines which operation to perform
based on the file it is applied to - an ordinary application, a locked
application or a lock log file.

Usage - Locking an application
------------------------------

NETLOCK OrigAppl [Switches]          ; Original application left as "Appl.UNL"
NETLOCK OrigAppl LockAppl [Switches] ; Original application unchanged

Switches and arguments can be entered in any order. No switch is mandatory.
One or two application names must be given. The default is no application
restrictions. In the following description [] denotes an optional value, "" a
string value and | one of two possible values.

/?              List a two page usage message. Can be redirected to file.
/D              List this program documentation. Can be redirected to file.
/X              Make execute-only.
                More secure where user has access to a debugger.
                Default is non-execute-only, which is not recommended.
/U [number]     Maximum number of simultaneous users. 0 means no limit.
                Default is a limit of one.
                If /U is not specified then the default is no limit.
/L ["logfile"]  Name of log file. Default is "Application.LOG".
                If /L is not specified then the default is no logging.
                Log files should be given a non-obvious name (ie. a password)
                and placed in a directory for which the application user
                has only Write/Open/Create privileges.
/N ["address"]  Name of user to be notified by broadcast.
                Default is "SUPERVISOR".
                If /N is not specified then the default is no broadcast.
/P ["password"] Password. Not echoed when typed by application user.
                If no password is specified then one will be generated.
                If /P is not specified then the default is no password.
/F "name"|hex   Name or hex address of file server application user is
                required to be logged in to. If /F is not specified then the
                default is the file server the output file or log file is on.
                A hex address is specified with a leading decimal digit.
                A name is specified without a leading decimal digit.
/S "name"       Name of lock semaphore used to restrict simultaneous users.
                Default is randomly generated. Should be given a non-obvious
                name.

Messages output if:

/MF ["message"] Error accessing file server.
/ML ["message"] Error accessing log file.
/MA ["message"] Error accessing software lock (semaphore).
/MU ["message"] User limit exceeded.
/MP ["message"] Password is bad.
/MQ ["message"] Prompting for password.
/MS ["message"] Successful application start.
/MN ["message"] Broadcast message.

Default messages are adjusted to reflect the name of the application being
executed and the number of users it is limited to.

Locking usage examples
----------------------

To limit the number of simultaneous users of the application TEST to 10 and
make it execute-only:

        NETLOCK TEST/U10/X

This will save the original, unlocked application under the name "TEST.UNL".
It will not password protect, broadcast a message or log to file when the
application runs. To do this:

        NETLOCK TEST/U10/X/P"syzygy"/L"F:UTILITY\LOGS\TEST.LOG"/N"SUPERVISOR"

This will limit the number of simultaneous users to 10, make it execute-only,
force the user to enter the password "syzygy" when the application starts, log
every execution to "F:UTILITY\LOGS\TEST.LOG" and broadcast a message to the
supervisor. If for some reason one of these actions is not possible a message
will be displayed to the user and the application terminated.

Usage - unlocking an application
--------------------------------

NETLOCK LockAppl          ; Locked application left as "LockAppl.LOK"
NETLOCK LockAppl OrigAppl ; Locked application unchanged

NETLOCK will output the commands which were used to lock the application so
that they can be redirected to file, modified and used as a response file (see
below) to lock the application again. This is not possible if the application
has been made execute-only. Only the SUPERVISOR or equivalent on the file
server the application is locked to can unlock it. If the application is
password protected only (not tied to a file server) then any SUPERVISOR or
equivalent can unlock it.

        NETLOCK TEST > TEST.RES
        NETLOCK TEST @TEST

Assuming TEST was previously locked then these commands will unlock it and
then relock it in the same way.

Usage - listing a lock log file
------------------------------

NETLOCK LogFile > TextLogFile   ; List a log file

LogFile is converted to ASCII and stored in TextLogFile. See below for the log
file format.

Response files
--------------

Long NETLOCK command lines can be placed in response files which are accessed
using the "@" symbol:

        NETLOCK @switches

Response files can be nested to a depth of 8 and mixed with normal switches:

        NETLOCK @messages @password TEST /U10 @override

Later switches override earlier switches. Switches in a response file can be
on the same or separate lines. Messages delimited by "'s in a response file
can cross line boundaries. The default response file extension is ".RES".
Comments start with a ";" and finish at the end of a line.

For example:

;
; Sample response file
;
/U10                    ; Limit program to ten users
/L"TEST.LOG"            ; Log application runs to TEST.LOG
/P"SYZYGY"              ; Password required
/MQ"Enter password. Use Backspace to correct mistakes and Enter to finish.

        Password? "     ; A valid multiline password prompt
;
; End of response file
;

Specifying lock messages
------------------------

A message is specified using "'s eg. "Password: ". If the message contains a "
then it should be doubled eg. "A "" quote". If a message contains no spaces
or special characters then no "'s are necessary. The program has been written
with foreign language support in mind. While the messages NETLOCK itself
displays cannot be changed all messages that may be issued by the modified
application can be specified by the system manager. By placing these messages
in a response file they can be used without retyping on every application that
needs to be protected. The normal MSDOS convention of specifying an unusual
character with the ALT key and the numeric keypad (Press the ALT key, type a
1-3 digit number on the numeric keypad and release ALT) is supported. Messages
can include all ASCII/display codes from 0 to 255. They are limited to 255
characters in length. In a response file they can be multiple line, only
terminating when a second '"' is seen.

Examples:

Valid messages:           "Hello world!"
                          "Hello ""world!"""
                          Hello!
                          Hello_world!
                          SYS:PUBLIC\NDIR.EXE
Valid multiline message:  "This ""is""
                          a 3 line
                          message ""≈"""
Invalid messages:         Hello world   (Contains a space and no " delimiters)
                          Hello@world   (Contains a special character)

Making applications execute-only
--------------------------------

Since NETLOCK works by modifying an application binary it follows that a
dedicated cracker can modify the application binary to remove the protection.
This threat can be reduced by making the application "execute-only" after it
has been modified by NETLOCK. This will be done by NETLOCK itself if /X is
specified. It reduces the possibility of the application binary being read
into a debugger. Due to the insecure nature of LAN's (any and all messages,
including passwords, can be read off a LAN with the appropriate software and
a workstation) no guarantee can be given but what can be done is to make it
hard enough to crack so that it's probably not worth a cracker's time.

It may be preferable to use NETLOCK with the execute-only option disabled,
compress the application using the public domain program LZEXE and then make
it execute-only using FILER.

"Microsoft Windows" users note: Windows cannot handle execute-only
applications - to avoid this problem without compromising security create a
one line batch file which executes the execute-only application and use it as
the application name in the PIF program information file.

Logging application exit
------------------------

NETLOCK can log application entry only. If it is necessary to log application
exit also then create a batch file of the form:

        @ECHO OFF
        Application
        NOP

The application is locked as usual. NOP (No operation) is a program which
comes with the NETLOCK sources. It does nothing but exit with a status of
zero. It can be locked in the normal manner. In particular; when it was run
can be logged. This can be bypassed by running the application directly but
the system manager can look at the application logs to see if a user started
an application and the finish was not logged. It is not possible to securely
log application exit without modifying network software as the user can either
exit normally, turn off, crash or press the reset button on the workstation.
If a workstation crashes then the file server eventually (after about ten
minutes or when the workstation reboots) detects this and releases any user
limit lock in use but provides no mechanism to log application exit.

MSDOS and Novell Netware file paths
-----------------------------------

Novell Netware uses a mixture of network paths and MSDOS paths. A network path
has the form "BASIL\SYS:UTILITY\TURBO\TPC.EXE" and always refers to the same
file. An MSDOS path has the form "F:\UTILITY\FRED\TEST.EXE" where "F:" might
be any network directory on any file server, or a local drive. NETLOCK avoids
ambiguity in MSDOS paths by converting any MSDOS path specified to it's
equivalent network path so that different workstations will always refer to
the same file. Since MSDOS itself is not "network aware" files using the
network paths are automatically accessed internally via the current MSDOS
drive. This process is normally invisible but can cause problems if a program
tries to access other files simultaneously using the same drive. These
problems should not occur during normal operation of NETLOCK.

Locking unmodifiable applications
---------------------------------

If the application binary is unmodifiable, either because it contains overlays
in the executable itself or because it is a COM file which can't be converted
(eg. COMMAND.COM), then execute a command of the form:

        PATCHANY ANY.EXE ApplicationPath

PATCHANY.EXE and ANY.EXE are programs which come with the NETLOCK sources.
Once patched ANY.EXE will execute the application as a sub-process, occupying
about 700 bytes of memory while it is running. ANY can be locked as usual after
being patched, including making it execute-only. If an error occurs it will
exit with the MSDOS error status. If no error occurs it will exit with the
application's exit status. PATCHANY and ANY require the application path
(including the extension ".COM" or ".EXE") to be fully specified. Security can
be improved by giving the application a non-obvious name in a directory where
the user does not have search privileges. Any arguments given to ANY are
passed on unchanged to the application.

The application path should normally be specified as a network style path,
so that the application will be found no matter what the workstation drive
mappings are. Unfortunately, some applications are not "network aware" and
have trouble finding their own directory when this is done.

This can be avoided by:
- Specifying an MSDOS style path instead and making sure all
  workstations have the same drive mapping. If a workstation is likely to
  login to more than one file server this is difficult.
- Specifying a network style path not prefixed by the server name but prefixed
  with one of the server search drives. This causes the nominated search
  drive rather than the default drive to be used when loading the application.
  eg. "Z:SYS:PUBLIC\FILER.EXE"
- If the application binary is configurable tell it where it's directory is.
  Some Borland programs can be configured in this way.

How it works
------------

NETLOCK attaches an assembly language program to the tail end of the
application binary and modifies the application start address so that it will
be executed before the main application. This program performs the tasks
detailed above, erases itself and then starts the application as usual.
Password, log file and broadcast message are straightforward calls to the
appropriate system facilities. File logging uses the file server to determine
user name and current time. The user limit is done by opening a semaphore
(with a name which is unique to the application) on the file server specified
and checking for the current number of users of the semaphore. If the limit is
exceeded the assembly language program forces an exit. The semaphore is
implicitly closed on application exit by the network software so that it is
not necessary to occupy memory while waiting to close it explicitly.

Application lock actions
------------------------

1. Access file server
2. Get user limit lock
3. Get password
4. Update log file
5. Check user limit lock
6. Check password
7. Send broadcast message
8. Start application

If the lock fails for any reason it erases itself and forces application
termination with a status of 255. If the application starts successfully then
the exit status is whatever the application sets it to.

    1. Access file server
    ---------------------

If the lock entails any operation requiring file server access (user limit,
log, broadcast) then the lock will check if the user of the application is
currently logged into the file server specified in the lock binary. If not
then a message will be output, the lock erased and the application terminated.

    2. Get user limit lock
    ----------------------

A semaphore is opened on the file server and the number of users currently
holding it open is checked. If the user limit is exceeded the lock is
immediately released but execution continues. The semaphore name is chosen at
random so that a normal user can't close it once the application is running. A
user with console privilege can use FCONSOLE to list a connection's semaphores
and close the lock semaphore.

    3. Get password
    ---------------

If the user limit was not exceeded in step 2 the user is asked to enter a
password. It will timeout if the complete password is not entered within 30
seconds. The backspace key can be used to correct mistakes, Ctrl/C to abort
input and Enter to end input. The password is converted to uppercase and
compared with an encoded password in the application binary. If the password
is incorrect this is recorded but execution continues.

    4. Update log file
    ------------------

A record is appended to the specified log file which details the application
user, the time they logged in, the time they used the application, the current
number of users of the application, the maximum number of users and whether
the password was okay. The time is taken from the file server, not the
workstation. If there is any error (apart from a file sharing error which is
retried) accessing the log file then a message will be output, the lock erased
and the application terminated. The lock will try to update the log file a
number of times before terminating with failure.

Since the log file needs to be world writeable it is possible for any user to
modify it. This risk can be reduced by giving the log file a non-obvious name
(ie. a password) and placing it in a directory for which the application user
only has the privileges Write/Open/Create.

    5. Check user limit lock
    ------------------------

If the user limit lock in step 2 exceeds the limit then a message is output,
the lock is erased and the application terminated.

    6. Check password
    -----------------

If the password in step 3 does not match there is a delay, a message is
output, the lock erased and the application terminated. The delay is to deter
password attacks using keyboard macro programs.

    7. Send broadcast message
    -------------------------

A message is broadcast to a nominated user on the file server found in step 1
notifying him/her that the application is being used. If no nominated user is
logged on to that server or the user doesn't exist then the message is lost -
the application will continue on regardless.

    8. Start application
    --------------------

The lock is erased and the application is started.

Usage variations
----------------

Running FCONSOLE, selecting "File/Lock Activity"/"Semaphore Information"/
"Semaphore Name" and entering the name of the lock semaphore will dynamically
list all connections currently using the locked application. Unfortunately,
some versions of FCONSOLE are buggy and this may not be possible. A program
called SEMLIST is provided with the NETLOCK sources which performs this task.
SEMLIST can list all semaphores in use on a file server simultaneously.

Specifying a semaphore name without a user limit can be used to restrict an
application to a file server without limiting the number of users. This can
also be useful in conjunction with the SEMLIST program to keep track of
application usage without restricting users unnecessarily.

It is sometimes useful to restrict a program which is not network aware to one
user to stop file update problems caused by multiple users accessing it
simultaneously.

If the same lock semaphore name is used for several applications then the
total number of simultaneous users for all the applications will be
restricted. Statistical packages are typical of program suites which have
multiple applications and a restricted license for all members of the suite.

Broadcasts from an application can be turned off by using the CASTOFF command.
Some applications enable broadcasts as a side effect, limiting the usefulness
of this command. PCWrite is one such application.

Some applications cannot be effectively run off a network drive, but by
locking the application to a file server it then becomes possible to copy the
application to local hard disk and run it there while still making it
unuseable when not logged in to the file server.

It is sometimes useful to unlock an application making the output file NUL,
just to obtain the switches that were used to lock it. For example, assuming
NDIRLOCK is a locked version of NDIR then "NETLOCK NDIRLOCK NUL > NDIR.RES"
will create a response file NDIR.RES while discarding the unlocked version of
NDIRLOCK.

Log file format - binary
------------------------

16 byte header: "Lock log v1.1", ^M, ^J, ^Z

followed by a series of 88 byte fixed length records:

Offset Size Name/value Description
  1      1  LogNum     Current number of application users
  2      1  LogLim     Maximum number of application users
  3      1  Connection Connection number user used to access application.
  4      7  UseDatTim  Use Year/Month/Day/Hour/Minute/Second/DayOfWeek
 11      2  12         "Get Internet Address" record length
 13      4  NetNum     Net file server net number
 17      6  NodeNum    Net workstation physical address
 23      2  Socket     Connection socket
 25      2  62         "Get Connection Information" record length
 27      4  ObjID      Object ID of connection owner
 31      2  ObjType    Object type of connection owner (USER = Swap(1) = 256)
 33     48  ObjName    Null terminated object name of connection owner
 81      7  LogDatTim  Login Year/Month/Day/Hour/Minute/Second/DayOfWeek
 88      1  PassOk     If non-zero then password was correctly entered
 89

If (LogNum > LogLim) and (LogLim > 0) then the application itself was not
started. If (PassOk = 0) then the application itself was not started.
If (LogLim = 0) then no user limit was in force. If the lock does not require
a password then PassOk will always be non-zero.

The connection number can be used to match lock log records with system
login/logout records. Note that the network word byte order (high to low) used
in this log file is the opposite of the PC's. All word and long integer values
should have byte order swapped before display or calculation.

Log file format - text
----------------------

All fields are separated by spaces. For field descriptions see the previous
section. The MSDOS SORT command may be useful when examining this file. To
facilitate sorting and concatenation the log file contains no header.

Field Name
  1   LogNum
  2   LogLim
  3   PassOk (Not present for version 1.0 log files)
  4   Connection
  5   UseDatTim-Date
  6            -Time
  7   NetNum:NodeNum
  8   LogDatTim-Date
  9            -Time
 10   ObjName

Credits
-------

NETLOCK is written in approximately 4500 lines of Turbo Pascal v5.0
and 1000 lines of Turbo Assembler v2.0.
The EXE was compressed using LZEXE v0.91, reducing it's size by over 50%.
The editor used was PCWrite v3.01 from Quicksoft.
Turbo Pascal and Turbo Assembler are trademarks of Borland International, Inc.
MSDOS and Microsoft Windows are trademarks of Microsoft Corporation.
PCDOS is a trademark of International Business Machines.
Novell Netware is a trademark of Novell, Inc.
COMTOEXE and LZEXE are freeware written by Fabrice BELLARD. They can be found
in the Internet anonymous ftp archive simtel20 and it's mirrors, for example
the version current when this documentation was written can be found at
"wuarchive.wustl.edu" in "/mirrors/msdos/filutl/lzexe91e.zip".

Shareware
---------

Shareware gives you a chance to try before you buy. It depends on your
honesty. You may use this program for a short time to test it. Two days are
suggested. If you will then be using it regularly you are expected to pay. The
price is low given the improved functionality this program will give to your
network. Not only do the logging features allow you to determine when new
application licenses may be necessary, use of this program shows that, legally,
you are making a best effort to fulfill the licensing provisions of the
application software. By registering you can also get the most recent version
of the program, all the extra utilities and the sources. Send electronic mail
once you've registered with the subject heading "NETLOCK Registered" if you
wish to be placed on an electronic mailing list for tips, bug fixes and
updates.

To encourage you to register: The binaries and sources for a graphical network
activity monitor and a network batch job processing system totaling 2500
lines of code is included with the NETLOCK sources. The activity monitor
displays a dynamic bar graph showing the activity of all current connections
to the server. It requires console privilege to run. The batch system allows
batch jobs and print jobs to be submitted to a dedicated PC from anywhere in
the network. It also allows jobs to be run at nominated times and at regular
intervals.

See "NETLOCK /?" for the program licensing terms.

Please register now, don't just forget about it. Thanks!
                ---
Enquiries
---------

Name:     Julian Byrne
Internet: [e-mail] (preferred)
Airmail:  Normanby House, Monash University, Clayton, 3168, Australia
------------------------------------------------------------------------------
This document can be saved in a text file by entering:

        NETLOCK /D > NETLOCK.DOC