必须禁用xp_cmdshell、ole automation procedures和远程dac，并禁用sa账户；先启用高级选项再配置，所有操作须在master库执行，检查value_in_use为0才算成功。

必须禁用 xp_cmdshell，但只关它远远不够——它只是最显眼的后门，不是唯一入口。

检查并关闭 xp_cmdshell 的正确顺序

直接执行 EXEC sp_configure 'xp_cmdshell', 0; RECONFIGURE; 会报错，因为 xp_cmdshell 属于高级配置项，必须先打开“显示高级选项”开关才能修改它。

• 先启用高级选项：EXEC sp_configure 'show advanced options', 1; RECONFIGURE;
• 再禁用功能：EXEC sp_configure 'xp_cmdshell', 0; RECONFIGURE;
• 最后（可选）关闭高级选项开关：EXEC sp_configure 'show advanced options', 0; RECONFIGURE; —— 不关也不影响安全，但能减少误操作风险

注意：所有操作必须在 master 数据库上下文中执行，否则修改不生效。检查状态用：SELECT value_in_use FROM sys.configurations WHERE name = 'xp_cmdshell';，返回 0 才算成功。

一点妙笔

一款AI工具，主要用于体制内必备 AI 公文写作助手，适合需要提升相关任务效率的用户。

下载

为什么关了 xp_cmdshell 还可能被命令执行？

攻击者一旦拿到 SQL 注入点，只要数据库配置里还开着 Ole Automation Procedures，就能用 sp_OACreate + sp_OAMethod 调用 WScript.Shell 或 PowerShell，效果和 xp_cmdshell 几乎一样。

• 检查状态：SELECT value_in_use FROM sys.configurations WHERE name = 'Ole Automation Procedures';
• 一并禁用：EXEC sp_configure 'Ole Automation Procedures', 0; RECONFIGURE;
• 别信“代码里没调用就安全”——注入语句是运行时拼进去的，跟你的源码无关

远程 DAC 和 sa 账户才是真正的放大器

xp_cmdshell 和 sp_OACreate 都需要高权限上下文才能执行。如果攻击者连不到 sa 或等效账户，很多命令根本跑不起来。

• 查远程 DAC 是否开启：SELECT value_in_use FROM sys.configurations WHERE name = 'remote admin connections';，值为 1 就危险
• 立即关掉：EXEC sp_configure 'remote admin connections', 0; RECONFIGURE;
• sa 账户必须禁用或重命名：ALTER LOGIN sa DISABLE; 或 ALTER LOGIN sa WITH NAME = [sa_renamed_2026];
• 所有应用连接改用最小权限账号，比如只授 db_datareader + db_datawriter，绝不能给 db_owner 或 sysadmin

真正难处理的是那些依赖 xp_cmdshell 的老脚本或监控工具——它们报错不是因为漏洞，而是该淘汰了。加固不是加锁，是清理信任链里所有不必要的环节。