GEMini Atari/GEMini_Atari_CD-ROM_Walnut_Creek_December_1993.iso/files/bbs/fn132bin/fdman/chapter.10

Text File | 1991-09-03 | 28KB | 572 lines

Chapter 10:  Anti-Ruggie Measures                                        133




10  Anti-Ruggie Measures


   __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
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.



10.1  Philosophy

   ``But  first, a  brief  philosophical interlude.''    The  developers  of
Fnordadel have  been running conversation-only BBSes  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 BBSes---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.

   *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.



Chapter 10:  Anti-Ruggie Measures                                        134




10.2  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.


10.2.1  Paranoid 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  #getname  to have  the  value `1'  in  your
`ctdlcnfg.sys'  (referred to  in the  literature as  ``paranoid mode'',  for
hysterical...   err...  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.



10.2.2  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  Mail> room is  an exception;  see the next  section.)
Simply  define the  `ctdlcnfg.sys'  variable #msgenter  to be  your  desired
maximum.   For most systems,  a number like  `4' or `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 `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.



Chapter 10:  Anti-Ruggie Measures                                        135




10.2.3  Mail messages per call

   The  parameter  #mailenter  in  `ctdlcnfg.sys'  works  exactly  like  its
counterpart msgenter  described above.    It controls only  the 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 `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 allmail.   If set  to `1',
the  parameter allows  all users  full access  to entering  messages in  the
Mail> room.   If set to  `0', however, users are  not able to enter mail  to
anybody except `Sysop',  unless you manually give them mail  privileges (see
Section 5.2 [User Status  Commands], page 80).  Naturally,  Aides, Co-Sysops
and the  Sysop always have  full Mail>  access.   See `flipbits.man' if  you
need a way to set the mail access flag for all users in one swell foop.


10.2.4  Maximum number of calls per day

   This parameter  is called  #maxcalls in  `ctdlcnfg.sys', 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
`0' means there is no limit.



10.2.5  Maximum connect time per day

   This parameter  is  called #maxtime  in `ctdlcnfg.sys',  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 `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  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 `5', all  calls of five  minutes or less  will
be charged as  five minutes.)  The  lowest acceptable value is `1',  but you
can set it higher  if you're concerned about users that call  frequently but
spend very little time connected.



Chapter 10:  Anti-Ruggie Measures                                        136




10.2.6  Maximum number of close calls per day

   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 `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 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  `ctdlcnfg.sys'  parameter
#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 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  `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 maxclosecalls,  that all users start
each day  with this  stat set to  `1'.   Their first  call is by  definition
close to itself.  Make sense?


10.2.7  Daily download limit

   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  `ctdlcnfg.sys'
parameter  #download, which  is  a number  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 `0', there is, of course, no limit.



10.2.8  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 [T]wit
toggle command  from the [U]ser  status sub-menu under  the Sysop menu  (see
Section 5.2 [User Status Commands], page 80).

   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 [S]ave.)    Note that  this
is different  from the purge  feature, covered  in Section 10.2.10  [Message
purging],  page 137,  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.



Chapter 10:  Anti-Ruggie Measures                                        137




  o A twit may not use the [C]hat command.

  o He/she may not upload or download files.

  o Doors are inaccessible to a twit.

  o The command  `.RG' for reading  all new messages  on the system will  be
    mapped to [N]ew.

  o A twit will not be allowed to use .E(nter) R(oom).

  o As a sort of  side-effect, no new users will be allowed to login  to the
    system immediately after a twit has [T]erminated.   (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.  See Section 10.2.14 [Closed system], page 140.)


10.2.9  Inheritance

   Another  favorite  trick   of  ruggies  is   to  play  around  with   the
.T(erminate) S(tay)  feature---that form  of .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  `.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.



10.2.10  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 `ctdlcnfg.sys'  parameter #purgenet  to `1',  all incoming  net
messages  (except in  Mail>) from  specified users  *or net  nodes* will  be
purged.

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

   When Fnordadel is  brought up it reads  the contents of `purge.sys'  into
memory.  When  a user [T]erminates, 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  Mail> room  (this gives them  a chance  to
talk to  you and redeem themselves).   The  deleted messages will appear  in



Chapter 10:  Anti-Ruggie Measures                                        138




Aide> in the case  of locally-entered messages; they will be marked  by `The
following message deleted from xyz> by Citadel'.

   You can  modify this  behavior by  setting the  `ctdlcnfg.sys' variable
#vaporize to `1'.   If you do this, your system will actually  ``roll back''
all messages  (including those in Mail>)  entered by the ruggie,  reclaiming
the space  they took  up in  the message  base.   This action  is logged  in
Aide>.   Note that  if the user  caused any 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  Aide> also,
but  the lost  Aide> messages  themselves are  not recoverable,  unless  you
are archiving the  room.  See  Section 4.2.1 [Sysop room-editing  commands],
page 70.

   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
`purge.sys'  file when  the BBS  is down;  and  by the  use  of the  [P]urge
sub-menu under the Sysop menu when when the BBS is up.   See Section 10.2.12
[Purge and Westwict menus], page 139, 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  (see Section  10.2.8 [Twit status],  page 136)  or go  to
validation mode (see Section 10.2.14 [Closed system], page 140).

   Note also that Fnordadel makes no check to see that  names in `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  #purgenet  and  #keepdiscards in  Section  8.1.2  [Optional  Networking
Parameters], page 98, and the [D]iscarded messages menu  in Section 8.2 [The
Net Menu], page 104.



Chapter 10:  Anti-Ruggie Measures                                        139




10.2.11  Login restrictions

   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 `restrict.sys'  in your #sysdir  containing a list  of
user names, one  per line.  When Fnordadel  is brought up it reads  the list
into  memory.   If  you specify  `+restrict' on  the  citadel command  line,
or if  you manually  turn on  restrictions using the  [W]estwict command  in
the Sysop  menu, then  Fnordadel will  restrict logins to  only those  users
named in `restrict.sys'.   All other attempted logins, whether by  new users
or  by existing  users,  will  be refused---the  system  will spit  out  the
`restrict.blb' file,  located in  your #helpdir,  or a  simple ``sorry,  the
system is closed'' message if it can't find `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...  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 `restrict.blb' into place, and then reruns citadel.   The first
event set the restriction  to ``members only'', and the second  event resets
things to open access.  The possibilities are endless!


10.2.12  Purge and Westwict menus

   The purge and  restrict lists may be  manipulated using these two  menus.
Their operation is identical.  The commands are:

      [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

[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).

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



Chapter 10:  Anti-Ruggie Measures                                        140




[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.

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

[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 RAM  to disk (as  the file  `purge.sys'
           or  `restrict.sys'.)    The  old  file, if  it  exists,  will  be
           overwritten.

e[X]it menu
           Exit back to the main Sysop menu.


10.2.13  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 [P]asswords
in Section  8.3 [Editing Nodes], page  107.)   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 Mail>,  and generally cause chaos.   Net passwords were put  in to
prevent this behavior.

   Two  other  things  you  can  do  are  to  set   the  anonnetmail  and/or
#anonfilexfer parameters  in `ctdlcnfg.sys'.   These  parameters, if set  to
`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  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 BBS networks.



10.2.14  Closed 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  `ctdlcnfg.sys'
variable #loginok  to 0.   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



Chapter 10:  Anti-Ruggie Measures                                        141




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
`ctdlcnfg.sys' parameter  called #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.



10.3  Other Hints and Notes

  o 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 `Dr. Zamboni' from  being blown away along  with
    those from  `Dr. Zam'.  However,  it is marginally possible (due  to all
    the strange and  wonderful variants of Citadel out there)  that messages
    from  `Dr. Zam'  would  not be  purged due  to  some software  somewhere
    sticking extra crap  in the user name field,  e.g.  `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.

  o 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.    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.

    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.

    Final  note:   If  you  don't like  this  behavior of  rolling  overages
    forward,  you can  get rid  of it  using the  `ctdlcnfg.sys' parameter
    #autozerolimit.     If  set to  `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.



Chapter 10:  Anti-Ruggie Measures                                        142




  o If  you need  to manually  reset  a user's  limit statistics,  for  some
    reason,  you can do  so using the  [R]eset daily  limits command of  the
    user status  menu.   You can look  at a user's  current stats using  the
    [V]iew user  status command  in the same  menu.   See Section 5.2  [User
    Status Commands], page 80.

  o 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.

  o 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 `ctdlcnfg.sys' variable #allnet is
    a good  one to check; if  it's set to `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.   (See Chapter  8
    [Networking], page 96.)