5.59 "start \\\"看不到共享目录列表 https://scz.617.cn/windows/201205162125.txt Q: 一台64-bits Win7，本身不是域控，但加入到域中。开了一些共享，配置成使用域帐 号登录访问。对该台Win7进行过各种安全加固。实测发现从其它smbclient、XP、 2003、Win7用域帐号可以正常访问这些共享，比如"start \\\"，是没有 问题的。但是，不能从其它smbclient、XP、2003执行"start \\\"，会报告: -------------------------------------------------------------------------- \\ 无法访问。您可能没有权限使用网络资源。请与这台服务器的管理员联系以 查明您是否有访问权限。 拒绝访问。 -------------------------------------------------------------------------- 这导致从其它smbclient、XP、2003访问这台Win7的共享时，必须提前知道共享名， 因为看不到共享目录列表。但从其它Win7可以成功"start \\\"，看到共享目录 列表。 A: scz@nsfocus 2012-05-16 21:25 有几个矬人用Wireshark抓了包，发现从Win7访问Win7时，使用的是SMBv2，从 smbclient、XP、2003访问Win7时，使用的是SMBv1，然后他们判断是这个区别导致后 一种情况下看不到共享目录列表。 后来我在2003上针对一台32-bits Win7以及前述64-bits Win7进行对比测试，发现从 2003可以获取32-bits Win7的共享目录列表，确实不能获取64-bits Win7的共享目录 列表。 用Wireshark抓包，发现"start \\\"失败时，相应的SMBv1报文指出无权访问 \pipe\wkssvc、\pipe\srvsvc。同样的user、pass，用SMBv2时可以访问 \pipe\wkssvc、\pipe\srvsvc。难道真地如那几个矬人所推测的，是SMBv1、SMBv2导 致的差异？ 这个现象引起了我极大的好奇。进行了一些排查: -------------------------------------------------------------------------- 确认目标Win7做过防火墙配置，只允许445/TCP进入，因此不考虑139/TCP相关的问题。 目标Win7上在组策略里做了一些设置: 网络访问: 限制对命名管道和共享的匿名访问 已启用 网络访问: 可匿名访问的命名管道 (空) 网络访问: 可匿名访问的共享 没有定义 网络访问: 将Everyone权限应用于匿名用户 已禁用 网络访问: 不允许存储网络身份验证的密码与凭据 已启用 网络访问: 不允许SAM帐户和共享的匿名枚举 已启用 网络访问: 不允许SAM帐户的匿名枚举 已启用 网络访问: 本地帐户的共享和安全模型 经典 - 对本地用户进行身份验证，不改变其本来身份 网络安全: 在下一次更改密码时不存储LAN管理器哈希值 已启用 网络安全: LAN管理器身份验证级别 仅发送NTLMv2响应 从网络访问此计算机: Administrators Backup Operators Everyone Users 允许本地登录: Administrators C$、ADMIN$等缺省共享、管理共享已被禁用。 已从Administrators中删除了Domain Admins，已从Users中删除了Domain Users。 -------------------------------------------------------------------------- 进一步的测试表明，无论是用local\Administrator，还是用domain\user，无论是从 什么OS访问64-bits Win7，"net use \\\ipc$"都是没有问题的， "start \\\"也没有问题。当目标是32-bits Win7时，无论源OS是什么， 都可以成功执行"start \\\"。这排除了很多低级错误的可能性。 惟一有问题的，就是从非Win7用SMBv1访问64-bits Win7，执行"start \\\"的时 候。 针对目标Win7上的安全加固，我进行了各种组合式的实验，均无法解决原始问题。尤 其当我从2003上用local\Administrator建立到64-bits Win7的SMB会话，仍无权访问 wkssvc、srvsvc时，我真是不能理解。 NT Create AndX Request, Path: \wkssvc NT Create AndX Response, FID: 0x0000, Error: STATUS_ACCESS_DENIED NT Create AndX Request, Path: \srvsvc NT Create AndX Response, FID: 0x0000, Error: STATUS_ACCESS_DENIED 找来sysinternals的accesschk.exe对64-bits Win7上这两个命名管道进行检查: -------------------------------------------------------------------------- > accesschk.exe -q \pipe\wkssvc \\.\Pipe\wkssvc RW NT AUTHORITY\ANONYMOUS LOGON RW Everyone RW NT AUTHORITY\SYSTEM RW NT AUTHORITY\NETWORK SERVICE > accesschk.exe -q \pipe\srvsvc \\.\Pipe\srvsvc RW NT AUTHORITY\ANONYMOUS LOGON RW Everyone RW NT AUTHORITY\SYSTEM -------------------------------------------------------------------------- 这个结果与32-bits Win7上的输出完全一样，应该不是这里出问题。此后，我一度怀 疑是64-bits Win7的BUG或者说是安全增强所致。 但最后还是让我找到了原因，参看《去除缺省共享》。 -------------------------------------------------------------------------- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters PipeFirewallActive REG_DWORD 0 缺省不存在，需要新建 1 启用命名管道过滤机制，动态生效、无需 重启 AllowedPipes REG_MULTI_SZ 被允许通过SMB会话远程访问的命名管道 列表，动态生效、无需重启 -------------------------------------------------------------------------- 命名管道过滤机制适用于所有SMB会话，无论是空会话还是经过认证的会话。启用命 名管道过滤机制之后将允许列表清空，就相当于删除了IPC$，此时无法通过SMB会话 远程访问任何命名管道。 很不幸的是，目标Win7的PipeFirewallActive为1，AllowedPipes为空。于是管理员 级的SMBv1会话都无法访问wkssvc、srvsvc。同时，说明这个安全设置对SMBv2无效！ 当我给AllowedPipes增加了wkssvc、srvsvc之后，从2003已经可以成功获取共享目录 列表。 我解决过太多变态的SMB相关的问题，这是几次最让我无语的自作孽之一。 最后的最后，原始问题几乎是自虐型选手才有微乎其微的可能性碰上。迷底揭穿的时 候毫无意义，真正有意义的是中间的各种排查、对比测试、Wireshark抓包。这也是 我一直强调的，不要盲目乱Google，搜也白搜，变态问题就得变态的自己去解决。