本文紀錄 Plesk / Cloudflare / Lightsail 混合架構的安全規劃。
開頭先介紹一下這三樣服務的角色：
- Lightsail 是 Amazon 的雲產品之一，可以理解為簡化版的 AWS，Lightsail 裡面的服務有通用虛擬機、資料庫、IP、儲存空間、快照備份這些，它們在 AWS 也都有相對應的服務，但在 Lightsail 這邊提供的是設定與費率更為簡化的版本，雖然設定簡化了，但享用與 AWS 同樣強健的基礎架構，很適合做為 AWS 的入門。在下文我們以一台 IP 為 5.1.2.1 的虛擬機為例。
- Cloudflare 是以 DNS 與 CDN 服務為核心的公司，以核心服務為基礎拓展了一堆安全與遠端存取相關的系列服務，以及以 CDN 全球節點為基礎提供的媒體串流服務 Stream 與 serverless 服務 Workers 等，把原本無聊的 DNS 和 CDN 生意做的多采多姿，是本人的愛廠之一。
- Plesk 是伺服器管理系統，和比較多人知道的 cPanel 比起來毫不遜色，而且有和 Lightsail 合作的佛心版，或許是本人是先用過 Plesk 後才用 cPanel 的關係，一直較偏愛 Plesk，因此也造成了難以適應 cPanel 的後遺症 XD。
本文以這三個服務做為某個 web app 的基礎架構為例，在安全性的方面做出規劃，在此我們希望能達成下列目標：
- 安全性要有，這是最基本的。
- 除了 80、443 以外的埠不要暴露，或者限定只給我的電腦訪問。
- Plesk 控制台要有網址入口，因為 IP 太難記，並且這個網址也限定只給我的電腦訪問。
- 主機的公共 IP 不要暴露。
- 防火牆盡量不要佔用到主機本身的資源，最大化 web app 本身能運用的運算資源以及節省主機費用。
用 Lightsail 防火牆做埠管理
Lightsail 的防火牆雖然滿陽春的，不過也能滿足我們對埠管理的需求，基本上只要是與網址無關的單純的 IP:port 規則，都會在 Lightsail 這邊做設定，簡單有效。
我們的 web app 除了會對外開放的 80、443 以外，還有幾個埠做為內部使用，必須管制只讓我的電腦的 IP 訪問，完整的清單如下：
- 80，HTTP 的標準埠，對外開放。
- 443，HTTPS 的標準埠，對外開放。
- 22，SSH 的埠，需限定連入 IP。
- 8443，Plesk web 控制台的入口，需限定連入 IP。
- 8447，Plesk Installer 的入口，變更 Plesk 元件或更新時會用到，需限定連入 IP。
埠管理這一塊很簡單，用 Lightsail 內的防火牆功能即可設定以上所有的埠號，設定畫面如下：
用 Plesk 設定 Plesk 控制台的入口網址
前面提到 Plesk 會用到 8443 和 8447 埠，在 Lightsail 那邊我們也已經對這兩個埠設定了只有我電腦的 IP 可以訪問它們，但目前的必須透過 IP:port 的方式進入，這對永遠記不住 IP 的本人來說會很困擾，所以最好讓它們有個網址方便往後進入，Plesk 也的確提供了指定網址的功能，見下圖的「自訂 Plesk URL」：
猛擊會出現網址的設定畫面：
我們選第二個，並輸入要當作 Plesk 控制台入口的網址，上例為 plesk.o.com，當然在 DNS 上也要有對應的一筆設定讓 plesk.o.com 連到這台 Plesk 主機的 IP。
接著我們要讓 plesk.o.com 只接受我的電腦的訪問。
施做前先整理一下目前的防火牆設定與 Plesk 的進入點：
- https://plesk.o.com/，這個網址目前是接受公眾訪問的，待會要讓它只能讓我的電腦訪問。
- https://5.1.2.1:8443/，這個入口受到 Lightsail 防火牆的管制，只接受我的電腦的訪問。
- https://5.1.2.1/ ，這個 IP 的入口目前並未受到管制，接受公眾訪問，待會利用 Cloudflare 的 proxy 來隱蔽此 IP，減少 IP 暴露的風險。
開始施工，進入 Cloudflare 的防火牆，建立一條規則：封鎖對 plesk.o.com 的訪問，如下圖：
封鎖後再開一個小門讓我電腦的 IP 可以進去，新增一個 IP 存取規則：
如此一來，plesk.o.com 就只有白名單內的 IP 可以進入。
用 Cloudflare 的 proxy 和防火牆做 IP 隱蔽與網址訪問管理
因為 Lightsail 的防火牆只能設定簡易的 IP:port 規則，如果是牽扯到與網址有關的訪問設定，就必須依賴 Cloudflare 的服務了。
Cloudflare 的全球 CDN 節點會幫我們網站上的內容做快取，讓訪客可以就近從 CDN 節點取得內容，這樣的服務除了有加速的好處外，還可以避免讓訪客直接連線到我們的主機，讓主機與 IP 獲得某種程度的隱蔽性，另外 Cloudflare 也幫我們做了分散流量的工作，讓我們的主機不會被暴衝的流量打爆，總之在自己的服務前面掛一層 Cloudflare 絕對是好處多多，絕對不要因為免費的節點不包括台灣就貿然放棄。
回到正題，要享用 Cloudflare CDN 加速與防護的好處，只要在 Cloudflare 的 DNS 管理頁面把那朵橘色的雲打開即可，如下圖：
橘色小雲表示 Cloudflare 的 proxy 節點，也就是前面提到的 CDN 節點，它們是同概念在不同視角下的名稱，Cloudflare 把這些廣怖在全球節點稱為 edge 節點，不論是 CDN 節點、proxy 節點或是 edge 節點，指的都是同樣的事物，即佈署在全球各個地理位置的伺服器。
開啟後等待個一分鐘讓新的 DNS 設定傳播完畢生效即可。
上圖中可以看到「mail」這筆設定是沒有開橘色小雲的，因為這個郵件代管服務會因為 Cloudflare 的 proxy 而異常。除了例子裡的 mail 外，在實際經驗下最好還是對每組 DNS 紀錄的小雲做一輪測試，確保在 Cloudflare Proxy 開啟時還是能正常工作，確保原服務的可用性，這是比較妥當的作法。
上圖的「www」這一組就是我們主要對外服務的網址，它對應的真實的主機 IP 是 5.1.2.1，但因為有開啟小雲，所以訪客訪問 www.o.com 時不會連到真正的 5.1.2.1，而是會連到 Cloudflare DNS 回應的某個離訪客地理位置最近的 proxy 節點，因此訪客無法從 DNS 查詢出真正的主機 IP 是 5.1.2.1，這樣的特性可以保護我們的主機 IP 暴露，並減少壞人直接對 IP 發動攻擊的可能性。（其實透過一些手段還是有機會知道真正的 IP，所以資安的防禦不能只依賴單一服務或單一層次，必須在架構的每一層都設想安全的防禦機制。）
總結
透過以上一連串的設定，我們做到幾件事：
- 只公開必要的服務。
- 內部用的服務入口都有限定 IP。
- 主機 IP 不暴露。
- 不用主機的資源跑防火牆。
- Plesk 可以用好記的網址進入，而且也受到限定 IP 的管制。
但還有一個小漏洞：https://5.1.2.1/ 這個 IP 的入口並未受到管制。其實可以利用 Plesk 本身的防火牆來設定可以進去的白名單，這點不在本文的宗旨內就不提了。
本文比較著重在基礎架構的安全設定，但其實最脆弱的環節是在用戶的安全意識上，其次才是系統的安全設計。
另外，設定這麼多的感想是，採用 PaaS 或 Serverless 才是更快達到 time to market 的做法，把底層的配置都轉嫁給平台，我們只要專心做產品就好，也不用考慮那麼多層面的安全設定，當然前提是平台本身要夠給力。
分享一點紀錄與心得，希望對大家有幫助。
Top comments (0)