5分鐘讓你的老舊網站支持IPv6、HTTPS、HTTP/2，不能再多了

      本文轉載自微信公眾號“ 鄭海山dump”(ID：zhsdump)，作者：鄭海山

　　領導讓我一個月部署100臺服務器，我剛花了一天時間寫了個自動化腳本，我現在占著工位吹著空調喝著咖啡刷著抖音看Ansible幫我敲命令，我是不是很沒有人性?我接下來29天只能這樣玩了我該不該告訴領導?

　　注：Ansible不是某個同事的英文名，是一個自動化部署工具，同類型的還有Puppet、Chef、Salt等等。有興趣以后再介紹。

　　本Git代碼適用范圍

　　假設你有一個老舊的Web站點 http://dog.xmu.edu.cn ，IP地址為IPv4 1.2.3.4 ，你再提供一臺配置了IPv6的Ubuntu 18.04 LTS服務器，Clone我的代碼，跑一條命令，會幫你把HTTPS和HTTP/2全部配置完畢，然后你測試正常后，修改下DNS，把 dog.xmu.edu.cn 指向新的IPv4和IPv6地址即可。

　　中間是無縫的，干凈的，測試完備的。時間在5分鐘。

　　具體步驟

　　● 安裝一臺Ubuntu 18.04 LTS，配置好IPv6地址。

　　● Clone代碼 https://github.com/haishanzheng/nginx-install/tree/ansible ，最后會PR到 https://github.com/bg6cq/nginx-install 。

　　● cp hosts.template hosts.real，配置你的服務器IP地址、控制機IP、域名、上游原始IP等信息

　　● 跑一下 ansible-playbook site.yml -i hosts.real --ask-become-pass，5分鐘安裝完畢

　　● 跑一下 certbot --nginx certonly ，申請一個免費的Lets Encrypt證書。

　　● 再跑下 Ansible腳本，加入HTTPS支持。因為Ansible腳本是冪等的，所以你跑幾千次都沒問題。

　　● 跑下curl測試，強制域名指向新的IP地址和測試IPv6。curl --resolve dog.xmu.edu.cn:443:2001:da8:e800::42 -I --http2 https://dog.xmu.edu.cn -6 -v

　　● 如果curl正確，則更改DNS即可。再保險點，本地更改DNS，使用瀏覽器測試。

　　● 可以考慮提交網站到張煥杰的測試網站 https://ipv6.ustc.edu.cn/ ，肯定是100分以上。

　　代碼

　　代碼fork自中科大張煥杰的 https://github.com/bg6cq/nginx-install ，PR暫時未提交，張煥杰老師的文檔對Nginx進行了加固，對系統進行了配置優化，可做為一步步操作手冊，了解內部的具體配置機制，張煥杰也帶了個sh自動化部署腳本，依賴較少。ansible目錄為我編寫的無腦自動化部署腳本，依賴Python3，可重復運行，冪等，會不定期同步張煥杰的配置。

　　Ansible跑起來類似這樣子：

　　具體看README.md文檔吧，如果真有人用，我考慮再更新，加個GoAccess統計啥的。。。

  如果你問我反代要怎么做，比較政治正確的說法我會告訴你去買大廠的應用交付設備，啟用一鍵斷網，并購買完善的維保服務，接收廠商定期的更新和威脅情報，并最終在出安全問題后甩鍋給設備和廠商，以避免你在余生中為自己的摳門和不專業而后悔。

　　為什么?以我的repo為例，如果你真的反代了你全校的網站，那這個服務器一定要三級等保合規，你需要在上面安裝防病毒、惡意代碼檢測、完整性檢查、監控、資源限制、審計，你的日志需要到遠程保留3個月，你必須時時更新安全補丁防止CVE漏洞，在Nginx新版發布后必須檢查changelog并關閉不必要的功能。為了防止單點故障，你應該需要2臺反代，上面安裝Keepalived做高可用。為了方便分析，你還需要分析日志。

　　這些我改改代碼都可以在10分鐘內讓你完成，但是我的代碼你自己審計了么?我是否了解了所有的坑?我是否會偷偷插入一些控制你全部站點的代碼?就比如更新免費的HTTPS證書，你在反代上去下載一個.sh文件就跑，安全么?如果為了隔離這個風險，我會使用一臺不可變服務器，3個月定期部署他并讓他跑起來，使用DNS challenge，在最后得到證書后scp到反代上并且銷毀那個服務器。這么折騰為什么不直接花幾千元買個一年有效期更高等級的EV證書?

　　就算你信任我，但是我也不是鐵板一塊，如果我被黑了呢?

　　所以除非你有足夠的自信，否則不推薦，當然張煥杰和我的文檔、repo也不是毫無用處，至少你可以借此揭開反代后面神秘的面紗。

　　潑了冷水，讓我們繼續來學習一下其他坑吧。寫的比較散，想到哪寫到哪，爭取這個系列就完結了。

　　部署反代不是無創的

　　IP地址傳遞

　　部署反代是一定需要的，反代的工作原理導致了你的應用無法得到真實客戶端IP地址，所以反代一般會把X-Forwarded-For、X-Real-IP等參數往應用后面傳，又由于這個參數是放在Header里的，所以必須應對偽造問題。

　　而且反代有時候是多級的，所以反代一定要找到自己的定位，在何時重置X-Forwarded-For、X-Real-IP字段，何時接受信任上級的字段。而應用必須更改自己實現獲取客戶端IP地址的機制，只接收信任反代發送的Header。這個去年底我寫了個案例，就是根據偽造X-Forwarded-For字段來欺騙應用突破IP地址授權驗證的。

　　應用的Web服務器日志配置也必須修改，否則只能得到反代的地址。有些關于X-Forwarded-For 的網上配置是錯誤的。有些是簡單粗暴用X-Forwarded-For替換掉%h，比如

　　LogFormat "%h %l %u %t \"%r\" %>s %b" common

　　LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b" common

　　但是這樣子也不能解決偽造X-Forwarded-For的問題，所以為了統計分析方便，不建議你直接去更改Log格式，建議你應當生成2個日志，一個是%h的，一個是%{X-Forwarded-For}i。各自分析。

　　而如果你在系統里面配置了諸如fail2ban、安全軟件等根據IP來封禁的全部必須做相應調整。

　　HTTP/2

　　以Nginx來做反代，Nginx對后端backend HTTP/2協議是無視的，這是由于HTTP/2協議本身特性造成的。所以你的反代必須清理所有backend傳過來跟連接相關的Header。舉個例子：

　　假設你用Chrome使用HTTP/2協議去反代取某個backend的網頁，然后反代以HTTP/1.1去backend取網頁，這時候支持HTTP/2的backend發現反代的協議好老，會給反代發送“upgrade: h3,h3c”頭部，就是告訴反代，你落伍了，該升級了，如果你的反代不清理這個頭部proxy_hide_header，那你的Chrome會拿到這個字段，他會覺得很莫名其妙。

　　IPv6

　　其實我覺得部署反代來解決IPv6問題是不是一個“上有政策下有對策”的做法，長期倒是會損害IPv6的發展，何時數據中心敢上純IPv6環境呢?

　　或者IPv6要真正推廣需要有應用廠商幫忙來推，比如某個系統很早前就號稱支持IPv6，在很多學校部署得也很多，但是基本上都不用IPv6，不知道是什么問題。確實，多一條路就多一個風險點，而上了IPv6又不會讓你飛起來，大家就沒有動力來推動這個事情。

　　說到這個系統，那繼續說下這個系統的安全問題吧，有些是部署的問題，有些是實現的問題。我不是具體負責這個系統的，我也只是零星使用時發現的。所以你不要讓我來看或者使用你的系統，我會發現一些亂78糟的問題讓你我都很尷尬。

　　● 密碼防止暴力破解設計很奇特。如果你對某個賬戶破解密碼超過一定閾值后不是告訴你被鎖定而是不管你輸入正確還是錯誤的密碼都告訴你密碼錯誤，對用戶很困擾，對攻擊者也不友好。我曾經寫信去咨詢希望能改變方式或者提供開關讓我們自己選擇，但是沒有下文。

　　● 直接把認證信息加在URL里，類似 http://dog.xmu.edu.cn/index.php?login-user-hash-is=GUID ，這樣子也是非常不安全的，雖然這樣子是對cookiless友好的，但是如果沒有HTTPS，地址很容易被嗅探，并且地址也會加入Web服務器的Log內，甚至都無法預防有人站在你身后拍照你的屏幕傳給別人。后來指出后，加了個同來源IP地址的驗證，也就是即使你拿到地址后，必須在同一個IP才能訪問。但是這個也不靠譜，在同一個物理NAT環境或者撥同一個VPN還是有可能被攻擊。而且在部署或者代碼里沒有對Referrer Policy進行指定，瀏覽器的默認Referrer Policy是no-referrer-when-downgrade，也就是，你在系統內點擊鏈接后會把GUID傳給黑客的Web服務器。再后來是加了Cookie，安全了。其實我現在也不是太明白，有了Cookie后為什么還要有那個login-user-hash-is，可能是為了兼容舊應用的API調用吧。

　　● 管理員界面和API調用綁定在普通用戶同一個Web服務器端口內，如果你的超級用戶密碼強壯，系統本身沒有問題這個是問題不大的，我們為了保險還是加了一層管理員IP限制，很多學校是沒有的。而且API認證模式是使用IP地址認證。

　　希望今后這個系統能真正對部署的安全梳理一層，提高各個學校的安全性吧。

　　關于IPv6地址規劃，我不是搞網絡的，我是搞應用的，所以我不是太懂，宋崟川寫了個 https://www.ipv6-cn.com/tutorials/ipv6-address-allocation-n-assignment.html 可以學習，我是看不懂的，但是如果你是使用IPv4來映射出IPv6地址的，雖然簡單但是感覺可以變了。

　　IPv6巨大的地址池給我造成的問題就是，原先使用IP地址來做諸如投票IP地址唯一性判斷方法有點失效了。攻擊來源IP非暴力破解的判斷策略也需要更改了。

　　HTTPS

　　HTTPS可以提供保密性、完整性，簡單給Web網站加個HTTPS可以解決大部分問題，如果你想再上幾層，還有其他可以改進：

　　● DNS權威服務器要上DNSSEC，免得DNS就被人篡改了。

　　● 為了防止諸如以前的某些廠商等讓用戶安裝他們的根證書，然后被黑導致MTTM攻擊，可以在DNS上加CAA，只允許某些CA給你某個域名簽名。

　　● 目前瀏覽器默認是訪問80端口的，未來可能會改變，所以一般網站的做法都是先訪問HTTP然后301到HTTPS，這中間是可能被攻擊的。所以你應當加HSTS、hsts preload list、STS-in-DNS等改變這個流程。

　　● 網頁如果加了HSTS一年，但是黑客可以利用NTP攻擊讓客戶端電腦時間推后一年導致HSTS無效。有人這么無聊么?反正都考慮到吧。

　　● HTTP服務器配置要防止SSL協議和加密方法降級攻擊。

　　HTTP/2

　　關于HTTP/2的介紹網絡上很多，我就不搬運了，改變很大，基本上目前HTTP/2都必須前置有HTTPS，所以有些調試技巧失效了，而且你以前掌握的一些HTTP/1.1的優化奇技淫巧也都沒用了，重新學習吧。