META: System Security (was: Re: [MUD-Dev] players who "take away from the game")

[J C Lawrence]

On Wed, 10 Nov 1999 16:59:18 -0600 
Grey  <Eli> wrote:

> What precautions should be taken when writing a MUD codebase from
> scratch?  

There are some useful links in the library under:

  http://www.kanga.nu/library.php3?viewCat=32

Writing secure code is not something done automatically or without
forethought.  Small assumptions may have large exposures.  Writing
secure protocols is tougher than just writing secure code.

The guys who wrote Diablo or the UOL clients or protocols were not
incompetent.  They did however not realise how hostile the
environment they were operating in was.  This fact alone cost both
companies significantly.

>From the laws:

  Never trust the client.
  Never put anything on the client. The client is in the hands
  of the enemy. Never ever ever forget this.

> Are most security holes that a MUD box might have at the OS level,
> or does having a program like a MUD running open up opportunities
> that would not otherwise exist (assuming that the ability to issue
> OS commands and such is not a feature)?

Both levels of exploit can exist, but the primary concerns are:

  Does the server run as a privileged user? (ie Can an exploit can
gain at least that level of access?).

  Is the server or any other eassociated code capable of being
exploited?  (ie Can any user can get all the access the server's
user has?).

  Does the server or associated programs expose weaknesses in the
host system?  (While comparitively rare, these do exist tho usually
in the form of DoS attacks).

The documents referenced by the library discuss the area at more
length eithout doing much more than trifling with the area.  

Before you start you need to define what your level of security is.
What actions are acceptable for your users, and what are not.  Some
of my metrics, for instance:

  I do not allow shell accounts on Kanga.Nu.  Period.  

  The only person who can run arbitrary commands on Kanga.Nu is me.

  All user authentication shall be by known secure and encrypted
  means (ie SSH v1.x or telnet-ssl).

  All public services shall run as the user "nobody".

  No services or ports, other than the absolute minimum required for
  operation shall be exposed.

  Where possible all exposed ports will filter to the exact IP
  ranges that are allowed to connect to them.  (TCP Wrappers)

There are obvious exceptions to this in the current Kanga.Nu: my MTA
(Exim) and wu-ftpd both run as root.  The various DB services
(Library, UdmSearch, Poll (coming soon), Zope etc) have other
exposures and are something I need to spend some research time on.

However this somewhat outside of the area of server design and
implementation.  

> Also, I am very curious about Kanga.Nu being "regularly attacked."

Port scans, ping floods, smurf attacks, SYN floods, attempted stack
exploits, regular probes for known buggy CGI's, weird attempted
logins from odd sources, etc.

> Would you (JCL or others) be able to describe the kind of attacks
> these usually are?  

Nothing terribly unusual to date.  Recently my FTP server has been
getting a lot of attention from Script Kiddies.  No holes _yet_, but 
I want to get off wu-ftpd PDQ and get onto something that runs with
no rights and does AFTP only.

> How you might prevent them from working, etc.  :)

I don't believe in security thru obscurity for the general case.
There are certain cases where it is useful, but not to rely on.

--
J C Lawrence                              Internet: claw at kanga.nu
----------(*)                            Internet: coder at kanga.nu
...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...


_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev