KeyHelp Community

Hallo,

sicherheitstechnisch fände ich's schön, wenn Keyhelp für das Speichern der Systemdaten eine eigene MySQL-Server-Instanz verwenden würde. Die könnte dann auch der Admin für etwaige Server-Dienste nutzen. So könnte man System- und Kundendaten besser voneinander trennen.

Viele Grüße,
Rainer

Jap dafür wäre ich auch ^^ (y)

Hallo,

ich muss zugeben, dass ich den Sinn in einem zweiten mySQL Server nicht erkennen kann. Außer einer komplexeren (und damit potentiell fehlerträchtigeren) Konfiguration sehe ich hier keine Vorteile. Sofern das mySQL root Passwort in falsche Hände gerät hätte man so oder so ganz andere Probleme. Nutzer selbst sind entsprechend auf die jeweilige Datenbank beschränkt, sofern keine manuellen Änderungen erfolgen.

Martin wrote:Sofern das mySQL root Passwort in falsche Hände gerät hätte man so oder so ganz andere Probleme.

Genau darum geht's aber. Wenn sich jetzt jemand Root-Zugang zum aktuell recht offen im Netz liegenden MySQL-Server verschaffen sollte, hätte er nicht nur Zugriff auf die Kundenprojekte (was schlimm genug wäre), sondern auch noch auf die von mir bzw. dem System gespeicherten Kunden(konfigurations)daten - was noch schlimmer wäre.

Die Versuche irgendwelcher Leute/Systeme, sich als Root-User Zugang zum System zu verschaffen, kann man ja quasi minütlich in den Logfiles verfolgen.

Einen zweiten MySQL-Server mit sensiblen Systemdaten könnte ich über einen anderen Port, einen zusätzlichen htaccess-Schutz, alleinigen Zugriff etc. relativ gut absichern. So gut, wie sich ein von Kunden genutztes System nur schwer absichern ließe (weil's ja auch noch von jedem einfach benutzbar sein soll).

Viele Grüße,
Rainer

Hallo,

standardmäßig ist der mySQL Server nicht für das lauschen auf der öffentlichen IP konfiguriert sondern nur per localhost erreichbar. Sofern dies manuell geändert wird, so wäre es natürlich sinnvoll hier nur spezifischen IP Adressen Zugang zu Port 3306 zu gewähren. Was ein zweiter mySQL Server hier als Vorteil bringen soll erschließt sich mir daher nach wie vor nicht.

Hallo,

o.k., vielleicht könnte man dann zumindest beim vorinstallieren phpMyAdmin standardmäßig den Root-Login deaktivieren, um die automatischen Login-Versuche ins Leere laufen zu lassen? Diese Zugriffe/htaccess-Schutz meinte ich oben, das hatte ich nicht klar abgegrenzt. Der Admin könnte sich dann ja noch ein separates phpMyAdmin installieren.

Vielleicht könnte man (und das wäre dann die bessere Idee) beim phpMyAdmin aber auch einen htaccess-Schutz implementieren/vorschalten, der die Zugangsdaten der KeyHeylp-Benutzer erfordert? Dann hätte man hier zumindest Gewissheit, dass nur Kunden über phpMyAdmin aufs System zugreifen können. Hierbei müsste es sich aber zwingend um die aktuellen KeyHelp-Benutzerdaten handeln, damit Kunden sich nicht noch weitere Zugangsdaten merken müssen.

Viele Grüße,
Rainer

Rainer wrote:o.k., vielleicht könnte man dann zumindest beim vorinstallieren phpMyAdmin standardmäßig den Root-Login deaktivieren, ...

Wenn dann aber mit der Option das der Admin sich wieder root login aktivieren kann.

Rainer wrote:Vielleicht könnte man (und das wäre dann die bessere Idee) beim phpMyAdmin aber auch einen htaccess-Schutz implementieren/vorschalten,

Das wäre wieder passwort gesichert und wenn es dann auch noch das selbe kunden passwort ist. Ist es nur ein mehraufwand das kaum bis gar keine Vorteile bringt. Komme ich an das kunden passwort ran habe ich automatisch das passwort auch für die htaccess-datei. Das machen nicht einmal grosse Hosting-Provider.

Hallo,

b0snaX wrote:Komme ich an das kunden passwort ran habe ich automatisch das passwort auch für die htaccess-datei. Das machen nicht einmal grosse Hosting-Provider.

das wird (auch von einem großen Hoster) schon so gemacht, durchaus.

Ich finde es sicherheitstechnisch schon problematisch, dass der phpMyAdmin-Zugang hier standardmäßig offen im Netz liegt. Ständig versuchen sich irgendwelche Leute/Bots, hier als "root"-User anzumelden. Wenn die zufälig mal das richtige Passwort erraten... Deshalb wäre beispielsweise eine htaccess-Abfrage ein weiterer Schutz - um allein diese automatisierten Login-Versuche zu unterbinden. Zu mehr soll das dann nicht gut sein. Und mit den KeyHelp-Zugangsdaten der Kunden wäre das eben für die Kunden kein allzu großer Mehraufwand (neue Passwörter merken etc.).

Viele Grüße,
Rainer

Rainer wrote:Ständig versuchen sich irgendwelche Leute/Bots, hier als "root"-User anzumelden. Wenn die zufälig mal das richtige Passwort erraten...

Ich dachte dagegen ist dieses fail2ban installiert.
Oder habe ich die Funktionsweise von fail2ban nicht verstanden?

Hallo,

was ich an der Sache unglücklich finde wäre, das sich der Nutzer immer 2x einloggen muss.

Als alternativen Vorschlag werfe ich mal das folgende in den Raum:
Einen extra fail2ban Filter für phpMyAdmin ( + ggf. auch für Roundcube / KeyHelp / ..., wobei diese ihren eigenen Brute-Force Schutz mitbringen).

Vorteil: der normale User bekommt davon nichts mit und Brute-Force Angriffe werden nach X-Versuchen erstmal für eine Zeit gesperrt.

Könnte man sich darauf einigen?

---
EDIT:
@Tobi, fast zeitgleich

---
EDIT2:
Mit dem Benutzernamen "root" kann man sich unter den neuen OS Versionen Debian 9 / Ubuntu 16 ohnehin per default nicht mehr via Web-Kontext einloggen.
Die Brute-Force-Versuche würden dann unter genannten Betriebssystemen also jetzt schon ins leere Laufen.
Schnelle Lösung: Alternativ erstellt man jetzt schon unter den früheren OS Versionen einen neuen root User, nennt ihn aber nicht "root".

Alexander wrote:Könnte man sich darauf einigen?

Geeinigt! Das klingt sehr gut!

Alexander wrote:Die Brute-Force-Versuche würden dann unter genannten Betriebssystemen also jetzt schon ins leere Laufen.

Ah, perfekt. Wird ja immer besser!

Danke & viele Grüße,
Rainer

Alexander wrote:Hallo,

was ich an der Sache unglücklich finde wäre, das sich der Nutzer immer 2x einloggen muss.

Als alternativen Vorschlag werfe ich mal das folgende in den Raum:
Einen extra fail2ban Filter für phpMyAdmin ( + ggf. auch für Roundcube / KeyHelp / ..., wobei diese ihren eigenen Brute-Force Schutz mitbringen).

Vorteil: der normale User bekommt davon nichts mit und Brute-Force Angriffe werden nach X-Versuchen erstmal für eine Zeit gesperrt.

Könnte man sich darauf einigen?

Das klingt doch Perfekt. Das wäre super.

Alexander wrote:Einen extra fail2ban Filter für phpMyAdmin ( + ggf. auch für Roundcube / KeyHelp / ..., wobei diese ihren eigenen Brute-Force Schutz mitbringen).

Ich dachte sowas läuft schon .

Wobei mir jetzt dazu (besser insgesamt) einfällt .. was zwar nicht direkt zum Thema passt .. aber von der Sache schon ..

Wenn wir hier im Forum nen geschützten Bereich hätten wo bestimmte Einstellungen/Konfigmöglichkeiten angeboten/getauscht werden könnten .. natürlich von den Keyweb-Leuten begutachtet .. lächel. Würde sicher auch einige Tickets sparen.
Klar gibt es im Web Hundertmillionentrillionen Webseiten die genau die Dinge behandeln. Aber meist auf englisch was für den speziellen Bereich zur Serversicherung nicht unbedingt von Vorteil ist. Weil man als Deutschaussengeländer doch nicht so fachenglisch Up2Date ist und .. ich spreche da für mich .. viel zu lange braucht um selbst ne Kurzanleitung schnell umzusetzen

Die Wiki-Idee wäre ja auch etwas anderes. Dort sollten nur Infos stehen ohne Diskussion. Würde mehr verwirren. Hier im Forum könnte man drüber diskutieren und sich mit einbringen bzw sogar lernen.

Nur ne Idee ...

Kurzes Feedback: Die kommende Version enthält 4 Sicherheitsverbesserungen für die phpmyadmin Installation.

- Script-Kiddies und Web-Crawler/Bots werden künftig komplett ausgesperrt.
- die Liste der "ansurfbaren" Ordner innerhalb des Installationsordners würde erneuert / bzw. Nicht benötigte Ordner gelöscht
- es wird die neuste Version 4.7.0 / 4.7.1 installiert (Bei Ubuntu 12 entsprechend die letzt-supportete)
- fail2ban Filter für fehlgeschlagene Logins (erst ab Version >= 4.7.0 möglich, von daher nicht für Ubuntu 12)

@mrbird. Gern kannst du den Hinweis nochmal im Offtopic Forum zur Diskussion stellen, da gibt es schon einen Ähnlichen Wunsch. Hier wird es sicher untergehen.