1. HOME
  2. ブログ
  3. CS四方山話(第4 話)多段防壁とパケットフィルタリングの仕組みをヒモ解く

CS四方山話(第4 話)多段防壁とパケットフィルタリングの仕組みをヒモ解く

四方山

CS=サイバーセキュリティ

前回は、防壁 = ファイアーウォールの概念と、防御に関連するキーワードに関して触れました(防壁の話が大半になってしましましたが..)。

今回は、防壁を多段にする御利益や、パケットフィルタリングの実際に関して見ていくことにしましょう。

なぜ多段の防壁が求められるのか? そのメリットは?
防壁を多重に組むメリット。それは、防壁を1つ突破しても次の防壁が立ち塞がり、何度も防壁を突破する手間が掛かるという点にあります。玉葱のように剝いても剝いても次の層が出てくるパターン。「銀河英雄伝説」(※1)のバーミリオン星域会戦で帝国軍が採った「機動的縦深防御」が多重防壁の究極版ですね。

また、複数の防壁によって、社内のネットワークを役割ごとに区分するという効果もあります。たとえば企業において、人事情報や契約情報など機密情報を扱うネットワークと、全員がアクセスできるネットワークは分かれている方が管理しやすいでしょう。来客者が使用する会議室のネットワークは社内のネットワークとは分離しておくべきでしょう。インターネットからのアクセスを前提とするWebサーバーやアプリケーションサーバーを配置するネットワークと社内のネットワークも分離すべきです。要するに、社内のネットワークも、建物に色々な用途の部屋があるように、「区分け」が在った方がよい、というか必要ということです(会社全体が1つの大部屋というのは、使い勝手が悪そうですから)。

こうして分割したネットワークを「セグメント」(segment, network segment)と呼びます。マーケティングなどでも使われる用語ですが、適当な和訳が見当たりません。区分けしてできた区画、といった感じでしょうか。医療の分野では、輸血や人工心肺装置などで使われるセグメントチューブが登場します。人と人、人と機械を区分するモノ=チューブということになるのでしょうか? 自然言語は面白いですね。

L3 SW(Layer-3 Switch)で社内ネットワークを複数のセグメントに分割
それでは、セグメント分けを行ったネットワークの例を見てみましょう。

この例では、4つのL3 SW を用いて、社内のネットワークを6つに区分しています。第3話に登場したレイヤ(Layer)が出てきました。L3 SWは、異なるセグメントをつなぐ役割を担っています。Layer-2としてはL3 SWで分断されていますが、Layer-3としては中継を行います。片方のセグメントからのパケットを受けて、もう一方のセグメントにパケットを流します。

L3 SW は、自身のネットワーク・デバイスの数だけ(原理的にはいくつでも)「腕」を持つことができます。図でも、2つの腕のL3 SWと、3つの腕のL3 SWが記述されています。腕の数といえば、元素と分子構造が頭に浮かびます。腕2本だと酸素、腕3本だと窒素というのが身近な元素ですね(完全に余談です)。

防壁の議論とは違う観点になりますが、セグメントを分けることで、他のセグメントの影響を受けにくくするという効果もあります。テストなどで行う通信が、日常業務での通信を邪魔しないようにする。そのためにセグメントを分けるという方策も有効です。

パケットフィルタリングの基本的な仕組み
 L3 SWは、パケットを中継する際、このパケットは通そう、このパケットは通さないという選択を行います。例えば「外からパケットは条件に合ったものだけを通す」。「内からのパケットは通す」、「内からのパケットへの返信のパケットは外からでも通す」といった感じです。

パケットフィルタリング機能を担っているのは、たとえばLinux では iptables というサービスです。iptablesには3つのfilter が存在し、これによってパケットの流れを制御しています。入ってくるパケットを処理する”INPUT”。出て行くパケットを処理する”OUTPUT”。自分自身で受け取らないで中継だけ行うパケットを処理する”FORWARD”です。

Cisco IOS、JUNIPER Junos などのルータに特化した OS もあります。また、Linux 上で動作する Vyatta という仕組みもあります。が、ここでは(シンプルに)Linux 上 iptables で ルータ(の firewall 機能)を構成してみましょう。

iptables は、自機を守る盾にも使えますし、ネットワークデバイスが2つあれば、上記のように内側(device #2)からのパケットは外側(device #1)に透過させるが、外側からのパケットは条件に合ったものだけ通すというL3 SW機能も実現できます。

パケットをフィルタリングする。そのフィルタリングは、どのように行われるのでしょうか? 言い換えれば、何を元にパケットを通すかどうか判断するのでしょうか?

そのためには、パケットの構成を知る必要があります。パケットは「小包」という意味ですが、ネットワークでデータを送る際に、データを分割して相手に送ることになります。
パケットの先頭部分は「ヘッダ」と呼びます。ここには Layer-2 で定義される IPヘッダ や、Layer-3 で定義される TCPヘッダ や UDPヘッダ などがあります。

Layer-1 の ethernet frame はここでは割愛しますが、主な情報としては送信先MACアドレス、送信元MACアドレスです。IPヘッダ、TCP/UDPヘッダとは異なり、送信先→送信元という順番になっています。何故でしょう? なんとなく? 私は分かりません。正確な理由をご存知の方は、是非ご一報下さい。

IPヘッダの先頭4ビットは「バージョン」です。ここに 0100 = 4と書かれていればバージョン4、すわち IPv4 のパケットということになります。0110 = 6 と書かれていれば IPv6 のパケットということになります。ここで区別可能なので、IPv4 と IPv6 のパケットが混在しても平気です。

パケットフィルタで主に使われるものは、「プロトコル番号」「送信元・送信先アドレス」「送信元・送信先ポート番号」です。宛先のポート番号は、通常は、その相手に求めるサービスの定義に使います。22 = SSH、53 = DNS、443 = HTTPS といった感じです。

「プロトコル番号」は、IPヘッダ以降のパケットの形を決めます。主なものとしては、1 = ICPM、6 = TCP、17 = UDPなどです。ICMPはIPを制御する情報で「ポート番号」という概念を用いませんが、TCP・UDPではIPヘッダの次に「送信元・送信先ポート番号」が来ます。パケットが届いた時に、TCP/UDPヘッダの先頭まで読めば(その後ろは無視して)パケットのふるい分けができるということになります。

平たく言えば、パケットの先頭を見て、誰から誰へのどんな目的の通信なのかを判断して、通す・通さないを判断します。その判断が「パケットフィルタリング」ということになります。

ということで、紙面(文字数)の都合で、今回はここまでです。今回書き切れなかったWAF、IPSと、UTMなどに関しては、次回で見ていくことにしましょう。

(※1) **銀河英雄伝説** に関する解説:

– 原作小説(作:田中芳樹)

 – 本伝:10巻(1982 – 1987年)

 – 外伝:4巻(1984 – 1989年)

– アニメ

 – OVA 本伝:110話(1988 – 1997年)

 – OVA 外伝:52話(1998 – 2000年)

 – TV「銀河英雄伝説 Die Neue These」第1シーズン(2018)、第2シーズン(2019)、第3シーズン(2021予定)

– その他

 – 舞台版(2011 – 2015年)

 – 舞台版「Die Neue These」(2018 – 2019年)

 – 宝塚歌劇版(2012 – 2013年)

 以下、私見です。

– 根底にあるテーマは **民主政体、専制君主政体、どちらが better?**

 – 愚劣な手段であるが止められない **戦争**、 **テロリズム** では時代は変革しない

 – 組織と求められる人格・人間性、マキャベリズムとは

  ということで **大人** が読む/観る価値が充分にあります。

  ただ、上記の通りのボリュームですので、取り組むには一定の覚悟が必要です。

  作品が超大作で社会を描くモノでもあり、600人以上の登場人物個々に声優をアサインするため、国内の声優は払底し、役者さんなども動員されています。当時、現在に於いて一線級の声優さんが殆ど登場しており、「銀河声優伝説」とも称されていました。

  現在、新しいアニメ版「Die Neue These」(ドイツ語で「新たな定説(解釈)」)が進行中です。

  現在、第2シーズン(13-24話)の放映が終わったところで、第3シーズンが制作中。先は長いです。

  アニメとしては、約30年後の remake になります。

  旧作と新作共にストーリも台詞も原作に忠実ですので、アニメ自体の品質の違いは大きい。新作を観てから旧作を観ると、繰り返し観てきた旧作の粗さが気になってしまいます。特に、艦隊戦のシーンは CG の恩恵が大きいです。勿論、旧作も、その時代に存在したということで大きな価値を持っていることは言うまでもありませんが。

株式会社シンクロ 中村健

◇◇◇◇◇◇◇◇◇◇◇◇◇ ◇◇◇ ◇◇◇ ◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇ ◇◇◇ ◇◇◇
中村 健(Ken Nakamura)
株式会社SYNCHRO 取締役 CTO
機械屋だったはずだが、いつの間にかソフト屋になっていた。以前は計測制御、知識工学が専門分野で、日本版スペースシャトルの飛行実験に関わったり、アクアラインを掘ったりしていた。
VoIPに関わったことで通信も専門分野に加わり、最近はネットワークセキュリティに注力している。
https://www.udc-synchro.co.jp/
◇◇◇◇◇◇◇◇◇◇◇◇◇ ◇◇◇ ◇◇◇ ◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇ ◇◇◇ ◇◇◇

関連記事

サイバーセキュリティの課題をテーマ別に紹介中!!