Mein Kollegen Vladimir entdeckte, dass man den SQL-Server-2005 nicht mehr so konfigurieren kann, dass er nur über Shared-Memory erreichbar ist.
Seit SQL-Slammer konfigurieren wir die an Arbeitspläzen installierten MSDEs so, dass sie nicht über das Netz erreichbar sind. Das wird auch von immer empfohlen, wenn man irgendwelche Sicherheitstipps liest.
Ist ja logisch, damit bietet der SQL-Server erheblich weniger Angriffsfläche.
Mit dem SQL-Server-2000 entfernt man einfach alle Protokolle "Server Network Utility" für die jeweilige Instanz. Dann kann man immer noch mittels Shared-Memory auf den lokalen SQL-Server zugreifen.
Der SQL-Server-2005 unterstützt das Shared-Memory-Protokoll aber nicht mehr. Im "SQL Server Configuration Manager" sieht man zwar noch das Protokoll "Shared Memory", aber das stimmt nicht. Das kann man auch ganz gut im Process-Explorer sehen, wenn man sich die beiden Prozesse ansieht. Es ist mit einem kleinen Tests aber auch leicht nachvollziehbar.
Dazu muss man einfach in dem Tool am SQL-Server-2005 alle Protokolle deaktivieren und nur Shared Memory übrig lassen. Danach muss man den Dienst neu starten.
Dann sieht man schon im Errorlog des SQL-Servers:
Server local connection provider is ready to accept connection on [ \\.\pipe\SQLLocal\SQLEXPRESS ].
Server local connection provider is ready to accept connection on [ \\.\pipe\MSSQL$SQLEXPRESS\sql\query ].
Wenn man sich nun explizit über Shared-Memory (LPC) zum SQL-Server verbindet, dann klappt der Zugriff:
>SQLCMD -S lpc:.\MyExpress -E
1> SELECT net_transport FROM sys.dm_exec_connections WHERE session_id = @@SPID
2> go
net_transport
—————————————-
Shared memory
(1 Zeilen betroffen)
1> exit
Der Zugriff verwendet aber nicht Shared-Memory, sondern eine spezielle Named-Pipe (obwohl Named-Pipes deaktiviert wurde):
>SQLCMD -S np:\\.\pipe\SQLLocal\MyExpress -E
1> SELECT net_transport FROM sys.dm_exec_connections WHERE session_id = @@SPID
2> go
net_transport
—————————————-
Shared memory
(1 Zeilen betroffen)
1> exit
Weil die alten Client, die bspw. ODBC nutzen, das "neue" Shared-Memory nicht kennen, werden sie auf etwas umgelenkt, dass sie kennen: die "bisherigen" Named-Pipes. Deswegen ist jetzt jeder SQL-Server immer auch über die Standard-Pipe erreichbar, selbst wenn das Protokoll Named-Pipes deaktiviert ist:
>SQLCMD -S np:\\.\pipe\MSSQL$MyExpress\sql\query -E
1> SELECT net_transport FROM sys.dm_exec_connections WHERE session_id = @@SPID
2> go
net_transport
—————————————-
Named pipe
(1 Zeilen betroffen)
1> exit
Man kann jetzt darüber streiten, ob das ein Sicherheitsproblem ist, aber es ist kein Bug, sondern ein beabsichtigtes Feature um abwärtskompatibel zu sein. Es ist auch kein Geheimnis, ich fand mehrere Artikel im Internet, die das bestätigen, wenn auch das Problem nicht als solches beschreiben (erkennen?), z.B. bei SQL-Protocols.
Der Zugriff über eine Remote-Pipe funktioniert hingegen nicht:
>SQLCMD -S np:\\MyPC\pipe\MSSQL$MyExpress\sql\query -E
HResult 0xE9, Level 16, State 1
Named Pipes Provider: Kein Prozess ist am anderen Ende der Pipe.
Sqlcmd: Error: Microsoft SQL Native Client : Communication link failure.
Sqlcmd: Error: Microsoft SQL Native Client : An error has occurred while
establishing a connection to the server. When connecting to SQL Server
2005, this failure may be caused by the fact that under the default settings
SQL Server does not allow remote connections..
Das geht nur, wenn man auch Named-Pipes erlaubt.
