SQL Server säkerhet – Instanskonfigurationer

I tidigare inlägg har jag beskrivit ett av stegen i vår säkerhetsrevision av en SQL Server instans där vi kontrollerade login och deras rättigheter. Ett av våra andra steg är att kontrollera inställningar på instansnivå. Vad som är installerat och hur det är konfigurerat.

Aktiva tjänster
Kontrollera vilka SQL Server tjänster som är installerade och vilka som verkligen används. Varje tjänst som är installerad utgör en risk och därför ska man bara installera de tjänster och features som verkligen behövs. Om de behövs vid ett senare tillfälle är det lätt att lägga till eller aktivera dem. Om det finns tjänster som inte används bör de avinstalleras. Kontrollera om följande är installerat och används per instans:

Database Engine
SQL Server Replication
Full-text and Semantic Extractions for Search
Data Quality Services
Analysis Services Engine
Reporting Services – Native and/or SharePoint
Integration Services
Master Data Services
Distributed Replay Server and Client
Various Tools and Clients
Documentation Components

Globala inställningar
Det finns ett antal inställningar som det är rekommenderat att kontrollera pga. att de utgör en risk. De vi framför allt kontrollerar är:

• Ad Hoc Distributed Queries – Ska vara inaktivt om det inte behövs. Är en säkerhetsrisk eftersom användare kan ange lösenord i klartext när de ansluter mot providers.
• Clr enabled – Ska vara inaktivt om det inte behövs. Kan vara en säkerhetsriks beroende på om det finns kontroll på vad objekten gör.
• Cross db ownership chaining – Gör det möjligt att kringgå rättigheter mellan databaser. Bör vara inaktiv.
• Xp-cmdshell – Ska vara inaktiv för att undvika nätverks- och OS relaterade attacker.

All konfiguration finns i sys.configurations

SELECT name, value_in_use 
FROM sys.configurations
WHERE configuration_id IN (16391, 1562, 400, 102, 16390, 16393)

Aktivera revision av login

SQL Server har funktionalitet för att revidera inloggningsförsök. Vid revideringen skrivs informationen till SQL Server error loggen. Det finns fyra olika nivåer:

• None – Ingen revidering.
• Failed logins only – Bara misslyckade inloggningsförsök revideras vilket normalt är defaultinställningen.
• Successful logins only – Bara lyckade inloggningsförsök revideras.
• Both failed and successful logins – Samtliga inloggningsförsök revideras.

Minst ”Failed logins only” ska vara valt. Det ger dig möjlighet att t ex upptäcka en eventuell ”brute force” attack eller andra otillåtna inloggningsförsök.

Kontrollera vad som är konfigurerat för instansen med:

DECLARE @level int
EXEC master.dbo.xp_instance_regread N'HKEY_LOCAL_MACHINE', N'SoftwareMicrosoftMSSQLServerMSSQLServer', N'AuditLevel', @level OUTPUT
SELECT CASE WHEN @level = 0 THEN 'None'
WHEN @level = 1 THEN 'Successful logins only'
WHEN @level = 2 THEN 'Failed logins only'
WHEN @level = 3 THEN 'Both failed and successful logins' 
END AS [Vald revideringsgrad för loginförsök]

Kontrollera även så att det finns en alert konfigurerad för severity 14 vilket är säkerhetsrelaterade error.

SELECT CASE WHEN COUNT(sa.id) = 0 THEN 'Alert finns inte' ELSE 'Alert konfigurerat ' + CASE WHEN COUNT(so.id) = 0 THEN 'men ingen notification till operator' ELSE 'med notification till operator' END END AS [Alert status]
FROM msdb.dbo.sysalerts sa
LEFT OUTER JOIN msdb.dbo.sysnotifications sn ON sa.id = sn.alert_id
LEFT OUTER JOIN msdb.dbo.sysoperators so ON sn.operator_id = so.id
WHERE sa.severity = 14

Misslyckade inloggningsförsök – Kontrollera om det finns några misslyckade inloggningsförsök i SQL Server error loggen med:

EXEC master.dbo.xp_readerrorlog 0, 1, N'login failed', NULL, NULL, NULL, N'DESC'

Tillåtna autentiseringsmetoder
I största möjliga mån ska enbart Windows autentisering vara tillåtet vilket är mycket säkrare än SQL autentisering. Om mixed mode är valt ska skälet till detta verifieras och dokumenteras.

SELECT CASE SERVERPROPERTY('IsIntegratedSecurityOnly') WHEN 1 THEN 'Windows Authentication' WHEN 0 THEN 'Windows and SQL Server Authentication' END AS [Autentiseringsmodell]

Port och SQL Browser
Det är normalt rekommenderat att inte använda default porten 1433 eller dynamiska portar utan ändra till en statisk. Det är även rekommenderat att inte använda SQL Browser och i stället ange porten i connectionsträngen på applikationssidan.

Kontrollera konfigurerad port:

DECLARE @port varchar(20), @key varchar(100)
IF CHARINDEX('',@@SERVERNAME,0) <>0 BEGIN
               SET @key = 'SOFTWAREMICROSOFTMicrosoft SQL Server'
+@@SERVICENAME+'MSSQLServerSupersocketnetlibTCP'
END ELSE BEGIN
               SET @key = 'SOFTWAREMICROSOFTMSSQLServerMSSQLServerSupersocketnetlibTCP'
END

EXEC master..xp_regread @rootkey='HKEY_LOCAL_MACHINE', @key=@key,@value_name='Tcpport',@value=@port OUTPUT
SELECT 'Port Nummer'  = CONVERT(varchar(10),@port)

Kontrollera SQL Browser Service:

DECLARE @REGKEY nvarchar(128)
DECLARE @IsRunning table(running bit)
SET @REGKEY = 'SystemCurrentControlSetServicesSQLBrowser'
INSERT INTO @IsRunning
EXEC master.sys.xp_regread @rootkey='HKEY_LOCAL_MACHINE', @key= @REGKEY
IF (SELECT running FROM @IsRunning) = 1 BEGIN
                      DECLARE @state table([state] nvarchar(25))
                      DECLARE @msg nvarchar(155)
                      INSERT INTO @state
                      EXEC MASTER.dbo.xp_servicecontrol N'QUERYSTATE',N'sqlbrowser'
                      SET @msg = 'SQL Browser Service är installerad'
                      SELECT @msg = @msg + CASE [state] WHEN 'Running.' THEN 'och är aktivt' ELSE 'men är inte aktivt för tillfället' END
                      FROM @state
                      PRINT @msg
END ELSE BEGIN
                      PRINT 'SQL Browser Service är inte installerad'
END

Då har vi gått igenom två av de tre stegen vi kontrollerar, login och instanskonfiguration. Det tredje steget är genomgång av rättigheter och inställningar på databasnivå. Mer om det nästa gång.

/Björn