那麼，Port 113 是做什麼用的呢？
（文章內容來源：http://www.grc.com/port_113.htm）
目的：驗證服務 / 辨識通訊協定
敘述：本地端電腦中運行了驗證/辨識伺服器，會開啟 Port 113 並聆聽監視，等待遠端伺服器連接 Port 113 並且詢問。遠端伺服器在詢問過程中將會提供一些「由本地端電腦與遠端伺服器建立的連線的雙方埠號配對（port number pair）」的資訊，而本地端的驗證/辨識伺服器將會回傳建立連線時使用的「使用者名稱（ID）」以及可能附加一些如地址，電話，電子郵件地址等資訊。
在 1984 年，於一份兩張半的RFC（Reqeuset for Comments）的 RFC912中所提出的，名為「驗證通訊協定」（Authentication Protocol），然後在四個月後，由 RFC931 取代之；八年後，重新定調於 RFC1413 並改名為「辨識通訊協定」（Identification Protocol）。
「辨識通訊協定」的目的是「讓遠端伺服器可以自動確認連上伺服器的使用者身分」，作法是當使用者連上遠端伺服器提供的公開服務時，遠端伺服器會主動連回使用者的電腦，並且確認使用者的確來自於這台電腦。
「辨識通訊協定」原本想提供的是，當使用者連到遠端伺服器時，遠端伺服器可以自行驗證，這麼一來使用者就不用手動輸入帳號與密碼來驗證自己的身分，就可以達到「自動登入」的效果。例如自動登入 Telnet 伺服器，或是 FTP 伺服器。不過這個想法實在是單純到有點蠢。因為整個架構並沒有真正安全性可言的技術成分，所以沒什麼人會認真的研究如何應用這個通訊協定，或是相信它。因為這個通訊協定從來就無法提供有效的「驗證（authentication）」任何事情，所以最後被改名為「辨識通訊協定」。
完全隱蔽 Port 113 所帶來的問題
儘管「辨識通訊協定」沒什麼用處，但是還是有一些很老的 UNIX 伺服器 — 像是 IRC 伺服器，或是一些郵件伺服器，他們的服務還是內建了「辨識通訊協定」。如果哪天有個使用者要連上這些伺服器來存取服務，那麼遠端伺服器就會連回使用者的電腦，試圖透過「辨識通訊協定」接上本地端的 Port 113 來辨識使用者。
如果使用者本身並沒有透過 NAT 路由器，也沒有個人防火牆 — 而且本機並沒有運行「辨識伺服器」來聆聽監視 Port 113 的話，本機收到「嘗試連接 Port 113」的要求，會直接駁回（Reject）這個需求。如此一來，遠端伺服器就會知道本地端電腦並不支援「辨識通訊協定」，然後放棄進行「辨識」的動作，並且放行使用者連接需求。
但是，如果 Port 113 被 NAT 路由器或個人防火牆完全隱蔽的時候，NAT 路由器或個人防火牆會封鎖並丟棄「辨識通訊協定」的封包。但是對遠端伺服器而言，一直在等待著回應。實際上卻由於封包被丟棄，要求被忽略，所以不會有任何回應傳達給遠端伺服器。當遠端伺服器等待一段時間後，又注意到使用者的連接需求，於是遠端伺服器再次嘗試送出要求封包；同樣的，不會有任何回應。就這樣，使用者的連接需求就被遠端伺服器擱置了，而且對使用者而言，會經歷很長一段時間等待卻得不到任何遠端伺服器送過來的回應。
於是隱蔽 Port 113 就出現了一個問題：使用者連接上遠端伺服器，卻必須等待很長一段時間（45 秒或甚至更久）才有可能獲得遠端伺服器的回應（遠端伺服器放棄辨識使用者，而允許連線建立）。更甚者，某些服務程式的設計上，是「無法自使用者端電腦的 Port 113 獲得辨識資訊，就不允許連接」，遇到這種情況，使用者就無法建立連線，當然也無法使用服務了。
這真的是個問題嗎？
也許... 不是。對大多數人來說，隱蔽 Port 113 並不會為他們的生活帶來任何不便。如果哪天你隱蔽了你的 Port 113，但是卻在某些時候發生了連接延遲的現象，那麼你可以猜測，也許是遠端伺服器使用了「辨識通訊協定」的關係（但是現在很少伺服器會使用「辨識通訊協定」了）。
其實對於那些很注重安全的人而言，比較麻煩的是 Port 113 有時候並不好隱蔽。
在 NAT 路由器上隱蔽 Port 113
NAT 路由器製造商當然不希望會有「使用他們的路由器會造成連線問題」的傳聞在網路上流傳。但是對 NAT 路由器來說，棘手的是，「辨識通訊協定」的封包並不是由內部網路電腦主動對外連線後，正常程序下回來的連線建立封包：要記得，「辨識通訊協定」是由遠端伺服器主動連接到本地端電腦，要求建立連線的。由於 NAT 路由器內建的防火牆硬體會主動拒絕所有來自外部網路，未經邀請的連線需求，來隱蔽保護內部網路的電腦。
但是由於隱蔽 Port 113 「理論上」可能會引起連線問題（通常不常見），所以 NAT 路由器製造商就對於 Port 113 給予「特別待遇」：如果有任何來自外部網路，要連接到本地端 Port 113 的需求，就給予一個「已關閉（closed）」的回應，並且主動駁回連線。但是 NAT 路由器製造商還是對外宣稱，他們的產品可以做到「全隱蔽」的功能。
通常一些 NAT 路由器新手，可能會透過外在檢查機制來檢查他們的 NAT 隱蔽狀況，通常他們都會對於無法得到一個完美的綠燈（全隱蔽）而只得到一個藍燈（部分埠回應「已關閉」）而感到失望。
好消息是，有可能可以藉由設定，讓 NAT 路由器做到全隱蔽的效果。那就是：藉由 NAT 路由器內建的「埠導向」功能。作法就是：將 Port 113 的要求導向到一個屬於內部網路，但是沒有被使用的 IP。這麼一來，NAT 路由器就不會對遠端伺服器回應「closed」訊息，而且遠端伺服器也不會得到任何訊息（因為封包已經被丟到黑洞裡面去了！），如此一來，就可以變成全隱蔽的狀態。
Linksys 的 NAT 路由器，現在的軔體都有提供隱蔽 Port 113 的功能，如果有需要，就可以打開它。
在個人防火牆上隱蔽 Port 113
該文作者說，Zone Alarm 個人防火牆第一個吸引他的地方，就是它非常善於處理 Port 113 的要求（雖然說「免費」這一點也是吸引他的地方）。Zone Alarm 對於處理來自外部網路的「辨識通訊協定」要求的方法是：如果接到一個封包，使用「辨識通訊協定」，連接到 Port 113 時，ZA 個人防火牆會先檢查，本機電腦（記住，這是個人防火牆！）是否跟發送「辨識通訊協定」封包的遠端伺服器正在建立連線關係（說技術一點，就是連線初始化行為）；如果沒有，則 ZA 個人防火牆會將這個封包丟棄，繼續隱蔽本機電腦。如果有，則會讓封包通過，讓連線建立。當然，如果本機電腦沒有辨識伺服器的話，遠端伺服器會得到一個 closed 的狀態，然後遠端伺服器就知道本機並不支援「辨識通訊協定」，然後讓連線繼續建立。這意味著，ZA 個人防火牆是一套「會檢視封包狀態的個人防火牆」，而不是一個單純的「封包過濾器」而已。
杜歐貓的話：無法判斷作者該篇文章的寫作時間點。現在已經有許多個人防火牆都有這種功能了。
看完以上文章，應該對於 Port 113 有點概念了吧。由於巴哈姆特 BBS 強制走「辨識通訊協定」，所以使得直接丟棄「辨識通訊協定」封包的環境中，連線會等待一分三十秒。知道原因之後，自然也就可以採取一些對應動作來處理這個情況了。
（文章內容來源：http://www.grc.com/port_113.htm）
Port 113
名稱：驗證 / 辨識目的：驗證服務 / 辨識通訊協定
敘述：本地端電腦中運行了驗證/辨識伺服器，會開啟 Port 113 並聆聽監視，等待遠端伺服器連接 Port 113 並且詢問。遠端伺服器在詢問過程中將會提供一些「由本地端電腦與遠端伺服器建立的連線的雙方埠號配對（port number pair）」的資訊，而本地端的驗證/辨識伺服器將會回傳建立連線時使用的「使用者名稱（ID）」以及可能附加一些如地址，電話，電子郵件地址等資訊。
在 1984 年，於一份兩張半的RFC（Reqeuset for Comments）的 RFC912中所提出的，名為「驗證通訊協定」（Authentication Protocol），然後在四個月後，由 RFC931 取代之；八年後，重新定調於 RFC1413 並改名為「辨識通訊協定」（Identification Protocol）。
「辨識通訊協定」的目的是「讓遠端伺服器可以自動確認連上伺服器的使用者身分」，作法是當使用者連上遠端伺服器提供的公開服務時，遠端伺服器會主動連回使用者的電腦，並且確認使用者的確來自於這台電腦。
「辨識通訊協定」原本想提供的是，當使用者連到遠端伺服器時，遠端伺服器可以自行驗證，這麼一來使用者就不用手動輸入帳號與密碼來驗證自己的身分，就可以達到「自動登入」的效果。例如自動登入 Telnet 伺服器，或是 FTP 伺服器。不過這個想法實在是單純到有點蠢。因為整個架構並沒有真正安全性可言的技術成分，所以沒什麼人會認真的研究如何應用這個通訊協定，或是相信它。因為這個通訊協定從來就無法提供有效的「驗證（authentication）」任何事情，所以最後被改名為「辨識通訊協定」。
完全隱蔽 Port 113 所帶來的問題
儘管「辨識通訊協定」沒什麼用處，但是還是有一些很老的 UNIX 伺服器 — 像是 IRC 伺服器，或是一些郵件伺服器，他們的服務還是內建了「辨識通訊協定」。如果哪天有個使用者要連上這些伺服器來存取服務，那麼遠端伺服器就會連回使用者的電腦，試圖透過「辨識通訊協定」接上本地端的 Port 113 來辨識使用者。
如果使用者本身並沒有透過 NAT 路由器，也沒有個人防火牆 — 而且本機並沒有運行「辨識伺服器」來聆聽監視 Port 113 的話，本機收到「嘗試連接 Port 113」的要求，會直接駁回（Reject）這個需求。如此一來，遠端伺服器就會知道本地端電腦並不支援「辨識通訊協定」，然後放棄進行「辨識」的動作，並且放行使用者連接需求。
但是，如果 Port 113 被 NAT 路由器或個人防火牆完全隱蔽的時候，NAT 路由器或個人防火牆會封鎖並丟棄「辨識通訊協定」的封包。但是對遠端伺服器而言，一直在等待著回應。實際上卻由於封包被丟棄，要求被忽略，所以不會有任何回應傳達給遠端伺服器。當遠端伺服器等待一段時間後，又注意到使用者的連接需求，於是遠端伺服器再次嘗試送出要求封包；同樣的，不會有任何回應。就這樣，使用者的連接需求就被遠端伺服器擱置了，而且對使用者而言，會經歷很長一段時間等待卻得不到任何遠端伺服器送過來的回應。
於是隱蔽 Port 113 就出現了一個問題：使用者連接上遠端伺服器，卻必須等待很長一段時間（45 秒或甚至更久）才有可能獲得遠端伺服器的回應（遠端伺服器放棄辨識使用者，而允許連線建立）。更甚者，某些服務程式的設計上，是「無法自使用者端電腦的 Port 113 獲得辨識資訊，就不允許連接」，遇到這種情況，使用者就無法建立連線，當然也無法使用服務了。
這真的是個問題嗎？
也許... 不是。對大多數人來說，隱蔽 Port 113 並不會為他們的生活帶來任何不便。如果哪天你隱蔽了你的 Port 113，但是卻在某些時候發生了連接延遲的現象，那麼你可以猜測，也許是遠端伺服器使用了「辨識通訊協定」的關係（但是現在很少伺服器會使用「辨識通訊協定」了）。
其實對於那些很注重安全的人而言，比較麻煩的是 Port 113 有時候並不好隱蔽。
在 NAT 路由器上隱蔽 Port 113
NAT 路由器製造商當然不希望會有「使用他們的路由器會造成連線問題」的傳聞在網路上流傳。但是對 NAT 路由器來說，棘手的是，「辨識通訊協定」的封包並不是由內部網路電腦主動對外連線後，正常程序下回來的連線建立封包：要記得，「辨識通訊協定」是由遠端伺服器主動連接到本地端電腦，要求建立連線的。由於 NAT 路由器內建的防火牆硬體會主動拒絕所有來自外部網路，未經邀請的連線需求，來隱蔽保護內部網路的電腦。
但是由於隱蔽 Port 113 「理論上」可能會引起連線問題（通常不常見），所以 NAT 路由器製造商就對於 Port 113 給予「特別待遇」：如果有任何來自外部網路，要連接到本地端 Port 113 的需求，就給予一個「已關閉（closed）」的回應，並且主動駁回連線。但是 NAT 路由器製造商還是對外宣稱，他們的產品可以做到「全隱蔽」的功能。
通常一些 NAT 路由器新手，可能會透過外在檢查機制來檢查他們的 NAT 隱蔽狀況，通常他們都會對於無法得到一個完美的綠燈（全隱蔽）而只得到一個藍燈（部分埠回應「已關閉」）而感到失望。
好消息是，有可能可以藉由設定，讓 NAT 路由器做到全隱蔽的效果。那就是：藉由 NAT 路由器內建的「埠導向」功能。作法就是：將 Port 113 的要求導向到一個屬於內部網路，但是沒有被使用的 IP。這麼一來，NAT 路由器就不會對遠端伺服器回應「closed」訊息，而且遠端伺服器也不會得到任何訊息（因為封包已經被丟到黑洞裡面去了！），如此一來，就可以變成全隱蔽的狀態。
Linksys 的 NAT 路由器，現在的軔體都有提供隱蔽 Port 113 的功能，如果有需要，就可以打開它。
在個人防火牆上隱蔽 Port 113
該文作者說，Zone Alarm 個人防火牆第一個吸引他的地方，就是它非常善於處理 Port 113 的要求（雖然說「免費」這一點也是吸引他的地方）。Zone Alarm 對於處理來自外部網路的「辨識通訊協定」要求的方法是：如果接到一個封包，使用「辨識通訊協定」，連接到 Port 113 時，ZA 個人防火牆會先檢查，本機電腦（記住，這是個人防火牆！）是否跟發送「辨識通訊協定」封包的遠端伺服器正在建立連線關係（說技術一點，就是連線初始化行為）；如果沒有，則 ZA 個人防火牆會將這個封包丟棄，繼續隱蔽本機電腦。如果有，則會讓封包通過，讓連線建立。當然，如果本機電腦沒有辨識伺服器的話，遠端伺服器會得到一個 closed 的狀態，然後遠端伺服器就知道本機並不支援「辨識通訊協定」，然後讓連線繼續建立。這意味著，ZA 個人防火牆是一套「會檢視封包狀態的個人防火牆」，而不是一個單純的「封包過濾器」而已。
杜歐貓的話：無法判斷作者該篇文章的寫作時間點。現在已經有許多個人防火牆都有這種功能了。
看完以上文章，應該對於 Port 113 有點概念了吧。由於巴哈姆特 BBS 強制走「辨識通訊協定」，所以使得直接丟棄「辨識通訊協定」封包的環境中，連線會等待一分三十秒。知道原因之後，自然也就可以採取一些對應動作來處理這個情況了。
沒有留言:
張貼留言