2006年9月19日

[users 6818] Re: ハッキングされてしまったのですが(もしも、ホスティングなら)


 こんばんは、前佛です。
 先ほどは急ぎで書かなかった事があるので補足させてください。

> > 困ったことにrootでログインしているのですが、ディレクトリの
> > パーミッションが変更できません。
> > 全てというわけではないのですが、/usr/sbin の属性変更が
> > できません。つまり、何もソフトがインストールできない状態です。


 少し気になったことがあります。まず、どのようなネットワーク形態
でインターネットに接続されているのかを記述されたほうが的確なアド
バイスを受けられたかもしれません。

 というのは、既にみなさんから返信がありますが、おそらく社内サー
バもしくは直接データセンターに出入りが可能な場合を前提にかかれて
いたと思われました。

 仮にホスティングやハウジング(このあたり広義のレンタルサーバと
させて下さい)でリモートによる遠隔操作しかできない場合であれば、
対処方法は異なってきます。

 以下、私のホスティング業サポート経験から、もしホスティングで不
正アクセスを受けてしまったら?というケースのアドバイス(といった
おおそれたものではありませんが・・・)。

●まずは業者に連絡を

 業者にもよると思いますが、不正アクセスを受けた状態(ユーザによ
る自己申請・他ネットワーク管理者からの通告・自社システム上での以
上検出)では、基本的に"そのまま放置"はありえないと思います。

 不正アクセス発覚後、利用者として出来ることはとにかくネットワー
クから切り離すことが最優先です。/sbin/ifconfig が書き換えられて
ネットワークを落とせない場合は、業者に事情を説明して LAN ケーブ
ルを抜くか上位機器でパケットを落としてもらいましょう。

 うっかり shutdown しそうにもなりますが、/sbin/init や
/etc/rc.d/rc.sysinit rc.local あたりに細工されて、起動しようと思っ
ても起動できなくなってしまう=復旧に余計時間がかかってしまうとい
う事態にもなりかねません。

 まず切り離しておけば侵入者は何もできませんし、自サーバを踏み台
にして、他の利用者(回線を共有している場合は特に)に迷惑をかけず
にすみます。

●復旧作業の前にするべきこと

 リモート作業前に自分が気がついた事を業者に伝えて、とにかく要望
を伝えましょう。まず、連絡をとって、救済措置(代替サーバの準備や
仮ページ準備)の有無の確認などです。

 業者によっては無償でこのあたりの対応を柔軟にしてくれる所もあり
ますので、とりあえず相談してみることをおすすめします。復旧が有償
となってしまう場合もあり得ます。

(このあたり、もしホスティング・サービスをご利用でしたら、事態収
束後に業者さんと細かく詰めておいたほうがいいと思います。)

 一番簡単なのは予備のサーバがあれば、仮に HTTP サーバだけ復旧さ
せて工事中の旨の表示ですね。あとは顧客向けにメンテナンス報告の表
示と連絡先の記入。

 もし Apache なら httpd.conf に

ErrorDocument 404 /

 や

ErrorDocument 404 http://example.jp/info.html

 のようにして、"File Not Found" の表示を避けて、表面上ただの緊
急メンテナンスを装うこともできます。

 MTA は停止させたほうがいいでしょう(User Unknown のメールが発
生して、大切な業務メールを失うかもしれません。)。

 あとは他の方もかかれてる通り、SSH など、対策は割愛させて下さい。


 以降はホスティングや自社内でも対応は同じでしょう。

●復旧が終わったら、不正アクセス原因の把握を

 復旧作業後、ログがもし残っているなら /var/log 以下のログや、
/tmp 配下に変なファイルが無いかや、find / -atime 1 (24時間以内に
アクセスされたファイルの一覧表示、詳しくは man find)である程度調
査できるでしょう。/root/.bash_history も運良く残っていれば、どの
ような攻撃や仕掛けを行ったか把握できるようになります。

 例外:rootkit といって linux kernel レベルでプロセスを隠してし
    まうようなものもあります。一段落した後、サーバを再起動し
    ても見た目は問題なくても、プロセスが隠れていたり色々ある
    ので、可能な限り状況を把握しておくことは大切だと思います。

 ログに残らない厄介な例としては XSS です。CGI のプログラミング
ミスや PHP のバージョンアップを忘れていたり、適切なパーミッショ
ンを設定していなかったりすると、OS を入れ直しても再度進入を受け
てしまう可能性はあります。

●最後に復旧手順のマニュアル化を

 不正アクセスは滅多にない事なので、上司への報告といった堅い意味
ではなく、ハードディスク障害など、不測の事態に備えた対策や、再度
不正アクセスを受けないためにも記録を残しておくべきです。

 余裕が出来てきたら、もっと効率的な復旧方法を考えるのも手ですね。
 ホスティング業者であれば対応の善し悪しによって会社を変えるのも
やむを得ないでしょう。費用を優先するか、危険(リスク)を優先する
か、なかなか両立がむずかしいですが。。。

 ・・・ご参考になれば幸いです。

--
前佛 雅人(Zembutsu Masato) zem@xxxxx
Pocketstudio.jp Linux Wiki http://pocketstudio.jp/linux/
GPG Key: 0xF093EC1D
GPG Fingerprint: 657B D1B3 7E4F E13B 8653 6E7C AF8D 3D55 F093 EC1D

_______________________________________________
users mailing list
投稿先アドレス: mailto:users@xxxxx
総合案内: http://fedora.jp/mailman/listinfo/users
過去の投稿の検索: http://fedora.jp/kabayaki/

投稿者 xml-rpc : 2006年9月19日 21:58
役に立ちました?:
過去のフィードバック 平均:(0) 総合:(0) 投票回数:(0)
本記事へのTrackback: http://hoop.euqset.org/blog/mt-tb2006.cgi/46094
トラックバック
コメント
コメントする




画像の中に見える文字を入力してください。