• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

mysql Server absichern

Kurt M

Hacker
ich habe einen virtuellen Mietserver (Opensuse 13.2).
Auf diesem möchte ich mir einen externen Zugang zum mysql Server schalten, damit ich von unterwegs auf meine Datenbanken zugreifen kann. Also Port 3306 öffnen.
Mir ist natürlich klar, dass kurz darauf tausende von Hackern diesen offenen Port finden und allen möglichen Unsinn versuchen.
Die Frage ist: welche Maßnahmen sollte man treffen, um sich abzusichern ?

viele Grüße
Kurt
 

gehrke

Administrator
Teammitglied
Kurt M schrieb:
ich habe einen virtuellen Mietserver (Opensuse 13.2).
[...]
Mir ist natürlich klar, dass kurz darauf tausende von Hackern diesen offenen Port finden und allen möglichen Unsinn versuchen.
Tausche zuerst mal das Betriebssystem gegen etwas, bei dem Support durch die Distribution gegeben ist. Bei openSUSE 13.2 ist das schon seit geraumer Zeit nicht mehr gegeben. Für Serversysteme bieten diverse Distributionen LTS-Varianten mit bis zu 10 Jahren Support an.

Datenbank-Ports würde ich auf keinen Fall frei ins Internet hängen.
 
OP
Kurt M

Kurt M

Hacker
Danke für die Hinweise,
das Suse 13.2 werde ich über die Weihnachtsfeiertage updaten, das wird richtig viel Arbeit und ist genau die Beschäftigung die ich brauche wenn im Fernsehen nur Weihnachts-Schmalzfilme laufen.

Das Linux selbst ist durchaus schützenswert,
die Datenbank jedoch nicht. Hier liegen nur Messdaten mit denen keiner was anfangen kann.
Angenommen jemand zerstört die Datenbank, das wäre mir egal, die baut sich schnell wieder auf.

Um Datenbank vom Betriebssystem zu trennen, könnte evt. eine VM helfen ?
Ich habe auf den Virt-Server aber nur Konsolenzugriff, da müsste ich erstmal sehen wie man eine VM per Konsole installiert.

Oder Suse hat so ein Teil "AppAmor", habe mich noch nicht damit beschäftigt, aber könnte man damit evt. das mysqld vom Rest des Systems trennen ?

Gruß
Kurt
 

spoensche

Moderator
Teammitglied
Kurt M schrieb:
das Suse 13.2 werde ich über die Weihnachtsfeiertage updaten, das wird richtig viel Arbeit und ist genau die Beschäftigung die ich brauche wenn im Fernsehen nur Weihnachts-Schmalzfilme laufen.

Hust, Hust, Räusper, Räusper. Du glaubst doch nicht allen ernstes das in den 2 Monaten niemand den Server findet bzw. begeistert festellt: "Ha, da läuft was alltes, was EOL ist. Kurz mal die offenen Ports abklappern und gucken was da so läuft. Neben bei noch schnell die diversen Exploit-DB's abfragen und tata ....."

Kurt M schrieb:
Das Linux selbst ist durchaus schützenswert,
die Datenbank jedoch nicht. Hier liegen nur Messdaten mit denen keiner was anfangen kann.
Angenommen jemand zerstört die Datenbank, das wäre mir egal, die baut sich schnell wieder auf.

Naja, der Inhalt der Datenbank ist da erst mal zweitrangig. Interessanter sind diverse Schwachstellen, die einen Root-Zugriff ermöglichen. Die Daten können danach auch noch in aller Ruhe begutachtet werden. Das solltest du dir vor Augen halten.

Kurt M schrieb:
Um Datenbank vom Betriebssystem zu trennen, könnte evt. eine VM helfen ?
Ich habe auf den Virt-Server aber nur Konsolenzugriff, da müsste ich erstmal sehen wie man eine VM per Konsole installiert.

Auf einem virtuellen Server wirst du bei keinem Hoster auch nur ansatzweise die Möglichkeit bekommen in dem virtuellen System noch ein virtuelles System zu installieren und zwar aus folgenden Gründen:

1. Dein V-Server ist mit 100%iger Sicherheit ein Container. D.h. er nutzt den Kernel des Hostsystems. Also kannst du Kernelmodule laden schon mal voll vergessen.

2. Der Hoster wird sich garantiert auch nicht dazu überreden lassen die entsprechenden Module zu laden, weil er so potentielle Einfallstore schaft.

Warum dir die Datenbank in einer, auf dem selben Host mit altem EOL OS nix bringt? Ganz einfach wenn das System gekarpert wird, nutzt dir die VM auch nix mehr.

Kurt M schrieb:
Oder Suse hat so ein Teil "AppAmor", habe mich noch nicht damit beschäftigt, aber könnte man damit evt. das mysqld vom Rest des Systems trennen ?

Mit App Armor kannst du nichts vom System trennen. Mittels App Armor Profilen kannst du "nur" festlegen, auf welche Verzeichnisse der Prozess lesend, schreibend und somit auch welche Shared Libraries er lesen und verwenden darf festlegen. App Armor kann allerdings nicht verhindern, das ein Angreifer durch einen Exploit des jeweiligen Prozesses Root Privbilegien erlangt. Deswegen sollten Prozesse auch nicht mit Root Berechtigungen laufen sondern mit einem eingeschränkten Benutzer.

Das Isolieren des Prozesses bringt in diesem Falle allerdings auch nichts, wenn der Angreifer durch eine andere Schwachstelle im OS, den Server übernehmen kann.

Grundlegendes zur MySQL-Sicherheit, unter der Annahme das du MySQL verwendest:

1. Immer nur mittels mysqld_safe starten
2. Der Datenbankuser root sollte sich nur von localhost am DB-Server anmelden können.
3. Für eine Datenbank einen eigenen User einrichten, der Schreiboperationen (Insert, Update, Delete) nur in der entsprechenden DB ausführen kann.
4. Wenn es notwendig ist, dass der DB-User sich von einem anderen Host aus anmelden muss, dann ist explizit der Traffic nur von diesem Host zur Datenbank mittels Firewall zu limitieren und der User mittels username@host-ip in der Datenbank anzulegen. Idealerweise sind nur per SSL verschlüsselte Verbindungen erlaubt, Aussnahmen wären z.B. ein VPN.
5. Von einer per SSH getunnelten Verbindung mit Passwort ist abzuraten, da nur unnötige Angriffsfläche für Bruteforce Angriffe ermöglicht werden.
6. Wenn ein User nur lokal auf eine Datenbank Zugriff hat ist auch nur eine lokale Anmeldung möglich, d.h es wird ein DB-User in der Form dbuser@localhost + Passwort angelegt, aber kein dbuser@* oder dbuser@ip-addresse.
7. Ein Useraccount in der Form von dbuser@* (dbuser kann sich von jedem x-beliebiegen Host anmelden) sind nicht erlaubt.

Die explizite Absicherung der Webanwendung und des Webservers ist wiederum eine andere Baustelle die nicht stiefmütterlich behandelt werden sollte. Sprich so restriktiv wie möglich und nur die notwendigen Rechte die für den Betrieb nötig sind. (Auf Dateisystemebene, wie auch Webserverebene).

Nicht zu vergessen, die Absicherung des Hosts selbst. Ist die nicht vorhanden brauch man mit den erwähnten Punkten erst gar nicht anfangen oder auch nur ansatzweise einen Gedanken an diese zu verschwenden.

Das ist erst mal genug "Stoff" den man inne haben sollte, wenn man daran denkt so ein Serverkonstrukt zu betreiben.

PS:
Also bis Weihnachten warten ist definitiv nicht zu empfehlen, sondern dieses Wochenende hinsetzen Upgradekonzept auf die Beine stellen und Vorbereitungen treffen. Nächstes Wochenende Backups gefolgt von der Migration durchführen.

Nach deiner Anwendungsbeschreibung nach sollte das ganze durchaus an einem, max. zwei Samstagen erledigt sein.

Du hälst mich evtl. jetzt für verrückt, aber die Weihnachtszeit kannst du dann beruhigt für weitere Experimente oder Erweiterung deiner Anwendungen nutzen, was du sonst evtl. auf nächstes Jahr vertagen würdest. ;)
 
OP
Kurt M

Kurt M

Hacker
ok, habe verstanden. Es gibt offensichtlich keine Möglichkeit einen mysql Server nach außen hin vernünftig abzusichern. Den Port lasse ich also zu.

Stattdessen baue ich mir eine eigene Verschlüsselung mit der die sql Kommunikation stattfindet und sende die zu einem Port xy. An diesem lauscht ein eigenes Programm, dass meine verschlüsselten Informationen zum internen mysql Server weitergibt, und umgekehrt. Da dieses Programm nur auf meine privaten verschlüsselten Daten reagiert kann ein Angreifer mit diesem Port nichts anfangen. Die Programme für Client und Server sollten an einem Abend geschrieben sein.
 

gehrke

Administrator
Teammitglied
Kurt M schrieb:
Stattdessen baue ich mir eine eigene Verschlüsselung [...] Port xy. An diesem lauscht ein eigenes Programm, [...]
Die Programme für Client und Server sollten an einem Abend geschrieben sein.
?!?

Dieses Programm wurde schon vor 20+ Jahren geschrieben und nennt sich SSH:
marce schrieb:
Tunnel via ssh, ssh nur per Key.
 

spoensche

Moderator
Teammitglied
Kurt M schrieb:
Stattdessen baue ich mir eine eigene Verschlüsselung mit der die sql Kommunikation stattfindet und sende die zu einem Port xy. An diesem lauscht ein eigenes Programm, dass meine verschlüsselten Informationen zum internen mysql Server weitergibt, und umgekehrt. Da dieses Programm nur auf meine privaten verschlüsselten Daten reagiert kann ein Angreifer mit diesem Port nichts anfangen. Die Programme für Client und Server sollten an einem Abend geschrieben sein.

Um Himmelswillen verwende etablierte bestehende Bibliotheken. MySQL kann verschlüsselten Traffic mittels SSL/TLS. Also kein Grund das Rad neu zu erfinden.
 
Oben