Server security

General

It is easy to set up a minimal server, however if you plan to host a server over a long time you should consider some security aspects. General goals:

1. Run the server with an underprivileged user account. This reduces the applications access to local system resources such as the filesystem
2. Run the server in a way that does not require an interactive session. This ensures that the server keeps running independent of any user session.
3. Run the server in a sandbox. Isolate the server process to minimize its ability to affect the local system

The following sections describe these measurements on different platforms. It is presumed that the reader knows how to perform basic administrative tasks such as creating new user accounts.

Microsoft Windows

This section covers the following Windows platforms:

• Windows Server 2000
• Windows Server 2003
• Windows XP Professional Edition
• Windows XP Professional x64 Edition
• Windows XP Media Center Edition 2005

Unfortunately, Windows XP Home Edition is missing some necessary features, so you will be unable to run a server as a service if you are running XP Home.

Running the AC server as a service

Creating an own service for the AC server is a good way to achieve the goals 1. and 2. : It runs the AC server using a configurable user credential and keeps it running independent of any user session.

Start > Run > lusrmgr.msc to access Local Users and Groups.

Error creating thumbnail: /bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_GB.utf8) /bin/bash: line 1: /usr/bin/convert: No such file or directory Error code: 127

The newly created ACserver account listed in the Local Users and Groups window, on Windows XP Professional

1. Create a new user account for the AC server, e.g. a local user account named ACserver.
2. Remove the account from the Users group.
3. Create a new group for game servers, e.g. Gameservers and add the ACserver account to it.
4. Set the correct filesystem permissions, as described below. To enable the Security tab on folder properties, go to My Computer > Tools > Folder Options... > View and uncheck Use simple file sharing (Recommended).
   1. Deny write permission on the system drive (C:\)
   2. Grant execute permission on the \bin_win32 folder
   3. Grant execute permission on the \assaultcube_server.bat file
   4. Grant Read permission on the \config\maprot.cfg file

Linux/Unix

For maximum security - on a machine you have root access to - you should create a dedicated user with no group memberships (except it's own group, of course). If you can and think it safer you might consider using some form of chroot. chown and chmod the files appropriately .. either accessible only for the user as owner and group chown -R acs:acs * (if your user is acs) or maybe you do trust your staff/admins - but be careful with any logfiles and extra careful (chmod 600) with config/serverpwd.cfg. Run the server inside a screen-session. There are also a number of ways to keep a server alive in case it crashes without having to manually interact with the machine. One of the most straight-forward methods is to have some script like the following run periodically via something like cron.

#!/bin/sh

ACdir="/usr/local/games/AC"
ACpsi=`ps aux | grep "bin_unix.\+_server" | grep -v grep | awk '{print $2,$3,$4,$8,$11}'`
ACpid=`echo "$ACpsi"|awk '{print $1}'`
ACstat=`echo "$ACpsi"|awk '{print $4}'`
# you might even want to check $ACstat doesn't contain "Z" .. as in zombie

if [ -z "$ACpid" ]; then

  echo "Couldn't find AC server running, restarting it."
  cd "$ACdir"
  # run the screen session:
  /usr/local/bin/my_screen_session_for_an_AC_server
  # or just try this:
  #nohup ./server.sh &
  echo ""

fi

Very advanced users may even poll the infoport to check for responsiveness and/or gamestate sanity - we leave that as an exercise to you ;-)