SQL Server的安全設定問題解答

目前SQL INJECTION的攻擊測試愈演愈烈，很多大型的網站和論壇都相繼被注入。這些網站一般使用的多為SQL SERVER資料庫，正因為如此，很多人開始懷疑SQL SERVER的安全性。其實SQL SERVER 2000已經通過了美國政府的C2級安全認證-這是該行業所能擁有的最高認證級別，所以使用SQL SERVER還是相當的安全的。當然和ORCAL、DB2等還是有差距，但是SQL SERVER的易用性和廣泛性還是能成為我們繼續使用下去的理由。那怎麼樣才能使SQL SERVER的設定讓人使用的放心呢?

　　第一步肯定是打上SQL SERVER最新的安全補丁.如果這一步都沒有做好，那我們也沒有繼續下去的必要了。

　　第 二步是修改預設的1433埠，並且將SQL SERVER隱藏。這樣能禁止對試圖列舉網路上現有的 SQL Server 客戶端所發出的廣播作出響應。另外，還需要在TCP/IP篩選中將1433埠遮蔽掉，儘可能的隱藏你的SQL SERVER資料庫。這樣子一但讓攻擊建立了SQL SERVER的賬號，也不能馬上使用查詢分析器遠端登陸來進行下一步的攻擊。單從ASP，PHP等頁面構造惡意語句的話，還有需要檢視返回值的問題，總比 不上直接查詢分析器來得利落。所以我們首先要做到即使讓別人注入了，也不能讓攻擊者下一步做得順當。修改方法：企業管理器 --&gt 你的資料庫組 --&gt 屬性 --&gt 常規 --&gt 網路配置 --&gt TCP/IP --&gt 屬性 ，在這兒將你的預設埠進行修改，和SQL SERVER的隱藏。

　　第三步是很重要的一步，SQL INJECTION往往在WEB CODE中產生。而做為系統管理員或者資料庫管理員，總不能常常的去看每一段程式碼。即使常常看程式碼，也不能保證我們在上面的疏忽。那怎麼辦?我們就要從數 據庫角色著手，讓資料庫使用者的許可權劃分到最低點。SQL SERVER的預設許可權讓人真的很頭疼，許可權大得非常的高，許可權小的又什麼都做不了，SYSADMIN和db_owner真是讓人又愛又恨。攻擊者一但確 認了網站存在SQL INJECTION漏洞，肯定有一步操作步驟就是測試網站的SQL SERVER使用者具有多大的許可權。一般都會藉助SELECT IS_SRVROLEMEMBER('sysadmin')，或者SELECT IS_MEMBER('db_owner')，再或者用user = 0(讓字元和數字進行比較，SQL SERVER就會提示了錯誤資訊，從該資訊中即可知道一些敏感資訊)等語句進行測試。方法還有，我也不敢多說了。其一怕錯，其二怕聯盟中的人扁。在當前， 如果網站的資料庫使用者用的是SA許可權，再加上確認了WEB所處在的絕對路徑，那麼就宣告了你的網站的OVER。db_owner許可權也一樣，如果確認了 絕對路徑，那麼有50%的機會能給你的機器中上WEB 方式的木馬，如海陽等。所以這兒我們確認了一點，我們必須要建立自已的許可權，讓攻擊者找不著下嘴的地方。在這兒引用一個SQL SERVER聯機幫助中的例子：

　　建立 SQL Server 資料庫角色的方法(企業管理器)

　　建立 SQL Server 資料庫角色

　　1. 展開伺服器組，然後展開伺服器。

　　2. 展開"資料庫"資料夾，然後展開要在其中建立角色的資料庫。

　　3. 右擊"角色"，然後單擊"新建資料庫角色"命令。

　　4. 在"名稱"框中輸入新角色的名稱。

　　5. 單擊"新增"將成員新增到"標準角色"列表中，然後單擊要新增的一個或多個使用者。(可選)

　　只有選定資料庫中的使用者才能被新增到角色中。

　　物件許可權

　　處理資料或執行過程時需要稱為物件許可權的許可權類別：

　　· SELECT、INSERT、UPDATE 和 DELETE 語句許可權，它們可以應用到整個表或檢視中。

　　· SELECT 和 UPDATE 語句許可權，它們可以有選擇性地應用到表或檢視中的單個列上。

　　· SELECT 許可權，它們可以應用到使用者定義函式。

　　· INSERT 和 DELETE 語句許可權，它們會影響整行，因此只可以應用到表或檢視中，而不能應用到單個列上。

　　· EXECUTE 語句許可權，它們可以影響儲存過程和函式。

　　語句許可權

　　創 建資料庫或資料庫中的項(如表或儲存過程)所涉及的活動要求另一類稱為語句許可權的許可權。例如，如果使用者必須能夠在資料庫中建立表，則應該向該使用者授予 CREATE TABLE 語句許可權。語句許可權(如 CREATE DATABASE)適用於語句自身，而不適用於資料庫中定義的特定物件。

　　語句許可權有：

　　· BACKUP DATABASE

　　· BACKUP LOG

　　· CREATE DATABASE

　　· CREATE DEFAULT

　　· CREATE FUNCTION

　　· CREATE PROCEDURE

　　· CREATE RULE

　　· CREATE TABLE

　　· CREATE VIEW

　　暗示性許可權

　　暗示性許可權控制那些只能由預定義系統角色的成員或資料庫物件所有者執行的活動。例如，sysadmin 固定伺服器角色成員自動繼承在 SQL Server 安裝中進行操作或檢視的全部許可權。

　　資料庫物件所有者還有暗示性許可權，可以對所擁有的物件執行一切活動。例如，擁有表的使用者可以檢視、新增或刪除資料，更改表定義，或控制允許其他使用者對錶進行操作的許可權。

　　db_owner 在資料庫中有全部許可權。

　　db_accessadmin 可以新增或刪除使用者 ID。

　　db_securityadmin 可以管理全部許可權、物件所有權、角色和角色成員資格。

　　db_ddladmin 可以發出 ALL DDL，但不能發出 GRANT、REVOKE 或 DENY 語句。

　　db_backupoperator 可以發出 DBCC、CHECKPOINT 和 BACKUP 語句。

　　db_datareader 可以選擇資料庫內任何使用者表中的所有資料。

　　db_datawriter 可以更改資料庫內任何使用者表中的所有資料。

　　db_denydatareader 不能選擇資料庫內任何使用者表中的任何資料。

　　db_denydatawriter 不能更改資料庫內任何使用者表中的任何資料。

　　在 這兒把新建的資料庫角色的許可權配置好，比如需要使用哪個表、檢視、儲存過程等。然後把Db_owner和db_securityadmin、 db_backupoperator取消，不給攻擊者BACKUP DATABASE和CREATE TABLE的機會，一但攻擊者具有這兩個許可權，那麼你的網站就還處在十分危險的狀態。還有注意一下，在建立資料庫賬號時，千萬不能對伺服器角色進行選擇。

　　第 四步是修改SQL SERVER內建儲存過程。SQL SERVER估計是為了安裝或者其它方面，它內建了一批危險的儲存過程。能讀到登錄檔資訊，能寫入登錄檔資訊，能讀磁碟共享資訊等等......各位看到 這兒，心裡可能會在想，我的網站中有其它的程式碼，又不像查詢分析器那樣能查接將結果輸出。給你這個許可權，又不能怎麼樣，還是看不到資訊。如果各位這樣想就 大錯特錯了。提示一下，如果攻擊者有CREATE TABLE的許可權，那麼建立一個臨時表，然後將資訊INSERT到表中，然SELECT出來，接著跟數字進行比較，讓SQL SERVER報錯，那麼結果就全出來了......所以我們要報著寧錯殺，不放過的態度進行修補。

　　先來列出危險的內建儲存過程：

　　xp_cmdshell

　　xp_regaddmultistring

　　xp_regdeletekey

　　xp_regdeletevalue

　　xp_regenumkeys

　　xp_regenumvalues

　　xp_regread

　　xp_regremovemultistring

　　xp_regwrite

　　ActiveX自動指令碼：

　　sp_OACreate

　　sp_OADestroy

　　sp_OAMethod

　　sp_OAGetProperty

　　sp_OASetProperty

　　sp_OAGetErrorInfo

　　sp_OAStop

　　將有安全問題的SQL過程刪除.比較全面.一切為了安全!

　　刪除有安全隱患的擴充套件:

　　exec sp_dropextendedproc 'xp_cmdshell' [刪除此項擴充套件後,將無法遠端連線資料庫]

　　exec sp_dropextendedproc 'xp_dirtree' [刪除此項擴充套件後,將無法新建或附加資料庫]

　　exec sp_dropextendedproc 'xp_enumgroups'

　　exec sp_dropextendedproc 'xp_fixeddrives'

　　exec sp_dropextendedproc 'xp_loginconfig'

　　exec sp_dropextendedproc 'xp_regaddmultistring'

　　exec sp_dropextendedproc 'xp_regdeletekey'

　　exec sp_dropextendedproc 'xp_regdeletevalue'

　　exec sp_dropextendedproc 'xp_regread'

　　exec sp_dropextendedproc 'xp_regremovemultistring'

　　exec sp_dropextendedproc 'xp_regwrite'

　　exec sp_dropextendedproc 'xp_enumerrorlogs'

　　exec sp_dropextendedproc 'xp_getfiledetails'

　　exec sp_dropextendedproc 'xp_regenumvalues'

　　恢復擴充套件

　　exec sp_addextendedproc 'xp_cmdshell', 'xplog70.dll'

　　exec sp_addextendedproc 'xp_dirtree', 'xpstar.dll'

　　exec sp_addextendedproc 'xp_enumgroups', 'xplog70.dll'

　　exec sp_addextendedproc 'xp_fixeddrives', 'xpstar.dll'

　　exec sp_addextendedproc 'xp_loginconfig', 'xplog70.dll'

　　exec sp_addextendedproc 'xp_regaddmultistring', 'xpstar.dll'

　　exec sp_addextendedproc 'xp_regdeletekey', 'xpstar.dll'

　　exec sp_addextendedproc 'xp_regdeletevalue', 'xpstar.dll'

　　exec sp_addextendedproc 'xp_regread', 'xpstar.dll'

　　exec sp_addextendedproc 'xp_regremovemultistring', 'xpstar.dll'

　　exec sp_addextendedproc 'xp_regwrite', 'xpstar.dll'

　　exec sp_addextendedproc 'xp_enumerrorlogs', 'xpstar.dll'

　　exec sp_addextendedproc 'xp_getfiledetails', 'xpstar.dll'

　　exec sp_addextendedproc 'xp_regenumvalues', 'xpstar.dll'

　　全部複製到"SQL查詢分析器"

　　點選選單上的--"查詢"--"執行"，就會將有安全問題的SQL過程刪除(以上是7i24的正版使用者的技術支援)

　　更改預設SA空密碼.資料庫連結不要使用SA帳戶.單資料庫單獨設使用帳戶.只給public和db_owner許可權.

　　資料庫不要放在預設的位置.

　　SQL不要安裝在PROGRAM FILE目錄下面.

　　以 上各項全在我們封殺之列，例如xp_cmdshell遮蔽的方法為：sp_dropextendedproc 'xp_cmdshell'，如果需要的話，再用sp_addextendedproc 'xp_cmdshell', 'xpsql70.dll'進行恢復。如果你不知道xp_cmdshell使用的是哪個.dll檔案的話，可以使用 sp_helpextendedproc xp_cmdshell來檢視xp_cmdshell使用的是哪個動態聯接庫。另外，將xp_cmdshell遮蔽後，我們還需要做的步驟是將 xpsql70.dll檔案進行改名，以防止獲得SA的攻擊者將它進行恢復。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/16436858/viewspace-617156/，如需轉載，請註明出處，否則將追究法律責任。