先日ブログを書きましたが、その後もLinuxのbash脆弱性に関する注意喚起が、続々と舞い込んできます。
- 【重要】GNU bash の脆弱性に関する注意喚起 | さくらインターネット
- 更新：bash の脆弱性対策について(CVE-2014-6271 等)：IPA 独立行政法人 情報処理推進機構
- GNU bash の脆弱性に関する注意喚起 JPCERT コーディネーションセンター
自分のサーバーは、9月27日にアップデートしました。しかしよく考えてみると、第一報を知ってから、アップデートするまでに2日空いています。
夜中にこれらのページを1人で見ていると、「発表から対応までのタイムラグの間に攻撃されていたら…」などと、つい後ろ向きな考えに陥ってしまいます。
目次
bash脆弱性の対応に関する悩み
そうは言っても、くよくよ悩んでもいるだけでは仕方がないので、今後の対応策を自分なりにまとめてみました。
1.攻撃の確認
すでに自分のサーバーに対して、攻撃リクエストがされたり、攻撃リクエストに含まれたOSコマンドを実行されていないか？
2.攻撃後のサーバー削除について
仮に攻撃がされていた場合、クラウド上のWebサーバーを削除してしまえば、それで済むのか？削除後もDDoS攻撃などに加担することはないのか？
3.9月29日にIPAから発表された更新情報について
bash脆弱性に関する更新情報が出ているが、9月27日にアップデートしたbashで対応できているか？
9月27日に個人的にアップデートしたbashは次のとおり。Qiitaの記事で紹介されたバージョンにしている。
Updated: bash x86_64 0:bash-4.1.2-15.el6_5.2
ちなみに、こちらのブログを参考にして、9月30日に自分のシェルを確認したところ、脆弱性はないバージョンということが分かっている。
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
this is a test
4.統合監視ツール「Zabbix」について
さくらのナレッジで、統合監視ツール「Zabbix」が紹介されている。このツールを導入すると、攻撃リクエストの有無や脆弱性の監視ができるのか？
広い範囲から狭いポイントにつめる
技術的な詳細をつめれば、いろいろな対応もしないといけないのでしょう。しかし、1人でWebサービスを作っているため、安全性に割けるリソースもごく限られています。
なので広いところから捉えて、徐々に個別の問題に狭めていきたいと考えています。
〔参考サイト〕