1. はじめに

このテキストは、侵入者からIRIXの身を守るための罠について書いてます。メインはIRIXですが、他のUNIXでも応用できる物もあります。私が以前書いた「IRIX攻撃マニュアル」にもありますが、IRIXにはポート5232でlistenしてる特殊なアプリがあり、それでIRIXマシンを特定されます。さらに、ディフォルトアカウントが幾つか存在しますので、それにパスをかけてない場合はさらっと侵入され、ヘボい場合はサクっとrootを盗られます。一度ハックされると多少の対策はムダというものです。こうなったら、侵入者を取っ捕まえて「ごめんなさい」と言わせましょう、ってのがこのテキストの主旨であり、けっして「ハッカーのためのIRIX鯖の罠の見破り方」じゃないです。

2. ある日気付く

いくらヘボい管理者が管理してても、いづれは侵入されたことに気付くってことはよくあります。そう、踏み台にしてる場合ですね。踏み台経由でターゲットに侵入したのはいいけれど、root盗れなかった、もしくはトロイ等の結果待ちってことはありがちですね。どの鯖でも速攻って訳にはいきません。そういうときに、ターゲットの管理者がログをチェックして、踏み台にクレームをつけるわけです。そうやってヘボい管理者はハックに気付きます。

3. 対策する

さて、どうしたものか... と管理者は考えます。firewallは導入するのには検討会議やなんやで時間がかかるし、お金もかかるし、不便だし。そこで、罠を仕掛けるわけです。以下に罠の例を挙げます。でも幾つかの罠は、やっぱり見破られて外されてしまいます。それらの罠の問題点も明確にすべく、見破り方もかいてます。要するに、そういう罠はrootとられると無意味ってことですね。

[1] TCP-wrapper

有名ですね。本来は指定IP以外のTCPを通さないようにするっていう目的で使われます。でも、どこからでもアクセスできるようにして、ログだけとることができます。コイツはデーモンですが、inetdから直接telnetd等を呼ばず、このデーモンから間接的に呼ばれます。このデーモンは、バレにくくするため通常in.telnetd等の名前にして、本物のin.telnetdなどは別に保存されているコトがおおいです。

見破り方 (以下のいずれか一つでもあると、TCP-Wrapperが入ってる可能性があります)

(1) /etc/hosts.arrowや/etc/hosts.denyとかいうファイルがある
接続許可、拒否ホスト一覧です。

(2) /etc/syslog.confにロギングが指定されている
local5.info /var/log/tcp_wrapper.log
みたいに指定されています。ほとんどコレで特定できます。
ログは、こんな感じで残っていきます。
Oct 21 11:12:13 hoge telnetd[1234]: connect from root@hacker.com
Oct 22 12:23:44 hohoho ftpd[4567]: connect from ppp01-hoge@hogehoge.ne.jp

(3) /etc/inetd.confで、telnetやftpなどに同じdeamonが指定されている
普通は、
ftp stream tcp nowait root /usr/etc/ftpd ftpd -l
telnet stream tcp nowait root /usr/etc/telnetd telnetd
みたいな感じですが、
ftp stream tcp nowait root /usr/etc/tcpd ftpd -l
telnet stream tcp nowait root /usr/etc/tcpd telnetd
みたいな感じになってます。

(4) だれかのhomeにTCP-Wrapperらしいソースが落ちてる
find / -name tcp_wrappers_7.6 -print みたいに検索すると出るかもしれません。

[2] cron

cronってのは、特定時間にとあるプログラムを実行させるというものです。これを応用して、wtmpやSYSLOG等をバックアップすれば、通常の方法でログ消しされてもログは残りますね。

見破り方

crontab -lとすると、現在のcrontabの設定状況が出ます。
%crontab -l
1 * * * * cp /var/adm/SYSLOG /usr/people/hoge/.cshrc_bak
みたいに出てきたら要注意。(これは一分ごとにSYSLOGをコピーするというものです)
ちなみに、crontab -lで出てくるのは、各ユーザーが設定したcrontabです。どのユーザが罠をはってるか分かりません。
ただ、crontabは
/var/spool/cron/crontabs
にspoolされますので、ここで確認できます。ちなみに、移動するにはrootじゃないとダメです。

[3] SYSLOG多重保存

IRIXのSYSLOGはwtmpより強力ですね。telnet失敗や5232記録(これはIPは出ないですが)、sendmailまでログります。普通は/var/admにありますね。これはsyslogdにより管理されてますので、/etc/syslog.confに
kern.debug |/usr/sbin/klogpp /var/adm/SYSLOG
*.debug;kern.none /var/adm/SYSLOG
*.crit |/usr/sbin/sysmonpp /var/adm/SYSLOG
みたいに書かれてます。
で、このセットをもう一つsyslog.confに指定する訳です。
kern.debug |/usr/sbin/klogpp /var/adm/SYSLOG
*.debug;kern.none /var/adm/SYSLOG
*.crit |/usr/sbin/sysmonpp /var/adm/SYSLOG
kern.debug |/usr/sbin/klogpp /usr/people/hoge/hohoho
*.debug;kern.none /usr/people/hoge/hohoho
*.crit |/usr/sbin/sysmonpp /usr/people/hoge/hohoho
これで、/var/adm/SYSLOGがいくら消されても、生き残ります。

見破り方

簡単ですね。/etc/syslog.confにあやしいものが書かれてたら、見に行きましょう。

[4] syslogd多重起動

SYSLOGを意地でも残すワザです。
%cd /usr/people/hoge
%cp /usr/etc/syslogd hogelogger
%cp /etc/syslog.conf hogelogger.conf
ログを指定
%cat hogelogger.confkern.debug |/usr/sbin/klogpp /usr/people/hoge/hohoho
*.debug;kern.none /usr/people/hoge/hoge.log
*.crit |/usr/sbin/sysmonpp /usr/people/hoge/hoge.log
kern.debug |/usr/sbin/klogpp /usr/people/hoge/hoge.log

%hogelogger -f hogelogger.conf
これで、多重起動です。hoge.logにSYSLOGと同じ内容が残ります。

見破り方

ps -elfとかで確認するしかないです。そして、'-f'オプションが指定されているヤツがあったら、そのファイルを検索します。catすれば確認できます。

[5] syslogd多重起動＋ps改

上記[4]で、発見を難しくするため、psを改造することもあります。つまり、psしてもhogeloggerが出てこないんですね。原理的には簡単で、ニセpsを/usr/binに置いといて、そのニセpsは、名前を変えられた普通のpsを呼んで結果をファイルに保存します。ニセpsはそのファイルの内容を読んで表示するのですが、そのときhogeloggerのみ表示しないようにすればいいのです。

見破り方

全バージョンのノーマルpsをコレクションしておきます。そして、バイナリで転送して、diff(ファイル比較)します。
%diff /usr/bin/ps ps_collection1
Binary files /usr/bin/ps and ps_collection1 differ
って出たら、内容が違うってことです。
もちろん、コレクションしたpsで実行すれば出ます。

[6] ニセDeamon

大抵オリジナル物ですね。TCP-wrapperみたいなヤツを作ってしまう訳ですが、/etc/syslog.confになんて何もありません。TCP-wrapperよりはちょっと高級ですね。こういうのを作れば、5232スキャンのIPをロギングすることも簡単です。tdmなんかも見つけることができると、尻尾をつかめますね。

見破り方

例えば、/etc/inetd.confでtelnetができないようになってるにもかかわらず、telnet出来てしまったらこういう罠が仕込まれてる可能性があります。
例えばこんな風に頭に#がついてるか、
#telnet stream tcp nowait root /usr/etc/telnetd telnetd
この行自体がないかです。
これの厄介なところは、ログがどこに残ってるのか分からない点です。しかも、オリジナル物なので、どういう形式かも分かりません。ログも暗号化されてると発見・削除は困難でしょうね。こういう時は、ニセデーモンのソースが落ちてないか、必死で探します。運良く見つかった場合は、ソースを便りに消すしかないです。ってことで、これは結構強力です。

[7] Packet monitoring

snifferなどはHackerの強い味方ですが、管理者にも強い味方です。このような、パケットLoggerを仕掛けると、どこから来てどこに行ったか、まる分かりですね。LAN内ならどこに仕掛けてもOKですから強力です。モニタリング専用サーバセキュをむちゃくちゃ強化して、ほとんどのネットワークサービスを禁止)が置いてあった場合は、侵入者にとってとってはかなりつらいですね。そういう場合は、発見・ログ消しは難しいでしょう。

[8] ログ転送

これも強力な例です。普通は[6]と組み合わせて使います。転送先がモニタリング専用鯖だったり、しっかりしたPCだったりすると、侵入者もお手上げです。しかも、パケットモニタリングでもしない限り、発見も出来ませんし、暗号化されてるとパケットモニタリングしてもムダです。外部からの侵入があると、警報装置が働く(PCが管理者に自動で電話をして、侵入者のドメインやIPを読み上げるなど)こともできますので、迅速に対応できます。

[9] システム監査トレールの管理

これは、ユーザーがやらかした反則行為までロギングします。このデーモンが走ってると、
%name -aで
Trusted IRIX/B　System_name ???? ?????
みたに表示されます。走ってなければ、
IRIX　System_name ???? ????
みたいな感じです。
ユーザがやらかした違反ってのは、アクセス許可の無いファイルアクセスを試みたり、パスワードを推測したり、通常の方法以外でrootになったり... 考えられる違反は全てチェックされます。もちろん、外部侵入も記録されます。しかも、ログファイルは独自の暗号化がなされており、しかもファイル位置は公開されていません。ログを編集できるのは、dbeditという専用ツールだけらしいです。

4. まとめ

罠も色々ありますが、結局管理者がどこまで本気でやるかってことにかかってきます。しかし、罠をはってるような所は本気の所が多いようです。逆に罠もセキュも何もない所ってのは、ハックされても文句は言えないんじゃないでしょうか。でも本気出さないとまずい場合もありますよ。企業だと特許に関連するようなデータ、大学・病院だと患者のカルテデータなどが入ってる鯖は極めて神経質です。自分の所に大事なデータが入っているときは、気をつけてくださいね。