朋友圈很多技術比我強的牛人，而且網路上也找得到技術解析，所以我能分享的只是那些非技術的事。

一、秋後算帳

資安弱點新聞揭露後，貴單位負責資安或系統的人員做了什麼？

公司目前只有我一個人負責系統，所以當天資安弱點新聞揭露後，我幾乎一整天都沒有睡，苦等著官方出新的軟體修正，而且修正完成後還要測試並驗收。

因此，如果貴公司直到現在都還沒有修復，或甚至根本都不知道這個資安事件，那我覺得可以請他走人了。

二、作業系統的更新進度

從資安事件的處理可以推敲出各作業系統商對於緊急事件的反應速度。

時間軸，按照修復的先後排列：

  1. OpenSSL (資安弱點的主角) 第一次公開揭露的時間約在 2014年4月6日 0時。
  2. RedHat 在 2014年4月7日 07:47:00 正式修復。
  3. OpenSSL 正式確認並修復的時間約在 2014年4月7日16時。
  4. OpenBSD 約在 2014年4月7日 20:17 正式修復。
  5. Arch Linux 約在 2014年4月7日 20:36 正式修復。
  6. Debian 約在 2014年4月7日 21:45 正式修復。
  7. FreeBSD 約在 2014年4月7日 21:46 正式修復。
  8. Ubuntu 約在 2014年4月7日 21:48 正式修復。
  9. Fedora 約在 2014年4月8日 00:33 正式修復。
  10. CentOS 約在 2014年4月8日 02:49 正式修復。
  11. OpenSUSE 約在 2014年4月8日 05:32 正式修復。
  12. Gentoo 約在 2014年4月8日 07:30 正式修復。(amd64/x86)
  13. Scentific 約在 2014年4月8日 08:27 正式修復。

重點整理：

  1. RedHat 修復的速度比 OpenSSL 官方還快。
  2. RedHat 派系的修復時間，除了 RedHat 外都算慢，如 Fedora 及 CentOS、Scentific，他們都比 RedHat 慢 16 小時以上。
  3. Debian 派系的修復時間，如 Debian 及 Ubuntu，都比 RedHat 慢上至少 12 小時以上。
  4. Scentific 是列表中修復最慢的。
  5. 若以資安黃金 6 小時來說，Fedora、CentOS、OpenSUSE、Gentoo 及 Scentific 都不及格。

三、大公司更新的速度

同樣地，從資安事件的處理可以推敲出各公司對於緊急事件的反應速度。

雲端相關公司

  • Cloudflare 約在 2014年3月31日至2014年4月7日 11時修復。(3月31日有人主動通知 Cloudflare)
  • DigitalOcean 約在 2014年4月8日 12時修復。
  • AWS 約在 2014年4月8日 12時修復。
  • Linode 約在 2014年4月8日 14時修復。
  • Heroku 約在 2014年4月8日 16時修復。

有些公司直到 2014年4月8日 16時都還沒修復。此時已離官方正式修復整整一天，也比上述機器數很多的雲端相關公司還慢。這些公司為，

  • Yahoo.com / Flickr.com
  • Kaspersky.com (資安公司)
  • stackoverflow.com
  • stackexchange .com
  • php.net

其它補充 * Google 在第一時間就把主要的伺服器修復了，原因在於 Google 的同仁是發現這個資安弱點者之一。 * 採用 Microsoft 解決方案的人反而沒有受到影響，因為這個資安弱點跟他們沒直接相關。 * 修復時間主要參考官方源庫或官方部落格。

四、參考來源