Heartbleedの件、CentOS6.xでのチェックと対策
細かい事をはぶきますが、SSL通信を行っているプロセスのメモリが読み取られる件。
http://heartbleed.com/
http://d.hatena.ne.jp/nekoruri/20140408/heartbleed
チェック方法
CentOS 6の話です。
1,まずパッケージ名を見る
# rpm -qa |grep openssl openssl-1.0.1e-16.el6_5.4.x86_64
CentOS 6系だと、1.0.x系で、「el6_x.x」のx.xが、5.7でなければ脆弱性あります。
yum update openssl とかしましょう。
注意点として、Opensslを野良でいれて、野良で他のプログラムをビルドしてないか気を付けましょう。
(…ということをさける為にも、よほどの事がなければ野良ビルドはやめましょう)
2,ツールをつかう
実際にパケットを飛ばして脆弱性を確認するツールがあります。
たとえばこれ、Go言語で書かれててカッコイイ
https://github.com/titanous/heartbleeder
他にも本当に色々あって、ウェブサービスになってるやつとか*1、Python製*2とかありますが、自分がコードよめないとつらいので、Go言語のこいつで試す事にしました。
ツールをビルド
go言語のコンパイル環境できていれば、
$ git clone https://github.com/titanous/heartbleeder Cloning into 'heartbleeder'... 略) /tmp$ cd heartbleeder/ /tmp/heartbleeder$ go build /tmp/heartbleeder$ ./heartbleeder --help Usage: ./heartbleeder [options] host[:443] Options: -pg=false: run a check specific to Postgres TLS -timeout=5s: Timeout after sending heartbeat
簡単ですね。
ちなみに、ビルド環境がなくても「話題の」Gobuild.ioでバイナリ配布はされている要です
https://gobuild.io/download/github.com/titanous/heartbleeder
しかしセキュリティ系のツールはよほど信用ができる所がつくっているか、必ず手元におとして、自分でコードをなんとなくみてから使わないとダメじゃないですかね??
ツールで試して見る
今回検証用にVultrでCentOS 6.5 環境を用意しました。
$ yum install httpd mod_ssl
確認したら、すでにパッケージが最新版になってしまっていたので(1.0.1e-16.el6_5.7)、ダウングレードする。
# rpm -qa |grep openssl openssl-1.0.1e-16.el6_5.7.x86_64 # yum downgrade openssl-1.0.1e-16.el6_5.4 Loaded plugins: fastestmirror (省略) Removed: openssl.x86_64 0:1.0.1e-16.el6_5.7 Installed: openssl.x86_64 0:1.0.1e-16.el6_5.4 Complete!
ダウングレードしたらhttpdの再起動も必要です。
(今回はともかく)新規でサーバーを立てたとき、パッケージが最新版になっている業者は「少ない」と思います。かならずyum updateやyum upgradeをしましょう。
必ずパッケージが最新版になるVultrはエライとおもう。*3サーバー立てて、yum updateとかすると300MbyteくらいDLする必要がある各社は見習ってほしい。
さて、では実際にツールで試して見る
$ ./heartbleeder 108.61.201.104 VULNERABLE - 108.61.201.104:443 has the heartbeat extension enabled and is vulnerable to CVE-2014-0160
はい(はいじゃないが)
ではおもむろにyum update opensslを実行し、最新版にもどし、httpdを再起動してからもう一度やってみる。
$ ./heartbleeder 108.61.201.104 SECURE - 108.61.201.104:443 has the heartbeat extension enabled, but timed out after a malformed heartbeat (this likely means that it is not vulnerable)
よさそう。
もう一回ダウングレードして…ちゃんと認識してるな、よさそう。
なんでこんな記事を書いたか
割と急ぎで諸々のサーバのパッケージをアップデートしたので、シッカリした検証を行えていなかった。(全部の穴をふさいだ後で、そういえば…となった)
「対応前後がちゃんとみれてなかったら、ツールがあっても意味ないやんけ!!!」感すごい。特にこのツールの出力が(読めばわかるが)フワッとしてて…w
とりあえず、アップデータをあてて、外してで挙動が実際に変わったことで、安心出来た。
*4
まあ、ツールがそもそも本当にイケてるのかは、これからツールのソースコードとHeartbleedの仕様を調べてからになりますがね!!
SSL証明書再発行について
世の中は厳しいので
「なんでこんな脆弱性があるんだ!!お前の責任だろ!ぶっ殺すぞ!!訴訟だ!!!土下座しろ!!!今後なにかあってもお前の責任だ!!」
みたいな無理筋っぽいクレームがついてきて、本当につらいですが、そういう所は本当になんかあったらクレーム飛ばして内容証明みたいなのがとどくので、やっておく方が良いでしょう。
あと、この脆弱性が公開されたのは数日前ですが、実際に脆弱性が存在していた期間というのはそのライブラリをいれてから対策するまでです。
(実質的にはそのサーバーを立ててから、対策まででしょう)
どうしても、やんごとなき理由で詰んでて上げられない場合
マジで!?(AA略
既存のhttpdのhttpsポートを移動し、そのポートをiptalbesなどでふさぎ、OpenSSL最新版を野良ビルドし、それで*5ビルドしたNginxやApacheを443において、それでリバースプロキシしましょう(真顔
*6
ホント…ホントなあ…どうかとおもうで!?!?!?
*1: http://filippo.io/Heartbleed/ コードもDLできるからそれつかえばよいけど…サイトには入れたくないなw
*2:https://github.com/musalbas/heartbleed-masstest
*3:過去のパッケージがないとダメ、という変わった人はdowngradeで頑張るほうがよいのではないか?
*4:少なくとも「アップデータがあたっている」ことの確認くらいにはつかえそう
*5:ちゃんとconfigure時にその野良ビルドの最新OpenSSLを指定し
*6:pop3sとかそういうのあるなら勿論それも同様に…ウッ