News zu Tech Portfolio
Eigentlich könnte man den aktuellen DBA-Tipp genauso gut als Netzwerk-Admin-Tipp bezeichnen. Denn hier geht es ausnahmsweise mal nicht explizit um Datenbanken, Tabellen und Zeilen. Stattdessen geht es um ein Thema, welches sehr häufig (und besonders zu Unrecht) übergangen wird – die TCP/IP-Konfiguration.
“Kleinigkeit!” … werden manche DBAs nun vielleicht denken.
“Einfach im SQL Server Config Manager aktivieren und schon geht ’s.” … ist häufig die Devise.
Doch die Realität sieht anders aus. Warum das so ist, zeigen wir euch im Folgenden:
Das SQL-Server-Setup installiert und konfiguriert zwar (fast) alles, ändert jedoch nicht die Einstellungen der Windows Defender Firewall. Diese Aufgabe wird dem DBA oder zumindest demjenigen überlassen, der den SQL Server installiert. In vielen Fällen führt das bedauerlicherweise dazu, dass die Windows Defender Firewall deaktiviert wird. Das mag zunächst unrealistisch klingen, ist im produktiven Umfeld aber in einem Drittel aller Fälle tatsächlich so vorzufinden.
Wir zeigen in diesem DBA-Tipp mit welcher TCP/IP-Konfiguration beides möglich ist – eine tadellose Verbindung von und zum SQL Server und zugleich ein aktiver IP-Paketfilter.
Die Lösung ist simpel. Alles was zu tun bleibt, ist zwei (optional drei) TCP/IP-Ports zu öffnen. Und das auch nur für zwei Dienste. Nachfolgend klären wir zunächst die Frage, welche Ports das sind und zeigen einen praktikablen Lösungsweg auf.
Hier erklären wir an zwei schlichten Beispielen, wie die beiden TCP/IP-Ports zu bestimmen sind und wie anschließend jeweils eine Ausnahme definiert werden kann.
Der erste Port ist besonders einfach, da er nicht konfigurierbar, und somit immer der Selbe ist. Es handelt sich um den SQL Server Browser, einen 32-Bit-Unterstützungsdienst, der die einzelnen lokalen Instanzen kennt und vermittelt. Er ist immer auf Port 1434 des UDP-Protokolls zu finden.
Der zweite (und zugleich wichtigste) Port ist zwar nicht immer pauschal zu nennen, doch es kostet keinen nennenswerten Aufwand ihn ausfindig zu machen. Man findet ihn in den Start-Meldungen des SQL-Server-Dienstes. Im Folgenden werden verschiedene Wege zur Bestimmung aufgezeigt.
EXECUTE [master].[sys].[xp_ReadErrorLog] 0, 1, N' listening ', N'', NULL, NULL, 'ASC';
EXECUTE [master].[sys].[xp_ReadErrorLog] 0, 1, N' listening ', N'', NULL, NULL, 'ASC';
SQL Server Network Configuration
Protocols for MSSQLSERVER*
TCP/IP → Properties
↓
IP Addresses
* Hier die jeweilige Instanz auszuwählen.
Eine SQL Server Standardinstanz läuft von Haus aus immer auf dem Port 1433 des TCP-Protokolls.
Eine zusätzliche (benannte) SQL Server Instanz läuft zunächst auf einem dynamischen Port des TCP-Protokolls, oft auch High Port genannt. Noch dazu ändert der Port sich bei jedem Start des Dienstes.
Letzteres ist unerfreulich und hieraus resultiert auch das eigentliche Problem für Administratoren, welches auch einer der häufigsten Gründe für das komplette Abschalten der integrierten Firewall sein dürfte.
Es stellt sich uns nun also die Frage: Wie soll man eine sinnvolle Ausnahmeregel anlegen, wenn der TCP/IP-Port wahllos wechselt?
Unsere Antwort: Gar nicht.
Denn anstatt sich mit dynamischen Regelwerken oder selbstlernenden Firewalls herumzuschlagen, ist es viel einfacher, den nötigen TCP/IP-Port fest (statisch) zu konfigurieren und anschließend eine simple Regel dafür zu definieren.
Hierzu entfernt man die dynamische Portangabe im Eingabefeld des SQL Server Config Managers und setzt stattdessen den statischen Port ein. Der einzige Nachteil daran ist, dass man die Instanz neu starten muss. Daher empfehlen wir, diese Konfiguration gleich unmittelbar nach der Installation durchzuführen.
Nachdem die nötigen Änderungen vorgenommen wurden, kann man schnell und einfach eine Regel in der Windows Defender Firewall anlegen. Dafür bietet die Management-Konsole einen guten Assistenten an. Doch selbst dieser ist nicht unbedingt nötig, sofern man die Windows PowerShell nicht scheut.
new-NetFirewallRule`
-Name "MSSQL13-Queries" ` -DisplayName "SQL Server 2016 - General Usage" ` -Group "SQL Databases" ` -Direction INBOUND ` -Description "Microsoft SQL Server 2016 - default instance - standard queries and DDL statements" ` -Protocol "TCP" ` -LocalPort 1433 ` -Program "C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Binn\SQLServr.exe" ` -Service "MSSQLSERVER"new-NetFirewallRule ` -Name "MSSQL13-Browser" ` -DisplayName "SQL Server 2016 - Instance Browser" ` -Group "SQL Databases" ` -Direction INBOUND ` -Description "Microsoft SQL Server 2016 - finding and advertising local instances" ` -Protocol "UDP" ` -LocalPort 1434 ` -Program "C:\Program Files (x86)\Microsoft SQL Server\90\Shared\SQLBrowser.exe" ` -Service "SQLBrowser"Das hier gezeigte Beispiel-Skript legt die nötigen Mindestregeln für eine SQL Server 2016 Standardinstanz an, um jenen Server unmittelbar im Anschluss zu benutzen. Erwähnt werden muss hier, dass der SQL-Browser-Dienst für Standardinstanzen nicht zwingend nötig ist.
new-NetFirewallRule `
-Name "MSSQL13-Queries" ` -DisplayName "SQL Server 2016 - General Usage" ` -Group "SQL Databases" ` -Direction INBOUND ` -Description "Microsoft SQL Server 2016 - instance CHRISTOPH - standard queries and DDL statements" ` -Protocol "TCP" ` -LocalPort 1492 ` -Program "C:\Program Files\Microsoft SQL Server\MSSQL13.CHRISTOPH\MSSQL\Binn\SQLServr.exe" ` -Service "MSSQL`$CHRISTOPH"new-NetFirewallRule ` -Name "MSSQL13-Management" ` -DisplayName "SQL Server 2016 - Maintenance" ` -Group "SQL Databases" ` -Direction INBOUND ` -Description "Microsoft SQL Server 2016 - instance CHRISTOPH - dedicated admin connection for emergency purposes" -Protocol "TCP" ` -LocalPort 1494 ` -Program "C:\Program Files\Microsoft SQL Server\MSSQL13.CHRISTOPH\MSSQL\Binn\SQLServr.exe" ` -Service "MSSQL`$CHRISTOPH"new-NetFirewallRule ` -Name "MSSQL13-Browser" ` -DisplayName "SQL Server 2016 - Instance Browser" ` -Group "SQL Databases" ` -Direction INBOUND ` -Description "Microsoft SQL Server 2016 - finding and advertising local instances" ` -Protocol "UDP" ` -LocalPort 1434 ` -Program "C:\Program Files (x86)\Microsoft SQL Server\90\Shared\SQLBrowser.exe" ` -Service "SQLBrowser"
Im zweiten Beispiel werden exemplarisch die Regeln für eine SQL Server 2016 Instanz mit dem Namen “CHRISTOPH” angelegt. Hierbei wurden die freien TCP/IP-Ports 1492, sowie 1494 genutzt, wie im Screenshot (rechter, oberer Bereich) zu sehen ist.
Es sei darauf hingewiesen, dass die beiden Ports vorher von Hand konfiguriert wurden. Zu sehen ist dies, zumindest teilweise, im rechten Drittel des Screenshot.
Mit beiden Beispielen wollen wir verdeutlichen, wie einfach und schnell man den Microsoft SQL Server auf die Verwendung eines gewünschten TCP/IP-Ports festlegen kann.
Hat man alles richtig gemacht – zur Erinnerung: Die Änderung am SQL Server wird immer erst nach einem Instanz-Neustart wirksam – so kann man sich anschließend davon überzeugen.
SELECT LEFT(CONCAT([ip_address],':',[port]),24) AS 'LocalConnection', LEFT(CONCAT([type_desc],' / ',[state_desc]),16) AS 'UsageStatus'FROM [master].[sys].[dm_tcp_listener_states]WHERE [type] = 0[is_ipv4] = 1;Eine Standardinstanz wird von Haus aus immer Folgendes melden:
Die im obigen Beispiel verwendete Instanz “CHRISTOPH” würde dagegen Folgendes ausgeben:
LocalConnection UsageStatus ------------------------ ----------------127.0.0.1:1434 TSQL / ONLINE 0.0.0.0:1433 TSQL / ONLINELocalConnection UsageStatus ------------------------ ----------------127.0.0.1:1494 TSQL / ONLINE 0.0.0.0:1492 TSQL / ONLINEBesonders kritische Geister können natürlich auch die NetStat.exe bemühen und “von außen” auf den SQL-Server-Prozess schauen.
Mit unserem aktuellen DBA Tipp wollen wir dazu beitragen, dass entstehende Firewall-Probleme durch eine mangelhafte TCP/IP-Konfiguration künftig vermieden werden.
Darüber hinaus können wir dir auch bei weiteren Herausforderungen, verbunden mit dem Thema TCP/IP-Konfiguration helfen.
Du planst, eine Standardinstanz absichtlich auf einen der hinteren Ports zu verlegen, um sie möglichst gut zu verbergen?
Dann ruf uns unter +49.371.909515–100 an. Unsere Spezialisten unterstützen dich gern!
Share this article