最悪のウィルスと、最悪の対応 (続続・Gumbler大流行中)。
問題のサイト、本日見たら「何事も無かったかのように」復旧していました。
そう、「何事も無かったかのように」。
さて問題です、この行為は正しいでしょうか。もしそうでない場合、どのような問題があるでしょうか。
答えは・・・皆さん正解ですよね。
「正しくない。何故なら、サイトがGumblerに感染していたことを告知していない」
いやはや、とても残念な結果となってしまいました。
・・・え、サイトの汚染を取り除けばそれでお終いだろ、って。
ちょっと待った、そりゃないですよ。もう少し考えてみて下さい。
このサイトは期間的にはあまり長くなかったとはいえ、明確に「キャリア」だった訳です。
「キャリア」に接触してしまった以上、無防備であれば「感染」してしまっているかも知れないワケです。
だとしたら、せめて過去に自分が「キャリア」であった、ということを明確にしておくべきでしょう。
まぁこういうトコで、サイト管理人のセキュリティ意識のレベルも分かるよね、ってなことです。
◇
突然話は飛びますが、今回のGumblerの大流行、個人的にはAIDSの流行と似ているな、と思っています。
「無防備のままムチャな接触をすれば感染する」
「感染しても気づかないままキャリアである期間が比較的長い」
・・・似てません？片や電脳世界、片や人間社会での話ですが。
そしてもう一つ、ややイヤな話を。
今、AIDSが蔓延している地域／年代での感染者の行動パターンを分析していると、感染者が無知・デマ・ヤケから自らの行動で感染拡大を助長している、という話があるそうです。
ここで突然Gumblerの方を見てみると、あれ、何か既視感が。
◇
とまぁそういうワケで、とあるサイトは「復活」したワケです、はい。
・・・念の為、無防備に接触して感染する方もダメダメなんですよ。
そこの責任転嫁はしないように。
Tags: Gumbler
オペレーション・セキュリティ (続・Gumbler大流行中)。
さて、昨日ネタにしたGumbler話の続き。
問題のサイト、本日見たら取り敢えず閉鎖されているようです。
つまりこのサイトは汚染されたまま放置されているワケではなく、管理者も汚染拡大を阻止するためにまずは正しいオペレーションを取りました、と。
・・・ということで。
先日から話題になっているFTPパスワードの件と絡めまして、少し「オペレーションとしてのセキュリティ」について考えてみましょうか。
といっても、実はこれがそんな簡単にまとめきれるような簡単な話ではなく。
「システム最後にして最大のセキュリティホールはユーザ自身」
などと言われるぐらい大きな話なのですよ。
なので、今回はGumbler対策、その中でも今話題の「FTPパスワードが抜かれる（盗まれる）」に話を絞っていきます。
＃一時期大流行したWinnyでの情報流出だって、所詮あれはユーザが原因だしね。
◇
この話、いくつものレイヤが一緒くたに語られているので、話がグチャグチャになっている印象があります。
なのでレイヤをバラしてみると、大きく分けて以下の3つの話になります。
1・ネットワーク上の通信を覗かれて、パスワードが盗まれる。
2・ローカルPCに保存された設定が覗かれて、パスワードが盗まれる。
3・ローカルPCの操作が記録されて、パスワードが盗まれる。
さて、順番にバラしていきましょか。
1★ネットワーク上の通信を覗かれて、パスワードが盗まれる。
今回の騒ぎで「FTPを捨てろ」という話が出てくる理由がこれです。
FTPというのはパスワードが「そのまんま」ネットワークを流れるため、ネットワークを覗き見していれば簡単にパスワードを拾う事が出来ます。
♯さすがにコレはカッコワルイということでOTP（One Time Password）やC＆R（Charrenge And Response）と呼ばれる仕組みも考え出されたのですが。
残念ながらコレはあまり流行らず、今でもパスワードを「そのまま垂れ流し」してるのが殆どです。
このこと自体は昔から周知の事実で、少しでもセキュリティに気を使う人は昔からFTPなど使っていないのですが。
今問題になっているのは、Gumblerの亜種に「ネットワークを覗いてパスワードを探している」ものがある「らしい」という話が出ているからです。
つまり、ユーザがFTPでパスワードを垂れ流すと、身を潜めてすぐ目の前のネットワークを覗き見しているだけでパスワードが手に入る、ということです。
このような「システムに積極的な攻撃をしない」タイプのウィルスは一般的にユーザに気づかれにくい上、アンチウィルスソフトウェアからも検出されにくく、気づかないうちに大量のデータが盗まれる可能性があります。
そもそも現在FTPでサーバに接続すること自体、激戦場に丸腰で突入するような（無謀な）ことなのですが、この上味方だと思っていた連中が実は全員スパイで自分の全てが監視されてた、みたいなこの状況。
・・・やめましょうよ、FTP。
対策としては、要するに通信を暗号化すればいいワケです。覗かれても理解できなきゃ問題ない。
・FTPの通信全体をまるっと暗号化してしまう →FTPS (FTP over SSL)
・同じくFTPの通信全体をまるっと暗号化してしまう →SFTP
・そもそもFTPを使わず暗号化通信を行う →SCP
イロイロ選択肢はあります。
この中で、お使いのサーバでサポートされている暗号化通信を利用して下さいな。
◇
2★ローカルPCに保存された設定が覗かれて、パスワードが盗まれる。
さて、1と違ってこちらは「うっかり感染してしまった後」の話ですね。
「感染した時点で既にダメ」なのは事実なのですが、それでも俗に言う「ダメコン」（Damage Control）、いかにして被害を最小化するかという考え方が出来るか出来ないかで、その後の被害状況は随分と変わるもの。
というワケでして、世間では一番盛り上がっているネタです。
そもそも、ローカルPCに設定を保存しているということは、必ず解読出来る形式でデータが保存されているということです。・・・解読出来ないと呼び出せないじゃないですか。
そして、Gumblerウィルスは、この「設定の解読方法」をいくつも知っている。解読に必要な情報が全てPCにあれば、ウィルスは簡単にそれらを回収して設定を解読してしまう。
今回はソレで見事にパスワードが解読され、どんどん盗まれている、ということ。
それでは、この対策をどうすれば良いか。
簡単です、解読に必要な情報の全てがPCに無ければいいんです。
要するに、パスワードを保存しなければ良いのですよ。保存してなければ盗みようが無い。
はい解決。
・・・え、ダメ？
まあ確かに、そんなにいっぱいパスワードなんて覚えられねぇよ、というのが人間。
大丈夫、そんな貴方に「パスワードマネージャ」というソフトがあります。
♯KeePass、とか。
これは「強力な暗号化と一つのマスタパスワードを組み合わせ、他のパスワードを暗号化して保存しておく」ツールです。
マスタパスワードが漏れない限り、他のパスワードは安全に保存しておけます、ということ。
勿論、いくら強力な暗号化とはいえ、マスタパスワードが漏れてしまったら守りようがありません。
自分のセキュリティを守るため、たった一つのマスタパスワードぐらい、きちっと覚えて管理しましょうね。
ということで、ローカルPCに全てのパスワードを保存してラクしよう、という考え方はいけません、という話でした。
♯念の為、パスワードマネージャを使う時は暗号化の強度を必ず確認しましょう。
◇
3★ローカルPCの操作が記録されて、パスワードが盗まれる。
さて、前ネタに続いてこちらも「うっかり感染してしまった後」の話。
今度は「パスワードを保存していないor安全に保存していても、パスワードを入力する操作そのものが記録されて、結果としてパスワードが盗まれる」という話です。
これはいわゆる「キーロガー」対策ということで、Gumblerだから特別ということはありません。
今回Gumbler対策でこの話が出るというのは、Gumblerの亜種に「キーロガー機能を持っている」ものがある「らしい」という話があるからです。最初のFTPの話と一緒。
まあこれに関しては、今更言うことはありません。FTP捨てようが、パスワードを全て毎回手入力しようが、防ぎようが無い。
防ぐには、そもそもこんなヤツを入れない、以外無いです。
◇
とまぁ、こんなワケで。
問題になりそうなのは、FTPしか使えないという、時代遅れのサーバのユーザですね。
もしOTPが使えるようでしたら何もしないよりはマシなのですが、今更ソレかよ、という気がします。
正直なところ、今時FTPしか使えないサーバなんて解約するのが一番いいと思います、はい。
FTPを使わずにファイル転送が出来るサーバなんて、今時珍しくないですから。
ちなみに、問題のサイトを収容しているサーバ業者のサイトを確認したところ、FAQの隅っこに「FTPSが使えるよ」と書いてあるだけでした。
普通に仕様表に書いていない辺り、割と残念な類の業者ですね、コレは。
Tags: Gumbler
Gumbler大流行中。
さて、世間では「Gumbler」が流行っております。
そして、ついに？いつも当方が巡回している某サイトに現れました、ソレが。
＃この呼称が正しいの正しくないのという話は疲れるので割愛。
ここでは「広くこう呼称されている、ソフトウェア脆弱性とWeb改竄を用いた連鎖型攻撃」の総称として使います、えぇ。
当方の日常巡回内では初めてだったので「ついにキター」と妙に感激して・・・おっとっと、それは兎も角。
というワケで、相変わらず大流行中なので「Gumbler」対策でもまとめておきますか。
◇
まず、Gumblerそのものについてはあちこちでイロイロ言われてますので、割愛。
但し、セキュリティ音痴による「嘘と間違いだらけの解説が氾濫している」のが現状なので、注意すること。
今回日本で続いている騒動については、ネットワークセキュリティ専門家も多数の情報を公開しているので、個人的には
「『専門家の肩書きを持つ人間が、所属するセキュリティ企業／組織サイトで公開している記名記事』以外信用してはいけない」
と思っているし、実際それで十分な情報が集まる。
何しろGumblerはサーバだけの問題だ、FFFTPが脆弱だ、などというデマが多数流れていて、しかもそれを臆面も無く堂々と知ったかしているblog等も多数存在する中、ヘタに検索かければそんなウソばかりが引っかかるのが現状。
「自らの身を守るのは正しい情報」
ということですよ。大震災の時とかと一緒。
◇
さて、ということで実際の対策しましょうね。
★脆弱性の元となる設定を潰す。
まず何より、Adobe AcrobatのJavaScriptを停止すること。
「環境設定」→「JavaScript」と選んで「Acrobat JavaScriptを使用」のチェックを外す。
これが有効になってないと困るということは、個人ユーザならまず無い筈。
♯企業ユーザでどうしても必要な場合は・・・そんなダメシステムを作ったSIerを怨みつつ、まあ頑張って。
といっても、そもそも企業ユースでもこんなん使われてるのなんてそうそう無いですけどね。
あと、Vistaや7でUACを無効にしている人は、速攻で標準状態に戻すこと。
100％引っ掛かる訳ではないが、引っ掛かって攻撃阻止できたら儲けモンでしょう。
★脆弱性の残るコンポーネントを一掃する。
Mozilla Firefox、Thunderbird。Adobe Acrobat、Flash、Shockwave。Microsoft IE、Silverlight、Office。(Oracle) Sun Java、Apple QuickTime、Real RealPlayer。
要するに脅威に晒されるBrowserおよびplug-inについて「使用を続けるなら最新版にアップデート」を行う。
「使わないならアンインストール」して捨てる。
これで脆弱性はゼロ・・・と思いたいのだが、どうもそうでもないらしい、という話もちらほらと。
とはいえ、脆弱性が一つでも減るなら、少しでも攻撃を避け得る可能性が高まるなら、そちらを選ぶのが基本中の基本。
ここで気をつけたいのが、Javaのように「新しいものを入れても古いものが残ってしまう」ソフトウェア。
普通の個人ユーザなら最新版以外が無くても困らない筈なので、「古いソフトウェアを確実に削除」すること。
更に気をつけたいのが、Acrobat等の設定項目が多数あるソフトウェア。
アップデート作業を行うと、環境設定の一部がデフォルト、つまり危険性が高い状態に戻ってしまうことがある。
つまり、「アップデート作業を行った場合は、必ず設定項目が変化していないか確認する」こと。
◇
あと、以下の方法も意外と有効・・・だと個人的には思うのだが、この辺りはイロイロと意見もある話なので、まぁ参考程度に。
★フィルタリングツール等で.ru／.cn等への接続をブロックする。
ネットワーク管理者の立場では絶対に出来ないが、個人ユーザが自分を守るために自分用端末に設定するなら特に問題ない「特定国ドメインの丸ごとブロック」。
実際問題、この辺りのドメイン名をブロックして、日本人の殆どは全く困らないと思われる。
＃というか、そもそも.ruとか.cnに日本人向けコンテンツってあるの？
・・・あ、.cnには海賊版動画サイトがいっぱいあったか（笑。
ちなみにGumbler本体が置かれているサイトは、少なくとも本日時点では大多数が.ru（ロシア）、その残りの半分ぐらいが.cn（中国）、後はあちこち。
なので.ruと.cnをブロックしたところで安全になるワケではないが、しないよりはマシかも知れないという話。
実際にどうするかについては、FirefoxならAdblock Plus／Adblock++を使うとか、IEならIE7Pro使うとか、ブラウザ問わずならProxomitron使うとか。Proxy自動設定スクリプト（proxy.pac）を使って弾くなんて方法も。
＃念の為、IPアドレス範囲が、じゃないですよ。ドメイン名で、という話。
★Acrobat Readerの環境設定（「インターネット」項目内）で「PDFをブラウザに表示」を無効にする。
これは脆弱性／攻撃対策としては全く役に立たないのだが、攻撃を受けたことを気づき易くする、という意味で有効。
というのは、Acrobatがブラウザ内部で起動する標準の設定では、かなりの確率で「実際に表示されている画面の裏側でAcrobatが起動」するため、攻撃を受けたことをユーザが気づかない、見落とす可能性が相当高い。
が、ブラウザ外で起動する設定の場合、Windowsの「後から起動したアプリが前面に表示される」の法則に従い、実際に攻撃を受けると「突然Acrobat Readerが起動する」というのが視覚的に確認出来る。
このため、自分が攻撃されたことに気づき易く、何より「攻撃されたことに永遠に気づかない」という最悪の事態を回避出来る可能性が高い。
◇
とまあ、以上つらつらと書いてみたり。
兎に角、皆さん気をつけて下さいね、ということで。
実際に感染してしまうとイロイロ大変ですよ～、念のため。
＃念の為、当方は攻撃は喰らったけど陥落＝感染はしていませんよ。
Tags: Gumbler
結局Google Apps側にメール統合ですか。
さて、以前「メール環境どうしよう」とウダウダと書いていたネタですが。
結局ローカルでの統合は諦め、Gmail側に旧メールをまとめてインポートすることにしましたよ。
ローカルでのIMAPやPOPはあくまでバックアップという感覚で、オンラインをメインに使おうといういうことですな。
＃にしても、不便極まりなかった「Webメール」の時代を知っている人間にとっちゃ、Gmailなんてまぁ（以下略。
ということで、以下作業記録。
理屈は簡単だが、実際の作業は割と手間がかかるんだ、コレが。
ちなみに以下の方法はWeMailに限らず、MH形式orそれに近い形式でメールを保持している全てのMUAで使えるテです、はい。
◇その1、正しいMH形式に整形する。
まず、WeMailのメール保存形式。
.wemという拡張子が付いていますが、これ要するにMH形式というヤツです。1メール1ファイル形式。
何故か未だにあちこちで使われてるmbox形式と比べて、圧倒的に分かり易く汎用性も高いフォーマット。
このため、拡張子の.wemを全て引っぺがして数字だけのファイルにすれば、Sylpheedをはじめ、大抵のMAUでざくっと取り込めます、はい。
まあ、一部ヘッダの文字コード絡みで問題が発生することも時々あるけど。
但し問題なのが、フォルダ構成。
大抵の人は階層管理していると思うのだが、インポート用にはこれをフラットにしないといけない。これ当然、ファイル名が衝突しますわな。
仕方ないので検索等を駆使して一カ所にまとめ、その後はお好きな連番改名ツールを使って通し番号に変更しますよ。タイムスタンプを見てくれるヤツだとちょっと嬉しい。
＃お気に入りの心当たりが無ければFlexible Renamerなんていかが。
◇その2、mbox形式に変換する。
次に、これらのメールをmboxに変換。面倒なのでIMAP用に日常使っているSylpheedにお任せ。
何故こんなことをするのかというと、SylpheedのIMAPで直接Gmailにアップロードすると、タイムスタンプがアップロードしたタイミングに書き換わってしまって、とても悲しいことになるんですな。
ところがThunderbirdのIMAP経由ではこの問題が発生しないため、わざわざThunderbirdが読み込める形式に変更してやる。と。
◇その3、mboxの中身をアップロードする。
出来上がったものをThunderbirdに読み込ませましょ。
インポートしてもいいが、簡単なのはユーザープロファイルの所にあるメールボックスの場所にmboxファイルを置いてからThunderbirdを起動する方法。
こうすると、勝手にmboxを読み込んでメール一覧に表示されます、はい。
後はIMAPのお約束。ローカルでメールの束をどかっと移動すると、するするするっとGmail側にアップロードされて、はい出来上がり。
ちなみに文字コードがS-JISなメールはThunderbirdにImportすると激しく文字化けすることが多いが、ほぼ確実にアップロード自体に問題は起こらないし、GMail上からもきちっと正しく読めるので、特に気にする必要はありません、えぇ。
但し、ThunderbirdのIMAPは正直Sylpheedと比べて圧倒的に遅い。
Sylpheedの軽快さに慣れてる人はウズウズしながら待つハメになりますな。
・・・以上。
結局5000通、100MBばかりアップロードしましたとさ。
取り敢えずアップロード直後にSylpheedでローカルキャッシュと同期しておいたし、まあこれで大丈夫だと思う、うん。
Tags: Google Apps
Google Sites Liberation を試してみる。
さて、googleネタが続きますが。
本日のターゲットは、Google SitesのImport／Export Tool。
＞http://code.google.com/p/google-sites-liberation/
これ何かというと、Google Sitesのバックアップ（Export）とリストア（Import）が出来るというシロモノ。
Google SitesのAPIを使うサンプルプログラムという位置づけでもあり。
jarなので、Java Runtimeが導入されている環境で試してみてね、と。
現状、1.01になっております。
まず、ダウンロード（Export）は、小規模サイトであれば特別問題は無いですな。
1,0の頃に問題があったらしい、日本語文字コードの問題も解消されている模様。
そもそもgoogle sitesで使っているcssが無いとレイアウトがガタガタになるという問題はあるものの、一応全てのサイト内容、添付ファイル等はダウンロード可能。
但し、ある程度の大きさのあるサイトではまともにDL出来ないという話が英語圏ではあちこちに出てきているので、現状ではホントに全部DL出来ているかの確認が必須の模様。
一方で、アップロード（Import）は・・・ダメですな。どう頑張っても全くImport出来ない。
こちらでは、ディレクトリ構造は再現されるが、ファイルは一つもアップロードされないという状態。
・・・ん～、まだまだですか。
取り敢えず、全くアップロードが出来ないというのはさすがにどうかと。
＃全く関係無いが・・・
ブラウザのキャッシュやCookieが壊れたり不整合起こしたりすると、Google Sitesって結構意外な、というか割ととんでもない挙動することがあるのね。
何か挙動がヘンだな～と思ったら、取り敢えずCookieとCacheを全消去は基本、ということで。
Tags: Google Apps
