FAQSEC- Security for Sysops        Dated: 02 MAY 98

Hello all!  Since we have been discussing a few items of security, here is
some general advice for setting up a more secure system.  Much of it will be
applicable to any BBS software so feel free to share the info about.

To start with, TG is a _very_ secure system.  It has no backdoors or known
security flaws in the current release.  What it does share with every other
software, is the ability for the sysop to change the native settings in ways
which may not be as safe as intended.  

1. Lets start with the archive conversion feature.  Note in TG3.09G1, this is
set to be a sysop s250 option by default.  Unless you really need it, remove
it.  There are external programs such as THDPRO which will scan for viruses
and convert archives at the same time.  If you must keep it, you want to leave
it set to s255.  No one but the sysop should be converting archives on your
system. Now that was easy eh?  The rest will be just as easy to do.

2.  Sysop access level.  This is an area where you will be best off if
devious.  Do you use the computer always at home?  If so, there is no need to
allow non-local keyboard access with that account.  If you set SYSOP access to
s255xL, no one can gain that access unless sitting at your local keyboard.

        a.  Devious trick #1, set the actual Sysop account to s50 then when
        you use it, hit alt-S to raise it to s255.  This works even if you
        do need to allow the account to login remotely, but wont allow you
        to remotely raise it's level to s255.  IE:  You will have normal user
        access if you login remotely and so will anyone else if they manage to
        figure out your system passwords.

        b.  Devious trick #2, dont use the main sysop account for other than
        sysop functions.  Make a second account in your real name, with handle
        if preferred, and set it basically at normal validated levels.  Mine
        is set to s50 for normal validated users, and my main account is s60
        with no extra ability except more logons per day and 10 hours time a
        day.  At the local keyboard, I can always raise it to S255 if needed.

3.  Co-sysops and access levels.  Now there are extremely reliable co-sysops
and very good reasons for having them.  I understand and most others do also,
but the new sysop does need to be aware that co-sysop access can be a
security problem.  When possible, this is the secure way to go about it:

        a.  Dont have any unless you really NEED one.  IE:  Don't use it as a
        reward for being your 'best buddy'.

        b.  If they live with you, or where the computer is, set their access
        to include the xL command.  This means 'local keyboard only' and will
        prevent anyone from dialing in as them and doing damage to your
        system.

        c.  Give them no more access than they *must* have to do their job.
        If they only remotely login to handle their messages, consider 2
        accounts just like in the sysop example above.

4. Look to the WFC screen and note almost every sysop function is there.  If
you really want to drive someone crazy, remove the sysop menu access from all
menus.  If it just isnt there, it *cant* be used against you.

5.  Passwords.  Encryption.  Use it.  This protects both you and your callers
in the unlikely event someone manages to get ahold of your user information
files.

        a.  Be aware of habits you may have developed as a sysop.  I can't
        stress enough the need to protect your system passwords.  Don't
        accidently use them on another BBS.  While drafting this FAQ, one
        feedback from a beta site was about how he knows the system passwords
        on most of the systems in his net.  How?  Easy, the sysops forget and
        try it out of habit on his system, get an error, then use the one they
        chose for his BBS.  On some softwares, this will leave your system
        password sitting in the other BBS's log file!

        b.  Don't use the same password in FD as you use on your BBS if you
        also use FD as your terminal program.  If you do, one day you may find
        when logging into another BBS, it sends your system password as it
        trys to 'autoconnect'. (There are ways around this but beyond the
        scope of this file.  See the FrontDoor documentation).

6.  Keyboard remapping.  This is when via file or othermanner, someone manages
to change your keyboard to say something like 'del c: /u' when you press the
F1 key (or whatever they chose to remap).  Dont allow it.  You have several
choices of ANSI.SYS type replacement files which literally dont contain the
keyboard remapping capabilities.  For regular DOS users, ZANSI.SYS works well
for most.  It also takes up less memory than normal ANSI.SYS does.  DVANSI is
for Desqview users and works just as well.  Other common types are NNANSI and
ANSI.COM.

        a.  ZANSI is the magic name at 1:275/100 for the Zansi replacement
        file should you not find it locally.

7.  Backups!  Security is also making sure you can put your system back
together after a hardware failure.  Make them nightly if possible with a
series of tapes or ZIP/JAZZ drive so that if one goes bad, you always have
a slightly older one to go back to.  If you have no tape backup, at the
least backup your critical files such as the userlist information, to
floppy.  If you have no tape backup but have plenty of extra drivespace,
a less than perfect but better than nothing method, it is backup to another
directory.  It is best if this is done to a separate drive.

8.  Path statements.  Define the Protocol path (DSZ/GSZ etc) and the Archive
Conversion path (PKZIP etc) in TG with a full description such as C:\protocol
and C:\converts.  Oh, and dont use those default names!  Neither one need be
listed in the Path= statement found in your AUTOEXEC.BAT.

        a.  Should you find it awkward to not have your compression utilities
        on your DOS search path, there are several ways to deal with that.  I
        happen to use a little batch file to reset my path statement to
        include my compression utility directory.  I just have to remember to
        run the other batch file to set it back afterwards (or reboot).

        b.  Many sysops just list the conversion archives in the path but
        leave out the protocol directory.

        c.  Now and again you will encounter a door which requires one or the
        other be in your path.  Best to look about for another simular product
        without that need.  If you can't live without that door, be aware that
        it has slightly reduced your system security.

9.  The most common method of breaching any BBS security is by taking
advantage of flaws or oversights of third party programs (upload checkers, 
protocols etc). When installing third party utilities it's best to research 
the source to find out how secure the program is and what you can do to ensure 
it is set up securely. NEVER trust the author's claims. Instead, get 
independant reviews if possible and solicit opinions of other sysops. Often 
the best gauge of a utility's security is how widely used it is. But don't let
this fool you (popular is not 'always' secure).

    a. When in doubt, ask the sysops in your area what they use and measures
    they take to ensure these utilities are secure.  Most importantly ask
    more than one person since no one person knows all the quirks of third
    party utilities.

    b. This text does not endeavour to suggest that any particular utility is
    either secure or insecure. Claims of this nature which 'may' be accurate
    at this time could be in error and may not reflect future versions of the
    same programs.

    c.  When passing information to a door or utility, never pass it more
    than it absolutely needs to function.  'More is not better' in this case.

10.  Some folks, just like to upload trojan programs.  A Trojan can best be
defined as a program which does something other than what it looks like it's
doing.  A famous one, looked like a flight simulator, but actually reformatted
the HD while playing.  Trojans do not infect other programs, but are damaging
just the same. To prevent the spread of them, mark your uploads to a secure
directory and do not autovalidate programs until you have tested them out.
This protects you, your callers, and the fellow sysops in your area if they
are downloaded before discovery and uploaded to another system.

11.  Doors, revisted.  Don't assume because a caller sends you a program, and
begs it be added, it's 'safe'.  Test it first.  Even if it looks like a common
archive, obtaining the same one from a safe source for comparison is a good
idea.

Well all!  This has been a collective effort of many.  By this point, I have
had inputs from virtually every beta site.  Special Kudos to: Lars Hellsten,
Don Johnson, David Muir, and Kevin Watkins.  For inspiration, thank Scott
Raymond of a long ago security package for earlier Telegard versions.
Portions contain ideas from the June 1994 IceNET News article (Copywrite) by
Ken Harris, WWIV Security:  One Semi-Expert's View (with permission).

Feedback may be given in the TG_SUPPORT echo, or netmailed to:  1:275/100.

                                        xxcarol aka Carol Shenkenberger
                                        DPC                         USN
                                        TG Beta                 Norfolk