端口
当2000使用网络共享的时候，就面临着选择139或者445端口了。下面的情况确定会话使用的端口：
1、如果客户端启用了NBT，那么连接的时候将同时访问139和445端口，如果从445端口得到回应，那么客户端将发送RST到139端口，终止这个端口的连接，接着就从445端口进行SMB的会话了；如果没有从445端口而是从139得到回应，那么就从139端口进行会话；如果没有得到任何回应，那么SMB会话失败。
2、如果客户端禁用了NBT，他就将只从445端口进行连接。当然如果服务器（开共享端）没有445端口进行SMB会话的话，那么就会访问失败了，所以禁用445端口后，对访问NT机器的共享会失败。
3、如果服务器端启用NBT，那么就同时监听UDP 137、138端口和TCP139，445。如果禁用NBT，那么就只监听445端口了。
所以对于2000来说，共享问题就不仅仅是139端口，445端口同样能够完成。
关于空会话
NULL会话（空会话）使用端口也同样遵循上面的规则。NULL会话是同服务器建立的无信任支持的会话。一个会话包含用户的认证信息，而NULL会话是没有用户的认证信息，也就好比是一个匿名的一样。
没有认证就不可能为系统建立安全通道，而建立安全通道也是双重的，第一，就是建立身份标志，第二就是建立一个临时会话密匙，双方才能用这个会话进行加密数据交换（比如RPC和COM的认证等级是PKT_PRIVACY）。不管是经过NTLM还是经过Kerberos认证的票据，终究是为会话创建一个包含用户信息的令牌。（这段来自Joe Finamore）
根据WIN2000的访问控制模型，对于空会话同样需要提供一个令牌。但是空会话由于是没有经过认证的会话，所以令牌中不包含用户信息，因此，建立会话双方没有密匙的交换，这也不能让系统间发送加密信息。这并不表示空会话的令牌中不包含SID，对于一个空会话，LSA提供的令牌的SID是S-1-5-7，这就是空会话建立的SID，用户名是ANONYMOUS LOGON。这个用户名是可以在用户列表中看到的。但是是不能在SAM数据库中找到，属于系统内置的帐号。
（关于这部分对NULL SESSION的分析，可以参照：《NULL Sessions In NT/2000》http://rr.sans.org/win/null.php）
NULL会话几乎成为了微软自己安置的后门，但是微软为什么要来设置这样一个“后门”呢？我也一直在想这个问题，如果NULL会话没有什么重要的用途，那么微软也应该不会来设置这样一个东西。好不容易才在微软上找到这个：
当在多域环境中，要在多域中建立信任关系，首先需要找到域中的PDC来通过安全通道的密码验证,使用空会话能够非常容易地找到PDC，还有就是关于一些系统服务的问题。而且LMHOSTS的＃i nclude就需要空会话的支持，可以参考文章：
http://support.microsoft.com/default.aspx?...b;EN-US;q121281
还有
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q124184
其实建立一个空会话的条件也非常严格。首先要能够满足上面的，也就是打开TCP 139和TCP 445端口。我们可以从一次关闭这两个端口的情况中看得出来。服务器关闭445和139端口，然后我们来进行空会话的连接。首先，客户端打算连接的是445端口，然后再试图连接139端口。当然最后还是失败了。
仅仅开放这两个端口还不行，服务器还必须得打开IPC$共享。如果没有IPC共享，即使共享一个文件，有权限为Anonymous Logon，也不能建立会话，即使权限设置为完全控制，出现的连接错误依然是权限不够。这和其他帐号是不一样的。如果要允许一个文件夹共享能够类似IPC$（命名管道而非共享）能够使用空会话，那么需要修改注册表：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver
\parameters\
中的：NullSessionShares，添加新的共享名，这样才能建立一个共享的空会话。这时，将不依赖IPC的存在了。（即使这样的空会话对于后面的突破也是一点没可取之处的，因为没有了IPC$命名管道，RPC不可取了，这下知道IPC这个命名管道的具体实现了。呵呵）
虽然空会话建立的要求很严格，但是那都是默认建立的。既然是默认的，对于使用WIN2K系统的服务器来说，就还是有利用的价值。最明显的就是空会话可以很方便地连接到其他的域,枚举用户、机器等。这也就是扫描软件进行探测的原理。
1. 有些人给共享名加个$，以达到隐藏的效果，可这用DOS下的net share是可被看到的；
这种隐藏只是微软Windows标准客户端net view的限制，不是服务端的限制，网络传输过程中是一视同仁的，所以直接修改客户端解除这种限制或者使用第三方客户端软件均可看到所谓的隐藏共享，比如smbclient就是典型代表。而直接修改windows客户端的办法，99年袁哥贴过，我在华中Security版上转载过，精华区中还在。
2. 有些人给共享加上密码，可听说这也是有办法破解的；
这个破解要看是什么层面上的，纯暴力破解的就不必说了，那当然总是可以的。而95/98另有漏洞，袁哥发现的，就是他那个著名的vredir.vxd，服务端验证密码时所用长度居然是客户端提供的，这就意味着至多猜测256次(事实上没这么多，考虑可打印字符范围)即可进入。当初N多人用这种办法非法浏览别人的机器。2000年报告微软，现在已修补。
http://security.nsfocus.net/index.php?act=...o=view&adv_id=6
顺便说一句，利用该漏洞可以快速穷举出原始口令，虽然在攻击中这是不必要的。因而我只能根据自己的理解结合netxray的实践来测试，细节部分难免有错，
推荐www.ethereal.com提供的Ethereal，这是我所见过的对SMB解码最强的免费软件，有Unix/Windows版，提供源码。
3. 在2000中，SMB可以直接运行在tcp/ip上，而没有额外的NBT层，使用TCP 445端口。因此在2000上应该比NT稍微变化多一些。
事实上正相反，在ssaxh_capabilities字段中指明不使用"扩展安全验证"，此时使用原有身份验证机制，只需去掉NBT层的Session Request，将139/TCP改成445/TCP，一样可以成功建立空会话，并且成功打开"ip>\IPC$"。
至于更高层的RPC Over SMB，更是不必作任何变动。换句话说，从139/TCP换到445/TCP，整个通信过程中减少了一对NBT Session Request/Response，后面的报文对于两者来说是完全一致的。
而所谓的NBT层，即使在445通信中也未去掉，一直存在着，区别只是上面这段话。
4. 如果客户端启用了NBT，那么连接的时候将同时访问139和445端口，
微软并没有让139/TCP与445/TCP公平竞争。发起连接的SYN包在宏观上是同时发出的，具体起来，有时是先向139/TCP发起连接请求，有时是先向445/TCP发起连接请求，有点随机性。
在向139/TCP发送三次握手的最后一个ACK报文时，Windows顺手携带了数据，这里以一个刻意弄错的NetBIOS名(*SMBSERV<00...(8)>)做了一次NBT Session Request。而445/TCP不需要NBT层的会话。
由于刻意弄错的NetBIOS名，139/TCP很难竞争过445/TCP。服务端返回Negative NBT Session Response，并且执行了close()操作。这使得必须重新建立到139/TCP的连接(传输层的TCP连接)。
可以看出，那个刻意弄错的NetBIOS名仅仅是为了给445/TCP制造抢先的机会。遗憾的是，445/TCP不争气，这个端口上的任务繁重、负载较高，即使在这种不公平竞争的情况下，139/TCP仍有可能重新抢在445/TCP之前建立NBT会话(注意，不是TCP连接)。于是445口会回送RST，后续SMB会话建立在139/TCP连接之上。
微软自己的操作系统不认"*SMBSERV<00...(8)>"，但是Samba Server 2.2.5认，居然返回Positive Session Response。这成为精确识别Samba Server的方法之一。
微软在<
话说回来，如非需求所致，完全不必关心这种差别。有需求的时候，这种差别是致命的。
5. 最明显的就是空会话可以很方便地连接到其他的域,枚举用户、机器等。这也就是扫描软件进行探测的原理。
XP、2003缺省禁止在空会话上进行PolicyAccountDomainInformation查询，可以看到LsarOpenPolicy2(44)失败，权限否定。如果事先指定有效帐号、口令建立SMB会话，而非空会话，LsarOpenPolicy2(44)将成功返回。
网友评论