问题描述
解决方法
下面这三个都属于“扩大实例能力范围、同时扩大攻击面”的参数/功能,生产环境一般都应默认关闭或强管控。
1)xp_cmdshell(风险高)
作用:允许在 SQL Server 内执行操作系统命令(如 dir / del / net user 等),并可把结果回传到 SQL。
主要风险
- 远程命令执行(RCE)入口:一旦攻击者拿到较高权限(或通过注入链条提升权限),可直接在主机上执行命令。
- 权限滥用与横向移动:可读写文件、下载工具、添加账号、访问共享等,进一步控制主机/域环境。
- 审计难:很多操作表现为数据库调用,传统主机审计不一定第一时间关联到数据库账号。
- 代理账号配置不当(
sp_xp_cmdshell_proxy_account):可能导致低权限用户间接获得更高 OS 权限。
建议
- 生产默认关闭;确需使用时:仅限少数 DBA、最小权限、开启审计/告警、用替代方案(SQL Agent 作业、外部运维系统)优先。
2)Ad Hoc Distributed Queries(风险中-高,取决于环境)
作用:允许使用 OPENROWSET/OPENDATASOURCE 临时连接外部数据源(含 OLE DB),实现即席分布式查询/导入导出。
主要风险
- 绕过数据访问边界:可从 SQL Server 主动连接外部数据源,形成“出站通道”,带来数据外泄风险。
- 与高权限结合的危害:攻击者可借此读取网络文件/外部库数据,甚至触发对外部组件的利用(取决于 Provider)。
- 凭据与权限问题:可能引入明文凭据配置、非预期的 Windows 身份委派/双跳问题,造成权限扩散。
- 稳定性风险:即席连接外部源增加不可控依赖,外部源慢/不可用会拖慢 SQL Server 工作负载。
建议
- 不需要就关闭。若确需导入导出,优先使用:SSIS、BULK INSERT(配合受控目录)、Linked Server(受控、可审计),并限制可用 Provider、网络访问。
3)allow updates(风险极高,且通常不应出现)
作用:允许直接更新系统表(历史遗留功能)。
主要风险
- 可破坏系统元数据:误操作或恶意更新系统表可导致数据库/实例不一致、损坏、不可恢复。
- 极难审计与取证:系统表被改写后,安全边界与行为追踪会失真。
- 不受支持/不推荐:现代 SQL Server 版本基本不应使用该选项;开启通常意味着严重合规与稳定性问题。
建议
- 立即确认为何开启;生产应保持关闭。需要修改元数据应使用受支持的 DDL/系统存储过程,而不是直接改系统表。
补充:如何快速核查当前状态
EXEC sp_configure 'show advanced options', 1; RECONFIGURE;
EXEC sp_configure 'xp_cmdshell';
EXEC sp_configure 'Ad Hoc Distributed Queries';
EXEC sp_configure 'allow updates';