Projects‎ > ‎Information Security‎ > ‎Honeypot‎ > ‎Whitepapers‎ > ‎

enemy2

Know Your Enemy: II 
Tracking the blackhat's moves

Honeynet Project 
http://project.honeynet.org 

Last Modified: June 18, 2001
Translated by SHIBUYA Yoshihiro (Self-Defence Force)
Original document is here

この記事は第2シリーズである。最初の記事(Know Your Enemy)では、スクリプトキディのツール及び手口について言及した。特に、どのように脆弱性を発見し、攻撃するかをである。第3シリーズではスクリプトキディが管理者権限を奪取した際、何をするか、特にどのような痕跡を残し、次に何をするのかを言及する。ここ(第2シリーズ)では、彼らの動作をどのように記録するかを言及する。ちょうど軍隊と同じように、あなたは悪い人間を記録し、何をしているか知りたいであろう。われわれはログで記録することができること、できないことについて言及する。あなたは侵入され、改ざんされ、どのツールが使われたか、そして侵入者の成功を知ることができる。ここではLinuxを例に取るが、たいていのUNIXシステムでも同じことが言える。それでももし心配なら、どうしようもない。しかし、この記事はスタートするのに適している。

Securing Your Logs 
この記事は素晴しいソースを持ったIDSの話ではない。もしあなたがIDSに興味があるなら、Network Flight Recordersnortを参照することを勧める。この記事は効率よく情報を集めることに焦点を置く。あなたはログの中にいかに多くの情報があることに驚くであろう。しかし、ログを語る前に、システムログを保護することについて議論しなければならない。もし内容を信用しないのであれば、ログも価値の無いものになる。たいていのクラッカーが最初にすることは、侵入したシステムを改ざんすることである。ログから痕跡を消すルートキットは様々なものがあり(cloakのように)、また、ログを改ざんするものもある(トロイの木馬のようなもの)。したがって、最初のステップとしてログを見直すことがログを保護することになるのである。

これは、リモートログサーバが必要なことを意味する。あなたのシステムがどのようなセキュリティを施しているかにかかわらず、侵入されたあとのログを信じてはいけない。もしすることがなければ、クラッカーはrm -rf /* として、ハードディスクをフォーマットしてしまうこともできる。こうなったらログを元に戻すことはいささか難しくなる。こうなると、システム中のあらゆる(ローカル、ネットワーク問わず)ログサーバのログが必要になる。ログ専用のマシンを用意し、他のシステムのログ収集を専門とすることを推奨する。金を出せば、簡単にLinuxベースのログサーバと立てることができる。このサーバはセキュリティを強化し、余計なサービスを立てず、コンソールのアクセスのみを許すようにすべきだ(例えばArmoring Linuxを見よ)。また、ポート514のUDPアクセスをブロックするかファイアウオールで制御し、インターネットの接続を制限する。このようにすればインターネットからのログ改竄等を防ぐことができる。

/var/tmp/.confのように、syslogの設定を変えて異なる設定ファイルを読み込ませるようにする。このようにすれば、クラッカーはどの設定ファイルが正規なのかが分からなくなる。簡単な方法は、/etc/syslog.confを書き換えることである。ローカルとリモートのログサーバの新しい設定ファイルを作る((例参照)。普通(すべてローカルにログと取る設定)の/etc/syslog.confのコピーを作る。そしてセキュアなログ方法を使う。一つのオプションに、syslogdを完全なチェック後に移動する。そのオプションとは、http://www.balabit.hu/products/syslog_ng/にある、syslog-ngである。 

我々が使うログのほとんどはリモートログサーバのものになるだろう。クラッカーがシステムに侵入する前にログを収集する。単純な方法でログを収集しているうちは、解析も簡単である。ローカルシステムのログとリモートのそれを比べることもできる。それによって、ローカルのものが改竄されていることが分かるであろう。

Pattern Matching 
ログの中身を見ることによって、たいていはポートスキャンにあっていることが分かる。ほとんどのスクリプトキディは、単独の脆弱性を探るためにネットワークをスキャンする。もしあなたのログを見ることで同じネットワーク内の別な端末から接続された記録及びポートスキャンの記録があれば、侵入されたと見ることができる。基本的に、敵は単独の脆弱性を発見し、見つければそのネットワーク内をスキャンする。脆弱性が見つかれば侵入する。ほとんどのLinuxでは、デフォルトでTCP Wrapperがインストールされている。それで、接続のほとんどが/var/log/secureで発見することができる。他のUNIX系では、ログをinetdに-tをつけることにより、デーモン化して起動することができる。典型的なスキャンは以下に示すとおりである。これは、wu-ftpdの脆弱性を付いたスキャンである。

/var/log/secure
Apr 10 13:43:48 mozart in.ftpd[6613]: connect from 192.168.11.200
Apr 10 13:43:51 bach in.ftpd[6613]: connect from 192.168.11.200
Apr 10 13:43:54 hadyen in.ftpd[6613]: connect from 192.168.11.200
Apr 10 13:43:57 vivaldi in.ftpd[6613]: connect from 192.168.11.200
Apr 10 13:43:58 brahms in.ftpd[6613]: connect from 192.168.11.200
ここで192.168.11.200がネットワークをスキャンしていることが分かる。いつもこのパターンとは限らないが、それぞれのIPが順次スキャンされていることが分かる。ころえがログサーバを持つ利点であり、すべてのログが結合されてからはネットワークでのパターンが容易に分かるようになる。ポート21番であるftpに何度も接続があったということは、彼らはwu-ftpdから侵入しようとしていたということだ。これでクラッカーは何を探していたのかが分かる。しばしばスキャンは段階的に行われる。誰かがimapの脆弱性を示せば、あなたはログの中でimapへのスキャンを直ちに探さなければならない。次の月にはftpから侵入されていることだろう。今の侵入に対する素晴らしい対策は、http://www.cert.org/advisories/ にある。ときどき、ツールは同時にさまざまな侵入を試みることがある。その時は、いくつかのポートへの単純な接続を見るとよい。

覚えておいてもらいたいのは、ログを取らなければ、スキャンされても知ることはできないということである。例えば、ほとんどのrpc接続はログに残らない。しかし、多くのサービスは/etc/inetd.confでTCP Wrapperによってログを取るように単純に設定されている。例えば、あなたはNetBusをinetd.confに追加することができる。あなたはTCP Wrapperで安全に接続拒否をするとともに、接続に対するログを取るように設定することができる。侵入検知の欄にさらなる情報がある。

What's the Tool? 
ときどき、あなたはネットワークをスキャンするのにツールが使われたことを知る。侵入するのにごく基本なツールとしてftp-scan.cがある。もしたった1箇所のポートまたは脆弱箇所から侵入するとすれば、彼らはたいていシングルミッションのツールを使用する。しかし、現在存在する多様な脆弱性を突くツールとして、2つのツール - jsbachによるsscanとFyodorによるnmapがある。我々はこれらの2つのツールを選んだ。なぜなら、この2つがちょうどよい分類となるからである。これらのツールをネットワークに適用し、結果に驚くことを勧める(自己診断する)。(注)sscanは古いツールであるため、例としてだけ記載する。自己診断するのであれば、Nessusを勧める。

sscanはスクリプトキディのスキャンツールのすべての目的を果たす。これはネットワークの一連の脆弱性を突く。カスタマイズもでき、新しい攻撃も加えられる。ネットワークまたはネットマスクに適用することにより、安心感を得ることができる。しかし、管理者権限で使用しなければならない。出力も分かりやすいものである。これで多くの脆弱性を簡潔に分かりやすく知ることができる。あなたは、ネットワーク上でsscanを起動し、出力でgrep VULNとし、exploit du jourを立ち上げさえすればよい。以下にシステムmozart(172.17.6.30)に対して行ったsscanの結果を示す。

otto #./sscan -o 172.17.6.30

--------------------------<[ * report for host mozart *
<[ tcp port: 80 (http) ]>		<[ tcp port: 23 (telnet) ]>
<[ tcp port: 143 (imap) ]>		<[ tcp port: 110 (pop-3) ]>
<[ tcp port: 111 (sunrpc) ]>		<[ tcp port: 79 (finger) ]>
<[ tcp port: 53 (domain) ]>		<[ tcp port: 25 (smtp) ]>
<[ tcp port: 21 (ftp) ]>

--<[ *OS*: mozart: os detected: redhat linux 5.1
mozart: VULN: linux box vulnerable to named overflow.
<[ *CGI*: 172.17.6.30: tried to redirect a /cgi-bin/phf request.
<[ *FINGER*: mozart: root: account exists.
<[ *VULN*: mozart: sendmail will 'expn' accounts for us
<[ *VULN*: mozart: linux bind/iquery remote buffer overflow
<[ *VULN*: mozart: linux mountd remote buffer overflow
---------------------------<[ * scan of mozart completed *
Nmapはツールセットに生のデータとして表示する。それでは、あなたはどこに脆弱性があるかが分からず、むしろ、どのポートがオープンなのかを示し、あなたはどこのセキュリティに重点を置くかを考える。Nmapは即座にポートスキャンをかけ、適切な結果を返す。これは最良のポートスキャナであり、OSでの防御を含め、UDPもTCPもスキャン視、実用的なポートスキャナである。しかし、あなたはこのツールを使いこなし、データを解析する技量が必要である。以下にNmapでの(先と)同じシステムにスキャンをかけた結果を示す。
otto #nmap -sS -O 172.17.6.30 

          Starting nmap V. 2.08 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/) 
          Interesting ports on mozart (172.17.6.30): 
          Port    State       Protocol  Service 
          21      open        tcp        ftp 
          23      open        tcp        telnet 
          25      open        tcp        smtp 
          37      open        tcp        time 
          53      open        tcp        domain 
          70      open        tcp        gopher 
          79      open        tcp        finger 
          80      open        tcp        http 
          109     open        tcp        pop-2 
          110     open        tcp        pop-3 
          111     open        tcp        sunrpc 
          143     open        tcp        imap2 
          513     open        tcp        login 
          514     open        tcp        shell 
          635     open        tcp        unknown 
          2049    open        tcp        nfs 

          TCP Sequence Prediction: Class=truly random Difficulty=9999999 (Good luck!) 
          Remote operating system guess: Linux 2.0.35-36 

          Nmap run completed -- 1 IP address (1 host up) scanned in 2 seconds
ログを見て、どのツールが使われたかが分かる。そのことにより、ツールがどのように作用したのかが分かる。最初に、sscanによるログを示す。(これは、設定ファイルともにデフォルトである。

/var/log/secure
Apr 14 19:18:56 mozart in.telnetd[11634]: connect from 192.168.11.200 
Apr 14 19:18:56 mozart imapd[11635]: connect from 192.168.11.200 
Apr 14 19:18:56 mozart in.fingerd[11637]: connect from 192.168.11.200
Apr 14 19:18:56 mozart ipop3d[11638]: connect from 192.168.11.200 
Apr 14 19:18:56 mozart in.telnetd[11639]: connect from 192.168.11.200 
Apr 14 19:18:56 mozart in.ftpd[11640]: connect from 192.168.11.200 
Apr 14 19:19:03 mozart ipop3d[11642]: connect from 192.168.11.200 
Apr 14 19:19:03 mozart imapd[11643]: connect from 192.168.11.200 
Apr 14 19:19:04 mozart in.fingerd[11646]: connect from 192.168.11.200
Apr 14 19:19:05 mozart in.fingerd[11648]: connect from 192.168.11.200 

/var/log/maillog 
Apr 14 21:01:58 mozart imapd[11667]: command stream end of file, while reading line user=??? host=[192.168.11.200] 
Apr 14 21:01:58 mozart ipop3d[11668]: No such file or directory while reading line user=??? host=[192.168.11.200] 
Apr 14 21:02:05 mozart sendmail[11675]: NOQUEUE: [192.168.11.200]: expn root 

/var/log/messages 
Apr 14 21:03:09 mozart telnetd[11682]: ttloop: peer died: Invalid or incomplete multibyte or wide character 
Apr 14 21:03:12 mozart ftpd[11688]: FTP session closed 

sscanはまた、cgi-binの脆弱性もスキャンする。これらはsyslogでは残されないので、access\_logで見つける。(参考までに。)

/var/log/httpd/access_log 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/phf HTTP/1.0" 302 192 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/Count.cgi HTTP/1.0" 404 170 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/test-cgi HTTP/1.0" 404 169 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/php.cgi HTTP/1.0" 404 168 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/handler HTTP/1.0" 404 168 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/webgais HTTP/1.0" 404 168 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/websendmail HTTP/1.0" 404 172 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/webdist.cgi HTTP/1.0" 404 172 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/faxsurvey HTTP/1.0" 404 170 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/htmlscript HTTP/1.0" 404 171 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/pfdisplay.cgi HTTP/1.0" 404 174 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/perl.exe HTTP/1.0" 404 169 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/wwwboard.pl HTTP/1.0" 404 172 
192.168.11.200 - - [14/Apr/1999:16:44:50 -0500] "GET /cgi-bin/ews/ews/architext_query.pl HTTP/1.0" 404 187 
192.168.11.200 - - [14/Apr/1999:16:44:50 -0500] "GET /cgi-bin/jj HTTP/1.0" 404 163 
SYN,SYN-ACK,ACKのすべてのポートに完璧に接続されたことが分かるであろう。これは、sscanはアプリケーション層で動くからである。sscanはftpポートが開いていることを探すだけではなく、どのftpデーモンが立ち上がっているかをも探すのである。このことは、imap,popも同じことがいえる。パスワードを捜し当てるありふれたツールであるsniffitを使ったsniffトレースでもこのことが分かる。

mozart $ cat 172.17.6.30.21-192.168.11.200.7238 
220 mozart.example.net FTP server (Version wu-2.4.2-academ[BETA-17](1) Tue Jun 9 10:43:14 EDT 1998) ready.

あなたが上で見たように、実行されていたwu-ftpdのバージョンを判別するため完全な接続が行われる。あなたがログで完全な接続が行われたことを確認したら、上で見られたように、あなたはエクスプロイトツールによってスキャンを受けた可能性がある。これらのツールは,あなたの実行しているものを判別するため完全な接続を作成している.

多くのポートスキャナーのように Nmap はあなたが実行しているものが何かは気にせず、あなたが特定のサービスを実行しているかどうかを調査する。このために,nmap ではパワフルなオプションが用意されており、あなたは作成された接続の種類が何か SYN, FIN, Xmas, Null などを含めて判断することが可能である。これらのオプションについてのより詳細な解説は、http://www.insecure.org/nmap/nmap_doc.htmlをチェックすること。これらのオプションのために、あなたのログはリモートのユーザによって選択されたオプションに基づいて異なるだろう。 -sT フラグによって作成された接続は完全な接続となり、そのログは sscan に非常に似たものになるだろう。しかしながら、通常 nmap はより多くのポートをスキャンする。

/var/log/secure 
Apr 14 19:18:56 mozart in.telnetd[11634]: connect from 192.168.11.200 
Apr 14 19:18:56 mozart imapd[11635]: connect from 192.168.11.200 
Apr 14 19:18:56 mozart in.fingerd[11637]: connect from 192.168.11.200
Apr 14 19:18:56 mozart ipop3d[11638]: connect from 192.168.11.200 
Apr 14 19:18:56 mozart in.telnetd[11639]: connect from 192.168.11.200 
Apr 14 19:18:56 mozart in.ftpd[11640]: connect from 192.168.11.200 
Apr 14 19:19:03 mozart ipop3d[11642]: connect from 192.168.11.200 
Apr 14 19:19:03 mozart imapd[11643]: connect from 192.168.11.200 
Apr 14 19:19:04 mozart in.fingerd[11646]: connect from 192.168.11.200
Apr 14 19:19:05 mozart in.fingerd[11648]: connect from 192.168.11.200 

-Dオプションを付けることを忘れてはいけない。Nmapのオプションは送信元アドレスをだます。あなたは同時に15の異なる送信元からスキャンを受けるが、その中の一つしか本物ではない。さらにしばしば、ポートスキャンに-sSフラグを付ける。これはバレにくいオプションで、SYNパケットのみを送る。遠隔のシステムが応答すれば、接続はRSTとともに破棄される。

/var/log/secure

おっと!なにも表示されない!これは、システムログにはフルコネクションしか記録されないからだ。Nmapに-sSオプションを付けたがために、完全なTCP接続は成立せず、ログに残らなかったのだ。これがバレないようにスキャンする理由であり、ログにはスキャンが記録されない。古いLinuxカーネル、特に2.0.xでは、不完全なTCP接続でもログに残ったが、それは破棄されたものとしてであった。古いカーネルでの-sSフラグを付けたスキャンの結果は以下のとおりである。(注: 最初の3エントリーのみ)。

/var/log/secure
Apr 14 21:25:08 mozart in.rshd[11717]: warning: can't get client address: Connection reset by peer
Apr 14 21:25:08 mozart in.rshd[11717]: connect from unknown
Apr 14 21:25:09 mozart in.timed[11718]: warning: can't get client address: Connection reset by peer
Apr 14 21:25:09 mozart in.timed[11718]: connect from unknown
Apr 14 21:25:09 mozart imapd[11719]: warning: can't get client address: Connection reset by peer
Apr 14 21:25:09 mozart imapd[11719]: connect from unknown

接続のすべてがエラーとなっていることが分かるであろう。接続が完了する前にSYN-ACKシーケンスが崩壊するため、デーモンが送信元のシステムを突き止められないでいる。このログによって、あなたはずっとスキャンされていたことが分かり、不運にもその送信元が誰なのかは分からない。これは、Linuxカーネル2.0.xにだけ出る表示である。Fyodorのを引用すると、'connection reset by peer'というエラーメッセージが表示される。Linuxカーネル2.0.xxと、2.2以降を含むその他では表示されない。このバグ(accept()が3-wayハンドシェイクが完了する前に返ってしまう)は解消された。

Nmapは-sF,-sX,-sN等の他のオプションを多様に使うことができ、ログがこれら のスキャンを拾うのを好むように見える。

/var/log/secure

もう一度見ると、ログに何も現れない。恐ろしいことに、あなたはスキャンされてもそれすら知らない。3つのタイプのスキャンでは、-sSオプションのようなものがあるため、どれもログに残されない。これらのバレないスキャンを防ぐには、tcplogdipplのようなログ用のアプリケーションが必要だ。また、IPFilter,SunScreen,FireWall-1のようなほとんどのファイアウオールもスキャンを防止し、ログを取ってくれる。 

Did They Gain Access? 
一度スキャンされたことに気づき、何を探すべきかが分かれば、次に来る大きな疑問は、侵入されたかということである。現在のリモートクラックでは、たいていバッファオーバーフローに基づいたものである。他にはスタック攻撃がある。簡単に説明すると、バッファオーバーフローは必要以上の入力をするプログラム(たいていはデーモン)で、メモリ内の危険領域に上書きする。実際の正しいコードはたいてい管理者権限で実行される。バッファオーバーフローのさらなる情報は、Aleph1の素晴しい論分 Smashing the Stack for Fun and Profitを参照すること。

あなたはバッファオーバーフローをmountdのような攻撃として /var/log/messagesや/var/adm/messages(UNIX)で知ることができる。また、imapdに対する似たようなログをメールログで見ることができる。バッファオーバーフロー攻撃は以下のようなものである。

Apr 14 04:20:51 mozart mountd[6688]: Unauthorized access by NFS client 192.168.11.200.
Apr 14 04:20:51 mozart syslogd: Cannot glue message parts together
Apr 14 04:20:51 mozart mountd[6688]: Blocked attempt of 192.168.11.200 to mount
~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P3Û3À°^[Í~@3Ò3À~KÚ°^FÍ~@þÂuô1À°^BÍ~@~EÀubëb^V¬<ýt^FþÀt^Këõ°0þÈ~HFÿëì^°^B~
I^FþÈ~IF^D°^F~IF^H°f1ÛþÃ~IñÍ~@~I^F°^Bf~IF^L°*f~IF^N~MF^L~IF^D1À~IF^P°^P~IF^H°
fþÃÍ~@°^A~IF^D°f³^DÍ~@ë^DëLëR1À~IF^D~IF^H°fþÃÍ~@~Hð?1ÉÍ~@°?þÁÍ~@°?þÁÍ~@¸.bin@~
I^F¸.sh!@~IF^D1À~HF^G~Iv^H~IF^L°^K~Ió~MN^H~MV^LÍ~@1À°^A1ÛÍ~@èEÿÿÿÿýÿPrivet
ADMcrew~P(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(Apr 14 04:20:51
mozart ^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^
E^H(-^E^H-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E
^H(-^E^H-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^ H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E
^H(-^E^H(-^E

もし上記のような記録をログファイル上に見たならば、誰かがあなたのシステムに侵入を企てたことになる。侵入が成功したかを見極めるのは難しい。見極める一つの方法は、リモートから接続があるかを確かめることである。もし誰からリモートからログインに成功したならば、彼らはアクセスしたことになる。もう一つの手がかりは/etc/passwdファイル内にmoof,rewt,crak0,w0rmが加わっているかである。これらuid 0 のアカウントの追加はありふれたスクリプトで実行される。一度クラッカーがアクセスに成功すれば、ログを消し去り、 syslogdにトロイの木馬を仕掛けるであろう。さらなる情報はKnow Your Enemy: III を参照のこと。こうなっては(侵入されては)いかなるログ情報も得られない。そうなる前に、http://www.cert.org/nav/recovering.htmlをチェックすることを勧める。

ログファイル内で異常を発見する助けとして、特別な用語をシグネチャとして検出するシェルスクリプトを使うことが挙げられる。Marcus Ranumの情報からさらなる検索方法を知ることができる。

Korn shell script

Conclusion 
あなたのシステムログは敵に関して多くの情報を与えてくれる。しかし、最初にログの完全性を保証しなければならない。最良の手段の一例として、リモートログサーバを構築し、すべてのシステムのログを一括して収集することである。一度セキュリティを施せば、ログファイルからパターンを見つけることができる。これらのパターンとログ内容に基づいて、クラッカーが何を探し、潜在的にどのようなツールを使っているのかが分かる。この知識に基づき、あなたはシステムをよりよい方法で保護することができるのである。 


The Honeynet Project

Comments