大学ネットワークにおけるサブネット管理者とのネットワークセキュリティ・トラフィック情報の共有
細川 達己，金子 康樹
慶應義塾インフォメーションテクノロジーセンター本部
hosokawa@keio.jp, yasuki.kaneko@keio.jp

Sharing Network Security and Traffic Information with
Subnet Administrators in University Network
Tatsumi Hosokawa, Yasuki Kaneko
Information Technology Center, Keio University
概要
慶應義塾においては、歴史的に多くのサブネットが存在しているが、昨今セキュリティ面での問題が深刻化している。その対策の 1 つとして、L7 ファイアウォールや基幹ルータなどから提供されるトラフィックのデータを格納し、高速な検索を可能とするデータベースと、そのデータベースを用いて異常な動作を抽出するためのトラフィック情報提供システムを構築した。
2017 年 1 月から、本システムを利用して、サブネット毎に分類されたトラフィック情報を、直接サブネット管理者に配信する機能の試験運用を開始した。まだ小規模な試験運用のため、顕著な成果は出ていないが、今後さらに広範囲なサブネットに提供先を拡張することで、管理者のセキュリティ意識やスキル向上に効果を発揮することを期待している。

1などの原因で十分な対応が取られない場

本学のネットワークの現状
本学では比較的初期からインターネットに接合がある。
l

学生がサブネット管理者となることが多続していたためか、特に理工学部のある矢上キャ

いが、学生は数年で卒業・修了してしま

ンパスを中心に、学内ネットワークが次のようなうことが多く、その際に知識やノウハウなどが継承されないケースが散見され1特徴を持つ傾向がある 。
lll

スのサブネットを割り当てられている。

これらの問題が本学固有の問題かというと、そのサブネット上で様々なサーバやクラたとえば 2013 年頃からしばしばメディアに取りイアントマシン、複合機、ファイルサーバ上げられている、複合機等からの情報漏洩などに等を運用している。

関する報道を見るかぎり[1]、似た問題を抱えた大昨今の状況から、そのようなサーバやクラ学も多いと想像できる。

イアントマシン、複合機、ファイルサーバ等でセキュリティインシデントが頻発している。
ll

る。

多くの研究室や部門がパブリックアドレ

これらの問題に対して、本学では次のような対応を今まで行ってきた。
l

Web サイトやメールサーバなど、わざわインシデント発生時に、研究室や部門のネざ自分でサーバを立ち上げる必要性がットワーク管理者への連絡先が不明だっ低下したサービスに関しては、学外のホたり、連絡がつかなかったりする。

スティングサービスや SaaS のクラウド

仮に連絡がついても、管理者のスキル不足サービスへの移行を支援する。
l1

本学の湘南藤沢キャンパスと、それ以外のキャンパスとはネットワークの運用体制が異なる。本稿の内容は、主に湘南藤沢キャンパス以外のキャンパスにおけるネットワークの運用管理に関するものである。

L7 ファイアウォールや基幹ルータ等の出す情報を分析して、概要や警告を提供するシステムを構築する。

l

複合機、ファイルサーバなどの調査を行

図 1

l2

トラフィック情報提供システムの構成概要

い、脆弱な設定の機器の存在するサブネ情報収集・分析目的のために機能強化が行われた。

ット管理者に警告する。

何度かの大きな改修を重ね、トラフィックデータ

インシデント発生時の、サブネット管理のソースはルータの ACL ログから L7 ファイアウ者への連絡体制を整備する。

ォールに移行し、さらに DNS キャッシュサーバのトラフィック情報提供システム
以上の対策のうち、「L7 ファイアウォールや基幹ルータ等の出す情報を分析して、概要や警告を提供するシステム」に関して紹介する。

ログや、基幹ルータの NetFlow 情報なども格納するように強化された。現状のシステム構成の概要を図 1 に示す
現在では、1 日あたり約 2 億行のデータが、発生から数分以内に SQL データベースに格納され、2003 年、本学ではファイル共有ソフトウェアの即座に高速な検索が可能な体制となっている。こ適切な利用に関するポリシーを決定した[2]。そののデータベースは、高速な NVMe SSD 上にデータ概要は次の通りである。

を持つ PostgreSQL で実現されている。このサーバ

l

学内で、特定のファイル共有ソフトを利用のハードウェア、ソフトウェア仕様を表 1 に示す。

するにはインフォメーションテクノロジーセンター（以下 ITC）に対する申請が必CPUIntel Xeon E5-2407 (4Core, 2.20GHz)
×2

要である。
l

利用目的は研究・教育目的に限る。

メモリ24GBl

申請のない利用はしてはならない。

SSDl

これらの目的を達成するため、ITC は適切

Intel SSD DC P3600 1.6TB(SSDPEDME016T4)
FreeBSD 10.3-RELEASE
PostgreSQL 9.5.3

なネットワークの監視を行う。
l

問題があれば ITC はサブネット管理者に調査・対象を依頼する。

lOSRDBMS

表 1 トラフィック情報提供システムサーバ仕様

対処が不十分な場合は、ITC は通信制限を行うことができる。

このデータベース上で、平均的な L7 ファイア

このポリシーに基づきネットワークを運用しウォールによるトラフィック情報 1 日分（約 8000ていくため、ITC では、ルータの ACL ログからフ万件）に対して、学内の宛先 IPv4 アドレス全て（ネァイル共有ソフトの利用が疑われるトラフィック

ットマスク 16 ビット= 65,536 件）毎に、すべてのを検出するシステムを構築した。

トラフィック情報を検索した場合の、検索時間（msこのシステムは、さらに汎用的なセキュリティ単位）の分布を示したグラフを図 2 に示す。

は、大幅な性能向上を実現すると同時に、IPv4/IPv6アドレスとネットマスクの包含関係による検索が可能となった（この機能は PostgreSQL の INET データ型と包含関係演算子を利用している）。
現在、学内に登録されているサブネット数は、IPv4 が約 660 個、IPv6 が約 190 個ある。これらのサブネット情報とサブネット管理者の情報を、トラフィック情報警告システムの PostgreSQL データベースに格納することで、以前から構想していた「システムの出す警告や各種情報を、サブネット管理者ごとに仕分けして提供する」システムの実現が非常に容易なものとなった。
これは、サブネット管理者に対して、自分の管

図 2

トラフィックデータベースの検索性能理下のネットワークで何が起こっているかを直接可視化することによって、次の目的を実現するこグラフ上は検索時間 50ms までのデータを示しとを意図していたものである。ているが、この範囲内に全データの 97.6%が含まlれている。検索時間の全体平均は 17.3ms である（なサブネット管理者のセキュリティ方面の意識向上とスキル向上

おこの例では、トラフィック情報の収集スクリプl

時間がかかりがちなサブネット管理者へト等を実行した状態で、性能測定を行っている。の連絡パスの簡素化（少なくとも、ITC ス

検索時間は、psql コマンドで出力先に/dev/null をタッフの不在時でもサブネット管理者に指定した状態で、timing メタコマンドで測定を行直接情報が提供される）った）。改修時、SQL データベース以外の採用も検討したが、このように性能的にまだ十分単体のPostgreSQL でカバー可能であることから見送った。
トラフィック情報提供システムのサーバ上では、多くの解析スクリプトが動作しており、この高速なトラフィックデータベースに数多くのクエリを送ることで、様々なインシデントに繋がる情報を抽出し、提供している。
また、インシデント発生時は、このデータベースを検索することで、同様の問題が発生していないかどうか、あるいは被害が拡散していないかどうか、等の検索を非常に効率的に行うことが可能である。さらに必要であればそこで得られた知見を解析スクリプトに反映することで、情報抽出能力の向上に役立てている。
また、外部機関から提供される DNS ブラックリスト情報なども、随時このデータベースに追加している。

3

サブネットデータベースの統合

4

試験運用開始2017 年 1 月 26 日から、理工学部の矢上キャン

パスを中心に、ITC が任意の申込みを募る形で、本システムの試験運用を開始した。矢上キャンパ
スでは、サブネット管理者などを対象に、ネットワーク管理に関する講習会を不定期に開催しているが、その席などでも、試験運用開始に関する広報を行った。
試験運用を公開するにあたって、システムの全機能を公開するのではなく、まずは偽陽性の検知が比較的少なく、また理解が容易であると考えられる警告や情報提供に限って運用を開始することとした。一般の研究室に対して提供される警告・情報提供は以下のとおりである。
l

学外向け SSH, RDP, SMTP セッション数の異常上昇（随時）lL7 ファイアウォールが検出した学外への脅威トラフィック（随時、毎日）

l

L7 ファイアウォールが識別不能としたトラフィックに関する各種情報（毎日）

2016 年に行った本システムの大規模な改修でl

非常に大容量の通信を行っているホスト

とその通信プロトコル等に関する情報（4

発見し、また外部組織からのインシデント情報提時間ごと）

供に対して、迅速な影響範囲の調査や原因究明、この情報提供メールの例を図 3 に示す。これは再発防止に役立ってきたという実績がある。

学内のある IP アドレスに対して、SMTP 通信が急一方で、このトラフィック情報のサブネット管増したことを知らせるメールで、過去 2 日間の 1理者に対する直接提供に関しては、従来は ITC か時間毎の SMTP 通信量の推移と、通信相手の IP アらサブネット管理者に対して、インシデントに関ドレス上位 5 位を示している。

する連絡をする一方通行だったものが、逆にサブ

この例では、7 月 27 日の朝 6 時台から、明らかネット管理者から「この情報は問題のあるものか」に異常な量の SMTP 通信が発生していることが容という質問がしばしば聞かれるようになったこと易に見てとることができる。

は一つの成果であるといえる。しかし、全体的に2017 年 9 月現在、理工学部矢上キャンパスを中心とした 28 の組織（主に研究室）が利用を開始しは未だ大きな成果を上げているとは言い難い。これにはいくつかの原因が考えられる。
lている。これらの組織が利用しているサブネット試験運用段階ということもあり、まだカバの合計は、IPv4 が約 180 個、IPv6 が約 80 個であーしている IP アドレスの範囲は、全学のる。組織数が少ない割に多くのネットがカバーさネットワークに比してごく狭い範囲であれているのは、大量のサブネットを管理しているる（先述の通り、ITC を除いた IPv4 アド

ITC が含まれるためであり、これを除くと IPv4 がレスのカバー率は約 5%）。
l

約 60 個。IPv6 が約 10 個となる（全学の IPv4 アドレスのカバー率としては、未だ約 5%にすぎない）。

5

任意で参加研究室を募っているため、一般的にセキュリティ意識の高いサブネットや、最近何かインシデントを起こしたこと導入の効果があるために、危機意識が強くなっているサブネットの参加が多い。

導入の効果であるが、まず「トラフィック情報提供システム」自体は、2003 年の導入から実に 14このため、今後理工学部でより広い範囲に参加年が経過しており、その間多くのインシデントをを募ったり、あるいは他キャンパスに募集を広げたりすることで、対象となるサブネットを広げていけば、より顕著な導入効果が現れてくることもあるのではないかと考えている。

6

今後の課題
本システムに関する今後の課題として、以下の内容を検討している。
l

メールでの情報提供に代えて、何らかのWeb 系のアプリケーションで情報提供とサポートを行う。タスク管理ツールの他、LMS 系のツールも採用を検討中である。

l

さらに広範囲のサブネット管理者に、試験運用への参加を呼びかける。

l

現状では NetFlow のデータをあまり活用できていないので、NetFlow を含めた解析を行うようにシステムを改良する。

l

PostgreSQL 9.6 以降にアップグレードすることで、シーケンシャルスキャン、結合、集約の並列処理による検索の高速化を図

図 3

大量 SMTP 通信情報メールの例

る。

l

さらに多様な解析の実験を行い、広く有用なものはサブネット管理者にも提供していく。

参考文献[1] 日本経済新聞、「複合機の情報、ネットで丸見え、東大など、コピーやスキャンした文書、内部に蓄積」、日本経済新聞 2013 年 11 月 8
日付朝刊、p.43、2013．
[2] 慶應義塾インフォメーションテクノロジーセ
ンター、「ファイル共有ソフトウェアについて」、http://www.itc.keio.ac.jp/ja/software_files
hare.html、2013．