Jump to content

Protected Mode - Valve


Stryker

Is Protected Mode A Possibility With TCAdmin?  

9 members have voted

  1. 1. Is Protected Mode A Possibility With TCAdmin?

    • Yes
      4
    • Maybe
      2
    • No
      3


Recommended Posts

Server Protected Mode for Source/Half life engine games built in to TCAdmin!

 

How to protect a game server?

It should be in your interest that your server cannot be

hacked or used with server side cheats. Take care to ensure that your

usability is not affected - your users are still able to modify their

servers how they wish. The best solution is having the option to

switch ?protected? mode on and off, with a publicly accessible log

to show when the server was and wasn't protected.

Why is protection necessary?

Research has shown that there are several motives to manipulate a game server. The most obvious

motive is to manipulate the game in a way that gives certain players or a team an advantage against

their opponent. It is also common to manipulate a server slightly in favour of the opponent. For

example, giving your opponent some unexplainable kills, which upon analysis of demos would give

the impression that they cheated instead, and then using this as leverage for blackmail. This not only

possible by changing files on the FTP directly, but also by hijacking the system, infecting other

systems or through security holes of the system. The following procedures and implementations are

standardised to prevent game server manipulations in multiple game server hosting setups.

Possible vectors of attacking a game server

There are multiple possible vectors of attack, but not all of them will always work for all providers.

Attacking by FTP is possible wherever files which will be executed by the game server can be

altered or replaced. This does not only include the game server engine's binaries, but all of the

start/stop and maintenance scripts too. Attacking by modification is possible wherever the customer

has the option of somehow adding modifications to his game server Most, if not all gameserver

providers permitted and up to a point encouraged the use of helpful server admin tools such as

Admin-Mod, StatsME, Mani ? but these are also simple ways of installing harmful modifications

too. Any and all known modifications to a gameserver rely on changing the contents of the binary

files in the image, or by altering the game servers configuration files of which modules are to load.

In the end it all comes down to the integrity of the core engine itself, e.g. the content of the /addons

folder, and the content of the liblist.gam. Therefore, even a game server image that has been verified

is only secure as long as no one can edit or alter the files of the running game server in any way.

Early implementations of ?secure certified game servers? showed a promising start by disabling

FTP access when switching to ?protected mode? and throwing out any changes made to the server

in the process. But if the user can create for themselves a ?backdoor? into the system, both this

verification and denial of FTP to the protected image does not help. Sadly, it is a well documented

fact that there are multiple ways to fork a shell or execute commands from a running unprotected

 

Measures to secure a gameserver

These serious implications arise from users being able to execute commands or modify files on the

machine running their game server, and can only be prevented through the use of multiple security

measures. In the process of switching from insecure to secure, several steps have to be taken:

At no time should a user be able to edit/write a script that can be executed by the gameserver. This

does not only include hlds_run or similar scripts, but any and all files that can be executed,

including all gameserver engine files which can be swapped for a binary an attacker would like to

run.

Therefore FTP, SSH or any other method of direct access to the gameserver should be disabled in

protected mode. Any open FTP, SSH etc sessions must be killed, and all processes belonging to the

user must be killed. including all spawned child processes and background processes. The

maximum number of running processes should be limited to the number needed by the gameserver

(usually 1). Users should not be able to run processes other than the gameserver itself. This includes

disabling things like crontabs.

 

The gameserver should be restored to its original state (e.g. a known clean image), e.g. using rsync

to overwrite the modified files, or trashing the UnionFS-Layer the user had access to, keeping the

underlying unmodified one.

 

Config files, custom maps and addons that are known to be safe should all configured exclusively

through a web interface.

 

If there are multiple gameservers or users on the same box, they must be securely separated so that

they cannot interfere with each other. E.g. they should be seperated by chroot jails.

 

As a last resort, in order to prevent e.g. a user setting up a bindshell to a random port, iptable rules

should be setup to restrict to only the ports the user needs. Rumour has it, that some server

manipulations use a sidechannel for control and communication with a manipulated client.

The usage of IDS and rootkit detection software is highly encourage to keep an eye out for

intruders.

 

 

Summary:

Finally, in order to prove when the server is in protected mode (for opponents and admins), a

publicly accessible log needs to be available. For example, a web interface where anyone can enter

the server details (ip:port) and return the timestamped history of when the server went in and out of

protected mode.

To summarize, suggested requirements are:

? secure means of configuring/customizing game server (web)

? resetting game server image on switch to ?secure mode?

? killing all processes of the game server user when switching

? cleaning out any reoccurring tasks that user might have (cron)

? limit the number of allowed concurrent running processes

? interface to get current server state (in)secure, changelog

? separate each customer in his own, restrictive chroot jail

? firewall to block all unwanted traffic to unneeded ports

? intrusion-detection systems and rootkit-detection programs

 

Build this into TCAdmin and you are GOD

Edited by Stryker
Link to comment
Share on other sites

  • 1 month later...

Yeah there are a lot of ESL cetificate GSP's who've chosen another route simply because protecting valve servers from hackers is a project on its own and requires extensive deveopment knowledge.

 

If some one ever makes protected mode for CS and 1.6 ready and pending implementation on TCA 2.0, post here.

 

Hurry-up-sign.jpg

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Who's Online   0 Members, 0 Anonymous, 16 Guests (See full list)

    • There are no registered users currently online
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Terms of Use