23
明文的遠端終端機連接埠。交換器、IP 攝影機和開發板到現在還是把它當出廠管理介面——也是不小心開出去、幾分鐘內就被掃描器找上的那一個。
照你的系統挑一行貼上去執行。它會直接印出占著這個連接埠的行程，以及它綁在哪個位址上——通常看到這兩件事答案就出來了。
sudo lsof -nP -iTCP:23 -sTCP:LISTEN每一個監聽中的 socket 一行。欄位依序是 COMMAND、PID、USER，然後是 NAME，裡面放的是綁定位址——`127.0.0.1:23` 代表只有這台機器連得到，遠端用戶端永遠不會通；`*:23` 則是每一張介面。`-n` 跳過主機名稱查詢，`-P` 跳過連接埠名稱查詢，所以你看到的是數字而不是 `telnet`。`-sTCP:LISTEN` 是把已建立的用戶端連線濾掉的那個開關；拿掉它就能一併看到現在誰連著。完全沒有輸出、lsof 以 1 結束，代表沒有任何東西占著它。不加 `sudo` 只看得到自己的行程，所以 root 擁有的 daemon 會像隱形一樣。
sudo ss -tlnp 'sport = :23'`-t` 只看 TCP，`-l` 只看監聽中的 socket，`-n` 讓連接埠維持數字，`-p` 補上所屬行程。要讀的是 Local Address:Port 那一欄：`0.0.0.0:23` 是每一張 IPv4 介面，`127.0.0.1:23` 只有回送位址，`[::]:23` 是 IPv6 萬用位址，在多數 Linux 主機上連 IPv4 也一起收。連接埠是被 socket activation 叫起來的時候，行程會顯示成 `users:(("systemd",pid=1,fd=42))`，這對 telnet 來說很正常，不代表有什麼不對。不加 `sudo` 的話，不屬於你的那些這一欄會是空的。
sudo netstat -tlnp | grep ':23 '沒有 iproute2 的機器就用這個 net-tools 的老寫法，旗標意思一樣，最後一欄是 PID/Program name 這一組——它自己的 man page 就警告這個值「不可信」，而且要看不屬於你的 socket 得有超級使用者權限。grep 樣式最後那個空格不要刪：少了它，`:23` 連 `:2323` 和 `:23000` 都會一起命中。
netstat -ano | findstr :23`-a` 會連監聽中的連接埠一起顯示，不只現行連線，`-n` 讓位址和連接埠維持數字，`-o` 在最後一欄補上所屬 PID。用 `tasklist /FI "PID eq 1234"` 把那個 PID 換成名字。比對要小心：`findstr` 比的是子字串，所以 `:23` 也會命中 `:2323`，還有任何含 23 的臨時來源埠——動手砍之前，先確認 Local Address 那一欄真的以 `:23` 結尾。
`nmap -Pn -p 23 192.0.2.10` 從主機外面問了唯一重要的那個問題，而 `-Pn` 讓 nmap 不會因為對方不回 ping 就跳過它。`open` 代表有東西完成了 TCP 交握——如果這台裝置不是你刻意開出去的，就當成資安事件處理。`closed` 代表主機回了一個 reset，所以它連得到但沒有人在聽。`filtered` 代表什麼都沒回來：防火牆或 ACL 把封包丟掉而不是拒絕。加 `--reason` 可以看出實際是三者中的哪一種，加 `-sV` 則會讓 nmap 讀 telnet banner，那通常會直接報出裝置廠商。只掃你自己負責的主機。
| 你看到的訊息 | 代表什麼 |
|---|---|
telnet: connect to address 192.0.2.10: Connection refused | 封包送到了那台主機，而它的核心回了一個 reset，因為沒有任何行程占著連接埠 23。可能是 daemon 停了、從來沒裝過，或是綁在一個不包含你撥過去那個位址的地方。上面那行探測指令要在目標機器上跑，不是在你的筆電上。 |
telnet: connect to address 192.0.2.10: Operation timed out | 完全沒有回應。有個封包過濾器正在安靜地丟掉你的 SYN——主機上的防火牆、網路 ACL，或者你根本不在那個 VLAN 裡。被拒絕會立刻回來，被丟掉要等好幾十秒。這段延遲本身就是診斷結果。 |
Connected to 192.0.2.10. ... Connection closed by foreign host. | 連接埠是開的，交握也成功了，然後伺服器把你掛斷。通常是 TCP wrappers 或某條存取清單規則先收下連線、再拒絕你的來源位址；也可能是那台裝置一次只允許一個 session 而現在已經有人在用；或者 daemon 一啟動就掛了。這不是網路問題：一路到應用層之前全都是通的。 |
telnetd: bind: Address already in use | 已經有東西占著你指定的那個位址上的連接埠 23 了。跑一下你系統對應的探測指令，看輸出裡的綁定位址，確認這個衝突是不是真的：綁在 `0.0.0.0:23` 的行程會擋掉第二個對 `192.0.2.10:23` 的綁定，但兩個行程各自綁在不同的特定位址上則可以相安無事。 |
bind: Permission denied when starting a listener on 23 as a normal user | 在類 Unix 系統上，1024 以下是特權連接埠，核心會在檢查其他任何事之前就用 EACCES 拒絕這次綁定。請用 init 系統以 root 身分啟動服務，或在 Linux 上給那支執行檔 `CAP_NET_BIND_SERVICE`，再不然就聽高位連接埠再轉導過去。連接埠是空的，只是你沒有資格拿它。 |
IANA 依 RFC 854 把 23 指派給 `telnet`，TCP 和 UDP 都有登記，但實際上只有 TCP 那一半在用。Telnet 是一個字元串流的終端機協定，沒有加密，也沒有任何完整性檢查：登入帳號、密碼，以及之後每一次按鍵，全都以看得懂的位元組在網路上跑。二十年來已經沒有人拿它在通用機器上當正經的登入服務，但它在網路交換器、IP 攝影機、DVR、機上盒、序列埠主控台伺服器、工業設備和玩家用開發板上還活得好好的，是出廠預設的管理介面——這就是它一直出現在沒人打算對外開放的網路上的原因。工程師查這個連接埠還有第二個完全不同的理由：拿 `telnet host 25` 當成一根戳 TCP 的棒子，看看對方有沒有回應。那個用法是用戶端而不是監聽者，完全沒有上面講的風險——`nc -vz host 25` 做的是同一件事，而且現在多數系統內建的是它，因為 macOS 和好幾個 Linux 發行版已經不預裝 telnet 用戶端了。動手找行程之前先知道一件事：telnetd 傳統上是有連線才被叫起來，而不是一直跑著，所以在用 socket activation 的 systemd 主機上，或是還在跑 inetd／xinetd 的老機器上，占著連接埠 23 的那個行程會顯示成 `systemd` 或 `inetd`——真正的 telnetd 要等連線進來才存在。
不要把連接埠 23 對外開，最好連辦公室網路也不要開。用戶端和伺服器之間路徑上的任何東西——一台交換器、一台被入侵的路由器、同一個 Wi-Fi 下的另一台機器——都能直接讀到明文密碼，而且沒有伺服器憑證，所以你連中間有人在聽都察覺不到。公開的 telnet 監聽者會被全網掃描器持續找到，並立刻拿廠商預設帳密清單一個個試；消費性裝置被組成大型殭屍網路，歷來就是這樣來的，而嵌入式裝置上跑的通常又是一個老舊、沒更新過的 daemon。正確的替代品是連接埠 22 的 SSH，你拿到的是同一個 shell，但多了主機金鑰驗證和加密。當裝置真的只會講 telnet，就把它留在管理用 VLAN 裡，只能透過 SSH 跳板機或 VPN 才碰得到，出廠密碼在它接上任何網路之前就改掉，而且要確認你的路由器實際轉發了哪些連接埠——UPnP 有一長串沒人要求就自己把連接埠公開出去的前科。「它在 NAT 後面」不是一道你驗證得了的防線，一條 port forwarding 規則或一個 UPnP 對應就能悄悄把它拆掉。
這些全都在你的瀏覽器裡跑，不會上傳任何東西。
查 23 的時候，通常也會順手看一下這幾個。
幾乎都是權限問題。lsof 和 ss 會列出 socket，但別人的行程它不會顯示所有者，所以由系統帳號、容器執行環境或 launchd 啟動的服務，在你補上 sudo 之前就只是一個沒有主人的監聽項。Windows 則是反過來：netstat 什麼都沒有，綁定卻還是失敗，那代表這個號碼落在 Hyper-V、WSL2 或 Docker Desktop 開機時預留的範圍裡。
先看清楚它是什麼。沒收乾淨的開發伺服器砍掉沒事；正在寫入的資料庫不行，其他東西依賴的系統服務也不行。如果持有者是容器，請停容器，不要砍主機看到的那個行程——砍了執行環境只會把它拉起來。遇到真的不能動的，把自己的服務換一個連接埠反而更快。
因為它綁在 127.0.0.1 而不是 0.0.0.0。每一頁的指令之所以會把綁定位址跟行程名一起印出來，就是為了這件事：綁在回送位址上的服務，不管防火牆怎麼設，都只有這台機器自己連得到。現在不少框架是刻意這樣預設的，所以通常是一個參數的問題，不是 bug。如果已經是 0.0.0.0 還是不通，下一個要懷疑的就是主機防火牆或雲端的安全群組。
幾乎沒有幫助。掃全網的機器持續在掃整段範圍，換號碼買到的是幾個小時，不是安全，代價卻是每個同事都得記住它。它確實能讓針對預設埠的無差別掃描少污染一點日誌，這算是實際但有限的好處。真正會改變結果的是認證、限制來源位址的防火牆，以及一開始就不要讓它對外。
連接埠 23 還是卡住嗎？看完整的連接埠對照表，或是回到上面，從你實際看到的那行錯誤往回追。