「崩潰」和「幽靈」來了，運維如何不崩潰？

最新 01-16

作者介紹

輕維軟體：敏捷運維找輕維！輕維軟體致力於以先進的互聯網技術，為傳統企業打造敏捷運維體系。立足於企業實際應用場景，團隊規模200+，擁有豐富的大規模集群設備運維經驗。主要技術方向包括自動化運維平台（智能監控、自動化運維、CMDB）、運維工具（資料庫運維管理、SQL審核、應用性能管理）、DCOS及DevOps。

據國家信息安全漏洞共享平台（CNVD）報道，英特爾X86處理器在底層設計方面存在「崩潰」（Meltdown）和「幽靈」（Spectre）兩個高危漏洞。1995年後生產的所有英特爾處理器，以及使用這些處理器的Windows、Linux和MacOS等操作系統都可能受到影響。

此外，ARM、AMD兩種處理器也受到影響。利用該漏洞的攻擊者可以在其登陸的設備上越權竊取數據，還可以突破雲平台的虛擬化隔離，跨賬戶竊取其他虛擬用戶的數據。目前，此漏洞的攻擊利用工具已經在互聯網上傳播，危害較高。

現在，操作系統廠商通過在其產品內核引入內核頁面隔離（KPTI）技術來修復Meltdown和Spectre漏洞。CNVD建議用戶密切關注操作系統、虛擬機、瀏覽器等產品官方網站發布的安全公告，並及時下載補丁進行更新。各廠商的修復情況和參考鏈接如下：

微軟：已為windows 10已供修復包，並對windows 7和windows 8進行在線更新

https://support.microsoft.com/en-us/help/4073235/cloud-protections-speculative-execution-side-channel-vulnerabilities。

瀏覽器安全補丁已發布

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180002

RedHat：已發布補丁

https://access.redhat.com/security/vulnerabilities/speculativeexecution?sc_cid=701f2000000tsLNAAY

Ubuntu：已提供修復補丁（https://insights.ubuntu.com/2018/01/04/ubuntu-updates-for-the-meltdown-spectre-vulnerabilities/）；

SUSE：已陸續發布補丁

https://www.suse.com/support/kb/doc/?id=7022512

Vmware：發布安全公告及補丁

https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html

Citrix XenServer：發布安全補丁

https://support.citrix.com/article/CTX231390

科普一下

什麼是 Meltdown 和 Spectre？

傳送門：https://www.redhat.com/en/blog/what-are-meltdown-and-spectre-here%E2%80%99s-what-you-need-know

預測執行漏洞對性能的影響 -針對 CVE-2017-5754、CVE-2017-5753 和 CVE-2017-5715D 的安全補丁對性能的影響。

傳送門：

受影響的產品更新及注意事項

傳送門：

https://access.redhat.com/zh_CN/security/vulnerabilities/3314391

最新消息，英特爾官方表示漏洞將會使伺服器變慢2%-14%，但安全顯然也同樣重要！

糾結歸糾結，最後大家估計還是得要打，安全是要命的事，伺服器變慢的問題留給英特爾及各操作系統廠商去考慮。但這麼大量的伺服器，這要命的補丁打起來也很要命。

補丁君曾在許多大型企業服務過，每年的安全加固、安全整改都是要運維脫幾層皮的事，還好咱人多，不行人肉。但這次，不管什麼機型、版本幾乎全受影響，而且是內核級的補丁，全要重啟，真的要命啊。估計得到這個消息後，所有運維都要哭暈在廁所了。

補丁君此前也深受這種重複勞動的折磨，於是在此前就積極投身到公司自動化運維平台的建設當中來了，希望能把運維從傳統的體力勞動中解脫出來，這次在以身試范，看如果用上自動化工具，看如何解救大家於水火之中。

補丁君公司的內部研發環境，有300多個LINUX 虛擬機，當然老闆沒發話，也不敢全部就打了，咱們也擔心性能問題。那就先搞些邊緣環境測試一下，找了30多個不太重要的環境來完成本次的測試。

因為涉及重啟操作，在各企業相信重啟伺服器都是件很大的事，重啟前肯定要進行相關的服務檢查、請求隔離等操作，重啟的過程也需要根據應用的集群情況，進行灰度補丁更新（咱們編排流程是支持嵌套編排的，嵌套編排一下就能達到灰度發布的效果啦=。=），最小化對業務的影響。但本次是個測試，最重要是拋磚引玉，就沒有做集群的灰度更新模擬。

本次測試的邏輯過程如下：

下面我們來看看通過自動化運維平台，如何來完成該項工作：

1、新建腳本

2、提交審核

危險命令可以高亮顯示並自動劃分為危險級別，針對不同用戶組進行授權操作（審核-分級-授權）。此處跟Ansible和SaltStack等開源工具不一樣，工具加入了對所有腳本的審批流程，所有批量執行的腳本應該是經過審核的安全的腳本。否則一個危險操作批量下去，就出大事了。

（工具會將reboot自動識別為危險操作，並作標識）

在對應的腳本里選擇需要執行的實例

3、通過編排功能將已經審核好的升級腳本組合在一起。

平台支持將各種操作按一定的順序組合成一個大的操作流程，支持各種複雜的操作調度。平台內置的流程里還可以設置在執行完步驟1後需要確認再執行步驟2，在重啟前進行確認。這裡也是跟相關開源工具不一樣的地方，平台會對各個步驟進行二次管控，包括再確認，再審核，執行步驟完成之後進行簡訊通知、二次確認等，確保整個流程執行過程的安全可控。

4、執行批量更新場景