Zugriff von Außen auf MySQL ohne SSL - wie unsicher ist das?

[evgueni]

Hallo!

Ich habe hier zur Zeit folgende Situation: mein Haupt(web)server war überlastet, also habe ich nen zusätzlichen Server bestellt, und habe vor ihn als DB-Server zu benutzen.

Hierzu habe ich versucht einen SSL-Tunnel einzurichten. Leider hat das nicht so ganz geklappt wie ich wollte. Eingerichtet habe ich ja alles, nur hat der sshd dann im laufenden Betrieb ca. 40% CPU-Last erzeugt und irgendwie konnte in 50% der Fälle keine Verbindung zu MySQL aufbauen. Ich vermute also dass der sshd einfach mit den ganzen Verbindungen nicht klargekommen ist.

Jetzt habe ich erstmal ohne SSL das ganze am Laufen, klappt wunderbar. Bisher kein einziger Fehler und um einiges schneller.

Nur, nun meine Frage: kann mir jemand sagen ob ich mir wirklich sorgen machen muss wegen der unversichert übermittelten Daten? Die Server sind im gleichen Rechenzentrum, es wird also nur netzinterner traffic verschickt...

irgendwo hier im forum hatte ich mal die behauptung gelesen, dass es in einem geswitchten netzwerk fast unmöglich sei daten abzuhören. Stimmt das?

Danke schon mal für die Antworten!

[captaincrunch]

Hierzu habe ich versucht einen SSL-Tunnel einzurichten. Leider hat das nicht so ganz geklappt wie ich wollte. Eingerichtet habe ich ja alles, nur hat der sshd dann im laufenden Betrieb ca. 40% CPU-Last erzeugt

SSL != SSH (ich hab's mal etwas hervorgehoben). Ein SSL-Tunnel kannst du recht komfortabel mit Hilfe von stunnel aufbauen, das dürfte dann auch ewtas perfomanter sein.

Um auf deine Frage zurückzukommen:
Zunächst einmal eine Gegenfrage: was für Daten gehen da über die Leitung? "Nur" Nutzdaten, oder auch Passwöretr etc?
Ich persönlich würd's, egal ob netzintern, geswitched, whatever für "schützenswerte" Daten (wie z.B. Passworte) definitiv nicht ohne Tunnel machen. Stichwort: trust no one...

irgendwo hier im forum hatte ich mal die behauptung gelesen, dass es in einem geswitchten netzwerk fast unmöglich sei daten abzuhören. Stimmt das?

Jein. Richtig konfiguriert ist es sehr schwer, die Leitung "abzuhören". Da dies aber (leider) nur in den seltensten Fällen der Fall sein dürfte, würde ich die Aussage beim besten Willen nicht unterschreiben.

[lord_pinhead]

Wie sieht es mit einer anderen VPN Lösung aus, SSL Tunnel dürften nicht ganz so fix sein wie eine VPN Verbindung mit Freeswan. Allerdings kenne ich stunnel nicht, kann dir jetzt nicht sagen ob das wirklich langsamer ist als Freeswan.

Lass am besten nur die IP von deinen Hauptserver auf den MYSQL Port verbinden, alles andere würde ich gar nicht zulassen. Wenn du Postgresql hast kannst du das ja sowisso über die ACL von PGSQL steuern.

Zu CC´s aussage braucht man glaube ich nichts mehr sagen :) Nur ein kurzes Beispiel: Einer meiner "Hoster" war der brüller dieses Jahr (einige Admins kenn die Geschichte *G*). Durch deren tolles Netzwerk bzw. deren Router (switches haben die ja anscheinend nicht) ist immer wieder mal der eine oder andere DNS Request oder ein Syn bei mein Serverinterface gelandet, obwohl er überhaupt nicht dafür bestimmt war (es waren auch keine Broadcasts). Als sie dem ganzen die Krone aufsetzten und anscheinend den kompletten Traffic aus dem Netzsegment auf mein Server schrieben (spitze 8GB pro Stunde), war es aus, seitdem such ich nach ein anderen Hoster in der Preisklasse der bei weitem nicht so blöd ist. Nachdem sie jetzt endlich Ihren Hub (switch kann man deren Zeug ja nicht nennen) ausgewechselt haben, verirren sich auch keine Packete, die nicht für die Kiste bestimmt sind, an den Server. Also nur mal als Beispiel wie schnell bzw. wie dumm manche Provider sein können und du damit die Serversicherheit in Frage stellst. Und ja, auch so mancher Login landete kurz an meiner Kiste, allerdings nur das Synpacket. Das war aber ausbaubar, wer den Hoster kennt weiß worauf ich hinaus will.

Also, bau ein Tunnel auf und gut isses, Hostern kann man ja nicht trauen wie du siehst ;)

[captaincrunch]

Wenn du Postgresql hast kannst du das ja sowisso über die ACL von PGSQL steuern.

...darüber hinaus beherrscht Postgres nativ SSL-verschlüsselte Verbindungen. ;)

Free-/Open und $whateverSWAN sind IMHO für die Geschichte mit Kanonen auf Spatzen geschossen.

[Roger Wilco]

...darüber hinaus beherrscht Postgres nativ SSL-verschlüsselte Verbindungen. ;)

MySQL übrigens auch, und das nicht erst seit Version 5... 8)
-> http://dev.mysql.com/doc/refman/5.0/en/ssl-options.html

[theomega]

Hallo,
ich kann selbst von ungefähr dem gleichen Fall Berichten: Ein Datenbank-Server sollte an einen Web-Server im gleichen Rechenzentrum angebunden werden. Aus genau den oben genannten Gründen war eine unverschlüsselte Lösung nie eine Alternative. Ich habe folgende zwei Lösungen ausprobiert:

1. SSH-Tunnel:
Vorteile:
- Einfach einzurichten, ein Befehl auf dem Client und gut ist

Nachteile:
- Nicht Fail-Safe: Wenn irgendwas schief läuft bricht die Verbindung ab und mann muss sich selbst drum kümmern.
- Tunnel-Server festgelegt auf den MySQL-Server

2. VPN via OpenVPN:
Vorteile:
- Erweiterbar auf mehrere Host, es können auch andere Dinge gleich mit verschlüsselt werden.
- Fail-Safe: Beide Seiten probieren bei einem Fehler einen Neuaufbau der Verbindung.
- Tunnel-Server frei wählbar

Nachteile:
- Einrichten nicht ganz trivial (aber auch nicht schwer).

Beide Lösungen haben jedoch einen entscheidenden Nachteil:
Sie verursachen einen deutlichen Server-Load. Ich habe den Vorteil das ich Server habe die das Hardware-Seitig wegstecken können. Jedoch wäre das nie ein Grund für mich ohne Verschlüsselung zu fahren!

Ich bin im Moment bei einem OpenVPN. Das ist eigentlich perfekt für meine Anwedungen geeignet. Die VPN-Lösung hat jedoch noch ein Problem, das ich jedoch nicht genau zuordnen kann, und ich kann nur vermuten das es am VPN liegt: Manchmal wird mein MySQL mit fehlerhaften Verbindungen geflutet und bricht dann irgendwann zusammen weil MAX_CONNECTIONS erreicht ist. Der MySQL-Server ist ausschließlich per VPN zu erreichen, ich kann also ein Fremdeinwirken ausschließen. Ich vermute ganz stark das dieses Problem an der VPN-Verbindung liegt, kann es aber nicht bestätigen.

Bezüglich XXXSwan-Lösungen: Ich habe mich mal dran versucht, bin jedoch gescheitert unter Debian. Das mit den Kernel-Modulen ist mir dann noch suspekt gewesen. Ich bin mit meiner OpenVPN-Lösung inzwischen eigentlich fast glücklich, einen Vorteil für eine Swan-Lösung gäbe es jedoch: Ein Client auf dem Pocket-PC (Mails abholen), aber das ist das kleinste Problem.

Gruß
TO

[lord_pinhead]

@CC
Das mit SSL hab ich auch noch nicht gewusst :D Hab nur mein ERP und ein paar andere Sachen wie Torrentflux hier lokal mit PGSQL laufen.

Also bisher bin ich relativ zufrieden mit meinen openvpn Tunneln, freeswan hab ich nur mal in der Schule getestet. Leider auch gescheitert am Verbindungsaufbau.

[evgueni]

Danke für die Antworten!

Gibt es denn ein FAQ oder eine Anleitung für VPN-Tunnel? Weil SSH kommt für mich nicht mehr in Frage, das war wirklich nicht auszuhalten...

[theomega]

auf der openvpn seite gibt es eine gute sehr ausführliche Anleitung!

[Roger Wilco]

Gibt es denn ein FAQ oder eine Anleitung für VPN-Tunnel?

Warum benutzt du nicht einfach die native SSL-Verschlüsselung von MySQL?

[evgueni]

Gibt es denn ein FAQ oder eine Anleitung für VPN-Tunnel?

Warum benutzt du nicht einfach die native SSL-Verschlüsselung von MySQL?

mal blöd gefragt... wie mach ich denn das?

soweit ich weiß wird die veschlüsselte mysql-verbindung von php nicht unterstützt, oder irre ich mich?

[pennybridge]

soweit ich weiß wird die veschlüsselte mysql-verbindung von php nicht unterstützt, oder irre ich mich?

Mit MySQLi funktioniert das.
http://de3.php.net/manual/en/function.m ... onnect.php
http://de3.php.net/manual/en/function.m ... sl-set.php

[evgueni]

ok, danke für den link.

Ich habe da mal ein bisschen gelesen. Wenn ich das richtig verstanden habe, gibts die Erweiterung erst ab PHP5. Ich habe noch PHP4 drauf, da müsste ich erst updaten...

Und ich habe in mysqli keine Funktion für Aufbau von persistenten Verbindungen gefunden... Gibt es da keine? :oops:

[Roger Wilco]

RTFM. Das geht auch mit der alten mysql-Erweiterung von PHP 4/5, siehe http://de3.php.net/manual/en/function.mysql-connect.php.

[Joe User]

http://www.php.net/manual/en/features.p ... ctions.php

[evgueni]

hey, das stimmt! tatsächlich!

die beste lösung ist wohl die einfachste!!! die sieht man immer nicht...

ich werde das mal ausprobieren!