將面板對外開放：會改變什麼，以及改變最少的途徑

伺服器放在家裡或辦公室，想從外面連進去。這個需求很合理，但答案不是該不該做，而是走哪條路。

一旦這麼做，會改變什麼

面板不再是只有自己網路上的人才能到達的地方。登入頁面對網際網路可見，而對網際網路可見的登入頁面，會被自動化程式反覆嘗試登入。這不是針對特定對象的攻擊，而是一種持續存在的背景雜訊，幾小時內就會找到新開放的位址。重點不在於有人鎖定目標，而在於遲早會自然輪到。

三條途徑

第一：不對外開放。先連入這個網路，再像在家裡一樣使用面板。面板從外部永遠看不到，因此也沒有可供嘗試的登入頁面。這是改變最少、保護最多的途徑。

第二：在前面加一道門。面板不先開口；先由一個確認來訪者身分的層級迎接訪客，之後才會到達面板。陌生人第一個接觸到的，仍然不是面板。

第三：直接對外開放。將連接埠轉送出去，一切都壓在登入頁面與憑證的肩上。這做得到，但此時的防線只剩單一層。

如果真的要對外開放，最低限度

第二道驗證因素不是偏好問題。日常工作不應以 root 進行，因為坐在一扇對外開啟的門後、擁有完整權限的帳號，會讓兩種風險相乘。憑證應該是正式有效的憑證，原因不在加密本身：如果每次登入都看到警告，就會習慣點過警告，等真正的警告出現那天，也會一樣點過去。

嘗試次數限制的用途

限制失敗嘗試次數擋不住有決心的人。它做的事更有價值：削減背景雜訊，讓留在記錄中的事件都是真正值得一看的。一份不斷產生成千上萬行的記錄不會有人去讀，而沒人讀的記錄等於不存在。

兩件常被遺忘的事

將面板對外開放，也就等於把主控台對外開放。進得了面板的人，就進得了機器的畫面，也就是裡面每一台虛擬機器的工作階段。面板背後有什麼，和面板本身一樣重要。

另外，遠端 Shell 存取是另一扇門。關上其中一扇，不會關上另一扇；兩者要分開考量。

Atlas 的做法

Atlas 把工作階段放在頁面指令碼無法讀取的 Cookie 中，並且只在來自自己網站的請求上將該 Cookie 視為有效，因此其他頁面無法利用使用者的工作階段替它做事。失敗的登入會受到限制：超過一定次數後請求會被拒絕，而這次拒絕會寫入稽核記錄。登入回應不會區分帳號存在與否，因此從外部掃描使用者名稱的人無法建立名單。這些都不會讓對外開放面板變得安全；它們決定的是，如果選擇對外開放，腳下站的是什麼樣的地基。