フライトシミュレーションコミュニティAvsim.comがハッキングされ、バックアップ共々破壊される 36
ストーリー by soara
侵入者は何がしたかったのか 部門より
侵入者は何がしたかったのか 部門より
あるAnonymous Coward 曰く、
フライトシミュレーションコミュニティAVSIMのオンラインサーバがハッキングされ、データが完全に失われてしまったそうだ（本家/.より）。
残念ながら、コミュニティが13年に渡って開発してきたマップやスキンなどのデータをリストアすることはできないとのこと。サイトの設立者である Tom Allensworth氏曰く、「バックアップを取っていなかったのか、との質問も寄せられているが、我々は毎日サーバのバックアップをとっていた。しかし残念ながらサーバのバックアップは我々のサーバ間で行われていた。ハッカーは両サーバを攻撃し、どちらかのデータを復旧のために使うということはできなくなってしまった」とのことだ。
本家/.のコメにもあるが、オフサイト（もしくは単にオフライン）バックアップの重要性が改めて認識される一件ではないだろうか。
なお、日本のフライトシミュレーションニュースサイトsimflight.jpによると、AVSIMは今回の件の情報共有などのために臨時のフォーラムを立ち上げているそうだ。
光メディアにしてしまえ (スコア:3, 参考になる)
詰まるところ、ある程度データが集まったところで整頓してライトワンスメディアに焼く、
ないしはプレスディスクにしてしまう、等といったことをして
攻撃やシステム障害等による完全なデータの蒸発を防ぐようにするべきだということですな。
そしてコミケや同人ショップで実費に近い金額で頒布する、と。まあこれは外国では難しいか
納期が長めで良いならDVDにプレスするのも1000枚10万円くらいで出来ます。
ライトオンリーファイルシステム (スコア:2)
ライトオンリーファイルシステムみたいのがあるといいですね。ファイルの追加は出来るが削除や上書きは出来ない。
クラッキングされても、破壊は出来ないぜ！
いやまぁ、情報漏洩はどうにもならんですが…
WORMメディア (スコア:4, 参考になる)
いわゆるWORMメディアですね．
http://en.wikipedia.org/wiki/Write_Once_Read_Many [wikipedia.org]
屍体メモ [windy.cx]
Re: (スコア:0)
今回は、リモートからの攻撃で論理的に破壊されたので、ライトワンスなメディアへの
バックアップがあれば、復旧できたのでしょうが、例えば、ライトワンスなテープに
書き出したとしても、そのメディアが物理的に読めなくなってしまう(例えば、火災
で燃えちゃうとか)と、どうしようも無いです。
なので、業者の選定も終わってるんで、オフサイト保管する予算をいい加減そろそろ
付けてください。よろしくおねがいします。
という状況にあったりするAC。
Re:ライトオンリーファイルシステム (スコア:4, おもしろおかしい)
ライトオンリーバックアップツール作ったよー
#!/bin/sh
cat > /dev/null
# 情報漏洩問題にも対応してみました
Re:ライトオンリーファイルシステム (スコア:2, おもしろおかしい)
どこにぶら下げるべきか迷ったが、ライトオンリーだと
と同じことだよな…。間抜け過ぎたネーミングでした…orz
Re:ライトオンリーファイルシステム (スコア:1, おもしろおかしい)
印刷しておけばOKってことか・・・
Re: (スコア:0)
結論としては石版に刻むと言うのが一番と言うことになっています。
Re: (スコア:0)
リードオンリーでしょ。
で、その次には、リードオンリーフラグを無視して書き込むクラックが流行るわけだ。
Re: (スコア:0)
お前は何を言っているんだ
Re: (スコア:0)
ライトオンリーだってば。
リードオンリーだったらファイルの追加も出来なくなるでしょ。
（強調は引用者）
リードは可能、ライトも可能。ただしデリートやオーバーライトは出来ない。ってこと。
Re:ライトオンリーファイルシステム (スコア:1)
ライトオンリーじゃリードできない？って言いたいのでは？
Re: (スコア:0)
それってバックアップ？ (スコア:2, すばらしい洞察)
ミラーリング(not RAID1)もしくはそれに近いデータのコピーはバックアップ用ではなく、
近連続稼働用だと思うが？
関連リンク：ミラーリングはバックアップにはならない [srad.jp]
まあ、実際はミラー的なコピーじゃないのかもしれないが、雷一発で全損傷という
事態が容易に想像できる脆弱な手法を選択していたとは嘆かわしいことではある。
Re:それってバックアップ？ (スコア:2, すばらしい洞察)
バックアップという用語が用いられてますが、データのバックアップとシステムのバックアップとが区別できていないんだと思います。
バックアップは手段であって目的じゃない（Re:それってバックアップ？ (スコア:1)
素晴らしい発言なのでついでにのっかり:)
「バックアップは取っていますか？」とか「バックアップがあれば安心」とか、
何かを守るための一手段に過ぎないバックアップで思考停止するのは良くないです。
# そもそも「バックアップ」という言葉は、予備・複製という連想に至るので良くない気がする
例えば、AppleのTime Machineをバックアップシステムと言って反対する人は少ないと思いますが、
あれは時系列でデータを取っておく「ある時点まで遡れるシステム」であって、データを保護する一手段に過ぎません。
MacBookと外付けHDDとを同じ机の上で運用している人は、コーヒーをこぼして全てが無くなる可能性があるわけです。
オフサイトバックアップ先の過去の水害状況把握とか地震の確率を考えておくのは（個人では）やりすぎかもしれませんが、
台風で部屋に瓦が飛び込んできたら全て無くしても諦めがつくデータしか持ってないかどうかは、自問する必要があると思います。
***
今回の事例では、例えばサーバは単体かつRAID無しの運用であったとしても、月に１度サーバ管理者のローカルにデータを持ってきてＤＶＤに焼いておくだけで充分守れます。活発なコミュニティでも先月までのなら再投稿でリカバリできるでしょう。
（もちょっと手間が掛けられるなら、コピー時の突然死をＲＡＩＤ１で防ぎ、物理的な不幸を複数管理者が交互にＤＶＤを焼いて守る）
サーバが２，３週間復帰しなくてもコミュニティは待ってくれると思いますが、２日で復帰してデータがまっさらになりましたでは納得してくれないだろう、という「何を守るのか」を考えて設計しなかったのが不幸の元だと思います。
# リソースが限られているので「死守しなきゃイカンのは何か」を念頭に置いて設計しないと悲しいことに。
# つまり「コミュニティの連絡手段だけは死守（＝また投稿して貰えば良い）」と考えていたなら、今回の対応で良いと言えます:p
Re: (スコア:0)
#1567048は「Avsim.comの選択は従って用途間違い」という意味なので、
何ら間違いではない。つまり、システムバックアップ用途における手法を
データバックアップ用途に使ったのは間違いだという話だよ、#1567048は。
Re:それってバックアップ？ (スコア:1)
Re:それってバックアップ？ (スコア:2, 興味深い)
#1567048に反対意見を書いてるように見えるからでは
私的には、コストとリスクの兼ね合いで、サーバー間の
バックアップというのは間違ってないと思いますよ
考慮が少し足りないだけで
＃いくらでも金が使える前提で文句いわれてもかわいそう
Re: (スコア:0)
主語の置き方で180度意味が変わってくるのが問題なのでしょう。
それはさておき、サーバ間のバックアップは使い方さえ間違わなければ有用ですね。
オフラインのバックアップも、バックアップサイクルのどこかに含めておけばいいだけで。
Re: (スコア:0)
文章を読む限り rsync とか pfsdump とかそういう感じかな。いわゆる RAID1 のような仕組みであったとは読み取れない。
Re: (スコア:0)
世代別にファイルを保存してないとダメですよね。
単なるミラーリングでは、知らないうちにファイルが壊れていて
あとになって気がついたときなどにも対応できないです。
Re: (スコア:0)
バックアップと言うよりはホットスタンバイだよな
バックアップの方向 (スコア:2)
バックアップサーバ→WEBサーバのSSH接続だけ許可しておけば、バックアップサーバが勝手にデータを引き上げていくことが出来るし、
WEBサーバに侵入されても、バックアップサーバまで一気に到達されることはないはずですよね？
Re:バックアップの方向 (スコア:2)
公開データであれば月１回ペースでzipとかで固めて、torrentで放流。
壊れたらユーザからの応募待ち。
＃エロゲ系のミラーサイトの充実ぶりは異様だと思った今日この頃。
＃壮大なストーリ。空転するアイディア。
Re: (スコア:0)
>WEBサーバに侵入されたらバックアップ側も侵入されちゃうのって、当たり前なのでしょうか？
ウェブサーバーとバックアップサーバーが同じリビジョンのOSやサービス類で構築されてたとしたら、当たり前かもしれませんね。
めんどくさいので (スコア:1, 興味深い)
そして、ジャーナルを保存している別サーバへの侵入対策は、えらくローテクです。
ジャーナルの転送はパラレルポートの直結で、ジャーナル受信側は送られてきたバイト列を一切解釈することなく、そのままHDDにシーケンシャルに記録していきます。侵入されたサーバにできることは、ひたすらデータを送り続けてジャーナル保存を満杯に溢れさせることだけです。
ジャーナル再生でドジを踏むと水泡に帰すので、ご注意を。
Re:めんどくさいので (スコア:1, 興味深い)
もしかして特許主の方ですか？
Re: (スコア:0)
アイデアだけなら中学生でも思いつくシロモノに特許が出てるなんて。
やべー、別の方式に切り換えないと。
どうも胡散臭い (スコア:1)
Re: (スコア:0)
「正しい」バックアップの重要性云々以上に
いったい誰が何のためにデータを破壊したのかのほうがよっぽど気になりますが
そこを詮索するとむっぐぐぐg......
Googleから完全キャッシュもらえば？ (スコア:0)
Googleはキャッシュを消さずに溜め続けているようなので
指定日の完全キャッシュは復元可能ではないでしょうか？
料金は幾らかかるかしらんけど・・
コネを最大限使って、みんながお願いしたらボランティアで
復元してくれるかもしれない。
ブログをGoogle Readerのキャッシュから復元 (スコア:4, 参考になる)
以前ちょっとしたブログをぶっ壊してしまった時，過去の記事をほぼすべてGoogle Readerのキャッシュから復元することができました．フィード自体は直近10エントリしかフィードしてなかったので，Google Readerが何らかの手段でキャッシュしていてくれたのだと思うのですが，他に購読者がすでにいたからキャッシュしていたのかクローリングでキャッシュしていたのを持ってきたのか…ATOM 1.0仕様の履歴とか使ってるフィードじゃなかったし，今でも謎．
そして先ほど同様に直近10エントリしかフィードしてないRSSを新たにGoogle Readerに登録してみたら・・・やっぱり過去100件くらいエントリが見える．すげぇ．って，この仕様からすると削除したはずのエントリも残るってことだよな．フィードってエントリの削除についてそもそも考えるべきものじゃないのかも．しかしATOM Publishing APIだと削除の仕組みもあった気がする．
屍体メモ [windy.cx]
Re:ブログをGoogle Readerのキャッシュから復元 (スコア:1, 参考になる)
こういうことですね。
閉鎖したサイトを閲覧する方法 - RSSリーダーのもうひとつの使い方CommentsAdd Star [hatena.ne.jp]
あれ？ (スコア:0)
飛行機を飛ばすのに飽きたらず、データまで飛ばしちゃった、とかそういうのじゃなくて？
聞き飽きた (スコア:0)
こういう話を聞く度に何のためにデータのバックアップをオフラインにするのか理解していないなと思う。