Kommentarlose Löschung von Themen

[Firewire2002]

Von solchen Dingen zu sprechen und es im kleinen bei sich zu testen geht immer schnell. Industriell skalierbare Wege zu bauen ist da schon etwas komplexer.

Ohne weiter auf das Thema einzugehen, kann ich dieser Aussage nur zu stimmen. Ich arbeite ebenfalls regelmäßig mit größeren Umgebungen und man erlebt immer wieder Überraschungen, obwohl es doch mit 2-3 Hosts im Test problemlos lief.
Das betrifft nicht nur Gameserver sondern auch viele andere Gebiete der IT. Wer allen ernstes was anderes behauptet, hat in der Tat noch nicht viel Erfahrung mit größeren Setups.

 

[Deleted member 11740]

Es kommt immer drauf an, wie man es organisiert. Wenn man 100 Hosts hat, dann fängt man nicht an wie wild die Spiele auf den Hosts zu mischen.

Da gibt es dann einen Host für CS:S, einen für DOD:S, .... usw. Das Symlinks funktionieren in Verbindung mit Gameserver haben Anbieter schon zu Zeiten von CS1.6 getestet. Will ein Kunde z.B. ein Backup von seinem GS, kann z.B. das Backupscript die Symlinks ausschließen. Dann hat jedes Backup eines Servers gerade mal 20-30 MB, wenn Plugins installiert sind. Wenn man dies bei einer Vollinstallation ohne Symlinks machen würde, müsste man wieder mit Dateilisten arbeiten. Naja, mir eigentlich auch egal, da ich nicht 100 Hosts managen muss und auch nie Kunde bei einem Anbieter sein werde, der ohne Symlinks arbeitet.

Zu dem restlichen blabla äußer ich mich jetzt mal nicht.

PS: Seit wann ist das veröffentlichen von Sicherheitslücken damit gleichzusetzen, dass ein Produkt durch den Dreck gezogen wird?

 

[DjTom-i]

Es kommt immer drauf an, wie man es organisiert. Wenn man 100 Hosts hat, dann fängt man nicht an wie wild die Spiele auf den Hosts zu mischen.

Zwischen Theorie und Praxis liegen auch noch betriebswirtschaftliche Aspekte, die du überhaupt nicht abschätzen kannst.

Das Symlinks funktionieren in Verbindung mit Gameserver haben Anbieter

zwischen funktionieren und performanten Gameservern liegt das was du noch nicht hast: Erfahrung aus der Praxis mit mehreren 100 Hosts.

Zu dem restlichen blabla äußer ich mich jetzt mal nicht.

Ist vollkommen ok. Mir wäre auch lieber wenn diese ganze Diskussion in einem völlig anderen Zusammenhang stattfinden würde.

PS: Seit wann ist das veröffentlichen von Sicherheitslücken damit gleichzusetzen, dass ein Produkt durch den Dreck gezogen wird?

Weil Ihr keine Sicherheitslücken aufgedeckt habt sondern systembedingte Gegebenheiten aufzeigt die seit Jahren bekannt sind und es lächerlich ist das der "Protection Mode" in dieser Form überhaupt existiert. Da aber Teklab nach vorne schiebt als wäre er der schuldige.

Ich wünschte Ihr würdet euch auf das konzentrieren was Ihr offenbar gut könnt: Das System insgesamt in Frage zu stellen und zu verbessern ohne den Coder eines einzelnen Interface öffentlich zu diffarmieren. Nur weil er evtl kein Bock auf eine Zusammenarbeit mit euch hat. Der Zusammenhang zwischen dir und dem anderen welcher wohl ein anderes Interface programmiert ist nunmal gegeben auch wenn du es abstreitest, somit ist das ganze einfach wettbewerbsrechtlich unfair und da sollte man schon seine Marke verteidigen. Würde ich auch nicht anders tun.

Wenn Ihr hingegen XSS, MySQL, Remote File Inclusions innerhalb der Php-Programmierung gefunden hättet und Teklab hätte euch ignoriert und uns Hoster somit einer direkten durch Ihn verursachten, und nicht direkt geschlossenen Gefahr ausgesetzt hätte wäre ich sicher der Erste der euch supportet. Aber so kann ich einfach nicht anders als die Dinge einfach versuchen gerade zu biegen, bzw aus einer relativ "neutralen" Ecke, auch wenn ich Teklab vorbelastet bin, ich sehe die sportliche Fairness und die technischen Dinge.

Ich hoffe du verstehst ein wenig warum ich hier auch ein wenig stur bin.

 

[Deleted member 11740]

Zwischen Theorie und Praxis liegen auch noch betriebswirtschaftliche Aspekte, die du überhaupt nicht abschätzen kannst.

Auch wenn ich selbst kein eigenes Unternehmen habe, heißt das noch lange nicht, dass ich es nicht abschätzen könne.

Ich weiß sehr wohl, dass es funktioniert die Hosts nach Spielen/Engine zu trennen. Bei den großen Providern ist es gang und gebe. Unter anderem erleichtert das auch die Verwaltung der Server.

Wenn man einen Host hat, auf dem sich der srcds mit seinen Mods, COD1-3 und 6, BF3 und ET, Q3, UT3. RO1/2 usw. befinden, verliert man leicht den Überblick. Mit einem WI, das Archive entpackt und mit dem man keine Möglichkeit zur zentralisierten Updateverwaltung hat, würde ich das eh nie in Erwägung ziehen. Dafür ist der Zeitaufwand einfach zu groß. Die Zeit fehlt dann wieder an anderen Stellen.

zwischen funktionieren und performanten Gameservern liegt das was du noch nicht hast: Erfahrung aus der Praxis mit mehreren 100 Hosts.

Auch hier muss ich verneinen. Als ich damals meinen ersten GS gemietet habe (digitallabs.de), liefen die Server bereits mit Symlinks. Keine Lags, Server waren sofort up-to-date und eine Neuinstallation dauerte weniger als 30 Sekunden. Als ich Supporter bei dem letzten großen GSP gewesen bin, hatte man dort auch mit Symlinks gearbeitet. Für die sind 100 Hosts Spielzeug. Sie setzen aber auch ihr eigenes WI ein.

Weil Ihr keine Sicherheitslücken aufgedeckt habt sondern systembedingte Gegebenheiten aufzeigt die seit Jahren bekannt sind und es lächerlich ist das der "Protection Mode" in dieser Form überhaupt existiert. Da aber Teklab nach vorne schiebt als wäre er der schuldige.

Die Lücken sind zwar bekannt, aber anscheinend nicht jedem kleinen Hoster. Ich frage mich, wieso es andere Anbieter mit eigenem WI gibt, die unter anderem die Binaries schützen. Lächerlich ist nur, wie der Protection-Mode eingeführt worden ist. Die Umsetzung sollen die Provider machen. Es können nur Provider zertifiziert werden. Ein WI wird von der ESL nicht zertifiziert. Das sind alles Informationen, die man im Laufe der Zeit bekommt. Unter anderem kenne ich auch schon die neuen Bedingungen für das Zertifikat. Mit diesen Anforderungen werden es nur ganz wenige schaffen, falls sich die Bedingungen nicht ändern.

Ich wünschte Ihr würdet euch auf das konzentrieren was Ihr offenbar gut könnt: Das System insgesamt in Frage zu stellen und zu verbessern ohne den Coder eines einzelnen Interface öffentlich zu diffarmieren.

....

Wenn Ihr hingegen XSS, MySQL, Remote File Inclusions innerhalb der Php-Programmierung gefunden hättet und Teklab hätte euch ignoriert und uns Hoster somit einer direkten durch Ihn verursachten, und nicht direkt geschlossenen Gefahr ausgesetzt hätte wäre ich sicher der Erste der euch supportet.

Der Tag hat leider nur 24 Stunden und ich verdiene meine Brötchen nicht in der IT. Ich glaube das ist hier vielen noch nicht klar. Ich habe in meinem Leben weder Studiert, noch eine Ausbildung in Richtung IT abgeschlossen. Wenn ich also als Privatperson noch Personen unterstützen müsste, die in der IT ihre Brötchen verdienen, so haben die Leute meiner Meinung nach ihren Beruf verfehlt.

Für meinen Teil werde ich zum Thema Teklab nichts mehr großartiges schreiben. Wir haben die Lücken nun öfters angemahnt und da es wohl angeblich gefixt ist, dürfte es dort ja keine Probleme mehr geben.

Sobald die ESL den Providern die neuen Informationen zugesendet hat, fangen wir erneut mit dem Ausgibigen testen an. Wir beschränken unsere Energie nur auf das Finden von solchen Lücken. Vorschläge dies zu fixen werden wir nicht mehr machen. Da es nicht in unserem Aufgabenbereich liegt, müssen sich die Provider darum kümmern Fehler zu beseitigen.

Achja, noch einen Vorteil hat dieser Protection-Mode sicherlich. Mehr Kunden:

http://www.esl.eu/de/css/5on5/ladder/rules/

3.1.2.1. Protected Server

Sollte nur eine der Parteien einen ESL zertifizierten Server stellen können, so wird das Match ausschließlich auf diesem Server ausgetragen.
Dies muss vor dem Match geklärt, geprüft und in den Matchcomments festgehalten werden.
News zu protected Server
Das ESL Gameserver Zertifikat

Da die ESL nun mal mit einer der größten Liga ist, sollte man nicht vergessen, dass es auch einige Kunden gibt, die Ligaspiele zocken.

Btw. den Protection-Mode gibt es nicht nur bei CS:S.


PS: Wieso zum Geier sollte es bei einem Host mit 150 Slots es bei Symlinks zu lags kommen. Ganz im Gegenteil. Im Cache befinden sich oft genutzte Dateien. Das ist bei Symlinks wahrscheinlicher, als bei Einzelinstallationen. Da es bei Steam sowiso den Updatezwang gibt und bei vielen anderen Spielen auch, macht es wenig Sinn auf Einzelinstallationen zu setzen. Unter anderem kann man durch geschicktes Scripten genau die Dateien schützen, die nicht verändert werden dürfen. Das sind nun mal die Dateien des Gameservers. Bei einer Einzelinstallation ohne Symlinks müsste man die Berechtigungen wieder anhand von Dateilisten setzen. Selbst der Verzeichniswechsel der Engine, welcher auch notwendig gewesen ist, lässt sich mit Symlinks einfacher aktualisieren. Die längste Zeit hätte der Befehl find -L /home/ -type l -delete in Anspruch genommen.

 

[Terrorkarotte]

Die Aussage alle Anforderungen erfüllt ist relativ. Die wichtigste Voraussetzung ist, dass man keine Servercheats nachladen können darf. Wenn es doch geht, bzw. ging, wie kann man sagen, man erfülle Anforderungen?
Sich hier auf einzelne technische Bedingungen zu beziehen ist schwer, da lange keine gestellt wurden und selbst seitdem es welche gibt, sie eher eine Richtlinie, denn eine genau Anleitung sind.

Es ist vielmehr nur ein Rahmen gesteckt worden, den der einzelne dann auf sein System ausfüllen muss. Wenn bei der Umsetzung Sachen übersehen werden, so dass das Ziel nicht unter allen Begebenheiten erreicht werden kann, warum ist es dann Schuld der ESL?

Dass bei Bekannt werden eines Problems nicht gleich Siegel entzogen werden, sondern Zeit zum Nachbessern gegeben wird, ist normal. Dies insbesondere, da Sicherheit ein fortlaufender Prozess ist. Dass bei den Server in der Zeit der Nachbesserung weiterhin Cheats nachladen kann, bis die Nachbesserungen abgeschlossen sind, liegt ja in der Natur der Sache.
Offiziell gilt er in dieser Zeit weiterhin als sicher, obwohl es technisch möglich ist, Cheats nachzuladen.

Aus dem Antrag für den protection Modus, was man alles machen kann bzw. sollte, um das Ziel "sichere Server" zu erreichen:

Zusammengefasst bedeutet das:
– Gameserverimage resetten
– Alle Prozesse stoppen
– Alle ausstehenden Aktionen müssen abgebrochen werden (cron)
– Die Anzahl der Prozesse muss limitiert werden
– Die Gameserver seperieren (chroot jail)
– Firewall-Regeln für ungewollten Traffic und Ports
– Intrusion-Detection System und Rootkit-Detection Programme

Diese Liste wurde zumindest Mitte diesen Jahres so schon verschickt.

Zumindest der Punkt "Alle Prozesse stoppen" wird, oder wurde von einigen Webinterface Lösungen nicht sauber umgesetzt, so dass folgendes Spiel möglich ist, bzw. war:
- Über manipuliertes Startskript, oder Shell Plugin eine Reverse Shell öffnen, die vom Gameserverprozess losgelöst ist.
- Einen Gameserver aus den ungesicherten Verzeichnis starten.
- Den angeblich sicheren protection Mode laden.
- Während GB an Daten gezogen, bzw. entpackt werden.

Was das Statement der ESL betrifft, wurde lediglich gesagt, dass es die Sache Dritter ist, was sie als Privatpersonen sagen.
Ein Interface hat sie noch nie zertifiziert oder bestätigt. Zertifiziert und bestätigt wird immer nur der einzelne Hoster, der die Software anwendet und gegebenen Falls zusätzliche Maßnahmen ergreift.

PS:
Das Ganze ist allgemein für Webinterface Lösungen zu verstehen und nicht nur auf ein einziges bezogen.

Nachtrag:
Mich wundert es etwas, warum es alles so dargestellt wird, als wenn man alleinig auf Teklab herum hacken würde. Es wurden mehrere Produkte genannt, bei denen das oben beschriebene Vorgehen zum Erfolg geführt hat.

Da du über diese Systemschwächen ja anscheinend schon so lange Bescheid weißt und angeblich der größte Kritiker bist, frage ich mich, warum es dennoch bei dem Produkt ging, dass du, nach eigener Aussage, konstruktiv kritisierst.