8
Welche Risiken habe ich wenn ich meine Mysql(MariaDB) ins Internet schalten
Hallo, ich bin seit einer Weile am überlegen wie ich meine Datenbank auf dem Hostsystem für meinen Docker erreichbar mache.
Ich habe auf dem Docker einen FiveM PD Server laufen, der braucht leider eine Datenbank.
Ich habe bis jetzt nur folgende Lösungen gefunden:
1. Datenbank in das Internet schalten.
2. Datenbank öffentlich machen und über die Iptables alle nicht erwünschten Verbindungen blockieren, also die von außen.
3. Eine extra Datenbank auf dem Docker installieren für meinen Dienst .
Bei 1.weiß ich nicht welche Risiken es gibt und ob es sich dabei nur um eine Standardwarnung handelt die bei sicheren Passwörtern unnötig ist.
Ich habe es auch so eingestellt, dass man sich in die Datenbanken, die keinen Login von außen benötigen, sich nicht von außen einloggen kann.
2. wäre möglich, wenn 1. nicht geht, ich muss halt auch das für IPv6 usw machen.
Das könnte bei einer Random Docker IP könnte das auf Dauer anstrengend werden, sie immer wieder neu zu schreiben, obwohl man ja irgendwie Hostnames setzen kann.
3. wäre eine Lösung die hat etwas mehr Ressourcen verbraucht, die ich nutzen würde wenn 1. 2. nicht funktionieren oder Unkomfortabel sind.
Wahrscheinlich mache ich mir da einen zu großen Kopf, viele Datenbanken sind ja im Netz erreichbar.
Ich habe auf dem Docker einen FiveM PD Server laufen, der braucht leider eine Datenbank.
Ich habe bis jetzt nur folgende Lösungen gefunden:
1. Datenbank in das Internet schalten.
2. Datenbank öffentlich machen und über die Iptables alle nicht erwünschten Verbindungen blockieren, also die von außen.
3. Eine extra Datenbank auf dem Docker installieren für meinen Dienst .
Bei 1.weiß ich nicht welche Risiken es gibt und ob es sich dabei nur um eine Standardwarnung handelt die bei sicheren Passwörtern unnötig ist.
Ich habe es auch so eingestellt, dass man sich in die Datenbanken, die keinen Login von außen benötigen, sich nicht von außen einloggen kann.
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address = 127.0.0.1
#bind-address = 172.%.%.%
#bind-address = 0.0.0.02. wäre möglich, wenn 1. nicht geht, ich muss halt auch das für IPv6 usw machen.
Das könnte bei einer Random Docker IP könnte das auf Dauer anstrengend werden, sie immer wieder neu zu schreiben, obwohl man ja irgendwie Hostnames setzen kann.
3. wäre eine Lösung die hat etwas mehr Ressourcen verbraucht, die ich nutzen würde wenn 1. 2. nicht funktionieren oder Unkomfortabel sind.
Wahrscheinlich mache ich mir da einen zu großen Kopf, viele Datenbanken sind ja im Netz erreichbar.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 600864
Url: https://administrator.de/contentid/600864
Ausgedruckt am: 22.11.2024 um 03:11 Uhr
8 Kommentare
Neuester Kommentar
Ich glaube nicht, daß sich Mädels von einer MariaDB im Internet beeindrucken lassen, auch wenn sie Reike heißen. Du wirst daher vermutlich gar keine Reike abbekommen.
Wahrscheinlich mache ich mir da einen zu großen Kopf, viele Datenbanken sind ja im Netz erreichbar.
Und werden leergelutscht. und es gibt des öfteren ein "Datenreichtum". Grad letztens war wieder so eine aktion, wo ein hacker alle möglichen datenbanken im netz "plattgemacht" hat, finde die Meldung aber gerade nicht.
Merke:
Eine Datenbank sollte eine direkt im Internet zugreifbar sein. Wenn überhaupt, dann nur in einem internen Netz und zugriff für externe Clients nur mit VPN-Zugang. Alles andere ist fahrlässig.
lks
moin...
warum nutzt du kein vpn?
frank
warum nutzt du kein vpn?
frank
Welche Risiken du eingehst? Naja - das jemand dein Passwort doch rausbekommt, das es ne Security-Lücke gibt die einen Einbrauch erlaubt,....
Wenn du aber feste IPs hast dann kannst du natürlich (sinnvollerweise) die Verbindungen schon per IPTables einschränken UND eben auch bei MySQL nen Nutzer erstellen der sich eben nur von dort aus anmelden darf (und auch nur auf die DB/Tabellen die du brauchst). Damit hast du es dann zumindest schon mal so abgesichert das es zwar keine 100% sind aber das min. 99% der Script-Kiddys rausfallen und sich was anderes suchen. Einen guten Einbruch wirst du so nicht verhindern, der wird aber dann ggf. auch gar nich die DB nehmen sondern andere Wege versuchen (System-Login,...)
Wenn du aber feste IPs hast dann kannst du natürlich (sinnvollerweise) die Verbindungen schon per IPTables einschränken UND eben auch bei MySQL nen Nutzer erstellen der sich eben nur von dort aus anmelden darf (und auch nur auf die DB/Tabellen die du brauchst). Damit hast du es dann zumindest schon mal so abgesichert das es zwar keine 100% sind aber das min. 99% der Script-Kiddys rausfallen und sich was anderes suchen. Einen guten Einbruch wirst du so nicht verhindern, der wird aber dann ggf. auch gar nich die DB nehmen sondern andere Wege versuchen (System-Login,...)
Für peinliche Vertipper in der Überschrift (Reiken usw.) gibt es hier immer den "Bearbeiten" Knopf. Rechts unter "Mehr..."
Damit kann man solche Fauxpas immer nachträglich korrigieren.
Zur Lösung sagt die Frage: warum nutzt du kein vpn? eigentlich alles ?!
Damit kann man solche Fauxpas immer nachträglich korrigieren.
Zur Lösung sagt die Frage: warum nutzt du kein vpn? eigentlich alles ?!
Installier die Datenbank ins Docker rein.
Und was soll das für einen Mehrwert bringen ?
Ob seine Datenbank jetzt über Portmapping via Port "4321" auf 3306 zur Verfügung steht oder direkt blank auf 3306 macht vielleicht kurzfristig einen Unterschied. Langfristig findet man solche Dienste auch hinter "nicht-Standard-Ports".
VPN, Firewall zu, fertig.
Ob seine Datenbank jetzt über Portmapping via Port "4321" auf 3306 zur Verfügung steht oder direkt blank auf 3306 macht vielleicht kurzfristig einen Unterschied. Langfristig findet man solche Dienste auch hinter "nicht-Standard-Ports".
VPN, Firewall zu, fertig.
Die Datenbank dort hin zu installieren, wo sie benötigt wird, hat mehrere Mehrwerte, die man als Admin normaler Weise kennt:
1) weniger Sicherheitslücken
2) weniger Performanceabhängigkeiten
3) leichtere Administration, da Firewall / VPN nicht mitberücksichtigt werden muss und alles an einer Stelle ist
4) Es muss nur ein Knoten funktionieren, damit der Server funktioniert (der Host selbst), keine externen Dienste und andere Abhängigkeiten
5) Im Fehlerfall muss weniger geprüft werden
6) Weniger Backupaufwand
Eine Konfiguration über VPN hat nur den Vorteil, wenn die Datenbank von mehreren Diensten (in verschiedenen Netzen) angesprochen werden muss. Dann ist der Dienst mit dem meisten Traffic, geringsten nötigen Latenz oder der bestenmöglichen Sicherung ( je nach Anforderung) am besten lokal und alle anderen Dienste über VPN.
1) weniger Sicherheitslücken
2) weniger Performanceabhängigkeiten
3) leichtere Administration, da Firewall / VPN nicht mitberücksichtigt werden muss und alles an einer Stelle ist
4) Es muss nur ein Knoten funktionieren, damit der Server funktioniert (der Host selbst), keine externen Dienste und andere Abhängigkeiten
5) Im Fehlerfall muss weniger geprüft werden
6) Weniger Backupaufwand
Eine Konfiguration über VPN hat nur den Vorteil, wenn die Datenbank von mehreren Diensten (in verschiedenen Netzen) angesprochen werden muss. Dann ist der Dienst mit dem meisten Traffic, geringsten nötigen Latenz oder der bestenmöglichen Sicherung ( je nach Anforderung) am besten lokal und alle anderen Dienste über VPN.
Zitat von @NordicMike:
Die Datenbank dort hin zu installieren, wo sie benötigt wird, hat mehrere Mehrwerte, die man als Admin normaler Weise kennt:
1) weniger Sicherheitslücken
2) weniger Performanceabhängigkeiten
3) leichtere Administration, da Firewall / VPN nicht mitberücksichtigt werden muss und alles an einer Stelle ist
4) Es muss nur ein Knoten funktionieren, damit der Server funktioniert (der Host selbst), keine externen Dienste und andere Abhängigkeiten
5) Im Fehlerfall muss weniger geprüft werden
6) Weniger Backupaufwand
Die Datenbank dort hin zu installieren, wo sie benötigt wird, hat mehrere Mehrwerte, die man als Admin normaler Weise kennt:
1) weniger Sicherheitslücken
2) weniger Performanceabhängigkeiten
3) leichtere Administration, da Firewall / VPN nicht mitberücksichtigt werden muss und alles an einer Stelle ist
4) Es muss nur ein Knoten funktionieren, damit der Server funktioniert (der Host selbst), keine externen Dienste und andere Abhängigkeiten
5) Im Fehlerfall muss weniger geprüft werden
6) Weniger Backupaufwand
Und das ganze klappt schon mal nur wenn du wirklich nur EINEN Service hast der die DB nutzt. Blöd wenn du eine Vielzahl an Systemen hast
Eine Konfiguration über VPN hat nur den Vorteil, wenn die Datenbank von mehreren Diensten (in verschiedenen Netzen) angesprochen werden muss. Dann ist der Dienst mit dem meisten Traffic, geringsten nötigen Latenz oder der bestenmöglichen Sicherung ( je nach Anforderung) am besten lokal und alle anderen Dienste über VPN.
Würde man aber im normalfall auch nicht machen - weil die Verbindungen zu langsam sind... Wenn man es programmmässig sauber abbildet würde man ja die Verbindungen über eine Strecke die man nicht kennt (-> Internet, selbst wenns VPN ist) nicht permanent offen halten. Das öffnen und schließen der Verbindung nimmt da dann zuviel Zeit in Anspruch...
Wenn man es SAUBER abbildet hat man irgendwo eben einen oder mehrere Webservices nach aussen über die der ganze Kram abgefackelt wird. Die DB wäre dabei natürlich trotzdem nich im "offenen" Internet sondern nur von den Webserver(n) erreichbar (und wenns im selben RZ ist dann eben zumindest per IP-Sperre).
Aber das hängt natürlich dann davon ab was der TO genau vor hat... da kann man mal wieder nur raten...
