Plesk / MySQL Port 3306 open

[tsk]

Hallo zusammen,

ich habe eine Frage zum MySQL Standardport 3306 auf meinem Ubuntu vServer unter Plesk 9. Nmap zeigt ihn als „open“, netstat ebensfalls:

tcp        0      0 0.0.0.0:3306            0.0.0.0:*               LISTEN

Ich habe ihn auch noch nicht über die my.cnf an localhost gebunden – und meine Frage wäre, ob ich dies tun sollte, um an Sicherheit zu gewinnen. Aktuell gelingt es mir nicht, über telnet eine Verbindung über Port 3306 herzustellen (Verbindung wird automatisch geschlossen). Tatsächlich möchte ich auch nie eine direkte Verbingung zu MySQL, mir genügt der Zugriff über das Plesk Panel vollkommen. Die Bindung an localhost (bind-address 127.0.0.1) ist auskommentiert; es steht allerdings auch kein bind-address 0.0.0.0 drin. Verstehe also nicht, warum der Port dennoch als offen gekennzeichnet wird.

Könnte mich da jemand mit Wissen bestäuben? Kann und sollte ich ein „bind-address 127.0.0.1“ setzen, oder bekommt Plesk dadurch Probleme?
Kann ich die my.cnf direkt editieren - und würde dies auch einen Plesk Update überstehen – oder sollte ich Änderungen besser über das inkludierte „conf.d“ vornehmen? Ich finde immer nur ähnliche Fälle, bei denen jemand den Zugriff von außen öffnen will. Ich will das Gegenteil – und nach Möglichkeit keinen Nebeneingang zu MySQL.

Danke für jeden Input,

Thomas

 

[Roger Wilco]

und meine Frage wäre, ob ich dies tun sollte, um an Sicherheit zu gewinnen.

Definitiv ja.

skip-networking ist dein Stichwort.

 

[tsk]

Hallo Roger,

danke für Deine Antwort (die ich eigentlich auch so oder ähnlich hören wollte). Mich hatte nur gewundert, dass Telnet Verbindungen auf diesem Port sofort geschlossen wurden - und ich keinerlei Direktiven gefunden habe, die dies auslösen könnten (ich dachte mehr an Plesk Voodoo).

Jetzt finde ich in der my.cnf folgenden Hinweis:

# 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

Also statt "skip-networking" (alte Versionen) den Port an localhost binden (neuere Versionen). Der Satz ist hochgradig verwirrend, spricht er doch von einem Default (der somit gelten sollte, wenn gar nichts angegeben ist) - führt aber direkt darunter die auskommentierte Zeile "# bind-address = 127.0.0.1" auf. Ich werd den Kommentar mal entfernen, und gucken, was passiert.

 

[tsk]

So, fertig:

bind-address		= 127.0.0.1

Danach klappte sowohl der Zugriff über Plesk auf MySQL (der Teil, der mir Sorgen machte) als auch ein nicht mehr gelisteter Port 3306 unter Nmap. Interessanterweise kann Nmap jetzt auch nicht mehr gesichert das Host OS erkennen ("No exact OS matches for host (test conditions non-ideal)." Offensichtlich war der MySQL Teil zielführend für eine korrekte Ermittlung des Host OS - auch fein, irgendwie.

Telnet kommt jetzt auch mit der korrekten Meldung "es konnte keine Verbindung zum Host hergestellt werden auf Port 3306". Vor der Änderung erschien es mir eher wie ein Timeout.

Danke nochmal für die Unterstützung. Ich mach mich jetzt auf zur nächsten Baustelle

 

[d4f]

Mich hatte nur gewundert, dass Telnet Verbindungen auf diesem Port sofort geschlossen wurden - und ich keinerlei Direktiven gefunden habe, die dies auslösen könnten

MySQL akzeptiert alle einkommenden Verbindungen und vergleicht dann die IP mit der Liste der hinterlegten gueltigen Hosts der Benutzernamen (benutzer@host).
Wenn kein benutzer@% (also alle Hosts) oder benutzer@DEINEIP gefunden wurde schliesst er wieder die Verbindung da kein erfolgreicher Login passieren kann und somit das ganze nur Ressourcenverschwendung waere.

Somit muss mindestens ein Wildcard-Benutzer eingetragen sein oder die IP fuer einen Benutzer erlaubt sein bevor ueberhaupt ein Angriff auf MySQL gestartet werden kann. Allerdings ist mir keine MySQL-Luecke ohne Authentifizierung bekannt. Ob es somit wirklich ein so grossen Sicherheitsvorteil ist wie oft hier diskutiert wird bezweifele ich somit - aber alles was nicht gebraucht wird sollte geschlossen sein.

 

[tsk]

Ja, genau wie beschrieben wirkte auch der Telnet Verbindungsversuch vor der Änderung auf mich. Aber die jetzige Lösung scheint mir sicherer und ressourcenschonender. Jetzt wird MySQL gar nicht mehr vom Netz belästigt.