「クラックされたり!」「しからば、いざゆかん」 119
ストーリー by wakatono
インシデントレスポンスの実例求む 部門より
インシデントレスポンスの実例求む 部門より
昨今のクラック騒ぎだが、名も知らぬ方から一石投じられた。"昨近、もじら組やNamazu.org、 ruby-langといったオープンソース開発サイトのクラックが話題になっている (/.J過去記事(もじら組、namazu.org ruby-lang.org)。 されないに越した事はないし、運営者、利用者の自己責任論もあるが、ここにアクセスされている皆さんには、「その次」の行動を起こすべき(業務か、あるいは義務感のみかを問わず)立場の方々も多いことと推察する。
ここで/.Jの諸賢に尋ねたいが、「クラックされてたぞ!」の次のアクション は(どうする|どうしてきた|どうあるべき)だろうか。
…「お客様」にいえないような忌憚無い論議を期待したい。"
これまたストレートな問いかけだが、インシデントレスポンスをどう考え、実践し、というのはシステム管理者やネットワーク管理者の関心事の1つだというのもまた事実だ。みなさんはこのあたりどうしてる?
中間管理職ブルース (スコア:5, おもしろおかしい)
最初にポートスキャンしたらAnonymous FTPと化していたようなのでさっそくお宝DVDを探す、のをぐっとこらえてPhotoshopから先に探す、という同僚を追いやって、Windowsマシンに向かって今後はtripwireくらい入れようという手順書を、初歩の初歩から手取り足取り解説付きで夜なべして作る。前任者は誰だよ、と少し頭にくるが、直属の上司がまさにその人だったのを思い出す。冷房も切れた部屋で額に汗すること2、3時間。終電はもう出て行ってしまった。サーバに触ることさえ禁じられたまま、やっちまったどうしようと青い顔をして突っ立っている管理者に、昔話のひとつやふたつ披露して緊張をほぐしてやろうとするが、上の空であまり聞いてはもらえない。コーヒー休憩だとふと見上げると時計は3時半を指していた。外に行くのも面倒だが、なんだか気詰まりがしてここにいるのも苦痛だ。そう思うと余計に暑い。
わざわざ表紙もつけた手順書がようやく出来上がるが、こんなときに限って紙が切れている。ストックの包み紙を破ると手に汗をかいているので用心しながら中身を取り出し、トレーに紙束を突っ込んで印刷したら、管理者君におごそかに手渡す。さっと隠していたが、こいつ、こっそり子供の写真を見てやがった。確か下の子が生まれたばっかりだったよな。
四時半。帰った方がいいのか、それともこのまま書類でも片付けていた方が面倒がないのだろうか。なんだかもう判断力が残っていない。外も少し明るくなってきた。お客さんに「どうも最近OSが不安定なのでリプレースしたい」ともっともらしく説明できるように夜明けの洗面所で顔の筋肉を鍛えるとするか。最近オッサン臭くなったと娘はいう。
Re:中間管理職ブルース (スコア:1)
でもね、他にやることあるでしょ。>> 中間管理職
こんな管理職にはなりたくないなぁ。
通報 (スコア:3, 興味深い)
ないだろうなぁ
やなぎ
字面じゃなく論旨を読もう。モデレートはそれからだ
Re:通報 (スコア:2, 興味深い)
Re:通報 (スコア:3, 参考になる)
その後、どこで扱っていいのかわからなくなったところでたらいまわし。そして調書作成という名の下に、一日ほど拘束されます。
マシンは数ヵ月後に戻ってきますが、その頃にはすでに他のマシンで動かしているのでまったく意味がありませんでした。
ちなみに、ハードディスクは検証に入る前に完全にコピーされるので、元のハードディスクの中のデータは破壊されることもありませんでした。
過去の経験 (スコア:3, 参考になる)
ちょっと具体的に書くと長くなるのですが、あるシステムに潜在的な脆弱性があり、その脆弱性を突かれたか?と思われる事態が発生したので通知したのですが、その ML にはシステムを利用していないスポンサー的な立場の人間も居て一悶着起こしてしまいました。。。
#つーか、基本的に関係ない人を ML に入れておく意味はなんだったのだ。。。
そのときはバカ正直に通知した私が怒られておしまいでした。システム開発の人は脆弱性を認識しているけどコストの関係でその実装になっているんだよ、と私に同情的でした。でも、通知先を確認しなかった自分が悪かったんだなぁと学習できました。
そのシステムは商用のものじゃなくて実験的な期間限定のものだったので、明確で大規模な問題とならない場合はコストの問題でどうしようもなかった感じでした。その後は疎遠になったので現状は知りませんが。
基本は掲示板系だったのでサーバそのもののクラックなどの話じゃないのですが、個人情報に関する問題が出る可能性を考慮しての行動だったのですが、思わぬところに落とし穴、という例でした。
talkでお話しするとか… (スコア:3, おもしろおかしい)
言ってみたかっただけです…。
管理者でもなんでもないけどID。
----
:oすずめのおやどはどこじゃろぉ
('>ぴよぴよ
Re:talkでお話しするとか… (スコア:4, 興味深い)
80年代の管理者と侵入者はそういう関係が多少
あったらしいですね。
侵入者と管理者の微妙な友好関係。管理者よりも侵入者の方が
よっぽどシステムに詳しいから色々と役立つ。
多少の不正利用……数十キロのファイル置き場を
あげるとか、アカウントをそのままにしておくとか……を
許してあげると、逆に侵入者はホストの管理を手伝ってくれる。
管理者にとっては仕事だけど、侵入者はハッカーで
システムを愛してるから親切丁寧に面倒見てくれる(笑
別のクラッカーの侵入を防いでくれたり(苦笑
やなぎ
字面じゃなく論旨を読もう。モデレートはそれからだ
Re:talkでお話しするとか… (スコア:1)
なんのひねりもないのですけれど (スコア:3, すばらしい洞察)
一番困るのは、発見まで時間がかかるような手法でクラックされること。
幸か不幸か、いままで「ログインしたらすぐに分かった」程度のクラックしか見たことがありませんが。
逆上して報復はしないように、CD-Rに信頼できるバイナリを用意しておくのがここでの嗜み。
>「お客様」にいえないような忌憚無い論議を期待したい。
仕事でやっている場合、そういうのは困るのです。
とりあえず、ハードウェア障害にしておく、と(おぃ
Re:なんのひねりもないのですけれど (スコア:1)
やたらハードウェア障害が頻発するような
無料ウェブスペース領域サービスなんていうところは
しょちゅう入られているのかなあ?
そういうのって、無料だから責任なんて曖昧だし
どうせ・・・とか言われるのがおちなんだろうか。
やっぱり少しぐらいのお金を払ってホームページを
作るべきなんだろう。。。
まずはケーブルを引っこ抜く。 (スコア:2, 参考になる)
#バカ防止だけなのでAC
Re:まずはケーブルを引っこ抜く。 (スコア:3, おもしろおかしい)
#ケータイの電源もお忘れなく。
Re:まずはケーブルを引っこ抜く。 (スコア:1)
身近にあって一番危険な物 = 電波。
もちろん、精神衛生上よろしくないという意味です。
#学生の身で障害対応に追われている私……。
Re:まずはケーブルを引っこ抜く。 (スコア:1)
うちのサーバーは28.8Kで外と繋がってるので(嘘)。
タイトルの元ネタがよくわからないんですが、 (スコア:2, おもしろおかしい)
#激しくオフトピ
RPM系Linuxの場合 (スコア:2, 参考になる)
ネットワークの無効化
# /etc/init.d/network stop
ログを保存
# tar zcvf /mnt/usb-hdd/log.tar.gz /var/log
変なユーザを探す
# who
変なプロセスを探す
# top
バックグラウンドでrpm監査コマンドを実行
# rpm -Va > /tmp/valid.txt 2> /dev/null &
rpmの監査が終わるまでsyslogの中身を読む
# lv /var/log/messages
rpm監査コマンドの結果を見る
# lv /tmp/valid.txt
ほか何かある?
Re:RPM系Linuxの場合 (スコア:2, 参考になる)
この程度で痕跡見つかる程度なら、たいしたことはないと思う。
もちろんやるべきことではあるが。
でも、まずはその前にchkrootkit。仕込んでればtripwire。
信用できるソースから管理系コマンドを再インストール。
侵入された後のホストのコマンドの出力なんて信じられるわけがない。
Re:RPM系Linuxの場合 (スコア:1)
log関係は、あてにならないので、procを
直接覗いて変な物動いてないか確認した
良いんじゃないかと思います。
romfffromのコメント設定
AC-2、プラスモデ+3、閾値0、スコアを表示しない(推奨)、高い評価のコメントを親にする
Re:RPM系Linuxの場合 (スコア:1, 参考になる)
システムコールをトラップしてるのでps, topとかlsとか役に立ちません。ネットワークケーブルを抜くくらいでは不十分。電源ケーブル抜いて、クリーンなOSでディスクをマウントしてファイルが改竄/追加されてないかチェックしなければ意味がありません。
kernel level rootkitどう作るか知りたい人はサンプルはネットで探してみて下さい。ありますから。
では、「やってはいけないこと」は何? (スコア:2, 興味深い)
では逆に「これだけは、やっちゃいけない」ことってありますか?
# 門外漢なので聞いてみるだけしか出来ませんが
*-----------------------*
-- ウソ八百検索エンジン --
Re:では、「やってはいけないこと」は何? (スコア:2, おもしろおかしい)
……頼むから帰ってきて。
Re:では、「やってはいけないこと」は何? (スコア:2, おもしろおかしい)
「上司、同僚にたとえ事実であってもありのままに報告するだけで放置すること」
「たとえ感染元や踏み台が上司や同僚の管理していた機器であっても
それを他人の面前で明らかにすること」
「通ぶってホイッスルブロアーや他人のせいにすること」
やってほしい事「上司、同僚に判る様に 以下の事を説明する」
1.落ち着いて行動するようにお願いすること
2.上司にこの災いをチャンスとして更なる予算や権力、最新機器を分捕れる
はずなので、協力してほしいと頼むこと
3.ウイルスとかいってもプログラムであって、人間に感染するものではないことを判るように説明すること。(-_-;)
#マジに書いてしまった orz
Re:では、「やってはいけないこと」は何? (スコア:1, おもしろおかしい)
隣の課の人がいきなり「ウィルスだっ!」と叫んで大騒ぎになったことがあります。
…血液の診断関係の機械作ってる部署だったもんで、そりゃもう大騒ぎに。。。
Re:では、「やってはいけないこと」は何? (スコア:2, おもしろおかしい)
「ウィルスだ!急いでケーブルを引っこ抜け!」
慌てたネットワーク担当がそう叫んだ次の瞬間、
ブチッ、ヒュ~ウゥン…
なぜか聞いてはいけないはずの音に続いて急に静かになった。
焦りながら振り向くと、PCの知識が乏しい年配のお偉方が
「これでええのか?」
と言いながら手に持ってるのは3Pプラグの黒いケーブルだった…
#ネタのつもりだけど、本当に有りそうで怖いなぁ…
腐乱化…もといFlanker
マジですか? (スコア:1)
じゃ、やっぱり「絶対サポセン…」に投稿して(をぃ)
PCの知識に乏しい年配の上司が一番危ないのはどこでも一緒みたいですね。
腐乱化…もといFlanker
Re:では、「やってはいけないこと」は何? (スコア:1)
そして本体側のケーブルが抜かれる...
Re:では、「やってはいけないこと」は何? (スコア:2, 参考になる)
crackされた後、一度でもパスワードを打ったマシンを再びネットワークに繋ぐ事。
たとえ他のマシン全てのパスワードを違うものにしていて、しかもランダムで生成したパスワードだとしても、一つ漏れてしまえばパスワードで用いている字種、長さ、クセなどから類推されてしまう可能性が格段に高くなる。
日頃からメンテナンスなどでリモートログインする時も、パスワードで認証するのではなく、sshのshared key認証でログインするようにした方が安全。
そういう意味では、一般に言われている「一般ユーザでログインしてsuすべし」というのもインターネットに公開されたサーバでは危険を伴う。
「一般ユーザでログインしてsuする」というのは、正規ユーザによる悪意の行為が行われた場合に誰がやったのかを識別できる利点はあるが、それもログが改竄されていない事が前提だし、昨今のインターネットに接続されたサーバではシェルアカウントを持つ正規ユーザが大量にいるという状況も少ないので、あまりメリットは無い。
逆にsuできる一般ユーザアカウントをクラックされて、suする時のキーストロークをロギングされてしまう事によってrootパスワードが漏出してしまう可能性もある。
より安全なのは、インターネット上に(暗号化されているか否かを問わず)一切パスワードを流さない事。
そのためにもshared keyなどを利用してパスワードを使わない運用体制を作るのが良い。
shared keyで直にrootでログインするよりも、安全性が保証できないマシン上でrootパスワードを打つ方がより危険度は高い。
パスワードはあくまでも簡便な認証の一手段であって、安全性はそれ程高くないという事を認識すべき。
Re:では、「やってはいけないこと」は何? (スコア:1)
オンラインな状態にしておく事だと思います。
(もちろん、構成により、のっとられたまんま
のほうがましな場合もあるかと思いますが)
ま、動いてるサービスにより、臨機応変な
対応が必要だと思います。
romfffromのコメント設定
AC-2、プラスモデ+3、閾値0、スコアを表示しない(推奨)、高い評価のコメントを親にする
Re:では、「やってはいけないこと」は何? (スコア:1, 参考になる)
Re:では、「やってはいけないこと」は何? (スコア:1)
Re:では、「やってはいけないこと」は何? (スコア:1, 参考になる)
まったく同じ設定状態に復旧
警視庁 ハイテク犯罪対策総合センターによると (スコア:2, 参考になる)
http://www.keishicho.metro.tokyo.jp/haiteku/haiteku/haiteku34.htm
1. 被害拡大の防止(ネットワークから切断)
2. 被害状況の保全(ログ・設定ファイルを保存)
3. 警察へ通報
とありますから、これでよいのでは。
もし、通報することで警察への対応に時間が取られるのなら、
その前におおまかな調査と被害範囲の確定、代替機によるサービスの暫定復旧、
といったことまで済ませておかなきゃいけないかもしれませんが。
そして一段落したら、詳細な報告書の作成と、再発を防ぐための対応策の検討。
外部への告知は他部署に任せます。
事後処理の最後は「クラックされちゃいました記念宴会」で締めたいですね。
管理者としての一生のうちにそう何度も経験できるものではないので(と思いたい)。
Re:警視庁 ハイテク犯罪対策総合センターによると (スコア:2, おもしろおかしい)
>ないので(と思いたい)。
と思いたかった。.... orz
まずは、システム切り替えだろうな (スコア:1)
バックボーンなどの都合で実際データセンターなんかに入っていたら
そこの管理者に連絡して、システムを切りかえるなり
リスク対応に沿った作業をするしかないかな
当たり前過ぎだが、これしか思いつかん
#だって、だって 今日ラックから煙が出たんだ・・・・マジな話
Re:まずは、システム切り替えだろうな (スコア:1)
全てのバックドアを削除するのは可能? (スコア:1)
実行するしか削除する術をしらないのですが、
世の中には全てのバックドアを検知して、
削除するツールもしくは、方法などがあるのでしょうか?
romfffromのコメント設定
AC-2、プラスモデ+3、閾値0、スコアを表示しない(推奨)、高い評価のコメントを親にする
たらいまわし (スコア:1)
まぁ、普通に考えたら、まずシャットダウンかケーブル抜くでしょうね。
# 内輪用だからこそできる技かも
止められないサーバーの場合を考えると、涙が出そうです。
Re:たらいまわし (スコア:2, 参考になる)
その後、chkrootkit して、入れ替えられたコマンド類(ps,netstat,ls,etc...)のバイナリを入れ替えて調査開始。
ですかね。
Re:たらいまわし (スコア:2, おもしろおかしい)
「あっ、LANケーブルを抜いて逃げ場を無くしたのに、侵入者がいなくなってる( ̄□ ̄;)
くそーどっかにセキュリティホールを造って逃げやがったな( ̄□ ̄;)」
# 激しく用語間違い(笑)
LANケーブル抜けない場合 (スコア:1, 興味深い)
LANケーブルを抜くという意見が多数のようですが、
遠くのデータセンターでリモートでしかサーバーに入れない場合や保守回線が無い場合って、どーするんですか?
ssh以外落とすということもありえそうですが、sshが穴な可能性もあるわけで。
Re:LANケーブル抜けない場合 (スコア:2, すばらしい洞察)
「おまえ、行って来い」
#電車で1時間以内の所しか保守したことありませんが
Re:LANケーブル抜けない場合 (スコア:2, おもしろおかしい)
ハワイとか、オーストラリアとか、西海岸とか。
データセンター通いが楽しくなります。
上司にその権利をとられないように気をつけましょう。
そして、決してアラスカにあるデータセンターを利用しないように気をつけましょう。
「おまえは、アラスカ行きだ~」
帰ってこれなくなります。
Re:LANケーブル抜けない場合 (スコア:1, おもしろおかしい)
まずは (スコア:1, おもしろおかしい)
まだ出てないので (スコア:1)
万が一漏れていることがあれば被害範囲の確認、記者会見の準備、
そして人数分の500円を......
......しかし、かつては500円払えば有名な猫さんに、質問に
答えてもらえたり面白い話をきけたりしたというのになあ。
#あえてリンクをはらないでネタをふってみる。
Re:ぬるすぎ (スコア:1)
他の装置への被害が広がるから、
ケーブル抜くんじゃないの?
クリーンにする為には基本的に
再インストールしか方法はないんだから。
romfffromのコメント設定
AC-2、プラスモデ+3、閾値0、スコアを表示しない(推奨)、高い評価のコメントを親にする
Re:ぬるすぎ (スコア:1, すばらしい洞察)
で?ケーブルを抜かないことより問題が大きいとでも?
#他人のことを考えない管理者にはなりたくない。。。
Re:ぬるすぎ (スコア:2, 参考になる)
マシンやディスクそのものが壊れるリスクもありますが、
どちらかというと電源ケーブルを抜くという方を支持したいです。
ネットワークから切り離しに成功した後でも、
侵入されたことが明らかな場合、リカバリやバックアップを含めてそのマシン上で作業することは
やってはいけないことの一つだと考えられます。
#既に破壊プロセスが動いていたり
#コマンドを書き換えられている可能性も捨て切れませんので。
その後ディスクを引っこ抜いて物理的な方法でミラーを取り、
安全なマシンにマウントしてチェックでしょうか。
#似たような事例を昨年の情報セキュアドの問題で見たような気がします。
[]_g@
Re:ぬるすぎ (スコア:1, すばらしい洞察)
困るといいたいのですよ