Firewall-Konfiguration MS SQL-Server 2019
Moin zusammen,
ich habe einen MS SQL-Server 2019 Express. Auf diesen soll sowohl über einen Connector als auch über das von Microsoft angebotene Management-Studio
von einem anderen Rechner im selben Netzwerk verwaltet werden. Nun ist das Problem, das die Windows-Firewall die Zugriffe blockiert. Ist diese ausgeschaltet ist die Verbindung kein Problem.
Als Anleitung der Firewall-Konfiguration habe ich mir direkt den Artikel von Microsoft zu diesem Thema genommen (https://docs.microsoft.com/de-de/sql/sql-server/install/configure-the-wi ..) sowie einige weitere Quellen.
Ich habe den Server testweise sowohl für dynamische Ports als auch für den Standardport TCP1433 konfiguriert. Leider hatte keine der beiden Varianten den gewünschten Erfolg gebracht. Habe ich noch irgendwelche Ports vergessen?
Viele Grüße
ich habe einen MS SQL-Server 2019 Express. Auf diesen soll sowohl über einen Connector als auch über das von Microsoft angebotene Management-Studio
von einem anderen Rechner im selben Netzwerk verwaltet werden. Nun ist das Problem, das die Windows-Firewall die Zugriffe blockiert. Ist diese ausgeschaltet ist die Verbindung kein Problem.
Als Anleitung der Firewall-Konfiguration habe ich mir direkt den Artikel von Microsoft zu diesem Thema genommen (https://docs.microsoft.com/de-de/sql/sql-server/install/configure-the-wi ..) sowie einige weitere Quellen.
Ich habe den Server testweise sowohl für dynamische Ports als auch für den Standardport TCP1433 konfiguriert. Leider hatte keine der beiden Varianten den gewünschten Erfolg gebracht. Habe ich noch irgendwelche Ports vergessen?
Viele Grüße
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 604576
Url: https://administrator.de/contentid/604576
Ausgedruckt am: 25.11.2024 um 18:11 Uhr
12 Kommentare
Neuester Kommentar
Moin Grmg2010,
last die Windows Firewall für das Domänennetzwerk aus und gut ist.
Das Ding bringt auf den Clients in einer Firmenumgebung mehr Ärger als das es gutes tut.
Am ende des Tages administrierst du dich damit nur zu tode ohne dafür einen sinnvollen Gegennutzen zu bekommen.
Du hast doch sicherlich auch etwas erwachsenes am WAN Anschluss hängen, oder?
Grüsse aus BaWü
Alex
last die Windows Firewall für das Domänennetzwerk aus und gut ist.
Das Ding bringt auf den Clients in einer Firmenumgebung mehr Ärger als das es gutes tut.
Am ende des Tages administrierst du dich damit nur zu tode ohne dafür einen sinnvollen Gegennutzen zu bekommen.
Du hast doch sicherlich auch etwas erwachsenes am WAN Anschluss hängen, oder?
Grüsse aus BaWü
Alex
Moin,
der Vollständigekeit noch folgender Link: Configure a Windows Firewall for Database Engine Access.
Hast du in der SQL Konfiguration die Name Pipes als Netzwerkprotokoll aktiviert? Dann solltest du auch die Regeln für File and Printer Sharing aktivieren.
Ansonsten anstatt die ausführbare Datei (sqlservr.exe) in der Regel anzugeben, auf den entsprechende Windows Service SQL Server verweisen.
Gruß,
Dani
der Vollständigekeit noch folgender Link: Configure a Windows Firewall for Database Engine Access.
Hast du in der SQL Konfiguration die Name Pipes als Netzwerkprotokoll aktiviert? Dann solltest du auch die Regeln für File and Printer Sharing aktivieren.
Ansonsten anstatt die ausführbare Datei (sqlservr.exe) in der Regel anzugeben, auf den entsprechende Windows Service SQL Server verweisen.
Gruß,
Dani
Zitat von @Palpatine:
Oh ja, in Zeiten von Verschlüsselungstrojanern die Firewall ausschalten, sehr guter Tipp...
Oh ja, in Zeiten von Verschlüsselungstrojanern die Firewall ausschalten, sehr guter Tipp...
Ok - und wo ist da das Problem? Auch der Verschlüsselungstrojaner braucht erst mal einen Service auf den er gehen kann. Jetzt gibt es also 2 Optionen:
a) Du hast nutzbare Services (z.B. eben zugriff auf die SQL-DB) und der VT ist so gut das er die Verbindung abfängt und die Daten verschlüsselt. Da du aber ja den Zugriff haben sollst geht das auch durch eine aktive Firewall locker durch - die hat ja keine grössere Filterung WAS du da machst...
b) Du hast Services laufen auf die der Nutzer keinen Zugriff haben soll - z.B. bei nem SQL-Server auch aus welchem Grund auch immer noch nen File-Server laufen ohne das du das willst. Dann würde ich eher überlegen WARUM der Service da ist und den eher abschalten...
Dazu kommt: Eigentlich sollte man annehmen das du das Servernetz vom Arbeitsnetz getrennt hast und die vorgeschaltete Firewall somit schon schaut was passiert... Also müsste man erst mal einen Server im Servernetz übernehmen um dann den SQL-Server zu bekommen (auf Ports die nicht eh schon an der FW vorbeigehen). DANN hast du aber in den meisten Fällen ganz andere Probleme da ich dann vermutlich auch schon Passwörter usw. habe. DANN kann ich natürlich richtig was machen - aber dann wäre die Win-Firewall auch kein Schutz mehr (da ich dann ja ggf. schon einfach per RDP auf die Kiste gehen kann um die FW abzuschalten...).
Also - von daher hat die in einem Netz bei dem es eine Firewall gibt (und die auch zwischen den verschiedenen Segmenten prüft) keinen grossen Mehrwert mehr...
Windows Firewall meldet sich, wenn unbekannte Programme versuchen, Ports etc. zu öffnen. Das reicht schon. Besser als nix. Die Aussage "Das Ding bringt auf den Clients in einer Firmenumgebung mehr Ärger als das es gutes tut." stimmt so nicht, sorry. Zumal alles über GPO regelbar ist.
@grmg2010: Ich habe bei mir noch zusätzlich die sqlbrowser.exe freigegeben, keine Probs bei der Verbindung.
@grmg2010: Ich habe bei mir noch zusätzlich die sqlbrowser.exe freigegeben, keine Probs bei der Verbindung.
Moin Palpatine,
jetzt habe ich die 5 Minuten um meinen letzte, leicht sarkastische Bemerkung auch etwas zu begründen.
Die Verschlüsselungsfieslinge kommen meiner Erfahrung nach zu > 90% über die Mailinfrastruktur der Unternehmen herein.
Hier eine gefakte Bewerbung, da eine Rechnung, ich sehe das täglich auf den SMTP-Proxys unserer Kunden.
Zum Schutz vor einer Infektion bringt dir die Windows FW absolut gar nichts, da du bestimmt nicht den eigenen E-Mail Client intern aussperren tust.
Wenn der User nun den Schädling aktiviert und die auf dem Client installierte AV ist nicht in der Lage dies zu erkennen, dann kannst du die Windows FW ab da an vollständig in die Tonne treten, da jeder halbwegs gut geschriebene Trojaner diese als erstes gegen die Wand fahren lässt.
Vor Verschlüsselung von dem Client auf dem Server schützt das Ding ebenfalls nicht, da die SBM Verbindungen im Normallfall ebenfalls gewollt sind. Hier bringt eher ein sauberes Berechtigungskonzept einen gewissen Schutz, falls es bereits zu einem Ausbruch gekommen ist.
Ich möchte nicht sagen, dass das Ding bei allem komplett nutzlos ist, aber der Administrationsaufwand und der Nutzen daraus, stehen bei der Windows FW, aus meiner Sicht in einem sehr ungesunden Verhältnis.
Grüsse aus BaWü
Alex
jetzt habe ich die 5 Minuten um meinen letzte, leicht sarkastische Bemerkung auch etwas zu begründen.
Die Verschlüsselungsfieslinge kommen meiner Erfahrung nach zu > 90% über die Mailinfrastruktur der Unternehmen herein.
Hier eine gefakte Bewerbung, da eine Rechnung, ich sehe das täglich auf den SMTP-Proxys unserer Kunden.
Zum Schutz vor einer Infektion bringt dir die Windows FW absolut gar nichts, da du bestimmt nicht den eigenen E-Mail Client intern aussperren tust.
Wenn der User nun den Schädling aktiviert und die auf dem Client installierte AV ist nicht in der Lage dies zu erkennen, dann kannst du die Windows FW ab da an vollständig in die Tonne treten, da jeder halbwegs gut geschriebene Trojaner diese als erstes gegen die Wand fahren lässt.
Vor Verschlüsselung von dem Client auf dem Server schützt das Ding ebenfalls nicht, da die SBM Verbindungen im Normallfall ebenfalls gewollt sind. Hier bringt eher ein sauberes Berechtigungskonzept einen gewissen Schutz, falls es bereits zu einem Ausbruch gekommen ist.
Ich möchte nicht sagen, dass das Ding bei allem komplett nutzlos ist, aber der Administrationsaufwand und der Nutzen daraus, stehen bei der Windows FW, aus meiner Sicht in einem sehr ungesunden Verhältnis.
Grüsse aus BaWü
Alex