臭い物に蓋をしていたcentOS6のカーネルアップデート

臭い物に蓋をしていたcentOS6のカーネルアップデート

弊社のウェブサイトやウェブアプリは基本的にherokuで、インフラの専門家はいません。開発に集中したいので、クラウドを使ってます。
しかしheroku導入前に作られたサイトやSMTPなどなどのためVPSの契約が一つありまして。

その前はすべてお任せのレンタルサーバーだったのですが、さほどアクセスもないのにドメインごとに別契約して高くついていましたし、メールをExchangeに移行したためメールを管理する機能や領域がいらなくなったため、入社したての私が、VPS借りてマルチドメインにしましょうと提案しました。

まさか誰も、サーバーを構築・運用した経験がないとは思わずに。

言い出しっぺの私が、VPSの管理をメインでするはめになっています。大昔にRed Hatを構築したきり、windowsでウェブの開発環境を作ることくらいしかしてこなかったこの私が。

そんな、サーバー初心者のブログです。

1

 

先月、こんなニュースが目に飛び込んできました。

Linuxカーネルに存在する「Dirty COW」脆弱性–攻撃も確認
http://japan.zdnet.com/article/35090987/

VPSを借りているさくらさんからも
【重要】Linux系OSにおける脆弱性「Dirty Cow」についての注意喚起 | さくらインターネット https://www.sakura.ad.jp/news/sakurainfo/newsentry.php?id=1446

 

これ、カーネルをアップデートしなくてはならないのでは、と溜息。
かなり前から存在していた脆弱性なんですね。

 

実はこのVPSは、数か月前、何も知らずにyum updateをえいっと実行して、kernel panicの文字が出て起動しなくなった後、根本的な解決をせずに前のバージョンで起動するようにして、放置してありました。
なんかもうよくわからないので、色々なサイトをみて、書かれているままに、とりあえず動くようにだけした状態。カーネルがハードウェアとソフトウェアをつなぐ基礎の基礎のプログラムだということは知っていたのですが、この事態では何も。

具体的にどうしたかというと、カーネルパニックを起こした後、この通りに起動して(意味はわかっていない)。

さくらのVPS (CentOS)シングルユーザモード

default=1にすればいいっていうから、viで/etc/grub.confを開いて、書き換えて(意味はわかっていない)。
※たぶん、当時、こうなっていたはず

で、再起動したら、動いたーーー!ヾ(*´∀`*)ノ

同じ失敗をしないように、/etc/yum.confを開いて、yumの設定をupdate時にkarnelを除外するようにして。相変わらず意味はわかってないけど、カーネルのプログラムは全部karnelで始まっててlinuxはわかりやすくていいなと思いました。

 

しかしDirty Cow対策はしなければ。カーネルをアップデートしなければ。

絶対にカーネルパニックは起こるし、復旧方法はわかっていても、サーバーが落ちるのは気持ちが良い物ではありません。嫌だなあ……。

しかも今回はバージョンをちゃんとあげて動くようにしなければいけないのです。

チェックするプログラムを実行してみたら、やっぱりダメ。

CentOS6系における CVE-2016-5195 暫定対応メモ
> 脆弱性の有無/PoC確認

Your kernel is 2.6.32-573.22.1.el6.x86_64 which IS vulnerable.

……はぁ…………。

 

まず、yum check-updateすると、アップデートしていないものがカーネル以外もいくつかあったので、yum clean allでキャッシュを消して、yum update。
またyum clean allで、カーネル以外はぴかぴかのcentOS6ちゃんになりました。

そして数か月ぶりに、/etc/yum.confをviで開き、exclude=kernel*をコメントアウトしました。

そして、yum update

これは成功したので、サーバーを再起動です。reboot

どうせ起動しないと思って、さっさとVPS管理画面付属のコンソールを起動。
やっぱり、カーネルパニックでサーバーは起動していませんでした。

上の、シングルユーザーモードで起動する説明を思い出しつつ、強制再起動し、エンターキーをおしてカーネルのバージョン選択画面になりましたが、多少は成長した私は、console=tty0~の編集はやらない。前のバージョンなら普通に起動する可能性が高いから。

しかし一つ前のバージョンは、数か月前に失敗した2.6.32-642だったので、二つ前のものを選択し、エンターキー。
蓋をしていたアップデート失敗バージョンがある方、気を付けてください! たぶんdefaultの書き換えで復旧していたときも、上のバージョンが0なので、失敗を重ねるごとに、どんどん番号が大きくなっていったと思いますが、ここでも、失敗した数だけ古いものを選んでください。

起動しました!

(ちなみにこういうときにいちいちSSLのパスワードを入れるのが面倒なのでhttpdは自動でサービス起動するようにしていないので、会社のホームページは告知通り落ち続けた。鍵つくるのは簡単ですけど、そもそもそんなに再起動しないしなって……)

ふたたび、/etc/grub.confを開きます。
今回は臭い物に蓋をするためではなく、最新バージョンで起動するため。

使いたいバージョンのところに、
initrd /initramfs-2.6.32-●●●.el6.x86_64.img の記述がないから起動しないので、
yum reinstall karnelで入れなおすか、手で追記すれば使えるようになるという情報は得ていました。

※ initrd:ITpro http://itpro.nikkeibp.co.jp/article/Keyword/20070207/261182/

しかし。

記述あるよ???

でも、数か月前の失敗は、initrdがなくて失敗していたことはわかりました。
なんか気持ち悪いので、失敗バージョンにinitrdを書いてみましょう

そして、だめもとで再起動。

起動しました!
uname -rで最新バージョンであることも確認し、bashでrh-cve-2016-5195_2.sh実行してwhich is NOT vulnerableも確認。

 

WHY!?