有關網上鄰居的問題，問的人一直比較多，在理解上存在的誤區也普遍較為嚴重。鑒于Microsoft的NETBIOS文檔不是很細致，我四處收集了一些相關資料加上自己的實踐經驗寫了這個系列，希望能對大家有所幫助．

　　本來想為了增加可讀性，把這個系列寫成問答的形式，不過一時之間腦袋里也編不出這么多的問題，還是按部就班先感性的對微軟的瀏覽服務作一大致介紹，然后再深入剖析NETBIOS的具體工作機理,大家要是有什么問題,可以提出來我們一起討論.

　　在“Windows NT系統管理技術內幕”一書中，講到了一個非常具有代表性的問題，我把它摘抄了下來：

　　問：什么情況下會導致在網絡鄰居中計算機能看見卻無法訪問或可以訪問卻看不見？

　　請選擇最佳答案：
　　A.你的網絡存在物理問題,比如網線
　　B.作為域主瀏覽器的Windows NTserver的瀏覽服務壞了
　　C.Windows NTserver網卡有問題
　　D.你的網絡沒有問題,用戶描述的是正常的微軟瀏覽現象

　　正確答案：D

　　書上的解釋:微軟的網絡瀏覽可能在使用中出現"中斷",而實際上它們并沒有中斷, 這種誤解是由于用戶對微軟網絡瀏覽的處理過程不熟悉造成的。

　　就象有人經常在抱怨的“為什么別人的網上鄰居可用，我的卻不行？”“為什么有時候可以瀏覽，有時候卻無法瀏覽網絡？”解鈴還須系鈴人，讓我們一起去看看微軟的網絡瀏覽到底是如何實現的。鑒于大家可能對NT的“域”概念還不甚了解，出現瀏覽故障的也多為98的機子，我將以98的“工作組模式”為大家講解。

　　1.什么是瀏覽列表（Browsing List）

　　在微軟網絡中，用戶可以在瀏覽列表里看到整個網絡（何指？子網還是廣播域？大家可以考慮考慮）上所有的計算機。當你通過網上鄰居窗口打開整個網絡時，你將看到一個工作組列表，再打開某個工作組，你將看到里面的計算機列表（也可在 Dos方式下用net vIEw /domain:workgroupname命令得到），這就是我們所說的 Browsing List。工作組從本質上說就是共享一個瀏覽列表的一組計算機，所有的工作組之間都是對等的，沒有規定不可以讓所有的計算機同處于一個工作組中。

　　2.瀏覽列表在哪里

　　曾在木棉上看到過一場爭論，有人說：網上鄰居里的計算機列表是廣播查詢得來的。可有人舉反例說：我的同學都關機了，可我還是能在網上鄰居里看到它，應該是從HUB或交換機之類較為固定的設備的緩存中取得的。 其實他們都只說對了一個方面，把他們二人的說法結合起來就是正確答案了--- 瀏覽列表是通過廣播查詢瀏覽主控服務器，由瀏覽主控服務器提供的。

　　3.瀏覽主控服務器又是什么

　　瀏覽主控服務器是工作組中的一臺最為重要的計算機，它負責維護本工作組中的瀏覽列表及指定其他工作組的主控服務器列表，為本工作組的其他計算機和其他來訪本工作組的計算機提供瀏覽服務，每個工作組都為會每個傳輸協議選擇一個瀏覽主控服務器，而我們經常遇到的無法瀏覽網絡的錯誤大多是因為你所處的工作組沒有瀏覽主控服務器而造成的。你可以在一個工作組中用NBTSTAT -a computername 命令找出使用NBT協議的瀏覽主控服務器，它的標識是含有//_MSBROWSE_名字段。

　　4.瀏覽主控服務器是如何指定的

　　缺省情況下，win98工作組中的瀏覽主控服務器是該工作組中第一臺啟用文件及打印機共享功能的計算機，也允許手工將一臺win計算機配置為瀏覽主控服務器（方法會在后面講述網絡配置時具體介紹，但由于瀏覽主控服務器需要維護動態瀏覽列表，性能會受影響），如果一個工作組中有多臺計算機配置了這個選項，或是當前的瀏覽主控服務器關閉了系統，又沒有其他計算機啟用主控設置時，就要進行主控瀏覽器的選舉。

　　5.如何通過瀏覽器選舉產生瀏覽主控服務器

　　關于瀏覽器的選舉報文,不太好抓包,我就只好按書上的東西來講述了.其實過程很簡單,首先由一臺計算機發送一個選舉臨界報文,該報文包含了來自發送計算機的信息(操作系統,版本及NET名等),選舉報文向網絡中廣播,工作組中的每一臺計算機都會用自身信息與選舉報文進行優先級比較,主要是操作系統起主要作用,記得好像是NT Server>NT Workstation>Win98>WFWG,反正到最后是那個自身條件最好的成為新的瀏覽主控服務器.

　　6.整個網絡瀏覽的過程是怎樣的

　　當一臺win98進入網絡時，如果它帶有服務器服務（啟用了文件及打印機共享）會向網絡廣播宣告自己的存在，而瀏覽主控服務器會取得這個宣告并將它放入自己維護的瀏覽列表中；而沒有在相應協議上綁定文件及打印機共享的計算機則不會宣告，因而也就不會出現在網絡鄰居里了。 //本文來自武林網m.survivalescaperooms.com轉載請注明

　　當客戶計算機想獲得需要的網絡資源列表時，首先會廣播發出瀏覽請求，瀏覽主控服務器收到請求后，如果請求的是本組的瀏覽列表，則直接將客戶所需的資源列表發回；如果請求的是其它工作組的瀏覽列表，瀏覽主控服務器會根據本身Browsing List中的記錄找到相應工作組的主控瀏覽器返回給用戶，用戶可從那里得到它想要的瀏覽列表。至于如何去和另一臺計算機共享交換資源，就不是我們這里要討論的問題了。

　　明白了網絡瀏覽的原理，下面我給大家講一個有用的應用，現在很多同學出于安全的考慮都不太歡迎陌生人通過網上鄰居訪問自己的機子，可有時下部電影又需要給認識的同學共享出來，因而還不能刪除文件及打印機共享服務。怎么辦？有些人給共享名加個$，以達到隱藏的效果，可這用Dos下的net share是可被看到的；有些人給共享加上密碼，可聽說這也是有辦法破解的，而且很容易激起“黑客同志”的好奇心。有沒有辦法將自己的機器在網絡鄰居里隱藏起來呢？而對于認識的同學可以讓他用//IP 來訪問。

　　想對了，關鍵就是要阻止自己的機器向網絡中去宣告自己，而且我知道我們其中的一些人已經將此變成了現實，至于方法嘛，就不要來問我了。

　　注：因為有關win98瀏覽服務的資料很少，涉及的書籍也多為以NT的“域”模型進行介紹，因而我只能根據自己的理解結合netxray的實踐來測試，細節部分難免有錯，歡迎大家指正。

　　7.在我的網上鄰居里為什么有些機子訪問不了

　　如果微軟的網上鄰居真能做到所見即所得，相信抱怨它的人不會象現在這么多，可通過前面對瀏覽服務的介紹，大家已經知道這是不可能的，因為瀏覽列表的獲得不是通過訪問其中每一臺機子得到的，很多時候網絡中的計算機并不能正確更新瀏覽列表。當一臺計算機正常關機時，它會向網絡發出廣播宣告，使瀏覽主控服務器及時將它從瀏覽列表中刪除；而非正常關機后，瀏覽列表里仍會把該條目保持很長一段時間(NT下是45分鐘),這就是我們仍能在網絡鄰居里看到它的原因.而98的穩定性是眾所周知的 ----在還沒來得及關機前就已經崩潰了^-^

　　SMB（Server Message Block）協議在NT/2000中用來作文件共享，在NT中，SMB運行于NBT（NetBIOS over TCP/IP）上，使用137，139（UDP），139（TCP）端口。

　　在2000中，SMB可以直接運行在tcp/ip上，而沒有額外的NBT層，使用TCP 445端口。因此在2000上應該比NT稍微變化多一些。可以在“網絡連接/屬性/TCPIP協議/屬性/高級/WINS中設置啟用或者禁用NBT（NetBIOS over TCP/IP）。//本文來自武林網m.survivalescaperooms.com轉載請注明

　　當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會話幾乎成為了微軟自己安置的后門，但是微軟為什么要來設置這樣一個“后門”呢？我也一直在想這個問題，如果NULL會話沒有什么重要的用途，那么微軟也應該不會來設置這樣一個東西。好不容易才在微軟上找到這個：

　　當在多域環境中，要在多域中建立信任關系，首先需要找到域中的PDC來通過安全通道的密碼驗證,使用空會話能夠非常容易地找到PDC，還有就是關于一些系統服務的問題。

　　其實建立一個空會話的條件也非常嚴格。首先要能夠滿足上面的，也就是打開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就是典型代表。

　　2. 有些人給共享加上密碼，可聽說這也是有辦法破解的；

　　這個破解要看是什么層面上的，純暴力破解的就不必說了，那當然總是可以的。而95/98另有漏洞，袁哥發現的，就是他那個著名的vredir.vxd，服務端驗證密碼時所用長度居然是客戶端提供的，這就意味著至多猜測256次(事實上沒這么多，考慮可打印字符范圍)即可進入。當初N多人用這種辦法非法瀏覽別人的機器。2000年報告微軟，現在已修補。

　　順便說一句，利用該漏洞可以快速窮舉出原始口令，雖然在攻擊中這是不必要的。因而我只能根據自己的理解結合netxray的實踐來測試，細節部分難免有錯。

　　3. 在2000中，SMB可以直接運行在tcp/ip上，而沒有額外的NBT層，使用TCP 445端口。因此在2000上應該比NT稍微變化多一些。

　　事實上正相反，在ssaxh_capabilitIEs字段中指明不使用"擴展安全驗證"，此時使用原有身份驗證機制，只需去掉NBT層的Session Request，將139/TCP改成445/TCP，一樣可以成功建立空會話，并且成功打開"http://<target 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的方法之一。

　　微軟在<<Direct Hosting of SMB Over TCP/IP>>中不會提這些的，只是說139/TCP、445/TCP公平競爭，優先使用最早返回的響應報文。不要相信它的鬼話。

　　話說回來，如非需求所致，完全不必關心這種差別。有需求的時候，這種差別是致命的。

　　5. 最明顯的就是空會話可以很方便地連接到其他的域,枚舉用戶、機器等。這也就是掃描軟件進行探測的原理。

　　XP、2003缺省禁止在空會話上進行PolicyAccountDomainInformation查詢，可以看到LsarOpenPolicy2(44)失敗，權限否定。如果事先指定有效帳號、口令建立SMB會話，而非空會話，LsarOpenPolicy2(44)將成功返回。