Sicherheitskonzept

[TKausL]

Hallo,

ich stelle mir derzeit eine Sicherheitsfrage. Folgendes Problem:
Ich habe mehrere Server, 2 von denen sind relevant.

Auf Server1 läuft die Webseite mit Forum und co, auf Server2 läuft ein Gameserver.
Bisher war es so, dass man sich für das Spiel extra nochmal ingame registrieren musste.

Allerdings möchte ich jetzt Forum + Game verbinden, sodass man sich mit den Forendaten einloggt.
Problem ist jetzt natürlich, dass die Datenbank auf Server1 liegt, der Gameserver auf Server2.
Es geht jetzt nur um das Verifizieren der Logindaten.


Meine ansätze:

1.: Ich öffne in dem MySQL-Server díe Verbindungen von außen, gebe die rechte fürs Connecten von außerhalb aber nur einem bestimmten User, der dann auch nur Leserechte hat.

2.: Ein kleines PHP-Skript übernimmt per GET die logindaten und überprüft diese. Der Java-Gameserver ruft dann das Skript auf.

3.: Auf Server1 läuft ein Mini-Java-Server auf einem geheimen Port. Der Gameserver kann dann zu diesem Mini-Server auf Server1 verbinden und die Logindaten überprüfen lassen. Der Mini-Server tut NICHTS, außer logindaten checken und das ergebnis zu returnen. Außerdem nimmt der Mini-Server nur Connections von der IP des Gameservers an.


So nun frage ich mich, was Performancemäßig am besten ist, was allerdings auch Sicher ist.

 

[irgendjemand]

also 2. würde mir noch nicht mal in den sinn kommen da man *wenn nicht genug gesichert* mit ner bruteforce-bombe und eventuellen SQL-injections sehr leicht an existierende daten kommt ... daher definitiv zu unsicher

1.) wenn überhaupt dann würde ich hier eine gesicherte verbindung via SSL/TLS oder SSH aufbauen ... da SQL soweit ich weis text/plain ist ...
auch würde ich natürlich im HOST-feld die ip von Server2 eintragen ... damit also nur verbindungen von diesem zulassen ...
dessweiteren zur weiteren absicherung : client-zertifikat ... im prinzip das selbe wie bei HTTPS ... nur halt mit vertauschten rollen
und ganz wichtig : PORT ÄNDERN ! selbst wenn du alle 3 vorherigen sicherheitsmaßnahmen ergriffen hast kann man den sql-server selbst noch mit nem DDoS abschießen ... daher also wenn möglich noch den port ändern ...

3.) klingt soweit ganz gut ... hat auch einige vorteile
1) nur DU weist welche daten wie übertragen werden
2) in java lassen sich einfach gesicherte verbindungen aufbauen *RSA/AES via Cipher*Stream* mit sehr geringem overhead
3) man könnte das ganze *wenn der game-server auch in java geschrieben ist* dierekt mit ein ander verbinden *stichwort : RMI*

ob nun 1) oder 3) ... ich wüsste selbst nicht was ich nehmen würde ... je nach dem worauf ich grade lust hätte ... aber 2) würde ich definitiv NICHT verwenden ...

 

[JohannisderKaeufer]

Dieses Problem oder diese Herausforderung, haben schon mehrere gehabt. Als Ergebnis ist dabei unter anderem OpenID herausgekommen. Ein weiteres Buzzword dazu ist Single-Sign-On.

OpenID funktioniert prinzipiell so, dass es einen Server gibt, auf dem User-Accounts vorhanden sind.

Nun möchte man sich auf einem zweiten Server mit eben diesen Userdaten anmelden.

Für den User sieht es dann so aus, dass wenn er sich auf Server 2 anmelden möchte, er auf Server 1 zu einer LoginSeite geleitet wird. Dort kann er sich anmelden und wenn alles ok ist, wird er auf Server 2 weitergeleitet und ist automatisch angemeldet.

Prominente Beispiele dieser Technik sind Google, Yahoo, Facebook und Twitter. Auf verschiedenen Seiten kann man statt einer mühseligen Registrierung und Anlegen eines neuen Accounts, eine Anmeldung über Twitter wählen, woraufhin man zu Twitter weitergeleitet wird, sich dort anmeldet, bestättigt welche Daten wohin übermittelt werden dürfen und dann auf der neuen Seite eingeloggt ist.

Das verfahren ist gut Dokumentiert und es gibt diverse Implementierungen für dieses Verfahren.

Du könntest also komplett auf OpenID umsteigen und Authentifizierungen über Drittsysteme anbieten, oder nur deine beiden Server als OpenID provider akzeptieren.

 

[TKausL]

@JohannisderKaeufer Danke, werde ich mal drüber nachdenken.

@irgendjemand du verurteilst hier PHP als Unsicher. Bei anständiger Programmierung ist PHP aber genauso sicher wie alles andere auch. Ich denke, ich werde dann erst mal Methode 3 ausprobieren.

 

[homer65]

Letztlich funktionieren alle drei Methoden.
Die Performance dürfte auch bei allen drei Methoden unkritisch sein.
Lediglich was das Thema Sicherheit angeht sehe ich Unterschiede.
Persönlich denke ich, das Methode 3 die kleinste Sicherheitslücke ist.
Du hattest noch nichts zum Betriebssystem der Server gesagt.
Falls es sich um Linux handelt, solltest du darauf achten, das der Mini Java Server nicht mit ROOT Rechten läuft.

 

[schalentier]

Nur mal, weils noch keiner genannt hat: Ich wuerd das ueberhaupt nicht miteinander verbinden, denn im Zweifel veringerst du die Sicherheit des Gesamtsystems. Das ist immer nur so sicher, wie das unsicherste Teilsystem.

Was passieren kann: Steam Hacked, Valve Investigating Possible Credit Card Theft

Gut, dass die nur die Forensoftware gehackt bekommen haben und nicht die eigentlichen Accounts.

 

[TheDarkRose]

Schon mal an einen SSH Tunnel zwischen den System gedacht? Dann brauchst du den MySQL gar nicht nach außen exposen.-

 

[irgendjemand]

@irgendjemand du verurteilst hier PHP als Unsicher. Bei anständiger Programmierung ist PHP aber genauso sicher wie alles andere auch. Ich denke, ich werde dann erst mal Methode 3 ausprobieren.

ich verurteile ja nicht mal PHP selbst ... sondern lediglich die angriffsmöglichkeiten darauf ...

was brauchst du denn wenn du über HTTP auf PHP zugreifen willst ... einen WebServer ... und dieser läuft in der regel auf einem bestimmten port *TCP/80* damit auch deine website normal läuft und so ...

wenn jetzt irgendwer *meinet wegen durch die ROBOT.TXT* auf das file stößt kann er gegen das PHP-script eine bruteforce-bombe laufen lassen *welche dann auch mit ziemlicher wahrscheinlichkeit den webserver falls nicht das gesamte system mit in die knie zieht* ...

heißt also : es ist ein wunder punkt den du so oder so nicht ausschließen kannst ... aber durch vermeidung dieses vorgehens zumindest keine JA/NEIN antwort auf eine USER/PASS kombi rausgibst ...

wenn du hingegen 1.) oder 3.) verwendest muss man erstmal darauf kommen ... die verschlüsselung knacken ... das protokoll kennen ... und dann die daten da i-wie rein / raus bekommen ... was außer mit nem port-scanner schlicht unmöglich wird ...


@TheDarkRose
würdest du dir die mühe machen meinen post zu lesen / verstehen dann hättest du bemerkt das ich SSH bereits in den raum geworfen habe ...

 

[schalentier]

Das Forum nutzt doch zu 99% Wahrscheinlichkeit auch PHP. Wenn PHP per se so unsicher ist, wie irgendjemand behauptet, reicht doch der Angriff darauf. Voellig egal, ob der Gameserver nun 'mylogin.php' oder 'phpbb/login.php' zum authen hernimmt.

Das waere vielleicht sogar Loesung Nummer 4. Log dich vom Gameserver einfach direkt im Forum ein und schau auf den Response-Code, oder lies den <title> Tag aus dem HTML aus.

Ich glaube, man kann hier keine sinnvolle Antwort geben, da die Umstaende unbekannt sind. Gehts um nen kleinen Gameserver fuer 5 Freunde? Oder was groesseres? Willst du was lernen, oder eine Serverfarm absichern?

 

[TKausL]

Das waere vielleicht sogar Loesung Nummer 4. Log dich vom Gameserver einfach direkt im Forum ein und schau auf den Response-Code, oder lies den <title> Tag aus dem HTML aus.

Sorry, aber das ist keine gute idee :lol:

Also, es geht um einem Gameserver auf dem Tagsüber ca. 50 Spieler online sind. In Höchstzeiten bis zu 70.

Ja, klar. Das sind keine Zahlen, aber trotzdem muss alles abgesichert werden.

 

[schalentier]

Sorry, aber das ist keine gute idee :lol:

Warum? Ne Begruendung waere gut ;-)

Das entspricht exakt deinem Ansatz 2 - nur musst du nix programmieren, sondern es geht einfach.

 

[TKausL]

Warum? Ne Begruendung waere gut ;-)

Das entspricht exakt deinem Ansatz 2 - nur musst du nix programmieren, sondern es geht einfach.

Weil dann der User auch als Aktiv angezeigt wird und was weiß ich nicht alles, was dann so alles im WBB passiert. Ich mache es lieber auf Datenbankebene, damit ein Login nichts verändert.