- PR -

インターネットへのRPC通信

1
投稿者投稿内容
某学校サーバ管理者
会議室デビュー日: 2004/05/24
投稿数: 18
投稿日時: 2004-11-29 15:39
こんにちは。
とある学校でネットワーク管理者をやっております。

現在本校では、インターネットの接続口にFireWallを設置しており、
 ・インターネットからの不要な通信は遮断
 ・インターネットへの通信は、RPC系通信を除いて制限なし
という設定をしています。
後者の設定は、お察しかとは存じますが、だいぶ前にBlasterウィルスの感染が学校内で発生した際に、学外からのクレームで投入したものです。

それ以降、このFireWallのアクセスリストの記録を一つのバロメータとして、学内のウィルス感染を監視していました。(他の機器には予算がつかず。。。)

利用者への教育の甲斐もあり、現在ではパッチ適用等対応が十分にされているので、感染端末が存在した時のような、1時間あたり1万件単位のRPCパケット捕捉は発生しないようになりました。
但し、週に数十個のRPCパケットが、現在でもインターネット向けに捕捉されます。

このパケットは一体なんだろう。というのが、今回の質問を主旨です。


FireWallへ流れるパケットを全てSpanして、スニファでRPCに絞ってパケット採取をした結果、
 ・Dist Port:TCP139、TCP445 (なぜか2つのポートに、ほぼ同数が出ている)
 ・Dist IP Address:
   - 送信先は一定(一箇所)で、シーケンシャルにアドレスを探る動きはない
   - 一部の通信は、なぜかプライベートアドレス宛てである
   - グローバルアドレスの物についても、DNSで逆引きできるようなものはない
 ・Source IP:5台の学内端末 (グローバルアドレスです。)
 ・個数:おおむね10個くらい。1分以内に連続して発生。5台とも別々のタイミングで発生。
 ・内容:空 (遮断された為、コネクションだけで終わった為かもしれませんが、
        コンテンツ部分が0byteでした。)
という通信が、1週間で5回ほど検出されました。

残念ながら、プロキシサーバなどがないため、学内端末がどのような通信をしているかを記録している物がありません。(スニファのフィルタ設定を外して全パケットをとって、RPC通信発生直前の通信を調べる事も出来そうですが、ディスクが足りるかどうか。。。毎日出ているわけでもないので。)
また、参照URLにあるようなWord文書の閲覧を考えましたが、ヒアリングできた一部の利用者からは、RPC通信が発生した時間帯は、IE上でWord文書を見ていないという回答が得られています。
また、発信元のPC端末には念のためウィルススキャンをかけましたが、感染は認められませんでした。(過去のログ上を含めて。)

本来、こうしたtcp139/445といった通信は、インターネットには送信される必要のない通信、という認識でおり、また利用者から、「RPC通信を止めてから、××が出来なくなった」というクレームも受けない為、
 ・ウィルス感染を示す兆候ではない。
 ・通信に(FireWallで止められるので)失敗しても、利用に差し支えない通信である。
という所までは言えそうなのです。しかし、実際にどのような利用をすると、こうした通信が発生するのかが、分からない状態でいます。

「ウィルス感染がなく、安全であることが確認できた」ので、良いといえばよいのですが、一つには、万が一にも必要な通信(利用者の広義の誤操作を含めて)を止めていないか、という事が気がかりです。
一番の理由としては、はっきりしないから気持ちが悪い、というところです。

こうした、インターネット向けの正常な(?)RPC通信について、ご存知の方がいらっしゃいましたら、お教えいただきたく存じます。
以上よろしくお願い致します。
komey
ベテラン
会議室デビュー日: 2003/11/27
投稿数: 76
投稿日時: 2004-11-29 20:09
引用:

・内容:空 (遮断された為、コネクションだけで終わった為かもしれませんが、
        コンテンツ部分が0byteでした。)



FireWallやパケットフィルタというのは、TCPのSYNを送ったところでブロックするよう、(普通は)設定するため、残念ながらデータは残りません。
データがないので、あとはクライアントを調べるしかありませんが、ログなんて残ってない、あるいは残っていてもそもそもログファイルを見つけるのが大変でしょうから、調べるのは非常に大変かと思います。
端末がWindowsXPで、運よくSocketが残っている状態に出くわしたならば、コマンドプロンプトで
> netstat -nao
> tasklist
を実行すれば、どのプロセスに起因するものかわかりそうです。
ちょうど、@ITに記事がありました。
http://www.atmarkit.co.jp/fwin2k/win2ktips/236portcheck/portcheck.html


なお、139や445はファイル/プリンタ共有する場合に使うポートであり、あまり外部に公開されるようなものではないので、どこかインターネット上のサーバの共有ファイルを使っている、など、管理者に覚えがないのであればそのまま閉じておいて問題ないと思います。
# ってことは、ネットワークプリンタの作成とか、IPアドレス直打ちで共有ファイルにアクセスしようとするこのパケットが流れるのかな?

Uchikoshi
@ITエディタ
会議室デビュー日: 2001/07/27
投稿数: 197
投稿日時: 2004-11-29 20:34
 137〜139はNetBIOS、445はDirect Hosting of SMB Over TCP/IPサービスという、ファイル共有で利用されるポートです。これらのポートはWindowsネットワークにおける非常に基本的なポートであり、利用しないようクライアント側で止めることは困難です。

・ポート445(ダイレクト・ホスティングSMBサービス)に注意
http://www.atmarkit.co.jp/fwin2k/win2ktips/088directhostedsmb/088directhostedsmb.html
(これ以外にも、TCP 139 445などで検索すると、この手の情報はたくさん得られます)

 なお、139と445へ同時にアクセスするのは、Windows 2000以降の仕様です。どちらかで接続を試み、成功した方でファイルアクセスを行います。

 ところで、どこでこのようなアクセスが発生するかですが、Windowsの基本プロトコルであるがゆえに、さまざまな場所でこのアクセスが勝手に発生する可能性があります。例えばブラウザで http://server/... とアクセスする代わりに、\\server とアドレスバーに入力するだけでも発生しますし、ドキュメント中に保存されているファイルサーバへのリンクをクリックするだけでも、勝手にアクセスが発生する可能性があります。また、一度使用したサーバへのショートカットなどがファイルの履歴(最近開いたファイル)などに保存されていれば、そこからアクセスしようとしたりしますし、サーバ名などを打ち間違えてたまたまそれがインターネット上のホストに一致していたりすると、そこへのアクセスが発生する可能性があります。また、自宅でサーバにアクセスしたあと、そのノートPCを学校へ持ち込んで起動すれば、(ネットワークのショートカットなどで記憶されていた)元のサーバをアクセスしようとして、このタイプの通信が発生したりもします(この場合は、たぶんローカルIPアドレス宛のアクセスになると思います)。

 というわけで、WORDのDOCに限らず、さまざまな場所で発生する可能性があります。

 一般的には、135番(MS-RPC)を止めるだけでなく、これらのポートも外部へアクセスしないようにファイアウォールをブロックするのが普通です(売っているブロードバンドルータでは、これらのポートはデフォルトで禁止になっているのがほとんどです)。これをしないと、外部から見れば不正アクセスみたいにみなされる可能性があります。また、ブロードキャストパケットなどに載せて、さまざまな情報が漏洩する可能性もあります。これらを禁止しても問題はまったくありませんし、むしろ、絶対通さないようにするべきです。これでユーザーから苦情が来るようならば、そのような使い方はしないように教育してあげてください。


 あとちょっと気になったのですが、ファイアウォールのポリシーで、

> ・インターネットからの不要な通信は遮断

としているそうですが、正しくは

・インターネットからの通信は、必要なもののみを選択的に許可、デフォルトは禁止

ではないのですか? もし特定のいくつかだけを禁止(かつ、デフォルトはすべて許可)となっているのでしたら、かなり危険かな、と思いました。

[ メッセージ編集済み 編集者: Uchikoshi 編集日時 2004-11-29 20:51 ]
某学校サーバ管理者
会議室デビュー日: 2004/05/24
投稿数: 18
投稿日時: 2004-11-29 21:14
komey様

ご返答ありがとうございます。
確かに、"現行犯"で現場を抑えられれば、対応方法はありますね。

ただ、今回に関しては、
 ・使用しているスニファの制約で、採取しつつリアルタイムでパケットを表示
  する事が出来ない
 ・RPCパケットの発生のタイミングが予測できない
 ・RPCパケットを送信する端末の予測が出来ない
という事から、現行犯逮捕でその現場を抑える事は難しい状態です。

というわけで、"こういう操作の時にそうしたRPC通信が発生する"、という事を経験した、或いは知っている、という情報があれば、と思い記載しました。


引用: -----------------------------------------------------------------------

  # ってことは、ネットワークプリンタの作成とか、IPアドレス直打ちで共有ファイル
   にアクセスしようとするこのパケットが流れるのかな?

 -----------------------------------------------------------------------------

確かにこの方法で、同様のパケットが送信されそうです。(netstatでのみ確認)
ただ、一部のヒアリングをした利用者からは、ファイル共有、プリンタ接続といった
操作を行った記憶はない、という回答がありました。
WEBアクセス(?)など、全く違う正常な?使用方法をしている裏で、RPCパケットの送信が
おきているのかなあ、と考えています。

某学校サーバ管理者
会議室デビュー日: 2004/05/24
投稿数: 18
投稿日時: 2004-11-29 22:40
Uchikoshi 様

ご返答ありがとうございます。
確かに、考えられるパターンは多いですね。
ログなし、対象者全員へのヒアリングが出来ない、という条件下では、雲をつかむような話しに思えてきました。

なお、ご指摘のありましたFireWallの学外->学内のポリシーは、
> インターネットからの通信は、必要なもののみを選択的に許可、デフォルトは禁止
という表現の方が正しい状態にあります。
(WEBサーバ、MAILサーバ等一部のホスト宛てに、80、25等のポートを限定的に許可)
お騒がせ致しました。
kaz
ぬし
会議室デビュー日: 2003/11/06
投稿数: 5403
投稿日時: 2004-11-30 01:06
こんばんわ.

その手の通信は意図しなくても頻発するのでは?
Firewall を構築する際,
意図的に drop しつつ logging しないことが多いです.
Linux の Netfilter で,iptables による設定事例にも数多く公開されています.
あまり気になさらないで良いのではないかと愚考いたしますが...
1

スキルアップ/キャリアアップ(JOB@IT)