1. TOPTOP
  2. Webサービス
  3. Linux

Linuxで使われているシェル、「bash」の脆弱性の件について。最新版をアップデートする以外にやるべきことを考えてみた

|

linux

先日ブログ(新しいタブで開く)を書きましたが、その後もLinuxのbash脆弱性に関する注意喚起が、続々と舞い込んできます。

自分のサーバーは、9月27日にアップデートしました。しかしよく考えてみると、第一報を知ってから、アップデートするまでに2日空いています。

夜中にこれらのページを1人で見ていると、「発表から対応までのタイムラグの間に攻撃されていたら…」などと、つい後ろ向きな考えに陥ってしまいます。

bash脆弱性の対応に関する悩み

そうは言っても、くよくよ悩んでもいるだけでは仕方がないので、今後の対応策を自分なりにまとめてみました。

1.攻撃の確認

すでに自分のサーバーに対して、攻撃リクエストがされたり、攻撃リクエストに含まれたOSコマンドを実行されていないか?

2.攻撃後のサーバー削除について

仮に攻撃がされていた場合、クラウド上のWebサーバーを削除してしまえば、それで済むのか?削除後もDDoS攻撃など(新しいタブで開く)に加担することはないのか?

3.9月29日にIPAから発表された更新情報について

bash脆弱性に関する更新情報が出ているが、9月27日にアップデートしたbashで対応できているか?

9月27日に個人的にアップデートしたbashは次のとおり。Qiitaの記事(新しいタブで開く)で紹介されたバージョンにしている。

yum_update_bash1

Updated:
bash x86_64 0:bash-4.1.2-15.el6_5.2

ちなみに、こちらのブログ(新しいタブで開く)を参考にして、9月30日に自分のシェルを確認したところ、脆弱性はないバージョンということが分かっている。

bash_conformation

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
this is a test

4.統合監視ツール「Zabbix」について

さくらのナレッジ(新しいタブで開く)で、統合監視ツール「Zabbix」が紹介されている。このツールを導入すると、攻撃リクエストの有無や脆弱性の監視ができるのか?

広い範囲から狭いポイントにつめる

技術的な詳細をつめれば、いろいろな対応もしないといけないのでしょう。しかし、1人でWebサービスを作っているため、安全性に割けるリソースもごく限られています。

なので広いところから捉えて、徐々に個別の問題に狭めていきたいと考えています。

〔参考サイト〕