SuperTAINS News No.16 [Page.3]

UNIXにおける不正アクセスへの対策

総合情報システム運用センター佐伯田鶴
`saeki@tains.tohoku.ac.jp`

TAINS利用研究会・DMA 津田和俊
`tsuda@dma.aoba.sendai.jp`

総合情報システム運用センター曽根秀昭
`sone@tains.tohoku.ac.jp`

1 不正アクセスへの対策のお願い

1.1 UNIXにおけるネットワーク経由の不正アクセス

　コンピュータを利用する上で，ネットワークに接続して TAINS やインターネットにより，電子メールやWWW，ファイル共有などを利用することは不可欠になっています。しかし，インターネットと自由に通信できることは，逆にみると，インターネット中のどこからでもあなたのコンピュータにアクセスできることにつながります。世の中にはいたずらで，あるいは悪意をもって他人のコンピュータを攻撃し，不正に利用したり，利用を妨害しようとする輩も少なくありません。インターネットには，見えない危険が潜んでいて，それに対抗する秩序が未整備であることを認識しなければなりません。
　前号で対策をお願いした，大量の電子メール(spam)の不正中継 (*1) と，不正な大量の通信の発生(smurf) (*2) は，その例です。これらは，通常の通信と同様に外部から操作して，結果として，非常に大量の通信を発生させ，一時的な負荷の増大や機能障害を引き起こします。
　Spam や smurf と異なり，コンピュータシステムのセキュリティホール (安全保障上の弱点)を利用して，システムに対して攻撃したり，内部に侵入しようとする不正アクセスもあります。システムの内部に入り，情報を持ち出したり破壊するような，悪意ある活動を行う点で， spamやsmurfとは質的に異なり，はるかに重大な問題です。システムプログラムなどには安全性の確保に配慮の漏れがあることもあり，それを悪用して，システムの安全を脅かすことが可能になることもあります。それがセキュリティホールであり，公に報告されたものについては，プログラムの修正を施すなどの対策をとるようにとの勧告がネットワーク上で広報されます (*3)。その一部を，表1に示します。

公知のセキュリティホールの一部

Buffer Overflow in Some Implementations of IMAP Servers
Buffer overflows in some POP servers
Buffer Overflow in NIS+
Multiple Vulnerabilities in BIND
Microsoft Windows-based Web Servers unauthorized access - long file names
Vulnerabilities in CDE
"smurf" IP Denial-of-Service Attacks
IP Denial-of-Service Attacks
Buffer Overrun Vulnerability in statd(1M) Program
Sanitizing User-Supplied Data in CGI Scripts
ftpd Signal Handling Vulnerability
JavaScript Vulnerability
Second vulnerability related to INN - ucbmail
Vulnerability in innd
MIME Conversion Buffer Overflow in Sendmail Versions 8.8.3 and 8.8.4

(CERT Advisaryのリスト ftp://ftp.jpcert.or.jp/pub/cert/cert_advisories より)

1.2 スキャンの脅威

　広報されている，公知のセキュリティホールは多数ありますが，これについて網羅的に，かつ多数のコンピュータに対してスキャン (走査)してセキュリティホール探しを試みるプログラムが公開されています。スキャン自体では実質的な被害がありませんが，収集した成果をもとにしてシステムへ侵入したり，被害を与える行動を始めることがあります (*4)。 3年ほど前からスキャン攻撃が見られ，SuperTAINS ニュースでも対策を施すようにとの呼びかけを掲載しました (*5)。
　今年の6月下旬から，新たなスキャンプログラムが広まり，スキャン攻撃が増加しています (*6)。これは，指定したドメインやIPアドレス範囲の全体に対して，公知のセキュリティホールを試してレポートを作成するもので， NFS (rpc statd)，HTTP(cgi-bin)，X，POP3，IMAP，DNS(BIND, named)， fingerなどからの侵入を試みるものとみられます (*7)。利用例として ac.jp ドメインに対するスキャンの例を示しているそうで，これを使い，世界中から日本の大学のネットワークへ攻撃していると推測されます (*8)。
　TAINSは基本的にインターネットと自由に通信できますから， TAINSに接続したコンピュータはインターネットからのスキャンを防ぐことが不可能といえます。すでに何回もスキャン攻撃を受けて，もしも十分な管理を施していないコンピュータならば，セキュリティホールを見つけられたと思って良いでしょう。さらに，侵入などの二次的な攻撃を許して，最悪の場合には他の組織へのスキャンや侵入の踏台に利用されて責任を問われる結果にもなり得ます。
　スキャンに対抗するためには，公知のセキュリティホールについて万全の処置を施し，スキャンによってセキュリティホールを発見されないようにするしかありません。次節以下では，それぞれのセキュリティホールについて対策の方法や，対策用プログラムや資料の所在を案内します。是非，直ちに，周りのUNIXコンピュータすべてについて，すべての項目の対策をとられるようにお願いします。ただし，攻撃の種類や手口は絶えず変化しつつ頻発していますから，今後も，それに対応して継続的に対抗処置を施していくことが必須です。
　なお，この資料の作成に当たっては，CERT/CC (*9)， JPCERT/CC (*10) などの発表資料を参考にしました。

(*1) 北村祐一郎，中村和浩，曽根秀昭：電子メールの不正な中継からの防御， SuperTAINSニュース，No.15, pp. 22-34 (1998,7)。
(*2) 曽根秀昭: smurf攻撃の中継への対策， SuperTAINSニュース，No.15, pp.17-21 (1998,7)。
(*3) Security Infomation, http://www.jpcert.or.jp/secinfos.html
(*4) とくに，root(特権ユーザ)の権限を入手されると，ファイルを自由に見たり改変されるだけでなく，システムプログラムを罠を仕掛けたもの (トロイの木馬といわれる)とすりかえたり，ネットワークを流れる情報を盗聴して，次の攻撃への踏み台に利用されるおそれがあります。あるいは，侵入の痕跡を消すために，セキュリティホールをふさいだり，ログファイルを改ざんしたり， ps や netstat などのコマンドをすりかえて侵入者を発見できないようにすることもあります。
(*5) TAINS 利用研究会: 戸じまりは大丈夫ですか?， SuperTAINSニュース，No.5, pp.17-18 (1995.10)。 (http://www.tohoku.ac.jp/TAINS/news/st-news-5/1718.html)
(*6) CERT/CC Incident Note http://www.cert.org/incident_notes/IN-98.02.html。
ポートスキャンを用いた不正アクセスに関する緊急報告 http://www.jpcert.or.jp/info/98-0004/。
AUSCERT Alert, multiscan (`mscan') Tool, 20 July 1998 ftp://ftp.jpcert.or.jp/pub/auscert/AA/ AL-98.01。
(*7) スキャンのプログラムは多くの種類があり，別のセキュリティホールを狙うものもあれば，一つだけの種類についてネットワーク中のコンピュータを調べていくものもあります。
(*8) ネームサーバをたどって攻撃目標を探すために，ネームサーバが狙われやすいようです。WWWサーバやMXサーバも確率が高いようです。
(*9) CERT Coordination Center, http://www.cert.org/
(*10) コンピュータ緊急対応センター, http://www.jpcert.or.jp/

2 セキュリティ対策

　この節ではUNIX上のプログラムのセキュリティホールの対策を紹介します。特別にガードを強固にする必要はなく，基本的な対策方法はセキュリティホールのあるプログラムの修正，もしくは停止です。

2.1 不要なネットワークサービスの削除

　各ホストが提供しているネットワーク・サービスのうち不要なものを停止します。具体的には，定義ファイル(典型的には /etc/inetd.conf) を見て， finger，telnet，imap，pop などの行で，不要なサービスをコメントアウトします。その後，inetd プロセスに kill -HUP シグナルを送るか，あるいはシステムを再起動します。
　また，DNS (named) や NFS (statd) のサービスが不要な場合は，OS 起動時の設定ファイル (典型的には /etc/rc*) の中で，これらのサービスを起動している行をコメントアウトします。その後，該当するプロセスを kill するか，あるいはシステムを再起動します。

2.2 DNS (BIND, named)

　スキャンの対象のリストが攻撃者の手に渡るのを防ぐために，ドメインネームサーバからホスト名一覧を持って行かれないよう，外部へのゾーン転送を阻止するよう転送制限を設定して下さい。
　また，BINDパッケージに含まれているネームサーバプログラムのnamed (一部のシステムでは in.named)の古いバージョンにはセキュリティホールがあることが知られています (*11)。現在の最新バージョンは4.9.7あるいは8.1.2です。これ以前のバージョンにはバッファオーバーランのバグ (*12) があるため，namedをハングアップ(コアダンプ)して停止させられてしまったり，最悪の場合にはnamedを稼働しているマシンにroot権限でログインされたりします (*13)。 namedが停止すると，そのサーバが担当するドメインのコンピュータの通信に支障が出ます。
　namedが停止しなかった場合も停止した場合も，named等でバージョンが古いものを使って運用している場合は気を緩めないでください。セキュリティホールのあるバージョンで運用していた場合，namedデーモンが停止しなかったということは，バイナリコードのOSとCPUが標的と一致したのでコアダンプを起こさなかったということであり，既にroot権限を奪われている可能性が非常に大きいです。逆に，仮にnamedがコアダンプした際も，このコンピュータは穴だらけのところだという記録が残ってしまいますので，対策を施していないと次にいつ侵入攻撃されるかわかりません。
　最新版ではこのバグは修正されていますので，namedを最新のものに入れ替えて下さい。最新版は，

ftp://ftp.coop.org.tohoku.ac.jp/pub/isc/bind/src/

などから入手できます。ネームサーバではないマシンの場合は，2.1 で述べた方法で named (または in.named)を起動しない方が安全です。
　古いnamedのセキュリティーホールをついて攻撃された場合の痕跡にはつぎのものがあります。

システムに次のファイルができている。

    /dev/reset    /dev/pmcf1    /dev/pmcf2    /dev/pmcf3
    /dev/pmcf4    /usr/lib/libsn.a

次のようなシステムログが残っている。

    May  1 11:28:49  named[28464]: starting.  named
       LOCAL-980501.020913 Fri May  1 02:09:13 EDT 1998
       ^Iroot@:/usr/lib/tntbot/bind/named

2.3 POP

　POPサーバはアクセスの記録を全く残さないか正常なアクセスだけを記録する設定をすることが多いので，繰り返し侵入を試みる入り口として利用されます。可能ならば，POP接続に失敗した記録をログに残すようにして，異状がないか監視して下さい。
　また，バージョン2.52以前のバージョンのqpopper にはバッファオーバーランのバグがあり，危険度の高いセキュリティホールとなっています (*14)。 qpopperのようなinetdから起動されるソフトは，セキュリティホールを攻撃された場合は，コアダンプしてその接続は終了し，引き続き接続要求があった場合には再びinetdから起動されます。そのため，ログのレベルをかなり深く取っているか，tcp_wrapper(3.1 節参照)で不必要なアクセスを記録するようにしていない限り，被害には気付きにくくなっています。
　メールのPOPサーバとして運用しているコンピュータでは，ただちに，最新バージョンに入れ換えて下さい。対策済みの最新バージョンは2.53です。

ftp://ftp.coop.org.tohoku.ac.jp/pub/qpopper/

などから入手できます。 POPサーバでないマシンは，popd を起動しないようにinetd.conf から削除する方が安全です。

2.4 NFS (rpc-statd)

　OSによっては，ネットワークファイルシステム(NFS)で使う状態モニタ rpc.statd(または statd)にセキュリティホールがあるものがあります (*15)。これにより，外部から root 権限で何でもできるようになりえます。これを狙った攻撃が近ごろ多数みられています。 statdのセキュリティホールに関して各ベンダーから情報が出ています (*16)。これを見て，OSによってはパッチを当てる必要があります。
　NFSサーバ，NFSクライアントでないホストで，かつlockdが動いていないホストは， statd プロセスは必要ありません。statdを停止し，起動しないよう /etc/rc* から削除した方が安全です。
　不正なアクセスを受けた場合は，システムのログファイル (/etc/syslog.conf)や一時ファイル (/tmp/.nfs09 など) に痕跡が残る場合があります。statd プロセスがファイルの作成に失敗したなどの不審なメッセージを出力していないか確認して下さい。
　なお，NFS でファイル共有を提供している場合に，外部からファイルを見たり改ざんされるおそれがありますが，TAINS では対外接続において外部からのNFS 要求を阻止しています。

2.5 IMAP

　ワシントン大学のIMAPサーバversion4にはセキュリティ上の弱点があり，外部から root 権限でのアクセスを許してしまうことがあります (*17)。該当する場合はIMAPサーバをIMAP4.1以降にバージョンアップして下さい。最新版は

ftp://ftp.cac.washington.edu/mail/imap.tar.Z

などから入手できます。
　またIMAPサーバでないならばimapを起動しないようinetd.confから削除して下さい。

2.6 Webサーバ(httpd)

　World Wide Webは情報発信の手段として便利なため，学内でも多くのサーバが立ち上がっていますが，cgiプログラムを中心にセキュリティホールが多く存在しています。これを悪用して，不正なコマンド(パスワードファイルの持ち出しなど)を実行されることがあります。httpdサーバを標準通りにインストールすると，同時にサンプルのcgiプログラムがインストールされて，その中に危険なものもあることがあります。不必要な cgi-binプログラムは削除もしくは実行不可能にしておくことが勧められています。特に，以下にあげるcgiプログラムは公知のセキュリティホールがありますから，処置が必要です。

2.6.1 cgi-bin/phfコマンド

　一部のhttpdサーバのcgi-bin/phfコマンドにはセキュリティホールがあります (*18)。対象となるサーバはNCSA 1.5a-exportと APACHE 1.0.3 httpd以前のものです。 phfコマンドはhttpdをインストールした際に自動的にインストールされることがあります。
　phfコマンドに対する攻撃を受けたかを調べるためには， httpdのログファイル (/usr/local/etc/httpd/logs/access_log* 等)を参照します。ログの中に /phf という文字列を含む行がある場合は，攻撃を受けた可能性があります。また同じ行のHTTPのステータスコードが200であれば，その攻撃が成功した可能性があります。
　対策は，httpdを最新のものにする，もしくはphfコマンドを削除または実行できないようにすることです。 apacheの最新バージョンは 1.3.1 です。

http://SunSITE.sut.ac.jp/pub/archives/WWW/apache/dist

などから入手できます。

2.6.2 cgi-bin/nph-test-cgiコマンド

　cgi-bin/nph-test-cgiコマンドも危険性が高いので (*19)，必要でない場合は， nph-test-cgiコマンドを削除するか実行できないようにして下さい。

2.6.3 cgi-bin/webdist.cgiコマンド

　IRIX 5.x ， 6.x 上での IRIX Mindshare Out Box software package に含まれる webdist.cgi コマンドを不正に利用されると，webのユーザがhttpd デーモンの権限で任意のコマンドを実行することが可能になる場合があります (*20)。ベンダー(Silicon Graphics Inc.)からのパッチを当てるか， cgi-bin/webdist.cgiコマンドを実行不可能にして下さい。
　ベンダーからの情報，OS バージョンごとのパッチはそれぞれ次の URLから入手できます。

ftp://sgigate.sgi.com/~ftp/security/19970501-02-PX
ftp://sgigate.sgi.com/~ftp/patches/

2.6.4 cgi-bin/Count.cgiコマンド

　Count.cgi コマンドにはバッファオーバーランのバグがあります (*21)。 Count.cgiコマンドのバージョンをあげるか，実行できなくして下さい。最新バージョンは2.4で，以下のURLで公開されています。

http://www.fccc.edu/users/muquit/Count.html

2.6.5 php.cgiコマンド

　php.cgi 2.0beta10 とそれ以前のphp.cgiコマンドにはバッファオーバーランのバグがあります(*22)。 version 2.0b10に対するパッチは以下のURLで公開されています。

http://www.secnet.com/sni-advisories/sni-11.php_overflow.advisory.html

2.6.6 cgiスクリプト中でのメタキャラクタ

　いくつかのcgiスクリプトは，スクリプトの書き方によっては，コマンドを不正に実行される可能性があります。cgiスクリプトではメタキャラクタが入力されるかもしれないときの処理に注意が必要です (*23)。メタキャラクタを検査したり除去する取り扱いの注意は下記をご覧下さい。 ftp://info.cert.org/pub/tech_tips/cgi_metacharacters

2.6.7 cgi-binコマンドのインタプリタ

　古い Netscape や他のサーバのドキュメントでは，cgiスクリプトを実行するための perlやshellをcgi-binのディレクトリに置くように勧めている場合がありますが，外部から不正なコマンドを実行される可能性がありますので，この指示には従わないで下さい (*24)。

2.7 anonymous ftp

　anonymous ftpはきちんと設定をしないと，不正アクセスを受ける原因となります。以下の事項に注意して下さい。
　ftp サーバプログラムは新しいバージョンを使用するようにして下さい。
　anonymous ftpで公開するディレクトリの所有者を ftp のアカウントにしないようにして下さい。ディレクトリの所有者がftpであり，かつ書き込みが許可になっている場合は，侵入者にファイルを書き込みされる危険があります。これにより，配布しているファイルを改ざんされたり，不正なプログラムの流通に悪用されることがあります。 anonymous ftpのディレクトリの所有者をrootまたはシステム管理者のグループ等にして書き込みを許可し，その他のグループには書き込みを許可しないようにすることが勧められています。外部からの書き込みを許可する必要がある場合は，以下のURLを参照して下さい。安全な方法が紹介されています。

ftp://ftp.jpcert.or.jp/pub/cert/tech_tips/anonymous_ftp_config

　~ftp/etc にはシステムの /etc/passwd， /etc/group のコピー(ユーザ名やパスワードがわかるもの) を置いてはいけません。Anonymous FTP へのアクセスの記録を残すようにし，定期的に監視して下さい。

2.8 NIS, NIS+

　NIS，NIS+ のサービスを不正に利用されると，外部から不正にroot権限でコマンドを実行することが可能になる場合があります (*25)。 NISが停止することもあり，その場合にはそのサーバが担当するNIS情報の利用に支障が出ます。
　脚注の資料を見て，パッチを当てる必要があります。あるいは，サブネットの入り口のルータで NIS (rpc) のポート(111)への外部からのアクセスを阻止するのも一つの手ですが， TAINS では対外接続において外部からの rpc 要求を阻止しています。

2.9 sendmail

　Sendmailの古いバージョンにあるセキュリティホールを悪用して，パスワードファイルを持ち出したり，root 権限でコマンドを実行することができます。また，他サイトのsendmailを利用して大量の電子メール(spam，スパム)を配布する不正な中継が問題になっています。スパムを中継させられると，コンピュータの負荷が増大するだけでなく，配布を受けた人から苦情や抗議が来たり，ブラックリストに載せられてメールを使えなくなることもあります。マシンの管理者は，spam対策を施したsendmailを運用するようにして下さい (*26)。最新バージョンは8.9.1で，

ftp://ftp.coop.org.tohoku.ac.jp/pub/sendmail/

などから入手できます。

2.10 finger

　fingerはユーザの情報を得る手段として便利ですが，反面，侵入攻撃に有効な情報(ユーザ名，ユーザの活動状況など) も提供してしまう可能性があります。必要がない場合はfinger を起動しない方が安全です。/etc/inetd.conf からfingerの行をコメントアウトした後，inetd プロセスに kill -HUP シグナルを送るか，あるいはシステムを再起動して下さい。サブネットの入り口のルータで finger のポート(79/tcp)への外部からのアクセスを阻止するのも一つの手です。

2.11 X

　X window system の画面の上に外部から偽のxtermなどを表示させて，そのウィンドウに打ったkey sequenceを拾ったり，Xサーバの利用を妨害する攻撃があります。いつの間にか開いているウィンドウには注意しましょう。 xhostやxauthの設定を慎重にすることも必要です。サブネットの入り口のルータで，Xサーバのポート(たとえば6000以上のtcp)への外部からのアクセスを阻止するのも一つの手です。

2.12 telnet

　telnet で接続したときに最初に表示するメッセージから OSのバージョンを確認できることもある (*27) ので，OS自体にセキュリティホールがあるマシンを狙うためにこれを試す攻撃もあります。表示メッセージを見直すか，あるいは，もしも必要がない場合はtelnet を起動しないようにした方が安全です。

2.13 INN

　ネットワークニュースサーバシステムの INN のセキュリティホールを悪用して，パスワードファイルなどを持ち出したり，ユーザの状況を盗み見ることができます(*28)。 INNを運用しているところでは，脚注の資料を参照して対策して下さい。

2.14 パスワードファイル

　パスワードが設定されていないアカウントがあると，不正に侵入するのに使われることがあります。一般ユーザだけでなく，root，lpなどの，初期設定から存在するアカウントに不要のものが残っていないか，また，独自のパスワードに変更してあるかを確かめて下さい。

(*11) (参考) namedサーバプログラムを悪用したアタック http://www.jpcert.or.jp/info/98-0002/。
Multiple Vulnerabilities in BIND http://www.cert.org/advisories/CA-98.05.bind_problems.html。
(*12) バッファオーバーランのバグがある場合，つまり，データを保存するのに，通常の使用の際には十分であるが固定された領域しか確保されていないようなものがあった場合には，故意にこれを越えるような長いデータを放り込み，データを壊して named デーモンを誤動作させることができます。多くの場合，named デーモンはroot 権限で動いていますから，うまくやるといとも簡単にroot権限を奪うことができます。注意深くプログラムを組んでいればこのような被害は未然に防げるのですが，残念ながらいくつかのnamed デーモンにはバグがあり対策が完全ではありません。
(*13) バッファオーバーランのバグを攻撃する場合，送り込むデータの中にバイナリコードを埋め込み，これを実行させるようにします。バイナリのコードでないと実行できないため，バッファオーバーランのセキュリティホールをつくには，侵入攻撃をかけようとする相手の機械のCPUとOSのバージョンがわからないとうまく成功せず，root権限が奪えずに，相手の named デーモンをコアダンプさせるだけで終わります。ただし，相手の機械にセキュリティホールがあるとの情報は残りますので，CPUとOSをうまく合わせて侵入攻撃をかければ，その機械のroot権限を奪うことができます。このためのツールも一般に出回っています。特に，Intel x86のLinux用が充実しています。
(*14) JPCERT: POPサーバプログラムを悪用したアタック http://www.jpcert.or.jp/info/98-0003/。
(*15) (参考) statd サーバプログラムを悪用したアタック http://www.jpcert.or.jp/info/98-0001/。
rpc.statd のセキュリティ上の弱点 http://www.jpcert.or.jp/ESA/CA-96.09.euc.txt。
Buffer Overrun Vulnerability in statd(1M) Program http://www.cert.org/pub/advisories/CA-97.26.statd.html。
Current activity relating to rpc.statd ftp://ftp.cert.org/pub/cert_summaries/CS-98.01。
(*16) http://www.cert.org/pub/advisories/CA-97.26.statd.html。
(*17) (参考) IMAP サーバ・プログラムを悪用したアタック http://www.jpcert.or.jp/info/97-0004/。
Buffer Overflow in Some Implementations of IMAP Servers ftp://ftp.jpcert.or.jp/pub/cert/cert_advisories/CA-98.09.imapd.txt。
(*18) (参考) phf CGI プログラムを悪用したアタック http://www.jpcert.or.jp/info/97-0003/。
Vulnerability in NCSA/Apache CGI example code ftp://info.cert.org/pub/cert_advisories/CA-96.06.cgi_example_code 。
(*19) (参考) Vulnerability in the httpd nph-test-cgi script ftp://info.cert.org/pub/cert_advisories/CA-97.07.nph-test-cgi_script。
(*20) (参考) Vulnerability in webdist.cgi ftp://ftp.cert.org/pub/cert_advisories/CA-97.12.webdist
(*21) (参考) Buffer Overrun Vulnerability in Count.cgi cgi-bin Program ftp://ftp.cert.org/pub/cert_advisories/CA-97.24.Count_cgi。
(*22) (参考) Buffer Overflow in php.cgi http://www.secnet.com/sni-advisories/sni-11.php_overflow.advisory.html。
(*23) (参考) Sanitizing User-Supplied Data in CGI Scripts ftp://ftp.cert.org/pub/cert_advisories/CA-97.25.CGI_metachar。
How To Remove Meta-characters From User-Supplied Data In CGI Scripts ftp://info.cert.org/pub/tech_tips/cgi_metacharacters。
(*24) (参考) Interpreters in CGI bin Directories ftp://info.cert.org/pub/cert_advisories/CA-96.11.interpreters_in_cgi_bin_dir。
(*25) Buffer Overflow in NIS+ ftp://ftp.jpcert.or.jp/pub/cert/cert_advisories/CA-98.06.nisd。
(*26) 詳しくは SuperTAINS ニュース No.15 の記事をご覧下さい。
(*27) Linuxとかは，ご丁寧なことにkernelのバージョンまで表示されます。
(*28) ネットワークニュースのサービスを悪用したアタック http://www.jpcert.or.jp/info/97-0002/。

3 侵入対策

3.1 監視用ソフトウェア tcp_wrapper，ipfw

　監視用ソフトウェアtcp_wrapperをインストールすることにより，外部からの接続を制限したり，監視したりすることができます。 fingerサービス，telnetサービスの接続を許可するホストを限定することも可能です。 tcp_wrapperは ftp://ftp.jpcert.or.jp/pub/cert/tools/tcp_wrappers/ などから入手できます。
　サービスしているポート以外も含めてポートスキャンを詳細に監視するには， ipfw を使ったほうがいいかもしれません。 ipfw は FreeBSD のカーネルに組み込まれています。本来はファイアウォール構築のためのキットで，かなり強力なパケットフィルタリングとロギングが可能です。一般に，ルータ(ファイアウォール)で不要なパケットを阻止するのは良い方法です (*29)。

3.2 不正アクセスに対するチェック事項

　不正アクセスを受けたかどうかの一般的なチェック事項を紹介します (*30)。

システムのログファイルを確認します。lastのログ，syslog，messages 等のログに，見慣れないサイトからのアクセス，不審な記録等が残っていないかどうかを調べます。
set-UID や set-GID ビットがセットされたファイルに注意します。特に rootやシステム関係のグループ(kmem等)の実行時ID がセットされたファイルに注意し，不審なものがないかどうかをチェックします。
システムのバイナリで変更されているものがないかどう確認します。侵入者はしばしば /etc/inetd.conf に記述されているバイナリや，ネットワーク・システム関連のコマンド，共有ライブラリなど(例えば login, su, telnet, netstat, ifconfig, ls, find, du, df, libc, sync)を置き換えることがあるためです。
ネットワークを監視するプログラム(sniffer, packet snifferなど)が勝手に動いていないか確認します。侵入者は，ユーザのアカウントやパスワード等の情報を得るために，このようなプログラムを仕掛ける場合があります。外部のマシンに表示している xterm プロセスがないかも調べます。
cronやatで動かすファイルを調べます。同時にcronやatのjobファイルや，これらが参照するファイルやプログラムが，所有者以外に対して書き込み許可になっていないかどうかも確認します。
/etc/inetd.conf が書き換えられていないか，またこのファイルに記述されているプログラム自体に変更が加えられていないかを調べます。
/etc/passwd ファイルが変更されていないかを調べます。知らないユーザまたは空行が加えられていないか。
システムやネットワークの設定ファイルが変更されていないかどうかを調べます。例えば，`+'のエントリがないか，/etc/hosts.equiv， /etc/hosts.lpd に外部のホストが追加されていないか， .rhosts ファイル(特にroot, uucp, ftp 等の .rhosts)に不審点はないかなどを確認します。ログファイルや hosts.deny が削除されたり， /dev/null へリンクされていないか。 index.html ファイルが不正に書き換えられていないか。
システム上に不審なファイルやディレクトリ(ドットファイルも含む)が作られていないかを調べます。特に /dev ディレクトリは，侵入者がしばしばファイルを置いていくことがありますので，注意が必要です。 /tmp ディレクトリのドットファイルも /tmp/.w0rm， /tmp/.w0rm0r などが置かれることがあります。
ローカルネットワーク上のホストに異常がないかを調べます。特にNIS を使用している場合や，.rhosts ファイル， /etc/hosts.equiv に登録されているホストは同様の被害にあっている可能性があります。

　スキャンを試みられた場合には，次のような痕跡が見られることがあります。

ドメインネームサーバに登録されているホストを調べて攻撃目標を探すことがあります。ネームサーバのログを見て，外部からのゾーン転送要求の記録があれば，ホスト名の一覧を持って行かれたと判断されます。
ICMP Echo 要求により，あるIPアドレス範囲に存在するホストを調べ，それから本格的に攻撃をかけることがあります。netstat -s コマンドで表示される Icmp: Input: echo の数が (pingコマンド等による正常なものよりも)多ければ，しかも近くのホストで似た状況ならば，外部からスキャンを受けた可能性が高いと判断されます。
セキュリティホールをスキャンされた場合(しかも，失敗した場合)に，同一のホストから複数のセキュリティホールをためした記録がログに残ることがあります。

　上記のような痕跡が認められた場合には，3.3節を参考にして，至急対処して下さい。

3.3 root権限の不正アクセスを受けた場合の対処

　この節では，不正なアクセスを受けてしまった時の対処法を紹介します (*31)。侵入して root 権限をとられた場合には，侵入の裏口を作られることが多いので，セキュリティホールをふさいだりパスワードを変更するだけでは効果がなく，システムを作り直す必要があります。

被害を受けたホストをネットワークから切り離します。システムをリブートしたりシングルユーザモードにすると，侵入の痕跡を調べる情報も消される場合がありますので，この時点では行わないで下さい。
システムのバックアップを作成します。
3.2節で紹介したチェック事項を確認します。
オリジナルのOSを新たにインストールし，セキュリティパッチを当てます。システムの再構築にはオリジナルのメディアや，バイナリからインストールして下さい。システムのバックアップからデータを復旧させる時は，このバックアップ自体も侵入を受けている可能性があることを念頭に置いて下さい。
システムの設定ファイルやサービスを確認し，不必要なサービスは停止します。
パスワードファイル等が流出している可能性がありますので，不要なアカウントを削除し，rootを含め全ユーザのパスワードを変更します。その際，fingerコマンド等で用意に推測できるようなパスワードは避けて下さい。不正アクセスを受けていない場合でも，パスワードを定期的に変更することは有効です。
セキュリティツールをインストールします。
ネットワークに接続します。

3.4 パケット盗聴プログラム

　ホストに侵入し root権限を手にいれた侵入者は，パケット盗聴プログラムを仕掛けることが多くあります (*32)。これにより，ネットワーク上を流れるパケットを拾って，ログイン時に入力するホスト名，ユーザ名，パスワード (平文) やそのほかの情報を収集して，次の標的を探すことがあります。そのプログラムは，不正に侵入したときにインストールする，お決まりのプログラムのセットに入っています。ほかに，正規のコマンドのファイルと差し替えてユーザに実行させて情報を収集したり被害を与える，トロイの木馬のプログラムもセットに入っていることがあります。

(*29) (参考) Packet Filtering for Firewall Systems ftp://ftp.jpcert.or.jp/pub/cert/tech_tips/packet_filtering。
List of Security Tools ftp://info.cert.org/pub/tech_tips/security_tools。
(*30) (参考) ftp://ftp.cert.org/pub/tech_tips/intruder_detection_checklist。
(*31) (参照) http://www.cert.org/tech_tips/root_compromise.html。
(*32) (参考) ftp://www.cert.org/pub/advisories/CA-94:01.ongoing.network.monitoring.attacks.html。

4 UNIXシステムでの設定上の注意

　この節では，一般的なUNIXの設定上の注意事項を紹介します。不正アクセスの防止にも役立ちます (*33)。

パスワードには，fingerやruserの情報から容易に推測できるようなものを設定しないで下さい。辞書に載っているような単語，有名な固有名詞，頭字語，自分の名前の簡単な変形などは避けるようにします。また，ユーザ名やパスワードを書き留めておくことはしないで下さい。
パスワードなしのアカウントや，デフォルトのパスワードのままのアカウントを残しておかないで下さい。
パスワードの再利用は避けて下さい。
tftpのサービスを停止する，もしくはアクセス制限を設定して下さい。tftp の利用により，システム上のworld-readableなファイルが，外部へ転送されてしまう可能性があります。
sendmailは常に最新のものを使うようにします。
anonymous ftpの設定には注意します。
ネットワーク設定ファイルのエントリに注意します。 /etc/hosts.equiv や .rhosts に `+' が書かれている場合は消して下さい。また，これらのファイルは world-writable であってはいけません。また，Xsession ファイルに `xhost +' という記述がある場合は消して下さい。
/etc/ttyps または /etc/ttytab などで， console以外には `secure' をつけないようにして下さい。
/etc/aliases の不適当なエントリに注意して下さい。特に `uudecode' や `decode' というエイリアスは消去して下さい。
システムのファイルやディレクトリの許可モードが適切に指定されていることを確認します。特に/，/etc，システム/ネットワーク設定ファイルには注意が必要です。
システムソフトウェアはアップデートをしてパッチを当てるようにします。
setuid シェルプログラム(特にsetuid root)は使用しないようにします。
/etc/exports ファイルをチェックします。
- 必要がない限りファイルシステムはread-onlyでexportする。
- exportsファイルの中でそのホスト自身を指定しない。
- ホスト名に`localhost'を使用しない。
- 必要なホストにだけファイルシステムをexportする。
- 素性の分かっているホストにだけexportする。

(*33) (参考) ftp://ftp.cert.org/pub/tech_tips/UNIX_configuration_guidelines。

www-admin@tohoku.ac.jp
pub-com@tohoku.ac.jp