Security on a MUSH (which many feel is an oxymoron already) addresses the needs of the game to provide four or five crucial factors:
- Stable service
- Players should be able to play the game - it should be up reliably.
- Database control
- Players should not be able to modify objects belonging to other players.
- Private player information (email addresses, sites, private conversations) should be inaccessible by unprivileged players.
- Freedom from harassment
- Players should be free of harassment from other players (gross spamming, for example.)
- A fair game
- Players should not be able to use MUSH knowledge to cheat in any game run on the MUSH, particularly if the game is the point of the MUSH.
Unwelcome players can generally be broken down into two major categories: crackers, who threaten stable service and database control, and twinks, who threaten privacy, freedom from harassment, and game fairness. A cracker seeks to destroy the integrity of the game by making it unusable. A twink seeks to destroy the integrity of the game by making it unenjoyable or unfair.
Handling crackers: a philosophy
Some people who try to compromise MUSH security claim that they're doing you a service, by showing you where you MUSH needs shoring up. As Amberyl once put it, this is akin to someone breaking into your house (unasked, of course) to show you that your locks should be repaired.
These folks not only put your game and database at risk, not only might become privy to sensitive information (player email addresses, etc), but destroy the trust which generally exists within the internet and MUSH community. It's no service.
Unfortunately, the crackers usually win, because they have a lot of time to spend trying to compromise your security, while you and your Wizards have more to do than just continually improve it. The goal here, therefore, is to emphasis some easy measures that you can take to deal with attacks on your MUSH.
Handling twinks: a philosophy
While the goal in dealing with crackers is to keep them away from your MUSH or minimize the damage they can do, twinks come in many flavors and require individual response. Many twinks are misguided newbies who, once set straight, become valuable players. Others merely seek to disrupt the game, creating dozens of characters and paging regular players with annoying messages. As Gilbert and Sullivan put it, with twinks it's often best to "let the punishment fit the crime."
The suspect flag makes an excellent first line of defense against suspected problem players. In addition to allowing you to tell when a SUSPECT player connects, disconnects, or changes their name, all actions by SUSPECT players are logged in the MUSH's command.log file, so you can decide if they really pose a threat.
The mugshot script (http://ftp.pennmush.org/Scripts) processes command.log and creates individual suspect files, one per player (by db#), which can be read or searched for keywords or whatnot.
By the way, I think it's good policy for every MUSH to place a statement in news ('news policy' perhaps) noting that while every attempt is made to preserve privacy, you reserve the right to log commands executed in order to maintain MUSH security and/or to fix bugs.
Registration and lockout
Site registration, and site lockout, are strong measures which can be effective in preventing twink invasions. The key to site-based access control is the access.cnf file.
You can control the following aspects of access:
- Whether or not a site can connect to guests
- Whether or not a site can connect to non-guest characters
- Whether or not a site can create characters at the login screen
- Whether denied connections will be logged or not
- Whether or not a site can use the "register" command at the login screen, to request that a character be created and its password be emailed to the player.
- Whether or not a site is suspect. Players who connect from suspect sites are automatically set SUSPECT.
- Which of the above your Wizards can override using @sitelock, and which are set in stone.
access.cnf (in the game directory) is a list of sites and their access control options. When someone connects, the file is read through in order, and the first line which matches their site is used to determine their access options. Order of the file is thus critical.
A line in the file looks like this:
[ ...] [# Comment]
Host patterns may contain the wildcard "*" which will match any number of characters. Patterns can match individual users from sites which run ident servers, but because ident relies on trusting the server and a reasonably speedy network, it's best avoided. Using "*" as the host pattern matches all hosts, and really only makes sense as the last line of the file.
A host which does not match any line in the file is allowed complete access. A host which matches a line with no options listed is banned completely; connections will dropped before the login screen.
There is also a special line in the file:
The "@sitelock" line marks where new additions to the file via the @sitelock command will be added (if your file doesn't contain one, one will be added at the end of the file when someone uses @sitelock). Any lines listed above the @sitelock line can not be overriddent by @sitelock; those listed below can. This allows you to decide which access control rules your Wizards should be able to override.
The available options include:
- allow players from this site to use the 'create' command
- don't allow players from this site to use the 'create' command
- allow players from this site to connect to non-guest characters
- don't allow players from this site to connect to non-guest characters
- allow players from this site to connect to guests
- don't allow players from this site to connect to guests.
- enable the 'register' command at the connection screen. Players may type 'register ' to create a new character and have its (randomly generated) password emailed to the player. Note that this does not disable 'create', so you'll probably want to use this option along with the !create option.
- cause all players connecting from this site to be set SUSPECT. Unless you want SUSPECT guests, you'll probably want to include !guest as well.
- prevents connection denials from being logged to connect.log. This is useful if a cracker is attempting a connection flood, and prevents your logfile from overfilling your disk
The @sitelock command sets the optional comment to inform you of who performed the @sitelock and when.
access.cnf is re-read when the MUSH receives a HUP signal or @readcache is run.
It is updated whenever someone uses @sitelock.
The file game/access.README contains examples of using access.cnf to enforce a variety of different access control policies.
Gagging, booting, guesting, newpasswording and nuking
There are a wide variety of things you can do to discipline a twink player. Amberyl's wiz-ethics lecture discusses many of these, and I, like her, believe that one should "let the punishment fit the crime" which choosing which command to use:
- The GAG flag
- Prevents the player from speaking, a handy response to spammers and those who page obscenities.
- The Guest power
- Restricts a number of commands players can use, depending how how you've set up the command restrictions in mush.cnf. Often prevents any building or attribute-setting.
- The FIXED flag
- This flag prevents the player from using the @tel and home commands. Handy if they keep @tel'ing where they're not wanted.
- Disconnects the player from the MUSH. Nothing, of course, prevents them from reconnecting, unless you lock their site or install a global @aconnect to listen for them connecting and boot them again.
- Changes a player's password. This is the proper way for non-Gods to "nuke" a player, as it doesn't actually result in any data loss, and can be reversed if the twink makes amends. This does no good against twinks who are just creating scratch characters they don't care about. God can also re-name a player without knowing/changing their password, which can have similar effects.
- This is how God cleans players from the database. It's also an appropriate response (along with a sitelock) against crackers.
Coded attacks on the MUSH (privacy, denial of service)
Most twinks just want to rise to ultimate power in your game. But some crackers are interested only in compromising your security in order to destroy and deny the game to others.
Admin passwords must be protected. A cracker who can log in as a Wizard can destroy your database in one command.
Players should not be given wizard-bitted objects if at all possible. Wizard-bitted global commands should be carefully checked for security. One important check is to try calling the command with arguments like "[set(me,visual)]" and "\[set(me,visual)\]" - if the function results in the wizobject becoming visual, it's not secure! (And Wizard globals shouldn't be visual anyway, just in case.) Best is if you can run without FUNCTION_SIDE_EFFECTS.
Be very careful of zones. My policy is that nothing owned by an admin should ever be zoned to a ZMO which has non-admin on the elock. Instead, it should be @chowned to a mortal builder-character and then zoned. You can find ZMO's without elocks by logging in as a mortal and running an @find to see what you control.
In the worst-case scenario, if you somehow lost your entire database, you'd still be okay if you've been making backups of your database every now and then (how often and how many depend on your disk space.) Always have at least one working backup somewhere. And chmod a=r it, too, so you don't accidentally overwrite it! If you really want disaster-recovery, you should keep a database backup on another machine as well, in case your host should crash.