Columns

• HUMOR - The World's Thinnest Books
• OL'WDB's COLUMN
• Techie Tech - FAQSEC- Security for Sysops

The World's Thinnest Books
Roy Reed rcreed@juno.com

STAYING HAPPILY MARRIED
   by Elizabeth Taylor

BEAUTY SECRETS
   by Janet Reno

HOME BUILT AIRPLANES
   by John Denver

DOWN HILL SKIING
   by Sonny Bono

ATLANTIC CROSSINGS OF THE TITANIC
   by White Star Lines

HOW TO GET TO THE SUPER BOWL
   by Dan Marino

THINGS I LOVE ABOUT BILL
   by Hillary Clinton

MY LIFE'S MEMORIES
   by Ronald Reagan

THINGS I CAN'T AFFORD
   by Bill Gates

MY PLAN TO FIND THE REAL KILLERS
   by O.J. Simpson

THINGS I WOULD NOT DO FOR MONEY
   by Dennis Rodman

THE WILD YEARS
   by Al Gore

ALL THE MEN I'VE LOVED BEFORE
   by Ellen DeGeneres

AMELIA EARHART'S GUIDE TO THE PACIFIC OCEAN

AMERICA'S MOST POPULAR LAWYERS

DETROIT...A TRAVEL GUIDE

DR. KEVORKIAN'S COLLECTION OF MOTIVATIONAL SPEECHES

MIKE TYSON'S GUIDE TO DATING ETIQUETTE

The Van Gogh Family Tree
wdbonner@pacbell.net

FAQSEC- Security for Sysops
Carol Shenkenberg
Dated: 6 OCT 2000

Hello all! 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, my software 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. 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 so only the SYSOP can convert 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 local only keyboard, no one can gain that access unless sitting at your local keyboard.
   1. Devious trick, 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.
   2. 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 the co-sysop access can be a security problem. When possible, this is the secure way to go about it:
      1. Dont have any unless you really NEED one. IE: Don't use it as a reward for being your 'best buddy'.
      2. If they live with you, or where the computer is, set their access to require 'local keyboard only' and it will prevent anyone from dialing in as them and doing damage to your system.
      3. 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.
3. Look to the WFC (waiting for caller) screen and note almost every sysop function is there in almost every software. If you really want to drive someone crazy, remove the sysop menu access from all other menus. If it just isnt there, it cant be used against you.
4. 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.
   1. 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 th chose for his BBS. On some softwares, this will leave your password sitting in the other BBS's log file!
   2. 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).
5. Note: The version I received had no #5, so in the interest of accuracy of this HTML version I am skipping #5.
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 isfor Desqview users and works just as well. Other common types are NNANSI and ANSI.COM.
   1. 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) 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.
   1. 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).
   2. Many sysops just list the conversion archives in the path but leave out the protocol directory.
   3. 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).
   1. 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.
   2. 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.
   3. 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 many sites! 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