sql server 2000 如何防护！

最新推荐文章于 2022-03-23 11:50:06 发布

0狩猎者0

最新推荐文章于 2022-03-23 11:50:06 发布

阅读量949

点赞数

本文链接：https://blog.youkuaiyun.com/dingjixian/article/details/1852627

版权

本文探讨了SQL Server 2000的安全配置方法，包括密码策略、账号管理、日志记录、扩展存储过程管理等内容，旨在提高数据库系统的安全性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

.

OK，通过这台被控制的SQL SERVER服务器，攻击者可以通过它来查找网络内部
其他机器来扩大战果，下面是一个SQL脚本来列举网络中其他SQL SERVER存在
空帐户'sa'的示例：

-----------------------------------------------------------------------

-- Create temp table to store enumerated servers

SET NOCOUNT ON

CREATE TABLE #temp (shelldump varchar(255))

INSERT #temp EXEC xp_cmdshell 'osql -L'

DECLARE @current_server varchar(255), @conn_string varchar(255)

DECLARE sql_cursor CURSOR FOR SELECT * FROM #temp

OPEN sql_cursor FETCH NEXT FROM sql_cursor INTO @current_server

-- Loop through potential targets and check for null sa accounts

-- If target is vulnerable, version information will be displayed

WHILE @@FETCH_STATUS = 0

BEGIN

  If @current_server <> 'Servers:'

  BEGIN

SELECT @current_server = rtrim(ltrim(@current_server))

SELECT @conn_string = 'exec xp_cmdshell ''osql -S' + @current_server + ' -Usa -P -Q "select @@version"'''

PRINT 'Attempting connection to server: ' + @current_server

EXECUTE (@conn_string)

PRINT '====================================================================='

  END

  FETCH NEXT FROM sql_cursor INTO @current_server

END

--Clean up

CLOSE sql_cursor

DEALLOCATE sql_cursor

DROP TABLE #TEMP

--------------------------------------------------
2、xp_proxiedmetadata (xprepl.dll)

该存储过程使用4个参数。给第二个参数传递超长的字符串会覆盖异常处
理程序所保存的返回地址。

3、xp_SetSQLSecurity (xpstar.dll)

该存储过程使用4个参数。给第三个参数传递超长的字符串会使整个SQL
Server进程立即终止。

4、xp_displayparamstmt(xprepl.dll)
xp_enumresultset(xprepl.dll)
xp_showcolv (xprepl.dll)
xp_updatecolvbm (xprepl.dll)

给第一个参数传递超长的串将导致非法操作并覆盖异常处理程序所保存的返
回地址。

这里告诉大家一个技巧性的东西，如果想要知道这些扩展存储过程调用了那写dll
文件，你可以如下操作，如：

select o.name,c.text from dbo.syscomments c, dbo.sysobjects o where c.id = o.id and o.name = 'xp_peekqueue'

这样你就可以获得调用这个扩展存储过程的DLL了，如果微软没有出补丁的话，你就
暂时把这个DLL文件改名吧，当然有些DLL文件调用几个扩展存储过程，不能盲目更改，
否则导致其他的也不能使用，你需要使用下面的操作来知道DLL调用那些扩展存储过程：

select o.name,c.text from dbo.syscomments c, dbo.sysobjects o where c.id = o.id and c.text = 'xpqueue.dll'

幸好微软出了补丁，你可以到下面的地方找到，不用一个一个找DLL程序了，呵呵：

http://support.microsoft.com/support/sql/xp_security.asp

这个漏洞@stake发现并提供演示的测试代码，大家可在这里找到：

http://www.atstake.com/research/advisories/2000/sqladv2-poc.c

--------------------------------------------------------------------------

OK，当然SQL SERVER也有一些其他漏洞，相对轻微些，如ISS发现的管理员
LOGIN ID存储在注册表中，其加密的方法比较简单，很容易获得，详细情况
请看：http://xforce.iss.net/alerts/advise45.php3。大家可以到其他
地方找找。

---------------------------------------------------------------------

一些对SQL SERVER系统的安全建议：

--保证打上最新的安全补丁，如下：
Windows NT 4.0 - Service Pack 6a

SQL Server 6.5 - Service Pack 5a

SQL Server 7.0 - Service Pack 2. (Various hotfixes - check
http://www.microsoft.com/download)

SQL Server 2000 - Hotfix S80233i.exe (Intel)
当然大家要密切注意微软的安全公告。

--不要在IP sockets使用端口1433，如果你使用Multi-protocol也请
修改端口。

--不要把'sa'密码嵌入到任意应用程序如VB/DELPHI apps里，或者一
global.asa文件里，因为"sa"是SQL Server 的一个默认密码，其权限
类似与WINDOWS NT系统里的管理员帐户，而且密码为空。

--改变'sa'和'probe'帐户的密码。

--保证SQL SERVER的错误记录在NTFS系统上。

--如果你不需要xp_cmdshell( use sp_dropextendedproc 'xp_cmdshell' )
就不要把xp_cmdshell extended stored proc(扩展存储过程) 留在服务
器上。在任何isql窗口中输入：
use master
sp_dropextendedproc 'xp_cmdshell'

--丢弃不需要OLE自动存储过程，当然Enterprise Manager中的某些特征也
会不能使用，这些过程包括如下：

Sp_OACreate    Sp_OADestroy

Sp_OAGetErrorInfo    Sp_OAGetProperty

Sp_OAMethod    Sp_OASetProperty

Sp_OAStop

--去掉不需要的注册表访问过程，如下：

Xp_regaddmultistring

Xp_regdeletekey

Xp_regdeletevalue

Xp_regenumvalues

Xp_regread

Xp_regremovemultistring

Xp_regwrite

--去掉其他系统存储过程，如果你认为你觉得你还有威胁，当然
要小心Drop这些过程，你可以在测试机器上测试，保证你正常的
系统能完成工作，这些过程包括：

sp_bindsession sp_cursor sp_cursorclose
sp_cursorfetch  sp_cursoropen sp_cursoroption
sp_getbindtoken sp_GetMBCSCharLen sp_IsMBCSLeadByte
sp_OACreate    sp_OADestroy sp_OAGetErrorInfo
sp_OAGetProperty sp_OAMethod sp_OASetProperty
sp_OAStop sp_replcmds sp_replcounters
sp_repldone sp_replflush sp_replstatus
sp_repltrans  sp_sdidebug xp_availablemedia
xp_cmdshell xp_deletemail xp_dirtree
xp_dropwebtask xp_dsninfo xp_enumdsn
xp_enumerrorlogs xp_enumgroups  xp_enumqueuedtasks
xp_eventlog xp_findnextmsg xp_fixeddrives
xp_getfiledetails xp_getnetname xp_grantlogin
xp_logevent xp_loginconfig xp_logininfo
xp_makewebtask xp_msver    xp_perfend
xp_perfmonitor xp_perfsample xp_perfstart
xp_readerrorlog xp_readmail xp_revokelogin
xp_runwebtask xp_schedulersignal xp_sendmail
xp_servicecontrol xp_snmp_getstate xp_snmp_raisetrap
xp_sprintf xp_sqlinventory xp_sqlregister
xp_sqltrace xp_sscanf xp_startmail
xp_stopmail xp_subdirs xp_unc_to_drive

--去掉数据库中guest用户。
--关闭SQL MAIL兼容能力，防止传递一些木马病毒等。
--设置一个任务处理来定时运行下面的程序：

findstr /C:"Login Failed" /mssql7/log/*.*'

再重定向到其他文件或者MAIL到管理员信箱。

--经常检查带有空密码的帐户：

Use master
Select name,
      Password
from syslogins
where password is null
order by name

--检查所有不需要'sa'权限的存储过程和扩展存储过程访问权限：

Use master
Select sysobjects.name
From sysobjects, sysprotects
Where sysprotects.uid = 0
AND xtype IN ('X','P')
AND sysobjects.id = sysprotects.id
Order by name

--保证SQL SERVER的传输信息在隔离的网络段中。

数据库是电子商务、金融以及ERP系统的基础，通常都保存着重要的商业伙伴和客户信息。大多数企业、组织以及政府部门的电子数据都保存在各种数据库中，他们用这些数据库保存一些个人资料，比如员工薪水、个人资料等等。数据库服务器还掌握着敏感的金融数据。包括交易记录、商业事务和帐号数据，战略上的或者专业的信息，比如专利和工程数据，甚至市场计划等等应该保护起来防止竞争者和其他非法者获取的资料。数据完整性和合法存取会受到很多方面的安全威胁，包括密码策略、系统后门、数据库操作以及本身的安全方案。但是数据库通常没有象操作系统和网络这样在安全性上受到重视。

微软的SQL Server是一种广泛使用的数据库，很多电子商务网站、企业内部信息化平台等都是基于SQL Server上的，但是数据库的安全性还没有被人们更系统的安全性等同起来，多数管理员认为只要把网络和操作系统的安全搞好了，那么所有的应用程序也就安全了。大多数系统管理员对数据库不熟悉而数据库管理员有对安全问题关心太少，而且一些安全公司也忽略数据库安全，这就使数据库的安全问题更加严峻了。数据库系统中存在的安全漏洞和不当的配置通常会造成严重的后果，而且都难以发现。数据库应用程序通常同操作系统的最高管理员密切相关。广泛SQL Server数据库又是属于“端口”型的数据库，这就表示任何人都能够用分析工具试图连接到数据库上，从而绕过操作系统的安全机制，进而闯入系统、破坏和窃取数据资料，甚至破坏整个系统。

这里，我们主要谈论有关SQL Server2000数据库的安全配置以及一些相关的安全和使用上的问题。

在进行SQL Server 2000数据库的安全配置之前，首先你必须对操作系统进行安全配置，保证你的操作系统处于安全状态。然后对你要使用的操作数据库软件（程序）进行必要的安全审核，比如对ASP、PHP等脚本，这是很多基于数据库的WEB应用常出现的安全隐患，对于脚本主要是一个过滤问题，需要过滤一些类似 , ‘ ; @ / 等字符，防止破坏者构造恶意的SQL语句。接着，安装SQL Server2000后请打上补丁sp1以及最新的sp2。
下载地址是：http://www.microsoft.com/sql/downloads/2000/sp1.asp　和　http://www.microsoft.com/sql/downloads/2000/sp2.asp

在做完上面三步基础之后，我们再来讨论SQL Server的安全配置。

1、使用安全的密码策略
我们把密码策略摆在所有安全配置的第一步，请注意，很多数据库帐号的密码过于简单，这跟系统密码过于简单是一个道理。对于sa更应该注意，同时不要让sa帐号的密码写于应用程序或者脚本中。健壮的密码是安全的第一步！
SQL Server2000安装的时候，如果是使用混合模式，那么就需要输入sa的密码，除非你确认必须使用空密码。这比以前的版本有所改进。
同时养成定期修改密码的好习惯。数据库管理员应该定期查看是否有不符合密码要求的帐号。比如使用下面的SQL语句：
Use master
Select name,Password from syslogins where password is null

2、使用安全的帐号策略。
由于SQL Server不能更改sa用户名称，也不能删除这个超级用户，所以，我们必须对这个帐号进行最强的保护，当然，包括使用一个非常强壮的密码，最好不要在数据库应用中使用sa帐号，只有当没有其它方法登录到 SQL Server 实例（例如，当其它系统管理员不可用或忘记了密码）时才使用 sa。建议数据库管理员新建立一个拥有与sa一样权限的超级用户来管理数据库。安全的帐号策略还包括不要让管理员权限的帐号泛滥。
SQL Server的认证模式有Windows身份认证和混合身份认证两种。如果数据库管理员不希望操作系统管理员来通过操作系统登陆来接触数据库的话，可以在帐号管理中把系统帐号“BUILTIN/Administrators”删除。不过这样做的结果是一旦sa帐号忘记密码的话，就没有办法来恢复了。
很多主机使用数据库应用只是用来做查询、修改等简单功能的，请根据实际需要分配帐号，并赋予仅仅能够满足应用要求和需要的权限。比如，只要查询功能的，那么就使用一个简单的public帐号能够select就可以了。

3、加强数据库日志的记录。
审核数据库登录事件的“失败和成功”，在实例属性中选择“安全性”，将其中的审核级别选定为全部，这样在数据库系统和操作系统日志里面，就详细记录了所有帐号的登录事件。如图：

请定期查看SQL Server日志检查是否有可疑的登录事件发生，或者使用DOS命令。
findstr /C:"登录" d:/Microsoft SQL Server/MSSQL/LOG/*.*

4、管理扩展存储过程
对存储过程进行大手术，并且对帐号调用扩展存储过程的权限要慎重。其实在多数应用中根本用不到多少系统的存储过程，而SQL Server的这么多系统存储过程只是用来适应广大用户需求的，所以请删除不必要的存储过程，因为有些系统的存储过程能很容易地被人利用起来提升权限或进行破坏。
如果你不需要扩展存储过程xp_cmdshell请把它去掉。使用这个SQL语句：
use master
sp_dropextendedproc 'xp_cmdshell'
xp_cmdshell是进入操作系统的最佳捷径，是数据库留给操作系统的一个大后门。如果你需要这个存储过程，请用这个语句也可以恢复过来。
sp_addextendedproc 'xp_cmdshell', 'xpsql70.dll'

如果你不需要请丢弃OLE自动存储过程（会造成管理器中的某些特征不能使用），这些过程包括如下：
Sp_OACreate       Sp_OADestroy Sp_OAGetErrorInfo Sp_OAGetProperty
Sp_OAMethod Sp_OASetProperty       Sp_OAStop
去掉不需要的注册表访问的存储过程，注册表存储过程甚至能够读出操作系统管理员的密码来，如下：
Xp_regaddmultistring Xp_regdeletekey    Xp_regdeletevalue    Xp_regenumvalues
Xp_regread       Xp_regremovemultistring       Xp_regwrite
还有一些其他的扩展存储过程，你也最好检查检查。
在处理存储过程的时候，请确认一下，避免造成对数据库或应用程序的伤害。

5、使用协议加密
SQL Server 2000使用的Tabular Data Stream协议来进行网络数据交换，如果不加密的话，所有的网络传输都是明文的，包括密码、数据库内容等等，这是一个很大的安全威胁。能被人在网络中截获到他们需要的东西，包括数据库帐号和密码。所以，在条件容许情况下，最好使用SSL来加密协议，当然，你需要一个证书来支持。

6、不要让人随便探测到你的TCP/IP端口
默认情况下，SQL Server使用1433端口监听，很多人都说SQL Server配置的时候要把这个端口改变，这样别人就不能很容易地知道使用的什么端口了。可惜，通过微软未公开的1434端口的UDP探测可以很容易知道SQL Server使用的什么TCP/IP端口了（请参考《深入探索SQL Server网络连接的安全问题》）。
不过微软还是考虑到了这个问题，毕竟公开而且开放的端口会引起不必要的麻烦。在实例属性中选择TCP/IP协议的属性。选择隐藏 SQL Server 实例。如果隐藏了 SQL Server 实例，则将禁止对试图枚举网络上现有的 SQL Server 实例的客户端所发出的广播作出响应。这样，别人就不能用1434来探测你的TCP/IP端口了（除非用Port Scan）。

7、修改TCP/IP使用的端口
请在上一步配置的基础上，更改原默认的1433端口。在实例属性中选择网络配置中的TCP/IP协议的属性，将TCP/IP使用的默认端口变为其他端口。如图：

9、拒绝来自1434端口的探测
由于1434端口探测没有限制，能够被别人探测到一些数据库信息，而且还可能遭到DOS攻击让数据库服务器的CPU负荷增大，所以对Windows 2000操作系统来说，在IPSec过滤拒绝掉1434端口的UDP通讯，可以尽可能地隐藏你的SQL Server。

10、对网络连接进行IP限制
SQL Server 2000数据库系统本身没有提供网络连接的安全解决办法，但是Windows 2000提供了这样的安全机制。使用操作系统自己的IPSec可以实现IP数据包的安全性。请对IP连接进行限制，只保证自己的IP能够访问，也拒绝其他IP进行的端口连接，把来自网络上的安全威胁进行有效的控制。
关于IPSec的使用请参看：http://www.microsoft.com/china/technet/security/ipsecloc.asp

上面主要介绍的一些SQL Server的安全配置，经过以上的配置，可以让SQL Server本身具备足够的安全防范能力。当然，更主要的还是要加强内部的安全控制和管理员的安全培训，而且安全性问题是一个长期的解决过程，还需要以后进行更多的安全维护。