Förord

Undersök om du har ett problem Många företag använder SQL server med kundanpassade applikationer som kopplar till en SQL server med SQL server verifiering. Jag vet att Microsoft gärna vill att alla använder Windows Authentication eller i alla fall en applikations regel, men det är inte normalfallet just nu. Det är ett stort problem med SQL server verifiering och lösenordshanteringen. Det finns inget som stoppar en från att logga in med ett blankt lösenord. Jag var så tacksam för att med SQL2000 så måste man tvinga fram ett blankt lösenord vid installation för SA, inte som förut att default så var det ett blankt lösenord, tyvärr finns det inget som tvingar fram en minimilängd på lösenordet, eller som hindrar folk att använda deras inloggningsnamn som lösenord. Det är med det här i åtanke som jag vill presentera en kort lagrad procedur som går in i system tabellen sysxlogins och kontrollerar att användarens lösenord möter dessa tre kriterier: Inget lösenord, samma lösenord som inloggningsnamn och om lösenordet består av bara en bokstav. Översättning: Anna-Karin Söderberg

Innehåll

  » Steg för att undvika svaga lösenord
  » Hur man kontrollerar ett login
  » Summering

Skapa den här lagrade proceduren i master databasen på varje server som du administrerar och kör den för att utföra en enkel kontroll av existerande användare för att upptäcka om du har några användare med "dåliga" lösenord.


IF OBJECT_ID('dbo.spAuditPasswords') IS NOT NULL
DROP PROCEDURE dbo.spAuditPasswords
GO

CREATE PROCEDURE dbo.spAuditPasswords
AS
SET NOCOUNT ON

--Variabler
DECLARE @lngCounter INTEGER
> DECLARE @lngCounter1 INTEGER
DECLARE @lngLogCount INTEGER
DECLARE @strName VARCHAR(256)

-- Skapa tabellen som håller SQL loginen.
kapCREATE TABLE #tLogins
(
numID INTEGER IDENTITY(1,1)
,strLogin SYSNAME NULL
,lngPass INTEGER NULL
)

-- Sätt in icke ntanvändare till en temp tabell
INSERT INTO #tLogins (strLogin)
SELECT name FROM master.dbo.syslogins WHERE isntname = 0
SET @lngLogCount = @@ROWCOUNT

--Undersök om lösernordet är null(tomt) eller att
-- användaren är SQL login
PRINT 'Följande användare har blanka lösneord'
SELECT name AS 'Login Name' FROM master.dbo.syslogins
WHERE password IS NULL
AND isntname = 0


--Kontrollera om användarman och lösenord är samma
SET @lngCounter = @lngLogCount

WHILE @lngCounter <> 0
BEGIN
SET @strName = (SELECT strLogin FROM #tLogins WHERE numID = @lngCounter)

UPDATE #tLogins
SET lngPass = (SELECT PWDCOMPARE (@strName,(SELECT password FROM master.dbo.syslogins
WHERE name = @strName)))
WHERE numID = @lngCounter
SET @lngCounter = @lngCounter- 1
END
PRINT 'Följande användare har
samma lösenord och användarnamn' SELECT strLogin AS
> 'Login Name' FROM #tLogins
WHERE lngPass = 1

--Nollställ kolumnen för nästa lösenordstest
UPDATE #tLogins
SET lngPass = 0
--Undersök om lösenordet består av bara ett tecken
> SET @lngCounter = @lngLogCount
WHILE @lngCounter <> 0
BEGIN

SET @lngCounter1 = 1
SET @strName = (SELECT strLogin FROM #tLogins WHERE numID = @lngCounter)
WHILE @lngCounter1< 256
BEGIN UPDATE #tLogins
SET lngPass = (SELECT PWDCOMPARE (CHAR(@lngCounter1),
(SELECT password FROM master.dbo.syslogins WHERE name = @strName)))
WHERE numID = @lngCounter AND lngPass <> 1
SET @lngCounter1 = @lngCounter1 + 1
END
SET @lngCounter = @lngCounter - 1
END
PRINT 'Följande användare har ett lösenord som är ett tecken långt'
SELECT strLogin AS 'Login Name' FROM #tLogins WHERE lngPass = 1
GO
-- Test
EXEC dbo.spAuditPasswords

GO


Steg för att undvika svaga lösenord

Nu när du har skapat och kört den lagrade proceduren och upptäckt att du har ett problem så börjar det hårda jobbet. Du måste genomföra en kontroll av varje login med dåliga lösenord och antingen flytta allt från den användaren eller dokumentera vilken process som måste användas när man skapar ett nytt lösenord för den användaren.

Att bara ändra lösenordet rakt av, även SA lösenordet, utan att kolla loginet kan bli en rejäl mardröm genom att många applikationer, DTS paket, SQL server replikering och DSN kopplingar använder det lösenordet.

Den andra saken du måste göra är att skapa en policy från den här dagen och framåt är att skapa en kontroll över användarnamn och lösenord. Det här betyder inte att du kan ändra lösenord som du vill, med det menas att om du ska skapa nya användare och lösenord, så måste de vara svåra lösenord att knäcka och att kontrollera vilka rättigheter den användaren har.

En liten markering bara, du bör aldrig låta en utvecklare använda> SA som inloggningsnamn. SA loginet ska vara fritt så att om den som kan loginet (det ska vara några få som vet det) ändrar jobb eller slutar, så ska lösenordet ändras så fort som möjligt utan att behöva ändra i andra applikationer eller objekt samtidigt.

Jag har oftast den vanan att ändra SA loginets lösenord en gång i månaden på mina serverar, skulle någon komma på lösenordet så har de bara tillgång till det för en månad.

Den tredje saken som du måste göra är att dokumentera allt du har lärt dig så att nästa DBA som tar över inte behöver använda sin första månad till att skapa sin egna dokumentation.


IF OBJECT_ID('dbo.spAuditPasswords') IS NOT NULL
DROP PROCEDURE dbo.spAuditPasswords
GO

CREATE PROCEDURE dbo.spAuditPasswords
AS
SET NOCOUNT ON

--Variables
DECLARE @lngCounter INTEGER
> DECLARE @lngCounter1 INTEGER
DECLARE @lngLogCount INTEGER
DECLARE @strName VARCHAR(256)

-- Skapa tabellen som håller SQL loginen.
kapCREATE TABLE #tLogins
(
numID INTEGER IDENTITY(1,1)
,strLogin SYSNAME NULL
,lngPass INTEGER NULL
)

-- Sätt in icke ntanvändare till en temp tabell
INSERT INTO #tLogins (strLogin)
SELECT name FROM master.dbo.syslogins WHERE isntname = 0
SET @lngLogCount = @@ROWCOUNT

--Undersök om lösernordet är null(tomt) eller att
-- användaren är SQL login
PRINT 'Följande användare har blanka lösneord'
SELECT name AS 'Login Name' FROM master.dbo.syslogins
WHERE password IS NULL
AND isntname = 0


--Kontrollera om användarman och lösenord är samma
SET @lngCounter = @lngLogCount

WHILE @lngCounter <> 0
BEGIN
SET @strName = (SELECT strLogin FROM #tLogins WHERE numID = @lngCounter)

UPDATE #tLogins
SET lngPass = (SELECT PWDCOMPARE (@strName,(SELECT password FROM master.dbo.syslogins
WHERE name = @strName)))
WHERE numID = @lngCounter
SET @lngCounter = @lngCounter- 1
END
PRINT 'Följande användare har
samma lösenord och användarnamn' SELECT strLogin AS
> 'Login Name' FROM #tLogins
WHERE lngPass = 1

--Nollställ kolumnen för nästa lösenordstest
UPDATE #tLogins
SET lngPass = 0
--Undersök om lösenordet består av bara ett tecken
> SET @lngCounter = @lngLogCount
WHILE @lngCounter <> 0
BEGIN

SET @lngCounter1 = 1
SET @strName = (SELECT strLogin FROM #tLogins WHERE numID = @lngCounter)
WHILE @lngCounter1< 256
BEGIN UPDATE #tLogins
SET lngPass = (SELECT PWDCOMPARE (CHAR(@lngCounter1),
(SELECT password FROM master.dbo.syslogins WHERE name = @strName)))
WHERE numID = @lngCounter AND lngPass <> 1
SET @lngCounter1 = @lngCounter1 + 1
END
SET @lngCounter = @lngCounter - 1
END
PRINT 'Följande användare har ett lösenord som är ett tecken långt'
SELECT strLogin AS 'Login Name' FROM #tLogins WHERE lngPass = 1
GO
-- Test
EXEC dbo.spAuditPasswords

GO


Hur man kontrollerar ett login

Det finns tre enkla sätt att kontrollera ett redan existerande login. Det första är att prata med dina utvecklare om vilka logins de använder och vilka applikationer som använder vilket login. När du ändå pratar med dina utvecklare så försök att få reda på hur mycket jobb det är att ändra login och lösenord till något om det skulle behövas.

Efter att du har pratat med dina utvecklare och har dokumenterat deras svar så måste du ändå använda en eller två av de återstående metoderna för att upptäcka om något har missats eller glömts bort.

En av dessa metoder är att sätta upp en Profil trace genom att använda Security Audit event klassen med Audit Login eventet. Du måste också säkerställa att hostname datakolumnen läggs till på listan Data Columns Tab för att hjälpa dig hålla koll på källan av applikationen.

Den andra metoden är att periodiskt köra och fånga upp outputen av antingen lagrade proceduren sp_who eller sp_who2. Du kan fånga sp_who2 genom att skapa den lagrade proceduren nedanför och skapa ett jobb som kör den lagrade proceduren regelbundet. Den bör köras minst varje kvart fär att fånga upp kortlivade processer.


IF OBJECT_ID('dbo.spTrapWho') IS NOT NULL DROP PROCEDURE dbo.sp
TrapWho
GO
CREATE PROCEDURE dbo.spTrapWho AS
SET NOCOUNT ON
IF OBJECT_ID('dbo.tSPWho') IS NULL
BEGIN CREATE TABLE tSPWho
( spid INTEGER NULL ,status VARCHAR(100) NULL ,
login SYSNAME NULL ,
hostname SYSNAME NULL ,
blkby VARCHAR(10) NULL ,
dbname SYSNAME NULL ,
command VARCHAR(100) NULL ,
cputime INTEGER NULL ,
diskio INTEGER NULL ,
lastbatch VARCHAR(50) NULL ,
programname SYSNAME NULL ,
spid2 INTEGER NULL )
INSERT INTO tSPWho
EXEC dbo.sp_Who2
END
ELSE
BEGIN INSERT INTO tSPWho
EXEC dbo.sp_Who2
END
GO

När du har kört och analyserat din spårning eller outputen från en av de system lagrade procedurerna, så kan du enkelt hitta vilken login som körs på vilken host och kanske även säga vilken applikation som använder det loginet.

Att använda outputen från den här analysen kommer att hjälpa dig när du intervjuar dina utvecklare för att se vilket arbete som krävs för att ändra de nyupptäckta loginen och deras kod. Kom ihåg att DTS paket ibland sparas med användarnamn och lösenord vilket kommer att påverkas om lösenordet ändras manuellt. Du kanske måste öppna varje DTS paket och spara dem under ett nytt login för just det paketet.

Om du missar en och måste återställa login lösenordet kan du spara det tillbaka till det gamla lösenordet precis så länge som det behövs för att spara om DTS paketet under ett nytt login.

När du öppnar varje paket, se till att kontrollera kopplings objektet för att vad den loggar in med för att koppla till SEL servern. Kom ihåg att SQL servrar som kör replikeringar vanligen kommer att påverkas om man byter SA lösenordet.

Du måste vara beredd på att köra om replikeringen om du ändrar SA lösenordet. Du kan scripta ut replikeringen, vilket är en smart idé,och sen återskapa scriptet när du har ändrat lösenordet.

Summering

Det är några få företag som har väldigt svag login säkerhet på deras SQL servar och att upptäcka deras svagheter borde vara en av de första åtgärder man gör när man kommer till en ny miljö. Den här artikeln har kort förklarat en del snabba vägar att kontrollera svaga login och gett dig en start på vägen till att förstå SQL server miljön.

Referenser:
Q189126 Microsoft's Policy Regarding Missing or Invalid PasswordsQ298758 PRB: Using the Auto_Fix Option with sp_change_users_login Can Leave Security Vulnerabilities
Q168001 PRB: User Logon and/or Permission Errors After Restoring Dump Q259710 PRB: SQL Server Agent Fails to Start on Windows 9x When You Change the sa Password
Q274773 FIX: If You Change Windows Security to Windows/SQL Security the SA Password is Blank

Copyright 2002 by Randy Dyess (www.transactsql.com) med tillåtelse att publiceras på Pellesoft.se.

0 Kommentarer

Skriv en kommentar på artikeln

Ditt betyg på artikeln

UtmärktLäsvärdIntressantMindre braDålig

Kommentar: