アクセス制御

• 1.0.0 筆者の環境
• 1.1.0 サーバー環境
• 1.2.0 ファイアーウォール
• 1.3.0 クライアント
• 2.0.0 問題点
• 3.0.0 解決の方向
• 3.1.0 POP3 before connection
• 3.2.0 補足的なコメント(1)
• 3.3.0 補足的なコメント(2)
• 3.4.0 pop3d へのパッチ
• 3.5.0 POP3 ポート
• 3.6.0 /sys/log/okip に関するコメント
• 3.7.0 デモン型のポートの保護
• 3.8.0 コネクションのリレー
• 3.8.1  relay
• 3.8.2  secstore のリレー
• 3.8.3  9fs のリレー
• 3.8.4  aquarela のリレー
• 3.9.0 リレーに関する注意
• 4.0.0 connect の応用
• 5.0.0 nodos, connect, logit

2005/05/14
履歴:

• 2005/05/10

筆者の環境

サーバー環境

これらのサーバには時折いたずらの telnet や ssh ボートへのアクセスがある。現在の所、これらは単なるいたずらに留まっており、現実的な脅威ではないが、対策をとることにした。

ファイアーウォール

クライアント

問題点

解決の方向

POP3 before connection

#!/bin/rc
ifs=! r=`{cat $3/remote} {ip=$r(1)}
if(test -e /sys/log/okip/$ip)
        exec /bin/ip/telnetd $*
echo Login rejected

/rc/bin/service/tcp23 の内容

ディレクトリ /sys/log/okip にアクセスを許可する IP アドレスと同名のファイルを作成しておく。例えば 164.46.240.3 に許可する場合にはファイル 164.46.240.3 を /sys/log/okip に作成しておくのである。クライアントからの作成は POP3 によって行う。POP3 認証に成功した場合には、成功した IP アドレスを /sys/log/okip に登録する*。

	ifs=! r=`{cat $3/remote} {ip=$r(1)}

	exec /bin/ip/telnetd $*

	/net/tcp/90

	cat $3/remote

	cat /net/tcp/90/remote

	164.46.240.3!18617

補足的なコメント(1)

	'164.46.240.3#32'

	'164.46.240.0#24'

Plan 9 の smtpd は esmtp をサポートしている。つまり、パスワード認証によってリレーの可否を決定できる。この方法であれば不正リレーを正しくカットできる。
また smtpd の -g オプションはなかなか旨く働いている。ratfs に頼らなくても筆者の環境では SPAM メールは適正レベルにまで落ちている。

補足的なコメント(2)

1. pop3 の認証パスワードは Plan 9 のバスワードとは異なるものに設定できる事
   
2. pop3 はシステムへの侵入路にはならない事
   
3. pop3 はボピュラーな事
   

による。従って Plan9 パスワードが使われる全てのポートに IP による保護を掛ければ pop3 パスワードと Plan 9 パスワードが同時に漏れない限り侵入が困難である。もちろん bootes には pop3 パスワードは必要ないし、与えない方が良い。

pop3d へのパッチ

        enableaddr();
        if(readmbox(box) < 0)
                exits(nil);
        syslog(0, "pop3", "OK %s", peeraddr); //Kenar
        return sendok("mailbox is %s", box);
}

	ar Apr 12 15:56:18 OK 202.250.160.166

POP3 ポート

#!/bin/rc
ifs=! r=`{cat $3/remote} {ip=$r(1)}
if(! nodos $ip 110){
        echo '-ERR Busy'
        exit
}
/$cputype/bin/upas/pop3
a=`{tail -1 /sys/log/pop3}
if(! ~ $a(6) $ip)
        exit
if(test -e /sys/log/okip/$ip)
        rm /sys/log/okip/$ip
touch /sys/log/okip/$ip

/rc/bin/service/tcp110 の内容

nodos のソースは後にまた解説するが、このプログラムは nodos の引数で与えた IP と同一の IP から多数の同時アクセスが発生している場合にエラー終了する。もう一つの引数(110) は nodos のログファイルにポート番号を残すために使われている。

ディレクトリ /sys/log/okip の許可ビットは

	d-rwx-wx-wx /sys/log/okip

/sys/log/okip に関するコメント

このディレクトリは本当はシステムユーザの悪態から保護されるべきである。しかし先に述べた許可ビットでは保護されない。この問題は、pop3 を none ではない仮想ユーザとして実行すれば解決できる。

このディレクトリの有効期間が過ぎたファイルは定期的に cron によって削除されるべきである。

デモン型のポートの保護

筆者のサーバでは secstore、 fossil への不正アクセスは未だ観測されないものの Plan 9 では重要なポートである。他方 aquarela には不正アクセスが多発し、しかも aquarela は 0.5 版に留まっているように十分な強度を持っていないように思える。

これらにパッチを当てるのは避けたい。以下の方法を採用すればパッチ当ては避けられる。

コネクションのリレー

relay

#!/bin/rc
#
#       usage: relay from_addr to_addr
#
#       Log is put into /sys/log/relay
#       Incomming call is relayed if and only if
#       it is allowed by /sys/log/okip/*
#
switch($#*){
case 1
        ifs='!
        ' r=`{cat $net/remote} l=`{cat $net/local}{i=$r(1) p=$l(2)}
        # $i is remote ip
        # $p is local port
        logit -l relay $p $i
        if(test -e /sys/log/okip/$i)
                exec connect -v $1 |[2] logit -l relay
        echo Rejected
case 2
        exec aux/listen1 $1 /bin/relay $2
}

relay の内容

relay の引数 from_addr と to_addr は

	tcp!ホスト名!ポート名

このスクリプトの中での

	$net

	/net/tcp/90

logit はログを採るためのプログラムで、使い方は

	logit -l logname [message ...]

relay に現れる connect は con と似ているのだが、con のようによけいな事をしない。純粋に標準入出力を指定されたアドレスに転送しているだけである。con にそのようなオプションがあれば connect を持つ必要は無いのだが今の所は無い。

connect の使い方は

	connect [-v] addr

relay のログが欲しくなるのは最初だけかもしれない。ログが不要なら

#!/bin/rc
#
#       usage: relay from_addr to_addr
#
#       Log is put into /sys/log/relay
#       Incomming call is relayed if and only if
#       it is allowed by /sys/log/okip/*
#
switch($#*){
case 1
        ifs='!
        ' r=`{cat $net/remote} l=`{cat $net/local}{i=$r(1) p=$l(2)}
        # $i is remote ip
        # $p is local port
        if(test -e /sys/log/okip/$i)
                exec connect $1
        echo Rejected
case 2
        exec aux/listen1 $1 /bin/relay $2
}

ログを採らない relay の内容

secstore のリレー

従って認証サーバ hera で

auth/secstored -s tcp!127.0.0.1!secstore
relay tcp!hera!secstore tcp!127.0.0.1!secstore &

	relay 'tcp!*!secstore' tcp!127.0.0.1!secstore &

9fs のリレー

一つは hera のサービスを il プロトコルに限定し、ar で

	relay tcp!ar!9fs il!hera!9fs &

二つ目は tcp!hera!9fs はファイアーウォールの後ろに隠し、ar で

	relay tcp!ar!9fs tcp!hera!9fs &

前者の方が厳重であるが。何れにせよ、大学の外のクライアントからは

	9fs ar

	bootargs=il

aquarela のリレー

もっとも筆者は Windows を使わないので aquarela もまた使わない。relay の実験は行っていないので、悪しからず。

リレーに関する注意

connect の応用

「9fs のリレー」で述べた事は次のように行う事もできる。

term%  mntgen
term% srv -e 'rx ar connect il!hera!9fs' foo /n/foo
post...
term% ls /n/foo
/n/foo/386
...
/n/foo/mnt
/n/foo/n
/n/foo/power
/n/foo/rc
/n/foo/sparc
/n/foo/sparc64
/n/foo/sys
/n/foo/tmp
/n/foo/update
/n/foo/usr
term%

nodos, connect, logit

• nodos download
• connect logit relay