Difference between revisions of "Securing Subgame"

Latest revision as of 00:22, 9 January 2014

There are several game configuration values which should be set to secure your game server. Some items below may refer to a specific game server such as Subgame or ASSS while others are more global knowledge which applies to both. This initial list was created by L.C. on a server forum post.

1. Generate new scrty and scrty1 files. You should do this for EACH instance of subgame2.exe/asss.exe. By generating new scrty and scrty1 files, the security checksum for your zone become unique for your zone. If all zones had the same scrty and scrty1 files, if one zone's encryption was broken, then everyone would be screwed. But if you use a unique pair of security-encryption files for your zone, you are safe from broken encryptions of other zones.

To generate new scrty and scrty1 files, run "Continuum.exe Z" in the command line and Continuum will generate new files. Just overwrite your old files with these new ones. Repeat this step for each instance and installation of subgame2.exe/asss.exe.

Source: http://sharvil.nanavati.net/projects/subspace/encryption.html

2. Place your ss:// address at the very beginning of the zone description. If you do not know what your address is, you probably do not have one. You must have a fully qualified domain name in order to use this feature. The reason for placing this address at the beginning of the zone description is to ensure and guarantee that this feature will be used; this will also make sure that no too long of a zone description will push your ss:// address beyond the maximum character limit, rendering this feature functionless.

The importance of ss:// is so that if the IP address of your server changes, players do not have to manually go and re-update their zone lists to get the new IP. Instead, Continuum will automatically check that address and update their zone lists for them -- and that way there will be no confusion about what happened to your zones as a result of an IP change.

3. Set CheckMod, CheckSMod, and CheckSysop to 1 in your server.ini. This will prevent unauthorized players from being able to login with staff powers if they happen to know the correct passwords.

4. Generate a random NamePassword under [Directory] in server.ini. Although unlikely, this will secure your zone's publishing in the directory server listings. You should use a unique password for each instance and installation of subgame2.exe/asss.exe. Unless someone figures out this password, nobody can hijack your zone's name in the listing. I would recommend using http://www.goodpassword.com/ to generate something that is preferably at least 13 characters and includes symbols. Then take that randomly generated password and feed it into http://gtools.org/tool/md5-hash-generator/ to get an MD5 of this password. Use this generated MD5 checksum as your NamePassword.

5. Consider using the following settings under [Misc] in server.ini: Quote: AllowPrerelease=1 // 0 = People with newer Continuum clients are not allowed to enter // 1 = People with newer Continuum clients are allowed to enter and play

ForceContinuumOnly=1 // 0 = The Continuum client is not required to be able to connect to the zone; old Subspace v1.35 clients will be able to connect // 1 = The Continuum client is required to be able to connect to the zone

AllowVIEClients=0 // 0 = Disalllow people from playing in your zone with the old Subspace v1.35 client // 1 = Allow people to play in your zone with the old Subspace v1.35 client

ForceObsceneCheck=1 // 0 = Normal or obscene checking on usernames is disabled // 1 = Obscene checking on usernames is enabled

CheckWeapons=1 // 1 = Will kick players that are violating the zone security settings through invalid or impossible uses of weapons if SecurityKickoff under [Security] in server.cfg is set to 1

CheckFastBombing=1 // 1 = Will check to see if a player is invalidly firing more bombs than possible

6. Consider using the following setting for ArenaMode: Quote: ArenaMode=5 // 1 = Any player can create their own subarena // 2 = Only moderators (Mod) and above can create subarenas // 3 = Only super moderators (SMod) and above can create subarenas // 4 = Only system operators (SysOp) can create subarenas // 5 = All subarenas will use spawn.cfg for settings, only system operators (SysOp) can create subarenas [Default] Be sure to make a copy of default SVS server.cfg file and rename it to spawn.cfg. By setting it to 5, you will prevent a million *.cfg files from being created in your zone's directory. However, you may need to manually create a *.cfg file for a subarena that you would like to create. I have heard that by setting this to 5, modifying the settings of any subarena (or arena that is not the public arena) will modify server.cfg/spawn.cfg. You may want to play around with this a little to figure out how to create subarenas, but overall -- you will save yourself and your system the trouble of the unnecessary creation of settings configuration files for each subarena that a player ?go's to in your zone.