MySQL von außen erreichbar - Risiko?

[theSilent]

Hallo zusammen,

ich hoffe, dass es zu dem Thema wirklich noch nichts gibt und ich nicht unnötig einen Thread aufmache - die Suche hat nichts ergeben...

Für ein Projekt brauche ich eventuell für einige Wochen Zugriff von außen auf meinen MySQL Server der auf einem Ubuntu VPS (von Hosteurope) läuft. Zuzeit ist der Zugriff auf MySQL per Firewall blockiert.
Nun frage ich mich, in wie fern die Öffnung das Ports ein Sicherheitsrisiko für meinen Server darstellt.
Ich kann leider den Zugriff auf die entsprechende Datenbank/die User für diese nicht auf eine bestimmte IP oder Range beschränken.
Alle anderen User würde ich direkt im MySQL nur den Zugriff von localhost erlauben.

Wäre klasse, wenn ich dazu ein paar Meinungen, bzw. auch was es noch zu beachten gäbe hören könnte!

Vielen Dank schon mal und

schöne Grüße,

silent

 

[danton]

Wieso tunnelst du die MySQL-Verbindung nicht einfach per SSH über dessen Port-Forwarding-Feature? Dann brauchst du den Port gar nicht extern aufmachen. So würde ich es machen, wenn ich von daheim an die Datenbank auf meinem Server ran müßte.

 

[Ben.]

Prinzipiell ist die Öffnung des Ports zu einem MySQL-Server genauso sicherheitskritisch wie die Öffnung des Ports für SSH.

VPN / Tunnel ist sicherlich etwas eleganter, da du nur einen Port zu überwachen hast bzw. mit Schlüsseln arbeiten kannst, allerdings sehe ich das nicht so kritisch.

Folgendes solltest du einfach überlegen:

1) Wenn jemand per SSH Zugriff auf deinen Server erhält, kann er theoretisch das ganze Dateisystem durchforsten und den Server kompromittieren.
2) Wenn jemand Zugriff auf den MySQL-Server erhält, kann er sämtlich darin enthaltenen Daten lesen/verändern. Dass jemand über einen MySQL-Server einen kompletten Server kompromittiert hat ist mir nicht bekannt.

=> Sind die Daten kritisch (Personendaten) oder ist es einfach eine Webseite in der Entwicklung, für die im schlimmsten Fall ein Backup eingespielt werden kann?

Ich empfehle für jede Datenbank einen eigenen User anzulegen. So kann ein Eindringling zwar auf die eine Datenbank, aber mehr auch nicht. Der Schaden wäre überschaubar.

Abgesehen davon sind Angriffe auf SSH viel häufiger als Angriffe auf MySQL-Server.

 

[Joe User]

Dass jemand über einen MySQL-Server einen kompletten Server kompromittiert hat ist mir nicht bekannt.

Mir schon, war allerdings noch MySQL 4.0 und local-infile aktiviert. Dennoch würde ich per VPN oder SSH tunneln. Ansonsten stimme ich Dir zu.

 

[theSilent]

Danke für eure Antworten!

SSH-Tunnel ist in dem Fall leider keine Option.
Die Daten sind auch nicht kritisch und ja, ich würde nur einen neuen User für die Datenbank anlegen und möglichst nur diesem User Zugriff von außen auf den Server erlauben.

 

[Ben.]

Ich sehe da kein grosses Risiko. Port-Knocking evtl. ne Option?

Du musst es halt im Auge behalten und bei längerer Nicht-Nutzung des Zugangs diesen wieder sperren.

Du kannst die Firewall ja noch entsprechend konfigurieren, dass du über einen anderen Port als 3306 drauf zugreifst. Trägt zwar nur zur gefühlten Sicherheit bei, aber immerhin.

 

[Roger Wilco]

Die Daten sind auch nicht kritisch und ja, ich würde nur einen neuen User für die Datenbank anlegen und möglichst nur diesem User Zugriff von außen auf den Server erlauben.

Dass die Daten dabei komplett unverschlüsselt durch das Netz geschickt werden, ist dir klar? Ich gehe mal nicht davon aus, dass du SSL für MySQL konfiguriert hast, wenn schon ein einfacher SSH-Tunnel keine Option für dich darstellt.

 

[DerMitSkill]

Wenn die Daten unkritisch sind ist's doch recht pups?

 

[Joe User]

SQL-Injection per man-in-the-middle?

 

[Roger Wilco]

Wenn die Daten unkritisch sind ist's doch recht pups?

Richtig, deshalb benutzt man heute auch SMTP-Auth über unverschlüsselte Verbindungen mit PLAIN oder LOGIN Authentifizierungsmechanismus, ruft seine (unwichtigen) Mails über POP3 und IMAP (natürlich ohne SSL/TLS) ab, führt seine Banktransaktionen über HTTP (nicht HTTPS) aus, benutzt kurze Passwörter (möglichst das eigene Geburtsdatum, der eigene Name, oder direkt "Passwort") und loggt sich via rlogin oder Telnet zur Administration auf seinem Server ein. Die Veröffentlichung des eigenen Namens, inklusive Geburtsdatum, Anschrift und der Hobbys auf diversen öffentlich einsehbaren Seiten darf natürlich nicht fehlen.

Die Daten sind ja ggf. unkritisch und damit ist's doch recht "pups", oder?

 

[DerMitSkill]

Der Vergleich hinkt imho..

 

[Joe User]

SQL-Injection per man-in-the-middle?

Um es mal zu verdeutlichen: VServer und Clouds sind hier ganz besonders betroffen, da man auf den Hosts problemlos mitlesen und injecten kann. Und das wird öfter gemacht, als man vermuten mag, nicht nur bei SQL...

 

[d4f]

Um es mal zusammen zu fassen:
- MySQL remote Zugriff von einer externen IP benoetigt
- keine hochsensiblen Daten in der Datenbank
- ueberschaubarer Verfuegbarkeitszyklus

Wir reden -um es mal so zu sagen- von einem tagtaeglich bei allen(?) gaengigen Massenhoster im Einsatz befindlichen Feature eines ausgereiften und als relativ sicher eingestufen Datenbanksystems mit Benutzerauthentifizierung und (optionaler) Kanalverschluesslung.
Man muss immer NAKS (Nutzung, Aufwand, Kosten, Sicherheitsrisiko) abwaegen, und zumals es seit Jahren auf tausenden von Maschinen ohne groesseres Skandal und Sicherheitsloch laeuft wuerde ich eher Bedenken gegenueber der Wahl eines vServers als einer Datenbankengine haben....

Aber dennoch
- Remote-Zugriff auf die notwendigen IP(s) begrenzen.
- Remote Port verlegen
- Kanalverschluesslung (SSL) aktivieren
- [optional] MySQL-Port verschieben um 'Hintergrundrauschen' -Bruteforce gegen 'root' los zu werden.

Ein Angreifer muss entweder ein 0day, IP und Port kennen (wobei es fuer die 0day sicherlich bedeutend interessantere Ziele als einen kleinen vServer gibt ) oder Port, Benutzername, Passwort und deine IP spoofen koennen.
Alternativ muss er einen Trojaner auf denen Rechner kriegen was sich eventuell als einfacher rausstellen koennte...


Um auf das eingangs erwaehnte NAKS ein zu gehen (da oefter abenteurlich-absichernde Methoden fuer triviale Anwendungen empfohlen werden): selbst ein hoch-sicheres System mit Festplattenverschluesslung kann man bei physischem Zugriff und 5$ Aufwand knacken: http://xkcd.com/538/

 

[Roger Wilco]

Wir reden -um es mal so zu sagen- von einem tagtaeglich bei allen(?) gaengigen Massenhoster im Einsatz befindlichen Feature […]

Du verallgemeinerst und vergisst dabei einen wichtigen (wenn nicht sogar den wichtigsten) Punkt: Bei den Massenhostern sind die Datenbankserver nicht öffentlich im Internet, sondern nur intern erreichbar. Das klappt dann natürlich von den Webservern aus, weil sie sich (zumindest mit einer Netzwerkschnittstelle) im gleichen Netz wie die Datenbankserver befinden.

theSilent möchte über das Internet auf seinen MySQL-Server zugreifen. Dazu muss er den Dienst an eine öffentliche IP-Adresse hängen, sofern er nicht von der bereits genannten Variante über ein VPN Gebrauch macht. Es wäre nicht der erste Server, der durch eine Lücke im mysqld kompromittiert wird. Davon habe ich schon einige gesehen - auch mit ein paar Jahren Abstand, also nicht immer durch die gleiche Lücke. Warum das Risiko eingehen und nicht gleich Maßnahmen dagegen ergreifen? Du setzt deine Kennwörter ja auch nicht auf "123" oder "Passwort", oder?

- Remote-Zugriff auf die notwendigen IP(s) begrenzen.

Ein SSH-Tunnel ist zu kompliziert und das soll einfacher sein?

- Remote Port verlegen

Bringt absolut nichts.

- Kanalverschluesslung (SSL) aktivieren

Hilft nur gegen ein einfaches Abhören der Verbindung und einfache MitM-Attacken.

(wobei es fuer die 0day sicherlich bedeutend interessantere Ziele als einen kleinen vServer gibt )

Deshalb versucht man, wie überall in der IT, so etwas zu automatisieren. Es ist ja nicht so, dass da ein kleiner, blasser Knilch vor dem Monitor sitzt und von Hand IP-Adressen aussortiert. Die bekannten IP-Ranges größerer (oder auch kleinerer) Massenhoster sind da schon sehr (sehr!) ergiebig.

 

[d4f]

Bei den Massenhostern sind die Datenbankserver nicht öffentlich im Internet

Bei (fast) allen die ich kenne gibt es die Moeglichkeit "Remote MySQL" im Interface. Somit sind sie sehr wohl von aussen erreichbar.

Du setzt deine Kennwörter ja auch nicht auf "123" oder "Passwort", oder?

Wenn ich einen Bufferoverflow von 2002 in OpenSSH und das debian-spezifische Entropie-Problem bedenke, sollte man nie ueber SSH sondern nur direkt physisch auf einen Server zugreifen. Ausserdem ist Apache auch sicherheitskritisch und sollte demnach abgeschaltet werden.
Moment, ist ja ein Webserver....

Ein SSH-Tunnel ist zu kompliziert und das soll einfacher sein?

"Das" ist eine Pflichtangabe beim Erstellen neuer Benutzer in MySQL

Zitat:

- Remote Port verlegen

Bringt absolut nichts.

Betonung lag auf Hintergrundrauschen. Nicht auf aktiven Angriffen.

Zitat:

- Kanalverschluesslung (SSL) aktivieren

Hilft nur gegen ein einfaches Abhören der Verbindung und einfache MitM-Attacken.

Wir reden wie bereits gesagt von einem normalen vServer auf dem ein MySQL mit unkritischen/uninteressanten Daten liegen. Nicht von einem verdammten Server des MI6...
(Afaik)

Deshalb versucht man, wie überall in der IT, so etwas zu automatisieren. Es ist ja nicht so, dass da ein kleiner, blasser Knilch vor dem Monitor sitzt und von Hand IP-Adressen aussortiert.

Das gleiche gilt fuer alle Server. Nur ein ausgeschalteter Server ist ein sicherer Server. (Wobei ich diese Wahrheit anzweifele da die Maschine noch immer entwendet oder angeschaltet werden kann)

 

[Joe User]

Bei (fast) allen die ich kenne gibt es die Moeglichkeit "Remote MySQL" im Interface. Somit sind sie sehr wohl von aussen erreichbar.

Weder bei 1und1, Strato, OVH, Hosteurope noch Hetzner gibt es Remote-Zugang zum MySQL. Welche (Massen)Hoster meintest Du?

 

[d4f]

Ich muss zugeben dass mein letzter Hosting-Vertrag schon paar Jahre her ist, aber aufgrund eines Projektes musste ich oefter mal auf die privaten Webspaces einer bunt gemischten internationalen Kundschaft zugreifen, welche ganz oft die entsprechende Funktion an zu bieten scheinen.
Wenn ich mich recht entsinne war Godaddy darunter, muesste aber ein Kunde des Anbieters bestaetigen - Google hat mir wiederspruechliche Aussagen ausgespuckt.

 

[Roger Wilco]

Bei (fast) allen die ich kenne gibt es die Moeglichkeit "Remote MySQL" im Interface.

Ich muss zugeben dass mein letzter Hosting-Vertrag schon paar Jahre her ist

Einigen wir uns also darauf, dass MySQL eventuell möglicherweise und unter Umständen doch nicht bei (fast) allen Providern öffentlich erreichbar ist.

Wenn ich einen Bufferoverflow von 2002 in OpenSSH und das debian-spezifische Entropie-Problem bedenke, sollte man nie ueber SSH sondern nur direkt physisch auf einen Server zugreifen. Ausserdem ist Apache auch sicherheitskritisch und sollte demnach abgeschaltet werden.
Moment, ist ja ein Webserver....

Du verallgemeinerst wieder und vergisst dabei wichtige Dinge: SSH und der Apache httpd sollen öffentlich erreichbar sein und erbringen einen entsprechenden Dienst. Bei MySQL ist das in diesem Kontext nicht der Fall.

"Das" ist eine Pflichtangabe beim Erstellen neuer Benutzer in MySQL

Ich bin davon ausgegangen, dass du einen Paketfilter meinst. Das von dir gemeinte Attribut für die MySQL-Benutzer bringt bei einem Fehler in mysqld sogar noch viel weniger…

Wir reden wie bereits gesagt von einem normalen vServer auf dem ein MySQL mit unkritischen/uninteressanten Daten liegen.

Richtig, das trifft vermutlich auf die Systeme von 90% der hiesigen Benutzer zu. Muss man deshalb aber schon bei den Grundlagen schlampen?

Nicht von einem verdammten Server des MI6...

Das gleiche gilt fuer alle Server. Nur ein ausgeschalteter Server ist ein sicherer Server. (Wobei ich diese Wahrheit anzweifele da die Maschine noch immer entwendet oder angeschaltet werden kann)

Polemik ist auch nicht mehr das, was sie einmal war.

Um es mal kurz zu machen: Mir ist es erstmal völlig egal, was du oder theSilent mit euren MySQL-Servern oder allgemein euren Systemen macht. Meinetwegen könnt ihr alle Dienste an ein öffentliches Netzwerkinterface hängen und schauen, was passiert.

Es ist mir in dem Moment nicht mehr egal, wenn von euren Kisten Spam bei mir ankommt oder versucht wird, meine Kisten mit stumpfen Bruteforce-Versuchen zu malträtieren.