Neulich musste ich einen SQL Datenbank über einen Port ins Internet exponieren – Ziel war, dass eine Anwendung von Remote auf diese Datenbank zugreifen kann. Um das System möglichst gut gegen Angriffe zu schützen habe ich folgende Maßnahmen ergriffen:

• Alle Microsoft Updates installiert
• Da für den Zugriff über das Internet SQL-Auth notwendig ist, habe ich den SA deaktiviert und einen neuen Login mit SA-Rechten angelegt, um damit Scans auf den SA zu umgehen
• Die Infrastruktur läuft noch vollkommen auf IPv4 und damit wird am Router NAT betrieben. Der Standard-Port auf dem der SQL Server intern läuft (1433) wird am Router auf einen beliebigen externen High-Port gemapped z.B. 47113
• Für den Zugriff auf die Datenbank selbst habe ich einen weiteren Benutzer angelegt und ihm in KeePaas ein hinreichend “scharfes” Passwort erstellen lassen

Der Zugriff von Remote sieht in einem Schaubild wie folgt aus:

Damit nicht von jedem beliebigen Rechner im Internet auf diesen Port zugegriffen werden kann ist es sinnvoll explizit nur die (externe) IP-Adresse des Benutzers in der Firewall des Windows Servers frei zu schalten!

Was aber tun, wenn der Benutzer eine dynamische IP-Adresse verwendet, welche z.B. bei der Telekom jede Nacht wechselt? In diesem Fall ist als Kompromiss zumindest eine Einschränkung auf den Provider möglich – hier z.B. auf 1&1 / Telefonica.

1. Ermittlung der externen IP-Adresse des Benutzers (http://www.wieistmeineip.de) oder alternativ einfach bei einer schon bestehenden Verbindung die externe IP-Adresse aus einem netstat heraus lesen
   
   Anmerkung: Das hier ist eine Verbindung aus dem KabelBW Netz und nicht von 1&1!
2. Ermittlung des vom Provider verwendeten IP-Ranges beim RIP
   
3. Ändern des Firewall Regel des SQL Servers wie folgt:
   
   Damit auf den Datenbankserver noch aus dem lokalen Netzwerk zugegriffen werden kann muss unter Remote IP address am einfachsten das lokale Netzwerk selbst mit z.B. 192.168.1.0/24 hinzugefügt werden.

Wer hierzu noch Verbesserungsvorschläge hat – nur zu, wir lernen immer voneinander.

Update, 2014-11-04-01:
Der Vorschlag ließ nicht lange auf sich warten – klar man kann die Verbindung zur Datenbank noch zusätzlich verschlüsseln. Hier die Anleitung für einen Windows Server 2012 R2 Essentials in Verbindung mit SQL Server 2014 Express (geht auch auf dem “alten” Windows Server 2011 Small Business Essentials mit SQL Server 2008 R2 Express):

1. Im SQL Server Configuration Manager unter Flags, Force Encryption auf Yes stellen
   
2. Unter Certificate muss dann noch das entsprechende zu verwendende Zertifikat ausgewählt werden
   
3. Damit die Einstellungen funktionieren, muss der SQL Server neu gestartet werden
4. Schlägt der Neustart des SQL Servers fehl und wird dazu folgende Meldung im System Eventlog protokolliert, gibt es ein Problem mit den Rechten welche der Service Account zum Zugriff auf das Zertifikat benötigt:
   
   Im Falle von SQL Server 2014 Express handelt es sich hier um
   NT System\MSSQLSERVER – ändert man diesen auf Local System oder einen entsprechend berechtigten Service Account welcher auf folgenden Pfad „C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys“ Zugriff hat, startet der SQL Server auch wieder
5. und damit wäre (entgegen dem verlinkten MSDN Artikel) die Verbindung fertig konfiguriert, auf dem Client muss nichts gemacht werden

Eine Prüfung ob auch wirklich verschlüsselt gearbeitet wird, ist durch folgende Abfrage möglich:

Select protocol_type, encrypt_option from sys.dm_exec_connections

Zusätzlich natürlich auch mit WireShark oder Netmon – was aber einen extra Artikel wert wäre.

Enjoy it, b!