Doesn't it really burn you when some jerk logs into your
remote CP/M system (that you've spent hundreds of hours and
thousands of dollars to put on-line for public use) and promptly
tries to steal you blind and crash or ruin your system? In the
(almost) 2 years that Technical CBBS has been on line, I've
compiled a user log about 6 feet high (no kidding, 5 boxes of
3000 sheets each) that probably has at least one example of every
possible thing that a system crasher can try to steal or screw-
up. I've been keeping a list of the "top-10" solutions that I've
found since TCBBS has been in operation, which might be of some
use to new SYSOP's. There is nothing amazing in the file, it's
mostly just common sense, but it is very easy to forget these
ideas. I know that from many painful experiences.
SYSOP'S, here are some things you can do to stop a potential
system crasher:
1. Keep a CRCK file for ALL of the .COM files that you leave
on-line (And also any other files that get loaded into the
TPA and executed, like MINICBBS.OBJ). If you have any
password files (like the PWDS file used by RBBS), CRCK those
too. For obvious reasons, don't leave the CRCK file on-line.
(CRCK.ASM is a program that produces a cyclic-redundancy-
check value for any specified files.)
2. Use MDIR.COM frequently to see what goodies the jerk may
have left you in certain user areas. Note; however, that
MDIR.COM will NOT find files that are "hidden" in the "user
areas" above 20H! The best way to see everything on the disk
is to use the MAP (M) function of DU.COM. It will show
EVERYTHING on the disk, even the remains of any erased files.
I routinely Map the disks on TCBBS and SYSOP CBBS and have,
on occasion, found special files and other no-no's on both.
3. Don't leave any .COM files on the system that can allow
a remote user to find .SYS files. Most directory programs,
and also WHATSNEW allow anybody to list .SYS files by just
typing an extra character or two. The best thing to do is
remove the .SYS list options altogether. (A quick fix is to
DDT the .COM file and change the character to a control
character like ^C which can't be entered into the command
buffer.)
4. Keep a hard-copy log of all remote input to the system.
Although a log won't actually make your system more secure,
it will give you an opportunity to see how anybody "gets in",
and will, hopefully, insure that the same break-in procedure
can't be used twice. Installing a log is really easier than
it sounds, since it only requires printing the stuff typed by
the remote user, not the stuff typed by the system. An
inexpensive (i.e. cheap) printer is perfect, since you don't
need letter-quality type to see who's been screwing up your
$3000-and-up computer system. Many BYE programs (like
BYE69.ASM) already include the option for a hard-copy log.
5. Of course, you should also change the CP/M commands.
Again, the best thing is to REMOVE commands like ERA and
SAVE, but if you're not that ambitious, or if you think you
can't do without them, just change them as usual, with SYSGEN
and DDT. Try to pick new commands that aren't easy to guess,
although it's impossible to guarantee that no one will be
able to figure them out in time. (I have a listing from TCBBS
log where some idiot spent about 8 hours trying to find one
of the commands.) If you want to eliminate a command, you
can embed a control character into the command word and make
it impossible to use.
6. Don't leave any .COM files out that would allow a remote
user to examine or modify memory, or to load a .HEX file. It
is perfectly safe to leave out ASM.COM, because it can't make
a .COM file, but to leave LOAD.COM or L80.COM out is to
invite a remote user to download his favorite debugger to see
what he can do. BASIC.COM and DDT.COM are also bad news,
since both could allow a remote user to make changes in
memory. Even a compiler can be left safely on-line, as long
as its associated loader program is not available. Also,
don't leave out any files that would allow a remote user to
send a .COM file over to your system. XMODEM.COM checks for
.COM files and won't allow them, but many other programs,
like MODEM.COM and BSTAM, will allow ANY file to be sent or
received. Once a system crasher has a way to download a .COM
file to your system, all is lost.
7. In CP/M 2.x, an illegal drive request might also change
the current user area! In other words, a remote caller who
is logged into A: user 0 could type "Q:" and end up on A:
user 1! Digital Research doesn't think of this as a bug,
because in an unmodified CP/M system, a disk select error
will cause a PERMANENT BDOS error. The problem arises when
the user changes his BIOS to allow a warm-boot on a disk
select error, instead of a permanent BDOS error. CP/M
doesn't reset the user/drive byte properly. That's the
reason for the strange results. This problem can be fixed in
your BIOS by properly handling a SELDSK error, but if you
don't have the source for your BIOS, you could be in trouble.
Another way to protect yourself against this problem is to
keep "private" stuff in user 5 or 16-32. Strangely enough,
all other user areas can be entered with an illegal drive
code. Putting things in user 5 will make them pretty safe,
and, of course, putting things in user areas 16-32 will make
them even safer, but the CCP can't get YOU into those areas,
so their use is a bit restricted. Most BYE programs have a
MAXUSER equate that will keep remote users out of any area
greater than a preset value, so they can also protect you to
a certain extent from an illegal drive select.
8. You can protect licensed or private software by keeping
it in an unaccessible user area, and using a short loader
program like Keith Petersen's SECURITY.ASM. This really
works, and makes the SYSOP feel good when he sees in the LOG
that some BOZO who thinks he has just successfully stolen
MINICBBS has actually just stolen a short loader program.
9. Probably the biggest security problem is INCREDIBLE
STUPIDITY. It is rumored that some SYSOP's have actually
done really dumb things like leave PIP.COM or MODEM.COM or
FORMAT.COM (shiver...) out in a public user area! If you
absolutely have to leave one of these (potentially) nasty
little programs on your system, put it in a user area that
can't be accessed remotely (or at least a non-public area)
and rename it to a .OBJ file. Then even if someone gets into
the user area with the program, he can't run it (.OBJ).
10. Don't leave your system or CP/M passwords anywhere on the
system. Use TAG.COM to make sure that someone can't XMODEM
your BYE.COM program and other goodies. Don't leave a SYSGEN
image (CPM56.COM) laying around either, since it could be
downloaded and DDT'ed to find the system commands. Also,
don't leave your system PW's on another system in a private
message to a friend thinking that his message system is
private, because it probably isn't. I'm not being paranoid,
everybody REALLY IS trying to break into my system...
Some of these things may seem like a pain in the neck, but the
more prevention you do, the less you have to worry about the 1
jerk in a thousand callers who wants to mis-use your system. NO
SYSTEM is absolutely secure, but with these suggestions you
should be able to run a system that is almost absolutely secure,
which isn't really that bad.
Good luck, Dave Hardy Sysop, TECHNICAL CBBS (313) 846-6127
Sysop, SYSOP CBBS (313) 885-0506
P.S. Please pass any additions or corrections on to me at one of
the above systems. -thanks
COROLLARIES:
11. Watch out for booby-trapped .COM files! If someone sends
down an .OBJ file suggesting that you leave it out on your
system, be sure to check that file for any hidden functions
that may allow someone to break into your system later. One
way to prevent this would be to only leave out .COM files
that you have assembled from SOURCE files. In any case, be
suspicious of any files left you for public use that don't
have the source with them. A good programmer could hide a
secret function in a .COM file so well that it could only be
found with a great deal of difficulty. In addition, an
unknown .COM file might also have many other terrible hidden
functions (See BANZAI.ASM for some ideas) that could even
destroy other files on the system's disks, so be careful.
-Dave Hardy (as suggested by Ron Fowler)
