(IT) Big-IPがやられたけど、仮想化してたから速攻でリカバーできた話


サーバセンターなんかで赤くて丸いf5と書かれた筐体を見たことがある人も多いはず(普通見ないかw)。

いまいる会社でもファイヤーウオールとロードバランサーで使ってるわけで。この会社の事例紹介でも取り上げてもらった。
ご存知の通り、紹介されるといろんなサービスがあっ(以下自粛)
採用したのはaws上(クラウド上)で動くVE(Virtual Edition)版ではあるものの、令和の時代にあっても、多くの企業や行政ではリアルな筐体でBig-IPを採用しているところは多い(はずだ)。
で、この日本だけではなく、世界でシェアをもつファイヤーウオールに脆弱性が発見された。
例えば、Windows10に脆弱性が見つかって攻撃されても、パソコンの中に入っている一人か二人分の個人的なデータ漏えいする可能性があるだけ(シゴト用のパソコンでサーバーへのログイン情報とかが記録されていたらその限りではないけどね)。しかし、一般的なWebサーバーは、「そいつ(ファイヤーウオール)が守ってくれるから、(一般的なことはするにしても)特別な防御をしなくてもいいよね?」という前提で、インターネットに直で出しているサーバーよりも安心感を持って設定してあるわけ。そこへもってきて、ファイヤーウオールに脆弱性があるってことは、みんなが頼りにしてたそいつに弱点があって、何ならログインされて、踏み台にされたら、壁の内側を荒らされ放題(技術的にはかなり高度な知識と経験がいるけど)になる可能性があるわけよ。もう、インフラ屋からすればオカルトそのもの(怖)。
一般的な「セキュリティ」の考え方としては、「可能性がある」時点で、「やられてしまった」と捉えて対応しないと、大変なことになる「可能性がある」ので、対応必須というのが常識なわけで。
というわけで我々も対応開始。業界的にいうと、「お祭りがはじまった」状態なわけだ。

セキュリティ上の問題で、当該のファイヤーウオールがどんな状態だったかは詳しく書けないけど、少なくともこの脆弱性をついた攻撃はゼロ回じゃなかったことだけは確かだと観測された。だって、前述の通り「この会社はf5のマシン使ってまっせー!」ってインターネット上に書いてあるんだから、ここの事例集に載ってる会社にはとりあえず攻撃してみるのが正しい「悪意のある人」の行動。
ということはもう、可能性があるわけだから、やられちまった前提で対応を開始。
とりあえず、メーカーが推奨しているようなネットワーク上の設定はすぐに実施したが、問題は機器の再構築。
オンプレでリアルの筐体を使っている会社はマシンをネットワークから外し、初期化して、ゼロからインストールして、それまで実施してきたシグネチャの適用を全部順番にしないといけない。それはそれは気の遠くなるような作業で、ベンダーさんに頼んでも何百万円もかかって何日いや何ヶ月かかるかもしれない。
しかしオレが担当しているファイヤーウオールは仮想化といって、クラウド上で構築されているので、毎日その機器の状態を「スナップショット」という形式でバックアップしている。なので、攻撃が開始された前日のスナップショットから復元することで、数時間で安全な状態に復帰できる、はずだった。スナップショットからの復帰については大きな問題はなかった。2台が並行して動いていて片方が死んでももう片方がすべてのトラフィックを捌ける設定となっており、リソース的に問題ないことも実験済だった。この機能を利用して、1台づつネットから隔離して復元してネットに復帰させれば、全体のネットワークを止めず、業務影響なく対応できるはずだった。
ところがネットワーク内の他のサーバーで数台、片方のファイヤウオールからの応答がないと動作に支障をきたす設定となってるものがあり、1台をネットから外すといくつかの部署で悲鳴があがる状況で、一台ずつ設定の確認と変更を実施したので、そこで時間がかかってしまった。
2日間にわたるお祭りも、そんな小さなトラブルもありながら、なんとか完了できた。何ヶ月もかかる可能性があるオペレーションが2日でできたし、追加のコストもなく完了したのは、スタッフやベンダーさんの緊張感を持ったオペレーションのたまものではあるわけだが、もう一つの手柄は「Big-IPをaws上のスナップショットから復元させる機能をメーカーであるf5に実現させた」男の存在だ。
VE版の出始めの頃、f5社はスナップショットからの復元は正式にサポートしていなかった。おいおい、f5さん、ソフトウエアの会社になると宣言している割には、むっちゃハード寄りというかオンプレ前提の話じゃないっすか、それ。VE版なんだからスナップショットからの復元をサポートしてくれよ、と強行に申し入れをして、結果サポートを勝ち取った。あれから3年以上経った日に、あの交渉が活きたということ。インフラを守るというのはこういうこと、と思ったよ。当時f5と直談判してくれた同僚に本当に感謝している。

(IT) 老害のAWS+CentOS7+Apache2.4など


NTT-ComさんのCloud-nは日本リージョンができる前からユーザーだった。
なんと言ってもネットワーク費用が固定というところがキモ。
できたての頃からエバンジェリストの林さんからの推薦もあって、まずは
個人のサイトからスタート。その後、法人でも契約したけど、その行方は
担当にまかせるとして、個人サイトは先日、引っ越しを余儀なくされた
USリージョンでも移行があるということで、これはマニュアル通りの
移行でなんとかなった。
今度はUSリージョン撤退ってことで、日本リージョンへの移行の案内は
あったものの、今のシゴトからすれば、AWS一択なわけで、そっちへ
移行することにした。

個人のドメイン(shirao.netとryoshr.net)はメールとWeb(blog)の
サーバーが一台にまとめてあった。まあ、安いからね。
今回はメールとWebのサーバーを分けよう、というアイディア。

とりあえず、自前の知識で、AWSのCentOS7上にqmailのインストールを
はじめてみたものの、あちこちでスタックして無理っぽい。
まあ、qmailのインストールといえば、オレが最初にやった時はgccの
コンパイルするところからだったんだぜ。
yumなんて魔法のツールがないころな。
ライブラリが足りないと、東京理科大のsun用のftpサイトから落としたりな。
最初にqmailいれたの、Sun SPARCだったなあ。
で、今回はセキュリティパッチだのtcp wrapperだのqmailの開発当時は
想定してなかったことをフォローするためにいろいろ手順があるんだが、
CentOS7+qmailという組み合わせの情報がほとんどない。
学生時代からのツレのけんちゃんの「いまからqmail?」というつっこみを
きっかけにpostfixへ切り替え。
そしたら、なんだよ、むっちゃ楽ちんやんけ。virtualという名前のファイルの
いじり方さえ覚えちまえば、どうにでもなりそう。Webで管理するツールも
あるらしいし(オレは使わないけど)。
というわけで、実家のじじばばも使っているshirao.netのメールサーバーの
移行はその後はかんたんに完了。Rout53にしといたのも勝因。

つづいてWordpressの移行。
メールサーバーの時もそうだったけど、CenOS7の最初のユーザーって「centos」
なんだよ。「es2-user」じゃないの。EC2でインスタンス作ったのに、ログインできない。
なんでーと思って、会社の同僚に聞いたら、教えてくれた。

SELinuxをまず無効にするのは、学習してた。でもそのあとrebootするのが常識らしく。
vsftpdが立ち上がらず苦労したのはrebootしてなかったからだったようだ。

続いて苦労したのはmysqlのデータの移行。
新しいサーバーは最新のmysql5.7。5.6まではコマンドでrootユーザーのパスワードが
変更できたのに、このバージョンではその「優しいモード(mysql_safe)」がなくなっている。
よくよくしらべると、/var/log/mysqld.logを見て、先頭の方にある
[Note] A temporary password is ・・・の行にパスワードが書いてあるという
Webに辿り着くのに半日以上使うなど。

mysqlでバックアップしたデータを新サーバーで戻したら、あとはwordpress関連の
ファイルをごっそりコピーしたら、blogの移行は完了。
これもDNSをRoute53にしてたから、切り戻しも考えやすかったしね。

よしよしと思ってたら、pluginのアップデイトにftpdが必要。
お約束のvsftpdをインストールしたが立ち上がらない。
一日以上費やしたあげく、あきらめて再起動したら何事もなく立ち上がった。
SELinuxを無効にしてからrebootしてないとよくある現象らしく。

というわけで、ようやくサーバーの引っ越しを完了。
現在smallインスタンスだけど、遅くなったら大きくしようかな、と。

Spesial Thanks to : @tamatamarock

(IT) iPhoneを機種変したらAWSにログインできなくなった


AWSのサービスコンソールにIAMでログインするのに仮想MFAデバイスとして
iPhoneのAuthenticatorを登録してあった。
itunes_authenticator

そんなことはすっかり忘れてた頃に先日iPhoneを機種変したんだった。
たまたまAWSから請求書が来たタイミングで気になることがあって、
サービスコンソールにログインしようと。
新しいiPhoneにも入れてあったAuthenticatorを使ってコード表示させて
コードを入力してもこんな画面。
Auth_Erro

うーん、そのままは使えないのな。
何回かやってもダメだったので、ページ上の「Contact us」ボタンをポチッと。
(実はこのボタン押したの2回目(告白))
予想通り、英語で電話がかかって来たので、英語のできる同僚に頼んで、
日本語でかけ直してくれ、と言ってもらった。

どうやってもログインできない中、ふと手元にマウスとして使ってた旧iPhoneが(笑)
mouse_iphone
そこに入ってたアプリのコードで無事ログインできた。(早く気付けよ)

IAMコンソールでデバイスを削除。
Delet_device

新しいiPhoneを登録。
スクリーンショット 2015-11-05 14.04.28

無事登録完了して、ログインもできた。
スクリーンショット 2015-11-05 14.05.41

たまにしかコンソールに入らない怠け者管理者は、機種変の前にMFA登録したデバイスの
削除をしておくことをお忘れなく。

と、ここまで書いたトコロで、日本語でAWSサポートさんから電話(笑)
すみません、おかげ様でなんとかなりまして、といいつつ、旧端末がなかった場合は
どうなりますかと聞いてみたら、電話で確認が取れたらAWSさん側でデバイス削除の
オペレーションをしてくれる、とのこと。
英語でかかってくる一発目の電話に耐えられるなら、何もしなくても大丈夫かもw。