home *** CD-ROM | disk | FTP | other *** search
/ CD Shareware Magazine 1996 December / CD_shareware_12-96.iso / DOS / Pub_elec / TGFAQ43.ZIP / FAQSEC.TXT < prev    next >
Encoding:
Text File  |  1996-08-25  |  8.5 KB  |  151 lines
  1. FAQSEC- Security for Sysops        Dated: 25AUG96
  2.  
  3. Hello all!  Since we have been discussing a few items of security, here is
  4. some general advice for setting up a more secure system.  Much of it will be
  5. applicable to any BBS software so feel free to share the info about.
  6.  
  7. To start with, TG is a _very_ secure system.  It has no backdoors or known
  8. security flaws in the current release.  What it does share with every other
  9. software, is the ability for the sysop to change the native settings in ways
  10. which may not be as safe as intended.  
  11.  
  12. 1. Lets start with the archive conversion menu.  Note that in TG3.02, this is
  13. set to be a sysop s255 option by default.  Unless you really need it, remove
  14. it.  There are external programs such as THDPRO which will scan for viruses
  15. and convert archives at the same time.  If you must keep it, you want to leave
  16. it set to s255.  No one but the sysop should be converting archives on your
  17. system. Now that was easy eh?  The rest will be just as easy to do.
  18.  
  19. 2.  Sysop access level.  This is an area where you will be best off if
  20. devious.  Do you use the computer always at home?  If so, there is no need to
  21. allow non-local keyboard access with that account.  If you set SYSOP access to
  22. s255xL, no one can gain that access unless sitting at your local keyboard.
  23.  
  24.         a.  Devious trick #1, set the actual Sysop account to s50 then when
  25.         you use it, hit alt-S to raise it to s255.  This works even if you
  26.         do need to allow the account to login remotely, but wont allow you
  27.         to remotely raise it's level to s255.  IE:  You will have normal user
  28.         access if you login remotely and so will anyone else if they manage to
  29.         figure out your system passwords.
  30.  
  31.         b.  Devious trick #2, dont use the main sysop account for other than
  32.         sysop functions.  Make a second account in your real name, with handle
  33.         if preferred, and set it basically at normal validated levels.  Mine
  34.         is set to s50 for normal validated users, and my main account is s60
  35.         with no extra ability except more logons per day and 10 hours time a
  36.         day.  At the local keyboard, I can always raise it to S255 if needed.
  37.  
  38. 3.  Co-sysops and access levels.  Now there are extremely reliable co-sysops
  39. and very good reasons for having them.  I understand and most others do also,
  40. but the new sysop does need to be aware that co-sysop access can be a
  41. security problem.  When possible, this is the secure way to go about it:
  42.  
  43.         a.  Dont have any unless you really NEED one.  IE:  Don't use it as a
  44.         reward for being your 'best buddy'.
  45.  
  46.         b.  If they live with you, or where the computer is, set their access
  47.         to include the xL command.  This means 'local keyboard only' and will
  48.         prevent anyone from dialing in as them and doing damage to your
  49.         system.
  50.  
  51.         c.  Give them no more access than they *must* have to do their job.
  52.         If they only remotely login to handle their messages, consider 2
  53.         accounts just like in the sysop example above.
  54.  
  55. 4. Look to the WFC screen and note almost every sysop function is there.  If
  56. you really want to drive someone crazy, remove the sysop menu access from all
  57. menus.  If it just isnt there, it *cant* be used against you.
  58.  
  59. 5.  Passwords.  Encryption.  Use it.  This protects both you and your callers
  60. in the unlikely event someone manages to get ahold of your user information
  61. files.
  62.  
  63.         a.  Be aware of habits you may have developed as a sysop.  I can't
  64.         stress enough the need to protect your system passwords.  Don't
  65.         accidently use them on another BBS.  While drafting this FAQ, one
  66.         feedback from a beta site was about how he knows the system passwords
  67.         on most of the systems in his net.  How?  Easy, the sysops forget and
  68.         try it out of habit on his system, get an error, then use the one they
  69.         chose for his BBS.  On some softwares, this will leave your system
  70.         password sitting in the other BBS's log file!
  71.  
  72.         b.  Don't use the same password in FD as you use on your BBS if you
  73.         also use FD as your terminal program.  If you do, one day you may find
  74.         when logging into another BBS, it sends your system password as it
  75.         trys to 'autoconnect'. (There are ways around this but beyond the
  76.         scope of this file.  See the FrontDoor documentation).
  77.  
  78. 6.  Keyboard remapping.  This is when via file or othermanner, someone manages
  79. to change your keyboard to say something like 'del c: /u' when you press the
  80. F1 key (or whatever they chose to remap).  Dont allow it.  You have several
  81. choices of ANSI.SYS type replacement files which literally dont contain the
  82. keyboard remapping capabilities.  For regular DOS users, ZANSI.SYS works well
  83. for most.  It also takes up less memory than normal ANSI.SYS does.  DVANSI is
  84. for Desqview users and works just as well.  Other common types are NNANSI and
  85. ANSI.COM.
  86.  
  87.         a.  ZANSI is the magic name at 1:275/100 for the Zansi replacement
  88.         file should you not find it locally.
  89.  
  90. 7.  Backups!  Security is also making sure you can put your system back
  91. together after a hardware failure.  Make them nightly if possible with a
  92. series of tapes so that if one tape goes bad, you always have a slightly
  93. older one to go back to.  If you have no tape backup, at the least backup your
  94. critical files such as the userlist information, to floppy.  If you have no
  95. tape backup but have plenty of extra drivespace, a less than perfect but
  96. better than nothing method, it is backup to another directory.  It is best if
  97. this is done to a separate drive.
  98.  
  99. 8.  Path statements.  Define the Protocol path (DSZ/GSZ etc) and the Archive
  100. Conversion path (PKZIP etc) in TG with a full description such as C:\protocol
  101. and C:\converts.  Oh, and dont use those default names!  Neither one need be
  102. listed in the Path= statement found in your AUTOEXEC.BAT.
  103.  
  104.         a.  Should you find it awkward to not have your compression utilities
  105.         on your DOS search path, there are several ways to deal with that.  I
  106.         happen to use a little batch file to reset my path statement to
  107.         include my compression utility directory.  I just have to remember to
  108.         run the other batch file to set it back afterwards (or reboot).
  109.  
  110.         b.  Many sysops just list the conversion archives in the path but
  111.         leave out the protocol directory.
  112.  
  113.         c.  Now and again you will encounter a door which requires one or the
  114.         other be in your path.  Best to look about for another simular product
  115.         without that need.  If you can't live without that door, be aware that
  116.         it has slightly reduced your system security.
  117.  
  118. 9.  The most common method of breaching any BBS security is by taking
  119. advantage of flaws or oversights of third party programs (upload checkers, 
  120. protocols etc). When installing third party utilities it's best to research 
  121. the source to find out how secure the program is and what you can do to ensure 
  122. it is set up securely. NEVER trust the author's claims. Instead, get 
  123. independant reviews if possible and solicit opinions of other sysops. Often 
  124. the best gauge of a utility's security is how widely used it is. But don't let
  125. this fool you (popular is not 'always' secure).
  126.  
  127.     a. When in doubt, ask the sysops in your area what they use and measures
  128.     they take to ensure these utilities are secure.  Most importantly ask
  129.     more than one person since no one person knows all the quirks of third
  130.     party utilities.
  131.  
  132.     b. This text does not endeavour to suggest that any particular utility is
  133.     either secure or insecure. Claims of this nature which 'may' be accurate
  134.     at this time could be in error and may not reflect future versions of the
  135.     same programs.
  136.  
  137.     c.  When passing information to a door or utility, never pass it more
  138.     than it absolutely needs to function.  'More is not better' in this case.
  139.  
  140. Well all!  This has been a collective effort of many.  By this point, I have
  141. had inputs from virtually every beta site.  Special Kudos to: Lars Hellsten,
  142. Don Johnson, David Muir, and Kevin Watkins.  For inspiration, thank Scott
  143. Raymond of a long ago security package for earlier Telegard versions.
  144.  
  145. Feedback may be given in the TG_SUPPORT echo, or netmailed to:  1:275/100.
  146.  
  147.                                         xxcarol aka Carol Shenkenberger
  148.                                         DPC(sel)                    USN
  149.                                         TG Beta                 Norfolk
  150.                       
  151.