ただひたすら書こうと思った事を書くところ

タイトルの通り、のつもり。主に技術的なこと、を書けるようになりたい。そんな大したことないことも書くかも。

スポンサードリンク

メンテナンスやらなんやらでてんやわんや

こいつを見てから*1対応に追われてました。


AWSで緊急メンテナンス


AWS to Reboot a Number of EC2 Instances


「Amazon EC2」が大規模なメンテナンス、一部ユーザーは懸念を表明 - ZDNet Japan



影響をうけるのはEC2、RDS、Elasticache、RedShift
情報が出たのが週の真ん中で、その週末に強制リブート。
事前のリブートや立て直しでの回避不可。


なんてことだ…。


これ、相当影響範囲広いんじゃないですかね?
週末の深夜にダウンしたりちょっと重くなったりしたサービスがあったら、それはAWSを利用してるかもしれません。
いや、まあある程度突然負荷が増える可能性のある最近のWEBサービスとかソーシャルゲームとかは
高確率で使ってるサービスではありますけれど。

それに加えてbash脆弱性が露見したりとか、
世の中のインフラエンジニアを殺す気ですかね?

回避策

Tokyo Resionに限った話で言えば、
Availability Zone 1aと1cは日程が1日分けられているようなので、
ELBにぶら下げてるWEBサーバなら、
別のAvailability Zoneにサーバを立てて、
新たにELBにぶら下げることで影響を最小限にできるかなと思います。*2

ただし、1台だけ立てているサーバは影響が不可避ですね。
最悪の場合ダウンタイムを許容するしかないでしょう。

RDSの場合は、Multi-AZにしてればフェイルオーバーするだけで済むみたいです。
ただ、2日でフェイルオーバー→フェイルバックとなることもままあるので、そのことを念頭に置いて。
Maintenance Windowである程度タイミングは操作できるようです。

Elasticacheはリブート不可避っぽいので、一つしか繋いでないのならそもそも乗せてるサービスをメンテナンスにしてしまうほうが無難かも。
複数繋いでて、メンテナンス対象じゃないものがあるなら、一時的にメンテナンス対象のインスタンスを外すぐらいですかね。
あんまりいい方法はわからんです…。


RedShiftは使ってないんでわかりません(・ω<)


bash脆弱性


影響範囲はどこまで?:bashにコードインジェクションの脆弱性「Shellshock」、管理者に大きなショック - @IT

簡単に言うと、
環境変数に、「関数につづいて任意のコマンドを入力する」と、コマンドが勝手に実行されてしまう
ということ。
任意のコマンドが実行できるのでもうやりたい放題ですね。

bash使ってないから…という方でも、CGIスクリプトbash使ってコマンド叩いてる可能性もあるので、
危険性は非常に高いですね

回避策

JPCERTからも正式に注意喚起が出てますね。対処法も。
GNU bash の脆弱性に関する注意喚起

まあ、bashを使わないか、対処されたバージョンにアップデートするかでしょうけど、
非常に使用率が高いので、ちゃんとアップデートするのが無難でしょう。






ここ数日書いてなかったのは忙しかったからであって、
決して書くのが面倒だったからではありません。
ほんとだよ!

*1:厳密に言うともう少し前だったりもしますが

*2:少なくとも、ELBにぶら下がっているサーバが全部同時にダウンする確率は限りなく低くなりますね。

スポンサードリンク