Sponsor-Board.de

Naja, gehen wir mal von dem Szenario aus, dass ein zentraler MySQL für Gameserver bereitstehen soll, soweit so gut. Die Gameserver würdest Du doch selbst vergeben dann alright? Dann weißt Du folglich auch die IPs von denen und kannst sie in die Firewall eintragen und somit den externen MySQL Zugriff explizit wirklich auf deine eigenen (bekannten) Nutzer beschränken. Angriffe werden dann immerhin schon eine Stufe vor dem MySQL Server abgefangen von der Firewall. Oder ist es wirklich notwendig, jeder x beliebigen IP auf der Welt den zugriff zu erlauben?

Das war nur mein Vorschlag ;-) Im Grunde baut es einfach nur auf deiner Idee auf, da hast Du recht!
Der Unterschied ist halt, so müsste keiner der beiden MySQL Server extern erreichbar sein, sondern anhand der eingehenden IPs (von den Gameservern) kann die FIrewall mit entsprechenden Regeln dann NAT betreiben und somit zum Beispiel

Zugriff von IP 87.65.32.1 auf Port 3306 des Hosts: 123.45.67.8
umleiten per NAT auf: 127.0.0.1:3307

So wäre es von außen auch noch unsichtbar, dass zwei verschiedene MySQL Server laufen -> Der Kunde muss keinen anderen Port angeben und trotzdem laufen zwei ausschließlich intern erreichbare MySQL Server parallel!

//EDIT: Sollte ein Angreifer also herausfinden, dass es überhaupt einen MySQL extern gibt auf Port 3306 und dann noch an der Firewall vorbeikommt so stößt er auf ein nicht-antwortenden MySQL, da dieser in Wirklichkeit nur auf Localhost lauscht.

Verstehst Du in etwa, was ich meine?

Was du meinst ist klar. Gleiche Prinzip wie der Router daheim

ABER, ich vergebe keine GameServer mehr, folglich kann ich auch nicht nur den Zugriff aus meinen Netzen zulassen. Desweiteren betreibe ich ja mit dem Server auch "Reselling" die Reseller wollen vielleicht auch externe Datenbanken anbieten, ohne das diese mir bei jedem Kunden mitteilen müssen von welcher IP er anstrebt diese nun zu nutzen.

Kniffeliger ist es für die Leute die vlt. eine Lokale Anwendung testen möchten, wie soll man eine Dynamische IP einschränken? ^^

Also ich hatte vor ca. 4 Tagen für Visual Basic ein extrens MYSQl gesucht. Aber dannach hab ich das Problem durch PHP gelöst. Die PHP Datei greift auf die locale Datenbank.
Und die gibt "echos" aus. Die man dann in VB abrufen kann. Somit ist das Problem gelöst.

Da bleibt leider in der Tat nicht viel übrig, als den externen Zugriff zuzulassen, wie du es beschrieben hast. Nur würde ich dennoch ein IPtables dazwischenhängen mit NAT, sodass MySQL schonmal nicht ganz am Interface zur außenwelt hängen muss. So hat man immerhin ein wenig die Kontrolle, woher die Anfragen kommen. Wenn ein Reseller eine eigene IP bekommt, dann könnte man sogar die Reseller an verschiedene MySQL Server zuweisen.

Es gibt viele Möglichkeiten mit Firewalls zu arbeiten - aber leider wirds brenzlig, sobald es an dynamische IPs oder Hostnamen geht. Einzige zusätzliche Sicherheitsvorkehrung, die ich noch für den zweiten MySQL Server sehe wäre chrooting oder noch besser, falls du ein kleines VM Netz hast eine Minimal-VM einrichten und dort drauf laufen lassen. Per IPTables wieder umleiten lassen und fertig ist. Sollte das System einmal kompromittiert werden, so kannst Du leicht ein Backup wieder einspielen, in dem du die VM zurücksetzt auf einen regelmäßig erstelltes Image.

Das ist ja der große Vorteil an Virtualisierung, da man dadurch eine quasi-physikalische Trennung von Diensten erreicht
Nach dieser Methode bearbeite ich übrigens das Problem mit den externen MySQL Zugriffen...ist manchmal schon lästig sich darum Gedanken machen zu müssen^^

nills schreibt doch schon die lösung...man verbietet den externen zugriff und nutzt z.B. php als wrapper.

so machen es die "profis" doch auch! Wieso also ein enormes Sicherheitsrisiko eingehen?

Dafür ja einen Zweiten MySQL Server, manchmal geht es nicht anders, wie z.B. bei Gameservern.