News zu Tech Portfolio

TCP/IP-Konfiguration und Probleme mit Firewalls im SQL-Server-Alltag

Eigentlich könnte man den aktuellen DBA-Tipp genauso gut als Netzwerk-Admin-Tipp bezeichnen. Denn hier geht es ausnahms­weise 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:

Firewall Problematik

Windows Defender Firewall

Das SQL-Server-Setup instal­liert und konfi­gu­riert zwar (fast) alles, ändert jedoch nicht die Einstellungen der Windows Defender Firewall. Diese Aufgabe wird dem DBA oder zumindest demje­nigen überlassen, der den SQL Server instal­liert. In vielen Fällen führt das bedau­er­li­cher­weise dazu, dass die Windows Defender Firewall deakti­viert wird. Das mag zunächst unrea­lis­tisch klingen, ist im produk­tiven 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 prakti­kablen Lösungsweg auf.

Herausforderung bei der TCP/IP-Konfiguration

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 konfi­gu­rierbar, 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 nennens­werten Aufwand ihn ausfindig zu machen. Man findet ihn in den Start-Meldungen des SQL-Server-Dienstes. Im Folgenden werden verschiedene Wege zur Bestimmung aufgezeigt. 

Ermittlung der Ports via klassischer ERRORLOG-Datei:

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';

Ermittlung der Ports per Windows-Ereignisprotokoll:

Filter Current Log
Event View Filter

Außerdem lohnt sich ein Blick in den SQL Server Config Manager unter:

SQL Server Network Configuration

Protocols for MSSQLSERVER*

TCP/IP → Properties

↓        

IP Addresses



* Hier die jeweilige Instanz auszuwählen.

SQL Server Config Manager

Dabei gilt:

TCP/IP Einstellungen

Eine SQL Server Standardinstanz läuft von Haus aus immer auf dem Port 1433 des TCP-Protokolls.

TCP/IP Einstellungen

Eine zusätz­liche (benannte) SQL Server Instanz läuft zunächst auf einem dynami­schen 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 resul­tiert auch das eigent­liche Problem für Administratoren, welches auch einer der häufigsten Gründe für das komplette Abschalten der integrierten Firewall sein dürfte.

Lösungsansatz zur Konfiguration der TCP/IP-Ports

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 dynami­schen Regelwerken oder selbst­ler­nenden Firewalls herum­zu­schlagen, ist es viel einfacher, den nötigen TCP/IP-Port fest (statisch) zu konfi­gu­rieren 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 statt­dessen den stati­schen Port ein. Der einzige Nachteil daran ist, dass man die Instanz neu starten muss. Daher empfehlen wir, diese Konfiguration gleich unmit­telbar nach der Installation durchzuführen.

Nachdem die nötigen Änderungen vorge­nommen 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.

Beispiel-Skript Standardinstanz:

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 unmit­telbar im Anschluss zu benutzen. Erwähnt werden muss hier, dass der SQL-Browser-Dienst für Standardinstanzen nicht zwingend nötig ist.

Beispiel-Skript benannte Instanz:

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"
Windows Defender Firewall Regeln

Im zweiten Beispiel werden exempla­risch 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 hinge­wiesen, dass die beiden Ports vorher von Hand konfi­gu­riert wurden. Zu sehen ist dies, zumindest teilweise, im rechten Drittel des Screenshot.

Mit beiden Beispielen wollen wir verdeut­lichen, wie einfach und schnell man den Microsoft SQL Server auf die Verwendung eines gewünschten TCP/IP-Ports festlegen kann.

Kontrolle

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.

Active Ports for T‑SQL
 
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:

Default Instance
 
LocalConnection          UsageStatus    
------------------------ ----------------
127.0.0.1:1434           TSQL / ONLINE  
0.0.0.0:1433             TSQL / ONLINE
Named Instance
 
LocalConnection          UsageStatus    
------------------------ ----------------
127.0.0.1:1494           TSQL / ONLINE  
0.0.0.0:1492             TSQL / ONLINE

Besonders kritische Geister können natürlich auch die NetStat.exe bemühen und “von außen” auf den SQL-Server-Prozess schauen.

Weiterer Bedarf und Impulse

Mit unserem aktuellen DBA Tipp wollen wir dazu beitragen, dass entste­hende Firewall-Probleme durch eine mangel­hafte 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 hast mehr als eine Hand voll SQL Server auf einem Windows-Host und willst nun jede Instanz auf den gleichen TCP-Port legen?
  • Dein Anliegen ist es, mehrere benannte Instanzen auf dem selben Windows-Host ohne laufenden Browserdienst betreiben?
  • Um den Security/Compliance-Richtlinien zu genügen, musst du ausnahmslos alle verwen­deten TCP/IP-Ports (inklusive DAC, Service Broker und AlwaysOn) deines SQL Servers auflisten?
  • 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 unter­stützen dich gern!

Hier findest du weitere Posts zu den Themen Microsoft oder SQL Server aus unserem News Bereich. 
icon-arrow_right_medium-violet-blue.svg

Share this article

Share on facebook
Facebook 
Share on twitter
Twitter 
Share on linkedin
LinkedIn 
Share on xing
XING 
Share on whatsapp
WhatsApp 
Share on email
Email