開頭先介紹一下這三樣服務的角色:
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 的做法,把底層的配置都轉嫁給平台,我們只要專心做產品就好,也不用考慮那麼多層面的安全設定,當然前提是平台本身要夠給力。
分享一點紀錄與心得,希望對大家有幫助。