mysql-DB auf unserem Root-Server von außen nicht zugreifbar

[pocopelli]

Tach,

wir betreiben bei Hetzner einen Rootserver. Eine Applikation in unserem Hause soll remote auf eine Mysql_DB auf dem, uns aus gesehen, externen Host bei Hetzner zugreifen. Nur dies funktioniert nicht.

Der Mysql-Deamon war gestartet mit

/usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-locking --port=3306 --socket=/var/run/mysqld/mysqld.sock

den hab ich platt gemacht (i.e. kill -9),
in der /etc/mysql/my.cnf hab ich "skip-external-locking" deaktiviert,
die Datei /var/run/mysqld/mysqld.pid gelöscht
und dann den Prozeß neu gestart mit

/usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --port=3306 --socket=/var/run/mysqld/mysqld.sock

aber alles ohne Erfolg. Ein Einloggen von remote geht nicht.
Weiß jemand Rat wie man das bewerkstelligen kann ?

Dank Euch im voraus!

Gruß

Poc

[Roger Wilco]

den hab ich platt gemacht (i.e. kill -9),
in der /etc/mysql/my.cnf hab ich "skip-external-locking" deaktiviert

Das bringt dir nichts, wenn in der my.cnf noch skip-networking steht oder der mysqld nur an das Loopback-Interface gebunden wurde.

Außerdem müssen die Benutzer natürlich die richtigen Rechte haben, um von außen auf die Datenbank zuzugreifen.

[pocopelli]

Hallo !

Dank deiner Hilfe funzt es jetzt. ich hab in my.cnf
bind-address = (unsere IP)
gesetzt und mysql reloaded. Zwischendurch hatte ich dann noch mal den Mysql-Daemon plattgemacht und neugestartet auch mit bind-address auf
unsere IP gestartet, so daß das wahrscheinlich wieder doppelt gemoppelt ist.

wichtig erscheint mir das man mysql reloaded also "/etc/init.de/mysql reload" sagt. Vielleicht interessiert es ja einen.

Falls Dir/Euch Sicherheitsvorkehrungen bekannt sind, die man in solchen Fällen trifft, oder Risiken, bin ich für jede Antwort dankbar.

Fürs erste nochmal vielen Dank ! sehr hilfreiches Forum !

Gruß

Poc

[daemotron]

Risiko: Standardmäßig kommuniziert MySQL unverschlüsselt, Anmeldedaten werden also im Klartext übertragen.

Gegenmaßnahme: SSL-Verschlüsselung in MySQL aktivieren oder gesamte Verbindung in einen VPN-Tunnel packen.

[pocopelli]

yep,

sowas hat ich auch schon gedacht.
Kennst Du evtl. ein gutes Howto.
Bei mysql.de steht ansatzweise was.
Schön wärs, wenn es eine halbwegs zusammenfassende Anleitung gäbe.

bedankt

Poc

[daemotron]

http://dev.mysql.com/doc/refman/5.0/en/ ... tions.html mit Unterkapiteln
http://blog.xl-im.net/index.php?/archiv ... l#extended

[isotopp]

Risiko: Standardmäßig kommuniziert MySQL unverschlüsselt, Anmeldedaten werden also im Klartext übertragen.

Gegenmaßnahme: SSL-Verschlüsselung in MySQL aktivieren oder gesamte Verbindung in einen VPN-Tunnel packen.

Die Authentisierung von MySQL Clients beim Server erfolgt immer mit mit einer Challenge-Response-Authentisierung. Auch bei einer Verbindung, die ansonsten unverschlüsselt ist werden die Anmeldedaten niemals im Klartext übertragen.

[daemotron]

Gut zu wissen... aber besteht dann nicht das Risiko, dass ein Angreifer schon das Challenge-Token abfängt und aus der Antwort des Clients Rückschlüsse ziehen könnte? Zwar nicht trivial (und ohne das Challenge-Token zu kennen sicher aussichtslos), aber IMHO aus technischer Sicht ein ähnliches Problem wie die Passwörter in der /etc/shadow.

[isotopp]

Gut zu wissen... aber besteht dann nicht das Risiko, dass ein Angreifer schon das Challenge-Token abfängt und aus der Antwort des Clients Rückschlüsse ziehen könnte? Zwar nicht trivial (und ohne das Challenge-Token zu kennen sicher aussichtslos), aber IMHO aus technischer Sicht ein ähnliches Problem wie die Passwörter in der /etc/shadow.

Dazu müßtest Du eine kryptographische Hashfunktion zuverlässig invertieren können. Das ist derzeit nicht möglich.

Ein MITM-Angriff, bei dem Du Dich in eine bestehende TCP-Session einhängst wäre einfacher (und ist nur durch SSL zu verhindern).