バックドアとのつき合い方


1.はじめに

最近流行っているのか知りませんが、やたらと日本のサイトが攻撃を受けているようです。 Web の改竄にはじまり、ホストへの不正侵入・占拠等、DDoS による攻撃まで噂されています。 そこで、侵入・占拠された可能性が考えられるが定かでない状態の UNI*X ホスト上で、バックドアプログラムの有無を調べるための手法を考えてみました。

このメモは随時更新してゆきます。特にバックドアの除去に関して、もう少し詳しく書こうと考えています。
またこのメモが全ての状況で有用であるとは思いませんが、いくつかの場面には適用できるかもしれません。

このメモは RedHat 系の Linux を基本として説明されています。




2.システムの確認

バックドアプログラムがしかけられる程の状態だと、ログ関係も改竄または消去されていると考えるべきでしょう。

場合によっては rootkit をシステムに組み込まれたために、システムが常に虚偽の情報を出し続けるような状態にまで陥っている可能性も考えられます。このような状態になると、主要なシステムコマンドのバイナリが改竄され、たとえば ps コマンドや netstat コマンドがバックドアプロセスを隠すように書き換えられていたりします。

これはシステムの情報が全て信用出来ない状態であり、とても危険であると言えるでしょう。もちろん外見は通常を装います。システムは一見正常に運用を続けているかのように振る舞います。

よってこれから行う作業で使用する主要なシステムコマンド類は、動作中のシステム内部のバイナリを使用せず、他の正常なホストや、あらかじめ正常な状態のホストから、フロッピー等の外部メディアにコピーしておいた物を使用すべきです。

また rootkit が仕掛けられているか否かを調べるためのツールを利用するのも良い考えです。厳密には他のクリーンなOSから実行すべきかもしれませんが、とりあえず汚染されている環境化からでも、いくつかの重要なバイナリが改竄されていないか等を調べる事が可能です。
むろん、このツールの結果だけで満足しないでください。巧妙に仕掛けられたtorojanを検出するのは、如何に優れたエンジニアであっても難しいのです。自動化されたツールだけに頼るのは危険であることを心得てください。
http://www.chkrootkit.org/

不幸な事にこれらの準備がされていないホストに侵入されてしまったと思われる場合には、以下の手順に従ってシステムを確認してください。

それでもバックドアが発見できなかった場合は、残念ですがシステムの再構築を行うべきでしょう。そして、かならず厳重なセキュリティ的強化を施し、侵入を防ぎ、また侵入されても十分に対処できる環境を整えるよう努力してください。


2−1.ログとプロセスを確認
まずはじめに、システム上のログを確認します。

last・who コマンドでの出力結果、/var/log/messages・/var/log/secure・/var/log/xferlog 等を慎重に確認してください。

このサイトの他のメモにもあるように<まだ途中です>、不審な記録が残っていないか必ず確認します。すこしでも不審に感じたら、接続元や利用者に問い合わせます。


つぎに ps ax で現在稼働中のモジュール情報を参照します。

[root@matrix log]# ps ax
  PID TTY      STAT   TIME COMMAND
    1 ?        S      0:32 init [3]
    2 ?        SW     1:03 [kflushd]
    3 ?        SW     0:00 [kpiod]
    4 ?        SW     0:18 [kswapd]
    5 ?        SW     0:00 [mdrecoveryd]
  261 ?        S     17:51 syslogd -r -m 0
  272 ?        S      0:01 klogd
  286 ?        S      0:03 crond
  292 ?        S      0:00 /usr/local/bin/supervise /usr/local/etc/ftpd
  293 ?        S      0:00 /usr/local/bin/supervise /usr/local/etc/pop3d
  297 ?        S      0:00 tcpserver -HRc 12 xxx.xxx.xxx.xxx 21 /usr/sbin/in.ftpd -l -a
  298 ?        S      2:34 tcpserver -HRc 50 xxx.xxx.xxx.xxx 110 /usr/sbin/in.pop3d
  318 ?        S      2:50 /usr/local/sbin/sshd
  383 ?        S      1:21 httpd
  445 ?        S      2:20 perl /usr/local/bin/watcher2
  496 tty1     S      0:00 /sbin/mingetty tty1
  497 tty2     S      0:00 /sbin/mingetty tty2
  498 tty3     S      0:00 /sbin/mingetty tty3
 8981 ?        S      3:51 sendmail: accepting connections on port 25
31152 ?        S     14:51 named
 4748 ?        S      0:03 httpd
 4749 ?        S      0:03 httpd
 4826 ?        S      0:04 httpd
 5561 ?        S      0:00 /usr/sbin/in.pop3d
 5564 ?        S      0:00 httpd
 5573 ?        S      0:00 httpd
 5574 ?        S      0:00 httpd
 5575 ?        S      0:00 httpd
 5587 pts/1    R      0:00 ps ax
不審なモジュールは動作していませんか?また、inetd や syslogd などの重要なモジュールが複数動作していたり、httpd のような複数動作しているモジュールの中で妙に TIME 情報の長いものが無いか等注意してください。


2−2.ネットワークの状態を確認
また netstat -n で現在のコネクション情報を確認します。

Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0    198 210.253.169.19:80       xxx.xxx.225.193:3160    ESTABLISHED
tcp        0  58400 210.253.169.19:80       xxx.xxx.225.193:3159    ESTABLISHED
tcp        0      0 210.253.169.19:80       xxx.xxx.230.58:3154     TIME_WAIT
tcp        0      0 210.253.169.19:80       xxx.xxx.101.167:1746    ESTABLISHED
tcp        0    588 210.253.169.19:22       xxx.xxx.45.143:955      ESTABLISHED
tcp        0   5117 210.253.169.19:80       xxx.xxx.192.115:60428   FIN_WAIT1

Local Address に不審なホストとポートが記録されてはいないでしょうか?


さらに netstat -ln で現在のリスンポート情報を確認します。

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 210.253.169.19:53       0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
tcp        0      0 210.253.169.19:110      0.0.0.0:*               LISTEN
tcp        0      0 210.253.169.19:21       0.0.0.0:*               LISTEN
udp        0      0 0.0.0.0:4067            0.0.0.0:*
udp        0      0 210.253.169.19:53       0.0.0.0:*
udp        0      0 127.0.0.1:53            0.0.0.0:*
udp        0      0 210.253.169.19:123      0.0.0.0:*
udp        0      0 127.0.0.1:123           0.0.0.0:*
udp        0      0 0.0.0.0:123             0.0.0.0:*
udp        0      0 0.0.0.0:514             0.0.0.0:*

運用している覚えの無いポートが発見されたら以下のコマンドでオーナープロセスを調べましょう。

fuser -vn

たとえば、こんなカンジで表示されますので、COMMANDとPIDおよびUSERを確認して、それが正しいのか否かを判断します。
[root@hoge]# fuser -vn udp 4067

                     USER        PID ACCESS COMMAND
4067/udp             root      31152 f....  named
これらの確認は普段からシステムの運用状況を注意深く観察して、動作中のプロセスや利用ポート等を書き留めておくと、このような状況下において非常に役立ちます。


2−3.設定ファイル等の確認
システムの主要な設定ファイルを確認しましょう。

/etc/inetd.confファイルを確認して、不自然なエントリが追加されていないか確認しましょう。ファイルの最後尾に追加されている場合が多いようです。

/etc/passwdファイルを確認して、不自然なエントリが追加されていないか確認しましょう。

/etc/rc.d/rc.localファイルで記憶に無いプログラム等を起動していないか確認しましょう。

/etc/rc.d/init.dディレクトリを確認して、タイムスタンプが妙に新しい物等が無いか確認します。同様に/etc/rc.d/rc*.dの全てのディレクトリ内の起動スクリプトを注意深く観察してください。

/etc/crontabファイルと/etc/cron.dディレクトリも同様に確認します。


2−4.バックドアのバイナリを探す
これは実に骨の折れる作業です。ディスク内を片っ端から探す以外に方法がありません。

RedHat 系のような rpm ベースによりシステムの構成パッケージが管理されている場合には、以下の方法でパッケージの整合性を確認することが可能です。

この整合性チェックでは、なにも変更が無かった場合にはなにも表示されませんので、表示されたファイルについてはなんらかの変更があったと考えられます。もちろんシステムの設定ファイルは構築時に変更されることが前提ですから、このチェックで不整合になります。ここではシステムのバイナリが不整合として表示された場合に改竄されている可能性があると見なされます。
[root@VooDoo ruby]# rpm -Va
S.5....T c /etc/printcap
S.5....T c /etc/securetty
S.5....T c /etc/services
S.5....T c /etc/termcap
以下略
もちろん、rpm コマンドそのものが改竄されていたり、パッケージ情報そのものが改竄されている可能性も考えられるので、ひとつの手段程度に考えた方が良いでしょう。


またこちらの方が基本的でしょうが、 find コマンドに検索パラメータを指定することにより、不審なファイル・ディレクトリ等を探し出す方法も良いでしょう。使用方法がよくわからなければ、以下の使用例を参考にしてください。

<FILE>のファイル、ディレクトリを探す。
find / -name <FILE> -print

先頭が「.」(ドット)で始まるファイルやディレクトリを探す。
find / -name '..'* -print
find / -name '.'* -print

rootでsetUIDされたファイルを探す。
find / -user root -perm -4000 -ls

<NN>日前に日に変更されたファイルを探す。1,2,3と段階的に行うと良い。
find / -mtime <NN>

所有者の無いファイルを探す。
find / -nouser
表示されたファイルが例えば /dev や /sbin 、/boot などの通常であれば手を触れるはずのないディレクトリ内などに存在していた場合は注意しましょう。また /tmp 、/usr/doc 配下などにも良く隠されます。

多くの場合、これらのバイナリは見つからないように隠されていますので、.(ドット)付きのディレクトリなどに注意してください。過去何日かで変更のあったファイルをリストアップして調べてみても良いでしょう。またシステムコマンドのバイナリが書き換えられている可能性も考えられます。


やはり普段から Tripwire などでシステムの整合性をチェックできるようにしておくと、このような場合に役立ちます。

探し当てるのはそう簡単では無いでしょう。適当なところで見切りをつけて、次のステップに進みましょう。



3.ツールを利用して探し出す

このステップでは、ネットワーク上からバックドアを探し出せるか試してみましょう。

ここのステップではプログラムのコンパイル等の作業が伴います。もしもシステムに開発環境が整備されていない場合は、このステップを飛ばして直ちにシステムの再構築を検討してください。

まず iplog で記録サルになる を参考に iplog をインストールしてください。

つぎに何日かiplogを運用します。この期間は特にホストのコンソール等に注意していてください。侵入者にログを消去される恐れがあります。可能であれば syslog 転送などの方法で他のホストにログを転送することを検討してください。

もしもバックドアが仕掛けられていれば、そのうち iplog が興味深いメッセージを記録してくれます。

不自然なポートに対して、不自然なネットワークからアクセスがある。
不自然なポートへのUDPへのセッションが異常な回数検出される。
icmpが異常な回数検出される。

以上のような記録が観察されるかもしれません。その他にも、海外や普通なら繋げてくる事が考えられないネットワークからのセッション等にも注意してください。

また、他ネットワークへのポートスキャンなど、バックドアから侵入してきた者が外部のネットワークと何らかの通信を行う可能性もあります。これらの記録もきっと検出されることでしょう。

如何でしょうか?不審な通信記録は検出されましたか?

もしも検出されたら、その通信内容を傍受して、本当にバックドアなのか調べると良いでしょう。

テキストベースの通信を傍受してくれるスニファを使用して、バックドアが動作しているポートを監視すれば、通信内容からどのような行為がされているか、ある程度の検討を付けることが可能です。

このツールに関しては取り扱いが難しいので、自分で情報を探し出せる人だけが行った方が良いでしょう。

UDPやICMPでバックドアが仕掛けられている場合は今のところ良い方法が思いつきません。他にも暗号化されている場合なども困難です。

また数日注意しつつ運用してください。なにか記録されましたか?


もしも他にコンピュータを所有しているのであれば、本コンピュータに対してポートスキャンをかけてみるのも良い方法です。

この場合、nmap のように UDP スキャンまでかけられるポートスキャナを使用して、全てのポートにスキャンを行ってください。不自然なポートが開いていないでしょうか? netstat コマンドとの出力結果と矛盾は無いでしょうか?

またいっそのこと、そのコンピュータでネットワークをスニッフィングするのも良いかもしれません。
あなたがそのネットワークの管理者で無い限りは取るべき手段では無いでしょうけど。


このステップでも何も検出されなかった場合には、かなり高度なバックドアが仕掛けられているか、または単なる気のせいの何れかでしょう。

これ以上時間を浪費するよりは、システムの再構築を行った方が遙かに効率的です。




4.バックドアを見つけたら

では運悪くバックドアが自分のシステムに仕掛けられている事を発見してしまった場合はどうしたら良いでしょうか?

バックドアが見つかろうが見つかるまいが、仕掛けられているらしいと感じたら、システムの再構築です。教科書どおりの発言ですね。かならず最新のパッチを当てたシステムで運用しましょう。そして毎日メンテナンスを欠かさないよう注意してください。

どうしても再インストールしたくない管理者の方は、あらゆる手段を使ってバックドアを探し出し、排除してください。ただし、そこまで発見に苦労するようなバックドアが仕掛けられている場合は、あなたの手に負えない相手だと考えた方が良いです。

簡単にあしらえるような相手なら、システム乗っ取られたりしないでしょ?

探し出すポイントとしては「システムの起動プロセスをひとつずつ全部追ってみる」でしょうか。

RedHat系のLinuxであれば、rc*.d ディレクトリ配下を見れば自分のシステムで何が動作しているべきか容易に解ります。そこで、いったんシングルモードで起動して、先に出てきた ps や netstat による情報に注意しながら、rc*.d ディレクトリ内で実行しているプロセスを一つずつ起動してゆきます。

おそらく見つかるのではないでしょうか?見つからなかったら、やっぱり再構築してください。



本メモを作成するにあたり、さまざまなアドバイスを下さった方々に感謝いたします。