@comment Tell Emacs to use -*-texinfo-*- mode
@comment $Id: ruggie.tex,v 2.2 91/09/01 23:04:40 royce Exp $

@node Anti-Ruggie Measures, Shells vs. the Desktop, Doors, Top
@chapter Anti-Ruggie Measures
@cindex Anti-ruggie measures

@cindex Ruggie
@dfn{Ruggie} is short for ``rug-rat''; it's a somewhat mutated term
which now refers to any brat, twit, twerp, loser, wanker, nud, idiot, len,
moron, or generally, any walking waste of protoplasm.  These types of
people (often, though by no means exclusively, kids who've
just been given their first modem for Christmas) may suddenly spring up
and begin to plague your @sc{bbs}.  They may do any one of a number of things,
from logging in and asking stupid questions, to putting drivel in the
discussion rooms, to strewing megabytes of profanity all over your board.
If they do the former, then you may simply want to take them aside, so to
speak, and answer their questions.  If they do something like the latter,
then read on.

@node Philosophy, Secret Weapons, Anti-Ruggie Measures, Anti-Ruggie Measures
@section Philosophy

``But first, a brief philosophical interlude.''  The developers
of Fnordadel have been running conversation-only @sc{bbs}es for a
number of years (the Round Table, Royce's board, went up in
August of 1984, and Secret Service, Adrian's board, has been around
since March of 1986).  In all that time, a philosophy of ``open''
Sysoping has prevailed.  That is, we've always disliked the
validation style of @sc{bbs}es---the kind where you have to leave
ten pages of personal information before the Sysop will grant
you access to his system.  We prefer to run systems where
anyone can create a new account at any time, without Sysoply
intervention, and then dive into most of what goes on with the system.

The problem with this, of course, is that undesirables
tend to slip in.  Any ruggie can call in and leave his drivel
or profanity at any time, and there ain't much that the Sysop
can do about it.  About the most he can do, on a standard
Citadel, is delete the offending messages as soon as he sees
them, hopefully before they got sent anywhere if the rooms affected
are networked, and pray the ruggie doesn't call back.  Or he can turn
his system into a ``closed'', validation-style system, which may
not be an attractive option.  It certainly isn't to us.

Here in Edmonton, we've had a pretty determined gang
of ruggies plaguing the boards for a couple of years, and it
was primarily these twits who prompted the development of
Fnordadel's anti-ruggie features which aren't found on other
Citadels.

@emph{Please note:} no security measures
ever devised can stop a determined incursion, so we advise you
to be pretty low-key about what security measures you may have in
place, to avoid tempting people to break them.

@node Secret Weapons, Ruggie Hints and Notes, Philosophy, Anti-Ruggie Measures
@section The Secret Weapons

Here, then, are the tools at your disposal.  Use any
combination that works for you without causing your regular users
undue discomfort.

@node Paranoid mode, Messages per room per call, Secret Weapons, Secret Weapons
@subsection Paranoid mode
@cindex Paranoid mode
@cindex Getname mode

Standard Fnordadel requires that users login
using their password only; if people are intelligent in
choosing their passwords, this works fine and is quicker
than having to type in one's user name as well.  Unfortunately,
many people are not the least bit intelligent when it
comes to password choosing (or anything else, for that
matter), so it leaves a resourceful ruggie with some
golden opportunities to hack someone's account and cause
chaos.

If you define the variable @code{#getname} to have the value
@vindex getname
@samp{1} in your @file{ctdlcnfg.sys} (referred to in the literature as
``paranoid mode'', for hysterical@dots{} err@dots{} historical reasons),
Fnordadel will ask for both a name and a
password when logging users in.  This means that a ruggie
has to guess not only a user's password, but to which user
the password belongs.  This is pretty tough.

@node Messages per room per call, Mail messages per call, Paranoid mode, Secret Weapons
@subsection Messages per room per call
@cindex Limits, messages per room per call

A favourite ruggie trick is to use an automated
macro to enter one message (frequently something short but
obscene) into one or more rooms, over and over and over
again; the goal being to scroll all the real messages out
of your message base.

To combat this, Fnordadel allows you to define
the maximum number of messages which any given user can
enter in any given room during any one login session.
(The @code{Mail>} room is an exception; see the next section.)
Simply define the @file{ctdlcnfg.sys} variable @code{#msgenter} to be
@vindex msgenter
your desired maximum.  For most systems, a number like @samp{4}
or @samp{5} is pretty good; it allows the legitimate users
plenty of leeway for verbosity, while helping to contain
the damage done by a vandal.  Deleting 4 or 5 messages
from a few rooms is much better than deleting hundreds,
or having to nuke your message base because it's full of
``Sysop Sucks Eggs'' messages.

Setting this parameter to @samp{0} means there is no
limit on the number of messages enterable by anybody.
Even if the value is non-zero, all Aides, Co-Sysops and the Sysop are
exempt from the limit.  Hopefully you won't all run wild.

@node Mail messages per call, Calls per day, Messages per room per call, Secret Weapons
@subsection Mail messages per call
@cindex Limits, mail messages per call

The parameter @code{#mailenter} in @file{ctdlcnfg.sys}
@vindex mailenter
works exactly like its counterpart @code{msgenter} described above.
It controls only the @code{Mail>} room, however, and thus allows you
to independently alter users' use of private mail.  Not only
can this be used to stop vandals from flooding your decent
users with junk mail, it can be used to control non-ruggies
who may be a bit too enthusiastically posting private messages.

Again, setting this parameter to @samp{0} means there is no
limit on the number of messages enterable by anybody.  Aides, Co-Sysops
and the Sysop are exempt from the limit in any case.

Another parameter to consider in this area is @code{allmail}.
If set to @samp{1}, the parameter allows all users full access to
entering messages in the @code{Mail>} room.  If set to @samp{0}, however,
users are not able to enter mail to anybody except @samp{Sysop},
unless you manually give them mail privileges (@pxref{User Status Commands}).
Naturally, Aides, Co-Sysops and the Sysop always
have full @code{Mail>} access.  See @file{flipbits.man} if
@pindex flipbits
you need a way to set
the mail access flag for all users in one swell foop.

@node Calls per day, Connect time per day, Mail messages per call, Secret Weapons
@subsection Maximum number of calls per day
@cindex Limits, calls per day

This parameter is called @code{#maxcalls} in @file{ctdlcnfg.sys},
@vindex maxcalls
and is used to limit the total number of calls any user (except
Aides, Co-Sysops and the Sysop, of course) may make in a given day.  Again,
setting the parameter to @samp{0} means there is no limit.

@node Connect time per day, Close calls per day, Calls per day, Secret Weapons
@subsection Maximum connect time per day
@cindex Limits, connect time

This parameter is called @code{#maxtime} in @file{ctdlcnfg.sys},
@vindex maxtime
and is used to limit the total connect time any user (except
Aides, Co-Sysops and the Sysop, of course) may use up in a given day.  The
value is in minutes.  Again, setting the it to @samp{0} means there
is no limit.

This measure is like the others, in that it is non-intrusive---users
will not be booted off the system the second they
exceed their daily allotment of connect time.  Instead, they
will be allowed to finish their current login session.  But
if they call back the same day, they will not be permitted entry.
This seems to us like a good mix of control for the Sysop vs.
consideration for the users.

A related parameter that you might want to look at is
@code{mincalltime}.  This value is in minutes, and specifies the
minimum connect time you wish to ``charge'' a user on any call,
no matter how short it is.  (For example, if you set this variable to
@samp{5}, all calls of five minutes or less will be charged as five minutes.)
The lowest acceptable value is @samp{1},
but you can set it higher if you're concerned about users that
call frequently but spend very little time connected.

@node Close calls per day, Daily download limit, Connect time per day, Secret Weapons
@subsection Maximum number of close calls per day
@cindex Close calls
@cindex Limits, close calls

Now we get really tricky.  First of all, you say,
``What the heck is a `close call'?  I just about got hit by
a truck, is that what you mean?''  Not quite.  We define a close
call to be any call made by a user that occurs a certain small
amount of time after the termination of his/her last call.
Ruggies frequently do this, as you'll know if you examine your
@file{calllog.sys} file after ruggie problems---you'll probably see
lots of (usually short) calls, one after the other.  They will
do this for sure if you have defined the @code{msgenter} parameter,
since that value unreasonably limits the number of drivelous
messages they can post during one call.

Well, there's hope.  Simply define the @file{ctdlcnfg.sys}
@vindex closetime
parameter @code{#closetime} to be the number of minutes separating
what you think are two calls that are ``close''.  We suggest
something like 10 minutes.  Next, define the parameter
@code{maxclosecalls} to be the maximum number of close calls that
users will be allowed on a daily basis.  We suggest a number
somewhere between 3 and 5 if you're having problems, but be
aware that you'll also be putting the clamps on any decent
users that have bad line noise problems or call-waiting on
their phone lines (they'll get disconnected frequently and
probably try calling back right away).

If either of the above parameters is set to @samp{0}, there is
(you got it) no limit.  Also, predictably, Aides, Co-Sysops and the Sysop
are exempt from the limit.  Be aware, when setting @code{maxclosecalls},
that all users start each day with this stat set to @samp{1}.  Their
first call is by definition close to itself.  Make sense?

@node Daily download limit, Twit status, Close calls per day, Secret Weapons
@subsection Daily download limit
@cindex Download limits
@cindex Limits, download

For those users that may be downloading stuff like crazy,
you may want to set a limit on how much they can do in a day.
Use the @file{ctdlcnfg.sys} parameter @code{#download}, which is a number
@vindex download
defining the maximum number of kilobytes of files downloadable
by any user (except Aides, Co-Sysops and the Sysop) per day.  If the value is
@samp{0}, there is, of course, no limit.

@node Twit status, Inheritance, Daily download limit, Secret Weapons
@subsection Twit status
@cindex Twit status

This is the ``twit-bit''; it's a flag in the user log
record to tell the system that the user is, as they say,
a twit.  To set it, use the @code{[T]wit toggle} command from
the @code{[U]ser status} sub-menu under the Sysop menu
(@pxref{User Status Commands}).

What does the twit-bit do, you ask?  The most useful function of the twit-bit
is to cause all messages entered by twits to be saved not to the message base,
but to the Great Bit Bucket In The Sky.  (I.e., they are thrown away the
nanosecond the user hits @code{[S]ave}.)  Note that this is different
from the purge feature, covered in @ref{Message purging}, where local
messages from undesirables are actually saved, but then automatically deleted
later.

In addition, certain Fnordadel functions will be
mysteriously inoperative or different for a twit.
@itemize @bullet
@item
A twit may not use the @code{[C]hat} command.
@item
He/she may not upload or download files.
@item
Doors are inaccessible to a twit.
@item
The command @samp{.RG} for reading all new
messages on the system will be mapped to @code{[N]ew}.
@item
A twit will not be allowed to
use @code{.E(nter) R(oom)}.
@item
As a sort of side-effect, no new
users will be allowed to login to the system immediately after
a twit has @code{[T]erminate}d.  (This is to stop his buddies, or new
aliases with him attached.)
As soon as one existing user signon has occured, new users will
once again be allowed to login.  (This function assumes that
you're not running your Fnordadel in validation mode.  @xref{Closed system}.)
@end itemize

@node Inheritance, Message purging, Twit status, Secret Weapons
@subsection Inheritance
@cindex Inheritance
@cindex Twit status inheritance

Another favorite trick of ruggies is to play
around with the @code{.T(erminate) S(tay)} feature---that form
of @code{.T(erminate)} which allows the user to stay connected
and login again (presumably under a different alias).

Fnordadel makes an assumption which is pretty
accurate, most of the time.  It assumes that anyone who
logs in after a twit has used @samp{.TS} is also a twit, and
assigns him/her twit status just as if the Sysop had
manually done so.

Currently, Fnordadel allows only twit status
to be inherited; the capability may be extended to
include purging and whatever else may arise.

@node Message purging, Login restrictions, Inheritance, Secret Weapons
@subsection Message purging
@cindex Message purging
@cindex Purging messages from ruggies
@cindex Ruggie message purging

This is probably the goofiest yet most useful of the ruggie
control features, mainly because it's the most devious.
Essentially, it allows Fnordadel to automatically
delete all messages from specified users, immediately
upon said users' disconnection from the system.  Also, if
you set the @file{ctdlcnfg.sys} parameter @code{#purgenet} to @samp{1}, all
@vindex purgenet
incoming net messages (except in @code{Mail>}) from specified
users @emph{or net nodes} will be purged.

Place a file called @file{purge.sys} into your
@code{#sysdir}.  It should contain a list of user or node names, one
@vindex sysdir
per line, to whom the purge will apply.  Case is irrelevant,
since all name comparisons during searches ignore case.  Now invoke
@pindex +purge (citadel)
@code{citadel} with @samp{+purge} on the command line.

When Fnordadel is brought up it reads the
contents of @file{purge.sys} into memory.  When a user
@code{[T]erminate}s, or a network session finishes, the list is checked.
New messages from the desired users and nodes are deleted, except for those
posted in the @code{Mail>} room (this gives them a chance to talk to you
and redeem themselves).
The deleted messages will appear in @code{Aide>} in the case of
locally-entered messages; they will be marked by @samp{The following
message deleted from @var{xyz}> by Citadel}.

You can modify this behavior by setting the @file{ctdlcnfg.sys} variable
@vindex vaporize
@code{#vaporize} to @samp{1}.  If you do this, your system will actually
``roll back'' all messages (including those in @code{Mail>}) entered by the
ruggie, reclaiming the space
they took up in the message base.  This action is logged in @code{Aide>}.
Note that if the user caused any @code{Aide>} messages to be generated during
his/her stay, they will be lost along will all the other user messages when
the vaporization occurs.  This fact is logged in @code{Aide>} also, but the
lost @code{Aide>} messages themselves are not recoverable,
unless you are archiving the room.  @xref{Sysop room-editing commands}.

Normal purging takes a little time,
but vaporize mode takes even longer.  Use with caution (if it screws up,
it will probably toast your message base), and only if you are being
plagued with so many ruggie postings that they're causing serious space
wastage in your message base.  Better yet, if you're having this much
trouble, consider moving and changing your identity.

The purge list can be maintained by using a text
editor on the @file{purge.sys} file when the @sc{bbs} is down; and by
the use of the @code{[P]urge} sub-menu under the Sysop menu when
when the @sc{bbs} is up.  @xref{Purge and Westwict menus}, for
details on how the menu works.

The purge feature works fairly well; however, it
does nothing to make your message base impervious to
having loads of crap dumped in it in the first place.  If you
want to stop the messages from being entered while still keeping
your system up, you have only
two choices:  use the twit status bit a lot (@pxref{Twit status}) or
go to validation mode (@pxref{Closed system}).

Note also that Fnordadel makes no check to see
that names in @file{purge.sys} are those of existing users on
your system; this allows you to add the names of ruggies
who may have been terrorising other boards but not yours.
You can prepare in advance for their arrival.  Also, once
a ruggie has hit your system, he may leave it alone long
enough for his user account to scroll out of your user file.
If he ever signs back on with the same name, however, he
will still be purged immediately.

Finally, the purge function can be applied to incoming net
traffic as well as locally-entered messages.  This can be effective
in eliminating dreck from problem net nodes to which you don't connect
directly.  Even better, net messages eliminated by the purger never
make it into your message base, so they cause no space wastage.  They are
either permanently lost, or saved each in its own offline file for you to
manually process.  See
@vindex purgenet
@vindex keepdiscards
@code{#purgenet} and @code{#keepdiscards} in
@ref{Optional parameters, , Optional Networking Parameters},
and the @code{[D]iscarded messages} menu in @ref{The Net Menu}.

@node Login restrictions, Purge and Westwict menus, Message purging, Secret Weapons
@subsection Login restrictions
@cindex Login restrictions
@cindex Restrictions on logins

This doesn't really qualify as an anti-ruggie
feature, in the truest sense, but we'll put it here
anyway because it's similar.

Put a file called @file{restrict.sys} in your @code{#sysdir}
@vindex sysdir
containing a list of user names, one per line.  When
Fnordadel is brought up it reads the list into memory.
@pindex +restrict (citadel)
If you specify @samp{+restrict} on the @code{citadel} command
line, or if you manually turn on restrictions using the
@code{[W]estwict} command in the Sysop menu, then Fnordadel will
restrict logins to only those users named in @file{restrict.sys}.
All other attempted logins, whether by new users or by
existing users, will be refused---the system will spit
out the @file{restrict.blb} file, located in your @code{#helpdir},
@vindex helpdir
or a simple ``sorry, the system is closed'' message if it
can't find @file{restrict.blb}.

In the ruggie-control sense, login restrictions
could be used to restrict access to your system to only
those users that you know are ``safe'', without having to
actually process their applications and create their
accounts yourself (as required by ``validation'' mode).  As with purging,
it has the advantage that you may specify the names of
users who have never logged in, so you can ``reserve a
spot'' for them, as it were.  (Of course, this is itself a security
hole, because a ruggie can try to guess who you've got
in your restrict list@dots{} but let's not get too paranoid.)

Login restrictions were originally put in during
a round of hacking on the software in which we were
constantly interrupted during testing by users calling
the board; we wanted to reserve the board for ourselves,
without disabling it.  Another possible use for login
restrictions is to designate a certain time period for
``members only'' or some such; simply set up a pair of
events which exit to a command shell, where a script file
copies a new @file{restrict.blb} into place, and then reruns
@code{citadel}.  The first event set the restriction to
``members only'', and the second event resets things to open
access.  The possibilities are endless!

@node Purge and Westwict menus, Network security, Login restrictions, Secret Weapons
@subsection Purge and Westwict menus

The purge and restrict lists may be manipulated using
these two menus.  Their operation is identical.  The commands are:
@cindex Purge menu
@cindex Restrict menu
@cindex Westwict menu
@example
[A]dd name to list
[D]elete name from list
[S]witch function on/off
[V]iew list in RAM
[W]rite list to disk
e[X]it menu
@end example

@table @code
@item [A]dd name to list
This allows you to add another name to
the list.  No check is made to see whether
the name is that of a currently-existing user;
this is deliberate.  (See below).

@item [D]elete name from list
Use this to remove someone from the list.

@item [S]witch function on/off
This toggles purging/restrictions on or off.
If it is off, the list will still be kept in memory, so
the feature can be turned on again at any time.

@item [V]iew list in RAM
This displays a list of the names currently in
the list stored in memory.

@item [W]rite list to disk
After you've made some changes to the
list, you'll probably want to make them permanent.  Use
this command to write the contents of the list in @sc{ram} to
disk (as the file @file{purge.sys} or @file{restrict.sys}.)  The old
file, if it exists, will be overwritten.

@item e[X]it menu
Exit back to the main Sysop menu.
@end table

@node Network security, Closed system, Purge and Westwict menus, Secret Weapons
@subsection Network security
@cindex Security, network
@cindex Network security

If you suspect another Citadel net node is actively
causing you grief (or if you just want to play it safe/paranoid), there
are a few things you can do to protect your system.  The first
is to set up net passwords with the systems
you normally net with, assuming you trust them (see @code{[P]asswords} in
@ref{Editing Nodes}.)  There have been
incidents in the past where unscrupulous Sysops set up systems
that looked exactly like other systems, and then dialed in to
places in order to intercept shared rooms and @code{Mail>}, and generally
cause chaos.  Net passwords were put in to prevent this behavior.

Two other things you can do are to set the @code{anonnetmail}
and/or @code{#anonfilexfer} parameters in @file{ctdlcnfg.sys}.  These
@vindex anonfilexfer
parameters, if set to @samp{0}, will make your system reject attempted
incoming net mail and file transfer requests, respectively, if the
sending node is not in your net list.  This prevents rogue
systems from scrolling your @code{Mail>} room and message base, or
filling up all available disk storage.  It would also prevent
the ``junk mail'' phenomenon, which is already a problem with fax
machines.  Heaven help us all if it hits @sc{bbs} networks.

@node Closed system, , Network security, Secret Weapons
@subsection Closed system
@cindex Closing your system

So, let's say that everything else has failed.
The ruggies have found out about all of the above
features, and have found workarounds for all of them.  Or
they haven't, but have enough time and perseverence to keep
plugging away with every automated macro and trick they
can come up with.  What do you do now?

Much as we hate to suggest it, the best option is
probably to close your system.  To do so, simply change
the value of the @file{ctdlcnfg.sys} variable @code{#loginok} to {0}.
@vindex loginok
This will prevent new users from creating their own
accounts; they will only be able to leave mail to the
Sysop to request that you create an account for them.  You
will then have total control over who gets access to your
system; unfortunately, you'll also have opened up a whole
new can of problem worms, such as ruggies who request bogus
accounts by just randomly pulling names from the phone book.
At this point, you should be talking to your
phone company about getting an unlisted phone number, and
perhaps a line trace.  They might be willing to help you out.

In conjunction with this step, you may also need to define the
@file{ctdlcnfg.sys} parameter called
@vindex anonmailmax
@code{#anonmailmax}, which controls the size of mail messages
enterable by users that aren't logged in.  This will help prevent
ruggies who can no longer log in from causing you problems in
Mail>, the last room available to them.

@node Ruggie Hints and Notes, , Secret Weapons, Anti-Ruggie Measures
@section Other Hints and Notes

@itemize @bullet
@item
When using the purge feature on incoming net traffic, make sure
that none of the user names in your purge list is the same as
any net node you get messages from.  The results are obvious,
and highly annoying.

Also, the net purge currently is set to be very literal about
matching user names on other nodes---no substring matching
is done.  This prevents messages from @samp{Dr. Zamboni} from being
blown away along with those from @samp{Dr. Zam}.  However, it is
marginally possible (due to all the strange and wonderful
variants of Citadel out there) that messages from @samp{Dr. Zam}
would not be purged due to some software somewhere sticking
extra crap in the user name field, e.g. @samp{Dr. Zam @@ Foobar}.
This isn't supposed to happen, but it might.  We'll figure
something out to get around it when/if it becomes a problem.

@item
When users exceed any of the limit values you have defined,
the system keeps track of the excess amount over and above
the maximums, and rolls that amount forward to future days.
This is done like so:  When the user calls back any day after
today (could be many days from now), the system subtracts from
his/her accumulated stats the maximum values you set.  It then
checks to see if the user should be allowed access; if not,
the new lower limit values are saved and the user is logged off.
Thus users who abuse your system (especially in the total
connect time area) could penalize themselves for several days.
@strong{Note:}  The system does not care if the user calls back tomorrow
or four weeks from now.  No extra deductions from the user's
accumulated stats are made if he/she waits for several days or
weeks to call back.

@strong{Also note:}  If a user makes a call and is prevented access due
to one or another of your defined limits, the call is counted
and recorded against their time and number of calls limits,
even though the user was not allowed onto the system.

@strong{Final note:}  If you don't like this behavior of rolling overages
forward, you can get rid of it using the @file{ctdlcnfg.sys} parameter
@vindex autozerolimit
@code{#autozerolimit}.  If set to @samp{1}, this flag tells the system to
graciously wipe out all the user's limit values and start from
scratch, rather than bringing forward any extra amounts.

@item
If you need to manually reset a user's limit statistics, for
some reason, you can do so using the @code{[R]eset} daily limits
command of the user status menu.  You can look at a user's
current stats using the @code{[V]iew user status} command in the
same menu.  @xref{User Status Commands}.

@item
The system pauses for about 20 seconds on bad passwords, to
discourage password guessing.  After a certain number of bad
login attempts (currently 3), the system will disconnect the
caller.

@item
If you're having ruggie problems and haven't got as far
as closing your system yet, you'll want to make sure that
you aren't being too careless with the new users'
privileges.  The @file{ctdlcnfg.sys} variable @code{#allnet} is a good
@vindex allnet
one to check; if it's set to @samp{1}, all new users are given
net privs (and can therefore enter net messages in shared
rooms, whether the room is autonet or not).  If you net
long-distance rooms (or even just local ones), it would
be both a profound annoyance for all the other Sysops,
and a possibly expensive proposition in the case of LD
netting, to send out a flood of messages from a ruggie
who was allowed to post net messages in a shared room.
Be careful.  (@xref{Networking}.)
@end itemize