Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: sourceserver.info. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

1

Sonntag, 13. Februar 2011, 22:35

Der Protection Modus ist absolut unsicher!

Ich habe bei zwei Anbietern, mit deren Einverständnis einmal getestet, ob der so genannte Protected Modus wirklich sicher ist. Im konkreten Fall war das Ziel Metmod auf einem Protected Server zum laufen zu bringen.
Das Ergebnis war erschreckend.
Ca. 1 Minute, und bei beiden lief Metamod. Dabei muss man nichtmal hacken/cracken, sondern nutzt nur einen Servercommand der HL2 Engine aus.

Mit Beweisbildern findet sich eine komplette Anleitung mit Lösungsvorschlag für das Problem, wie man dieses Vorgehen verhindern kann, unter folgendem Link:
http://www.ulrich-block.de/?p=940

Einer der beiden Anbieter hatte dabei das ESL Zertifikat. Ich frage mich jetzt, wie es bei anderen zertifizierten Hostern aussieht und auf welche Weise die Anbieter von der ESL getestet, bevor man ihnen das Zertifikat verleiht.

Auf jeden Fall werden einige Hoster nachbessern müssen.
Webbasierender Config Ersteller: www.ulrich-block.de für CS 1.6, CSS, DODS und TF2.

Ebenso wird werden verschiedene Debian Gameserverkernel zum Download angeboten.

Kathy

Fortgeschrittener

Beiträge: 523

Wohnort: München

Beruf: Roaster/Freelance Editor

Rootserver vorhanden: Ja

  • Nachricht senden

2

Montag, 14. Februar 2011, 01:14

Ich habe deinen post mal ueber twitter ueber den sosi account geschickt. :D


NTcgNjggNmYgNjEgMmUgMjAgNDQgNjUgNmEgNjEgMjAgNzYgNzUgMmU=

Wer weiss was das ist?

3

Montag, 14. Februar 2011, 08:26

Das war ja schon seit ein paar Monaten bekannt. Jeder, der die hlds Mailinglist liest und etwas auf seinen Ruf bedacht ist, hätte sein System angepasst ;)

Wobei ich jetzt nicht weiß, was schlimmer ist.
Kenntnis von der Lücke zu haben und nichts zu tun, oder aber sich gar nicht erst über die eingesetzte Software auf dem laufenden zu halten.
Webbasierender Config Ersteller: www.ulrich-block.de für CS 1.6, CSS, DODS und TF2.

Ebenso wird werden verschiedene Debian Gameserverkernel zum Download angeboten.

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »Terrorkarotte« (14. Februar 2011, 08:50)


4

Montag, 14. Februar 2011, 09:36

ist eventuell schwierig sowas überhaupt zu verhindern. auf jeden fall müsste man dann auch noch spraylogos verhindern, sonst läd nacher jemand ein plugin als spraylogo hoch... und was weiß ich was es noch alles für tricks gibt.
http://fpsmeter.org
http://wiki.fragaholics.de (Linux Kernel HOWTO!)
http://www.fragaholics.de

Bitte keine technischen Fragen per PM!

5

Montag, 14. Februar 2011, 10:06

Das umbenennen der Dateien/uploaden und nachladen habe ich auch probiert.
Konkret hatte ich die server.so in server.bsp umbenannt. In diesem Fall hat es nicht geklappt, den Spaß nachzuladen. Ob es jetzt an Metamod liegt, oder generell nicht geht, kann ich nicht sagen

Bei Maps kann man auch relativ einfach verifizieren, ob es sich wirklich um eine Map handelt.

Quellcode

1
if [[ `grep "info_player_" mapname.bsp` ]]; then echo "ist ne map" 


Bei Spraylogos müsste halt das Schreibrecht für den betroffenen Ordner entzogen werden, um sicherzustellen, das nichts geuploaded werden kann.
Webbasierender Config Ersteller: www.ulrich-block.de für CS 1.6, CSS, DODS und TF2.

Ebenso wird werden verschiedene Debian Gameserverkernel zum Download angeboten.

MadMakz

Super Moderator

Beiträge: 1 878

Wohnort: ~#

Rootserver vorhanden: Ja

  • Nachricht senden

6

Montag, 14. Februar 2011, 10:57

ist eventuell schwierig sowas überhaupt zu verhindern. auf jeden fall müsste man dann auch noch spraylogos verhindern, sonst läd nacher jemand ein plugin als spraylogo hoch... und was weiß ich was es noch alles für tricks gibt.
sv_allowupload anzuschalten macht auf einem matchserver onehin nicht viel sin bzw ist es eine sache die man wirklich nicht braucht. für alles andere gibt/gab es dfens von voogru.

man könnte auch darüber diskutieren ob VALVE das pluginsystem komplett deaktivieren sollte wenn sv_pure = 2 gesetzt.

das würde so alleine zwar auch dinge wie zBlock unmöglich machen, aber da VALVE seit TF2 eigentlich sehr community angagiert ist könnte man eine plugin whitelist aushandeln wenn man eine humane diskussion führt. wie zuletzt das fixen des sv_allowupload exploits welches ebenfalls mit einer internen whitelist arbeitet.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »MadMakz« (14. Februar 2011, 11:05)


7

Montag, 14. Februar 2011, 12:07

Super wieder eine Funktion die nicht richtig funktioniert. Aber gerade diese sollte doch eigentlich Sicherheit bringen.


DeaD_EyE

Administrator

Beiträge: 3 980

Wohnort: Hagen

Beruf: Mechatroniker (didaktische Systeme)

Rootserver vorhanden: Nein

  • Nachricht senden

8

Montag, 14. Februar 2011, 17:50

ist eventuell schwierig sowas überhaupt zu verhindern. auf jeden fall müsste man dann auch noch spraylogos verhindern, sonst läd nacher jemand ein plugin als spraylogo hoch... und was weiß ich was es noch alles für tricks gibt.
sv_allowupload anzuschalten macht auf einem matchserver onehin nicht viel sin bzw ist es eine sache die man wirklich nicht braucht. für alles andere gibt/gab es dfens von voogru.

man könnte auch darüber diskutieren ob VALVE das pluginsystem komplett deaktivieren sollte wenn sv_pure = 2 gesetzt.

das würde so alleine zwar auch dinge wie zBlock unmöglich machen, aber da VALVE seit TF2 eigentlich sehr community angagiert ist könnte man eine plugin whitelist aushandeln wenn man eine humane diskussion führt. wie zuletzt das fixen des sv_allowupload exploits welches ebenfalls mit einer internen whitelist arbeitet.

Das wird nicht umgesetzt, da viele Admins sv_pure 2 für Server einsetzen, die auch mit Plugins laufen.
Man könnte sv_pure 3 einsetzen, welches wiederum für Matchserver nicht eingesetzt werden könnte, weil zBlock Pflicht ist.
Des weiteren wäre die Umsetzung kompliziert, da Plugins schon vor dem Laden der Configs initialisiert werden.

Mögliche Lösungsansätze
  • Das Laden von Plugins, die außerhalb von addons/ liegen unterbinden.
  • sv_pure 3/4 einführen
    3 = Plugins per Startbefehl laden
    4 = Plugins nicht laden
    Wäre aber wie bereits beschrieben wäre das recht schwer umzusetzen
  • Neue Optionsschalter: -noplugins / -noplugins_after_start / -plugin_load ../cstrike/zblock.so
    Nach einem Update von zBlock müsste der Server neugestartet werden. Das ist soweit ich weiß jetzt schon so.
  • Die vorzeitige einfachste billigste Lösung: +alias plugin_load
    valve.rc (schreibgeschützt)

    Quellcode

    1
    
    alias plugin_load "echo This command is not allowed in protection mode"

    Kennt jemand einen Befehl um einen alias zu löschen?

9

Montag, 14. Februar 2011, 18:27

Jop zBlock installieren...
Webbasierender Config Ersteller: www.ulrich-block.de für CS 1.6, CSS, DODS und TF2.

Ebenso wird werden verschiedene Debian Gameserverkernel zum Download angeboten.

DeaD_EyE

Administrator

Beiträge: 3 980

Wohnort: Hagen

Beruf: Mechatroniker (didaktische Systeme)

Rootserver vorhanden: Nein

  • Nachricht senden

10

Montag, 14. Februar 2011, 18:38

Siehe ESL-Post:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
./srcds_run -game cstrike +map de_inferno -autoupdate +alias plugin_load
 
 ....
 
 
 [zBlock] Forcing map: "maps/de_inferno.bsp"
 --------------------------------------------------------
 sv_pure value unchanged (current value is 2).
 --------------------------------------------------------
 EVERYONE CAN BUY!
 Connection to Steam servers successful.
    VAC secure mode is activated.
 plugin_load
 alias
 Current alias commands:
 plugin_load :
 
 plugin_print
 Loaded plugins:
 ---------------------
 0:  	"zBlock Server Plugin [4.5]"
 ---------------------


PS:

Quellcode

1
2
3
4
5
6
cvar list
--------------
alias                                    : cmd      :                  : Alias a command. [zBlock]
alias                                    : cmd      :                  : Alias a command.
--------------
  2 convars/concommands for [alias]

Du meinst sicher das. Irgendwas wird abgefangen. Sicherlich verschiedene aliase, die Clientseitig nicht gestzt werden sollen oder serverseitig nicht erlaubt sind. "plugin_load" gehört nicht dazu.

Ähnliche Themen