ファイアウォール～知り尽くされたはずの言葉が変わる！？～

ファイアウォール～知り尽くされたはずの言葉が変わる！？～
ファイアウォール～知り尽くされたはずの言葉が変わる！？～ Internet Week 2004 – T1 FUTAGI, Masaaki (SSE) 最終版： 11/30

ファイアウォールって何さ！？つまり・・ Firewall = 防火壁・・・・・・・というよりは防火ドア
　　・・・・・・・というよりは防火ドア何かを通す必要がなければ「壁」でいいあけることが必要だから「ドア」ドアを開ける＝延焼のリスクどうして、みんなこの絵を描くのだろう・・・・・・・・・？？？？？？ 2018/10/13 Copyright (C) M.Futagi

ネットワークの検問所 Firewall = 検問所セキュリティポリシーの異なるネットワークを相互接続するためのセキュリティゲートウエイ
それぞれのポリシーを維持しながら通信する HTTP,SMTP以外立ち入り禁止証明書提示！！ 2018/10/13 Copyright (C) M.Futagi

ファイアウォールのおさらい＊これまでのファイアウォールは、こんなもの「だった」！？ 2018/10/13
Copyright (C) M.Futagi

ファイアウォールの仕事基本的な仕事（かならず備えるべき機能）ルータもしくは中継装置としての仕事
通過させていい通信かどうかの判断と通過させてはならない通信の排除危険な兆候の検出と警告通信の許可、不許可状況などの記録の保存必ずしも、「ルータ」である必要はない。アプリケーションを「中継」できれば可。（アプリケーションゲートウエイ：後述・・もあり）「記録」も重要な仕事であることに注意（意外と忘れがち） Net-1 Net-2 Firewall 互いのポリシーを崩さないように通信 Net-1　のポリシー Net-2　のポリシー 2018/10/13 Copyright (C) M.Futagi

通信の中継機能大別して２種類の方式があるパケットフィルタ方式アプリケーションゲートウエイ方式
ルータとしてIPパケットを中継することで、通信を行いたい機器同士が直接通信できる方式アプリケーションゲートウエイ方式 Proxy （代理）サーバに一旦接続して、接続相手を指示して代理通信させる必要があるため、Proxy方式とも呼ばれる。直接的なパケット中継は行わず、要求を受けたProxyが相手方と通信して必要な情報を取得してから受け渡す方式。たとえれば図書館で、いわゆる「開架方式」と「閉架方式」の閲覧方法の違い。自分が直接本を取って来ることができるか、係りに頼んで出してきてもらうかの違いと言える。 2018/10/13 Copyright (C) M.Futagi

パケットフィルタとProxyの違い 2018/10/13 Copyright (C) M.Futagi OS パケットフィルタ処理
アプリケーション各種ＡＰＩネットワーク処理ＬＡＮインターフェイスパケットフィルタ処理プロキシサーバ 2018/10/13 Copyright (C) M.Futagi

パケットフィルタとProxyの違い 2018/10/13 Copyright (C) M.Futagi
サーバクライアントフィルタ機構ファイアウォールプロキシ　サーバパケットフィルタ方式ではクライアントはサーバと直接通信を行う。クライアント、サーバ間は単一の通信。プロキシ方式ではクライアントはプロキシサーバと通信を行う。クライアント、プロキシ間、プロキシ、サーバ間は独立した通信となり、プロキシサーバは、その内部で通信内容を相互に受け渡す役割をする。 2018/10/13 Copyright (C) M.Futagi

通信の許可、不許可通信の発信元、相手先のIPアドレスやポート番号で許可、不許可を判断
ACL （Access Control List) の適用パケットフィルタ方式では、フィルタ定義としてACLを適用する。アプリケーションゲートウエイ方式では、Proxyサーバごとにアクセス許可情報としてACLを適用。これがファイアウォールのもっとも基本的な仕事。いずれの方式も特定のサービスに対するアクセスの可否を決定し、強制できるが、パケットフィルタ方式では、一括した（すべて許可・禁止）的な記述が可能であるのに対し、アプリケーションゲートウエイでは、Proxy すなわちサービス単位での許可、不許可となる。従って、パケットフィルタでは、とりあえず全部通しておこう・・・といった暫定措置が可能なのに対して、アプリケーションゲートウエイでは、Proxy が用意されているサービス以外は基本的に通せないため、あらかじめポリシーをきちんと決めないと導入が困難。（これが「安全さ」の所以かもしれないが）パケット中継機構アプリケーションゲートウエイ ACL Proxy ACL (パケットフィルタ） 2018/10/13 Copyright (C) M.Futagi

ファイアウォール関連用語・概念ダイナミックパケットフィルタ NAT (Network Address Translation)
(類）ステートフルインスぺクション NAT (Network Address Translation) (類) IP Masquerade, NAPT, PAT etc. DMZ (De-Militarized Zone) VPN (Virtual Private Network) IPSec, L2TP, PPTP etc. ステートフルインスペクションはチェックポイント社の考案した用語であり、正確には同社の製品のみに適用される概念。しかし、「ステートフル」を名乗る製品は多いものの、その仕様は千差万別。多くが、単純なダイナミックフィルタ機能を「ステートフル」と称している。（本格的なステートフルインスペクションがはたして必要かどうかという議論はあるので、それで充分という話もあるのだが、議論をややこしくしているところだ） DMZという言葉も誤解が多く要注意：後述 2018/10/13 Copyright (C) M.Futagi

ダイナミックパケットフィルタファイアウォール製品とルータのフィルタ機能の最大の相違点
通過を許可した通信パケットへの応答や付随する他のセッションなどを総合的に管理、自動処理を行う。ポリシー設定を単純化できる。（許可するセッションの方向のみ定義）通信は基本的に双方向のパケットのやりとりによって行われる。従って、通過許可、拒否の設定は両方向について必要。 2018/10/13 Copyright (C) M.Futagi

単純パケットフィルタとの比較上り方向の通過許可 HOST-A HOST-B 下り方向の通過許可 HOST-B HOST-A
双方向の通過許可を定義する必要ありダイナミックパケットフィルタＰｏｌｉｃｙ上り方向の通過許可 HOST-B ダイナミックパケットフィルタは通信のセッション（コネクション）を管理する機能とも言える。セッション単位の通過許可をポリシーに従って行う機能。セッションの開始を検出してそのセッションを許可した場合、その応答も自動的に通過させる。また、TCPのような「状態」のあるプロトコルについては、その「状態」も管理し、プロトコル上の異常を排除するようなことも可能。 HOST-A 下り方向の通過許可下り方向の通過許可を通信開始時に自動的に発行 2018/10/13 Copyright (C) M.Futagi

ダイナミックフィルタの特徴１コネクションのみで構成される通信は確実に対応可能
複数コネクション／セッションから構成される通信は対応できないものあり。（ストリーミング系の通信など）たとえば、H.323 などは、ファイアウォール製品がそのプロトコル対応をうたっていない場合、通過できないことが多い。音声、動画を扱うようなプロトコルを使用する場合は要注意。 2018/10/13 Copyright (C) M.Futagi

FTPの場合のダイナミックフィルタ Client ftp Server FTP の通信は２つのコネクションから構成される。
Ｐｏｌｉｃｙコマンド上り方向の通過許可 Client コマンド下り方向の通過許可 ftp Server → PORT x,x,x,x,x → データ上下方向の通過許可 FTP の通信は２つのコネクションから構成される。データコネクションの開設や使用するポート番号は、コマンドコネクション内でネゴされる。また、データコネクションはデータ転送のたびに新しいコネクションが生成される。 FTPのような複数のコネクション／セッションから構成されるプロトコルに対するダイナミックパケットフィルタは複雑。特に、アプリケーション上で二次的コネクションについての情報（アドレス、ポート）が交換される場合は、ファイアウォールはこうしたアプリケーションレイヤのデータも横取りして管理する必要がある。 2018/10/13 Copyright (C) M.Futagi

ステートフルインスペクション Checkpoint社オリジナルの用語
本来は、単なるパケットヘッダのみのチェックではなく、アプリケーションレイヤまで、プロトコルをデコードして細部の検査ができる方式のこと。一般にはダイナミックフィルタと同義に使用されることが多い。C社以外のファイアウォールの場合、厳密にはこの言葉に該当しないものが多いが、ステートフルと称することが多い。 2018/10/13 Copyright (C) M.Futagi

NAT, IP Masquerade, Etc. 内部アドレスにプライベートアドレスを使用したネットワークとインターネットの境界にファイアウォールを置く場合に必須。（除く、アプリケーションゲートウエイ型F/W）プライベートアドレスネットワークを起点とする通信がファイアウォールを通過する時点で、発信元をグローバルアドレスに変換する。 NAT も混乱の多い言葉。NATと呼ばれている機能にも様々なものがあり、その方式に応じて、使えるプロトコルに制限があったりすることに注意。 2018/10/13 Copyright (C) M.Futagi

NAT (RFC1631) グローバルアドレスプールからアドレスを割り当て。
内部側ホストが外部と通信する際にプールからアドレスを一次的に割り当てて、アドレスを変換同時通信数はグローバルアドレスの数に制約される主に双方向通信を行う場合に利用基本的に、グローバル対プライベートアドレスを１対１で変換する。このため、同時通信数だけのグローバルアドレスが必要になるが、双方向（外部からのコネクション、セッション接続の受付を含む）が可能になるため、プライベートアドレス上のホストを外部公開する場合に使われることが多い。内部クライアントが外部と通信する目的においては、双方向通信が不要な場合は不向き。 2018/10/13 Copyright (C) M.Futagi

NAPT,IP Masquerade, PAT 1個もしくは少数のグローバルアドレスを多数の内部ホストで共有
アドレス変換後のセッションが重複しないように発信元のポート番号も含めて変換利用可能なポート番号数×アドレス数分の同時セッションをサポート一部のプロトコルに対応が困難外部からの着信は不可これらの表現は、すべてほぼ同等の機能を表す。 NAT 全般に言えることだが、アプリケーションプロトコル内で、IPアドレスやポート番号を受け渡すような仕様の場合、NAT越えの通信がうまくできない場合があることに注意。（メーカーが個別対応していないとダメ）また、発信元のポートが変わってしまうとうまく動作しないようなケースでは、IP Masqueradeなどの方式には対応できないケースが多い。たとえば、一部のリモートアクセスプロトコルなどで、発信元が特権ポートであると扱いがかわるものなどがある。このような場合、特権を使えなかったりする。また外部からの着信（セッション要求）は原則として不可 2018/10/13 Copyright (C) M.Futagi

ＮＡＰＴ／IP Masquerade 内側フホァ外スイ側トアホウスォト｜ル内側ホスト
From: :1024 ファイアウォ｜ル From: :32768 外側ホスト To: :80 To: :80 To: :1024 To: :32768 From: :80 From: :80 内側ホスト From: :1024 From: :32769 To: :80 To: :80 発信元ポート番号を書き換えていることに注意実際は同じ発信元ポート番号を持つセッションをユニークな番号に振りかえることで、衝突しないようにしている。従って、同時にファイアウォールを通過できるセッション数は、振り替えのために用意されたポート番号プールの大きさに依存する。 To: :1024 To: :32769 From: :80 From: :80 2018/10/13 Copyright (C) M.Futagi

ＮＡＴ使用上の注意点複数のコネクションを使うプロトコルで対応できない可能性がある。（ダイナミックフィルタと同様の理由）
データとしてIPアドレスを受け渡すようなアプリケーションの動作を保証できない。（FTPなどは一般に対応されているが、新しいアプリケーションでは未対応のものも多い）パケットヘッダの改ざんチェックを行うようなプロトコルに対応できない。（IPSecなど） IPSec については、NAT Traversal もしくは UDP カプセリングと呼ばれる NAT 越えの手法が別途あるため最近はNAT下でも使われている。 2018/10/13 Copyright (C) M.Futagi

サーバ保護とDMZ DMZの意味もともとは軍事用語 DeMilitarized Zone = 非武装地帯（直訳）
直接侵入を防ぐための「緩衝地帯」的意味合いが強い（決して「非武装＝無防備」ではない）危機管理的考え方ＤＭＺ：誤解が多い言葉「非武装」＝「無防備」という誤解が一番多く、次に、単純に内部とは違うセグメントを作ることがDMZをつくることという単純な誤解がある。基本的な考え方は、「ファイアウォール」で防げなかった場合の「予防策」 2018/10/13 Copyright (C) M.Futagi

公開サーバの保護サーバをファイアウォール下に配置外部からサーバに対して、公開するサービス以外へのアクセスを禁止
しかし、公開サービスは通さねばならないサーバの公開サービスに脆弱性があると、攻撃、侵入の可能性がある。これをファイアウォールで防ぐことは難しい 2018/10/13 Copyright (C) M.Futagi

単純な保護モデルの場合ルータ仮想アドレスファイアウォール/NATルータクライアントクライアント実サーバクライアント
単純な２ネットワークモデルで、サーバを保護する場合内側においたサーバへの通信を限定的に許可する。プライベートアドレス使用時は NAT またはリバースProxyを使用して、外部の仮想アドレスへの通信を内部サーバに振り向ける。インターネットへルータバリアセグメント仮想グローバルアドレス仮想アドレスファイアウォール/NATルータ NAT(1:1) Reverse Proxy など内部セグメント (Private addr) 一部のSOHO向けブロードバンドルータなどで、この機能をDMZと称しているものがみられるが、「重大な誤解」である。クライアントクライアント実サーバクライアントクライアント 2018/10/13 Copyright (C) M.Futagi

単純モデルで攻撃を受けたらルータ仮想サーバファイアウォール内部サーバ内部サーバクライアント実サーバ実サーバクライアント
ファイアウォールは、基本的に公開サービスの保護はできないため、万一、公開したサービス経由でサーバに侵入された場合、サーバが内側にあれば、それを踏み台にして、他の内部サーバが攻撃を受ける可能性がある。インターネットへルータバリアセグメント仮想グローバルアドレス仮想サーバファイアウォール NAT(1:1) R.Proxy 内部セグメント (Private addr) なぜ、「重大な誤解」なのかは、これを見れば一目瞭然。こうならないように考えられたのがDMZの概念だから。内部サーバ内部サーバクライアント実サーバ実サーバクライアントクライアント 2018/10/13 Copyright (C) M.Futagi

DMZモデルの場合ルータファイアウォールサーバサーバクライアントクライアント内部サーバクライアントクライアント
サーバへの必要なアクセスは許可するが、サーバから内部セグメントへのアクセスは禁止する。もし、サーバに侵入されても、踏み台にして内部にアクセスはできない。インターネットへルータバリアセグメントファイアウォール DMZセグメントポリシーが正しく設定されていれば、プライベートアドレスで構成してNAT 等を併用してもDMZと呼べる。サーバサーバこれが、一般的なファイアウォール製品のDMZ構成モデルただし、セグメントをわけるだけでは無意味。DMZ上のサーバが侵入された場合に、それを踏み台にして他が攻撃されることを防ぐにはどうすればいいか。これは自明。内部セグメント (Private addr) クライアントクライアント内部サーバクライアントクライアント 2018/10/13 Copyright (C) M.Futagi

ＤＭＺを構成する意味ＤＭＺは中間的な保護層公開サーバ群をファイアウォールで保護し、必要以外のアクセスを排除する。
万一、公開サーバが不正アクセスにより侵入されるなどの事態が生じても、そこから内部に直接入れないようにすることで、安全性の向上をはかる。（不正アクセスに対応する時間をかせぐ）さらに、外部へのアクセスも制限することで、侵入されたサーバを踏み台にして外部を攻撃することも困難にする。（かごの鳥作戦）不正アクセスによって深刻な事態に陥るような重要なホストは置かない。原則論はこのとおり。例外を作る場合は、そのリスクを考えて。 2018/10/13 Copyright (C) M.Futagi

DMZ本来の形ＤＭＺ安全でないネットワーク安全なネットワークファイアウォール１ファイアウォール２外部→DMZ DMZ→内部
必要なサービスへのアクセスのみ通過 DMZ→内部基本的に通過できないように設定。 DMZ←内部外部←DMZ 基本的に通過できないように設定。どうしても必要なもののみ通過。ファイアウォールの古典的な教科書に登場するDMZの形。これが一番わかりやすいし、たとえば、２個のファイアウォールやルータを使っても構成ができる。 2018/10/13 Copyright (C) M.Futagi

DMZを正しく理解するために DMZは「非武装=無防備」ではない正しくポリシー設定しなければDMZではない
2018/10/13 Copyright (C) M.Futagi

ＶＰＮとファイアウォール VPNゲートウエイ機能
インターネットなどの安全でない（セキュリティポリシーの異なる）ネットワークを介して、安全にネットワーク間接続を行う。 VPNゲートウエイは相手側のネットワークに対するルータの役割をする。ゲートウエイ間は暗号通信によって、通信の内容が保護される。セキュリティの観点から見ればファイアウォールに別のネットワークを追加接続したのと同じ意味合い。接続先ネットワークのセキュリティが破られれば、当然、リスクにさらされることに注意 VPN接続は特別な接続ではない。セキュリティ的に考えれば、専用線やダイヤルアップ接続となんら変わらないことに注意。たとえば、取引先とのネットワーク接続にはどのようなリスクが伴うか・・・・これを考える必要あり。 VPNは「セキュリティ」ではなく「ネットワーキング」である 2018/10/13 Copyright (C) M.Futagi

VPNの利用目的同一組織のブランチ間のインターネット経由接続モバイルアクセスのコスト削減と安全性の確保
専用回線の代替えまたはバックアップ、回線費用の節約モバイルアクセスのコスト削減と安全性の確保複数組織の協同ネットワーク（エクストラネット）構築回線費用の節約インターネットの利用による柔軟性の確保組織内のネットワークセキュリティーの階層的強化組織内 LAN のセキュリティー階層化セキュリティーの低いネットワークを使って重要なネットワークを接続ワイアレスLANのセキュリティ強化策 VPNの利用は、なにもインターネットに限ったことではない。たとえば、物理的に異なる複数のネットワークを作る代わりに１個のネットワーク内に作られた複数のVPNを利用することもできる。（帯域が許せば・・・だが）これらは、別個のネットワークよりも安全に分離される上、配線などのインフラを共有できるため、コストダウンもはかれる。 2018/10/13 Copyright (C) M.Futagi

ＶＰＮ利用時の注意点 VPNは安全か？パケットサイズ（MTU）に注意ＮＡＴ越えの場合、通信できない場合あり
通信方式は安全でも、相手によっては接続すること自体に問題が生じることに注意（ポリシー設定による利用制限やサービス単位の認証はきちんと行う必要あり）パケットサイズ（MTU）に注意カプセリングを行うことで最大パケットサイズ(MTU）が実質的に減少するため、フラグメントが発生する可能性あり。（Ｐａｔｈ　ＭＴＵ　Ｄｉｓｃｏｖｅｒｙ　などによる動的対応、またはホスト側のMTU制限で回避）ＮＡＴ越えの場合、通信できない場合あり IPSec の場合、特殊な方法（NAT Traversal）を使用する必要がある。ＶＰＮは安全か？　答え：ＮＯ！パフォーマンスの問題では、まず、MTU問題（不要なパケット分割の発生）を疑う。ここでは、IPSec のみを紹介したが、他にも L2TP, PPTP などがあるので、たとえば、個人（ユーザ）ベースでの認証や、クライアントへの内部アドレスの割り当てなどが必要な場合、これらを使うことも考えられる。 2018/10/13 Copyright (C) M.Futagi

ファイアウォールの運用・管理ログは宝の山定期的な解析を・・・・ファイアウォールのログだけでも・・・・・異常ログの検査
通信傾向の掌握（各プロトコルの利用状況など）ファイアウォールのログだけでも・・・・・特定プロトコルセッションの異常増加→ワーム侵入？拒否ログの増加→ポートスキャンなどの偵察活動？ DMZ から外部への接続→サーバ上での不正行為？などなど・・・・ 2018/10/13 Copyright (C) M.Futagi

たとえば・・・バックドア、トロイの木馬検出内部側から外部の悪意あるサイトへのHTTPやSSLを使った通信を発見するには・・・
相手は多くの場合「踏み台」サイト「踏み台」はマイナーなサイトが多い。つまり、ふつうは誰もアクセスしないはず・ファイアウォールのHTTPやHTTPSのセッションログを取得・ログ解析ソフトを使って、相手先、発信元アドレス別に集計・アクセスランキング最下位から順に相手方サイトをチェック 2018/10/13 Copyright (C) M.Futagi

ファイアウォールがもたらす安全とは基本的にはIPアドレスやサービスをベースにした通信の到達性の制御つながるか、つないでいいかの制御
従来型の基本的にはIPアドレスやサービスをベースにした通信の到達性の制御つながるか、つないでいいかの制御つないだことの記録、つながなかったことの記録アクセスされる必要のないホスト、サービスに到達できなくなること。ファイアウォールは、ポリシーがなければただの「箱」であることに注意。「安全性」はポリシーしだい。 2018/10/13 Copyright (C) M.Futagi

ファイアウォールが苦手なこと通信内容の厳密なチェックと内容による通信制限
従来型の通信内容の厳密なチェックと内容による通信制限特にパケットフィルタ系はこれが苦手（複雑な処理は負担が大きいため）アプリケーションゲートウエイ系はこうしたことも可能だが、スピードはそれなり。オール・イン・ワン型もあるにはあるが・・・・基本的に通過させたサービスに関する保護はサーバ側で行うのが基本となる機能と性能のトレードオフに注意 2018/10/13 Copyright (C) M.Futagi

ファイアウォール：参考資料過去の IWチュートリアル資料など情報セキュリティプロフェッショナル教科書
情報セキュリティプロフェッショナル教科書 JNSA 監修：１２月に出版予定・・・・株式会社秀和システム刊 Stateful Inspection 資料（CheckPoint社） 2018/10/13 Copyright (C) M.Futagi

今、そして、これから・・・・ファイアウォール製品はどこへ向かうのか・・・・・・・・ 2018/10/13

ファイアウォール製品の付加機能ウイルス対策機能侵入検知と防御機能電子メールに対するウイルス対策
Webアクセスやファイル転送に対するウイルス対策侵入検知と防御機能 IPS (Intrusion Prevention System)機能 Application Firewall　（アプリケーション防御） 2018/10/13 Copyright (C) M.Futagi

ファイアウォールとウイルス対策 2018/10/13 Copyright (C) M.Futagi

コンピュータウイルス・ワームって？コンピュータ、情報機器を標的に、それに侵入して望まれない動作をさせてしまう「悪性プログラム」(Malicious Code) プログラムファイル等に寄生して、その動作を乗っ取るもの　＝　ウイルス単独のプログラムとしてコンピュータ内で動作するもの　＝　ワーム侵入の手引き、情報持ち出し・・・　＝トロイの木馬最近では「ウイルス」とひとくくりにされてしまうことも多い 2018/10/13 Copyright (C) M.Futagi

ウイルス・ワーム感染のタイプファイル媒介型電子メール媒介 Web媒介自動感染（脆弱性攻撃）型
特定のファイル（プログラムやスクリプト）に自分を組み込んで、誰かがそれを他のコンピュータに持ち込むのを待つもの電子メール媒介主に、電子メールの添付ファイルに組み込まれ、それを実行すると、そのコンピュータ内に感染するもの。多くの場合、感染すると、そのコンピュータ内に格納されているメールアドレスを使って大量のウイルス付きメールを送信する。 Web媒介ワームなどのケースでは、侵入したWebサイトのページに自分自身を組み込んで、ブラウザの脆弱性を利用して参照したユーザＰＣに感染するものもある。自動感染（脆弱性攻撃）型人手を介さずに感染を広げる、最も危険なタイプ。主に特定のアプリケーションやプラットホームに残された脆弱性（セキュリティホール）を攻撃して、そのコンピュータの制御を奪い、侵入する。侵入したコンピュータを踏み台にしてさらに感染を広げるものが多い。感染、流行の速度が非常に速いのが特徴。 2018/10/13 Copyright (C) M.Futagi

ウイルス・ワーム侵入経路オフラインでの侵入（古典的経路）オンラインでの侵入 FD, CD(R,RW),MO,USB-Device …
電子メール（主に添付ファイルからの感染） Webアクセス（ファイルダウンロード、不正なスクリプト読み込みなど）ファイル共有（Windows, NFS, P2P …) 脆弱性攻撃による自動感染 2018/10/13 Copyright (C) M.Futagi

ウイルス・ワームの侵入経路インターネットＦ／Ｗ公開サーバメールサーバファイルサーバグループウエアユーザＰＣ
メールによる配信（ユーザが被害）脆弱性を狙って侵入・感染Ｆ／Ｗ公開サーバメールサーバダウンロードファイルからの感染脆弱性を狙って侵入・感染脆弱性を狙って侵入・感染メールによる感染ファイルサーバグループウエアユーザＰＣファイル共有による感染オフラインメディアによる持ち込み 2018/10/13 Copyright (C) M.Futagi

ウイルス・ワームのターゲット主にユーザ（クライアント）ＰＣやファイルサーバなど
電子メール、ファイル感染系のウイルスは明らかにユーザＰＣへの感染が目的（混乱誘発、業務妨害、情報漏洩・・・）自動感染型は対象を選ばない。（脆弱性があれば、どれでも感染） 2018/10/13 Copyright (C) M.Futagi

ゲートウエイにおけるウイルス対策の意味各ＰＣやサーバにウイルス対策ソフトが入っていればいいのではないか・・・？という疑問
すべてのＰＣを確実に管理できますか？（最新のパターンファイルに即時更新できますか？）すべてのＰＣユーザが対策ソフトのアラームに適切に対処できますか？大流行時にヘルプデスクがパニックになったりしませんか？ウイルス流入経路の８割以上が電子メールメールサーバもしくはその前でウイルスを排除できれば、かなりリスクを減らすことができるそれでも、ユーザＰＣには対策が不可欠（オフライン感染、持ち出し感染の問題） 2018/10/13 Copyright (C) M.Futagi

現在のウイルス対策モデル多段構成の防御集中管理インターネットとの接続点での流入、流出阻止
ファイルサーバ、グループウエアなどを介した蔓延の防止ユーザＰＣへの直接感染防止集中管理すべてのパターンファイル更新の管理でも現実に１００％更新は困難ウイルス検出状況の管理でも、「感染」の検知は困難・・・・・（だって、これは予防策） 2018/10/13 Copyright (C) M.Futagi

ファイアウォールでの実装ウイルス対策サーバと連携するもの自前でエンジンを搭載するもの
CVP (Content Vectoring Protocol）での連携 iCAP （Internet Content Adaptation Protocol）での連携（ＨＴＴＰなど）自前でエンジンを搭載するもの内部的にはProxyとして実装されたものが多いパケットフィルタ系への実装は難易度が高い 2018/10/13 Copyright (C) M.Futagi

ファイアウォール実装の問題点負荷の問題「遅い」・・・・大量のウイルス検索を瞬時に行う必要がある
CPU能力やメモリ容量の多くを、この処理に消費する可能性が高い場合によっては、基本的なファイアウォールの性能に影響が出る可能性も「遅い」・・・・ HTTP、FTP などのウイルス検査を行うと、方式によっては、「急に遅くなったように感じる」ことがある（ファイアウォールに限らない、ゲートウエイでの対策固有の問題）検査が完了しないと、流せない・・・という宿命ファイアウォール側の方式やクライアント側のソフトによっては、タイムアウトしてしまう場合も・・・ 2018/10/13 Copyright (C) M.Futagi

ファイアウォールを使うべきか基本的には、ケース・バイ・ケース分けるにこしたことはない・・・・
餅は餅屋・・・ボトルネック回避・・・・中小規模のサイトにはコスト面から見て良いかも負荷が大きくなりすぎないことが前提 H/W化など性能面での向上も期待できる大規模サイトにはあまりおすすめしないそもそもただでさえ、ファイアウォールの負荷が高いウイルスの大流行時にファイアウォールがDDoS状態に陥りかねないお金があるサイトはウイルス対策サーバを買おう！！ 2018/10/13 Copyright (C) M.Futagi

ウイルス対策の限界も知っておこう「後手」の技術である「先手」対策も組み合わせて使おう新種の悪性プログラムにはすぐに対応できない
最近のウイルス・ワームは流行のスピードが速いパターンファイル提供は後手にまわる（発見後１時間から数時間くらいはかかる）「未知ウイルス発見機能」は完全ではない「先手」対策も組み合わせて使おう脆弱性の排除（パッチ、ワークアラウンド）侵入検知・防御対策の併用 2018/10/13 Copyright (C) M.Futagi

情報システムとウイルス・ワーム対策インターネット 2018/10/13 Copyright (C) M.Futagi モバイルＰＣ
ＰＤＡなどインターネットウイルス対策ソフト P-F/W ・IDS 電子メール用ウイルス対策メールサーバファイアウォール IPS ＩＤＳウイルス対策機能Ｗｅｂサーバ P-F/W ・IDS IPS ユーザＰＣ業務端末ファイルサーバ業務サーバグループウエアウイルス対策ソフト P-F/W ・IDS データベースサーバ P-F/W ・IDS ウイルス対策ソフトウイルス対策ソフトウイルス対策ソフト P-F/W ・IDS P-F/W ・IDS 2018/10/13 Copyright (C) M.Futagi

メール拡散型ウイルス対策最近のウイルスは直接のSMTPをファイアウォールで禁止しよう自分自身でSMTPエンジンを持っている
自分の組織のメールサーバを使わず、直接相手側のメールサーバと通信してウイルスを送り込む従って、一般のクライアントから直接、大量のSMTPコネクションがファイアウォールを通過して外部に対して発生する直接のSMTPをファイアウォールで禁止しよう新種ウイルス感染の可能性は小さくない世間様に迷惑をかけないようにしよう仕事上のメールは自社メールサーバ経由で出そう 2018/10/13 Copyright (C) M.Futagi

ウイルス対策：参考資料 IPA （情報処理推進機構）ホームページ ITmedia 特集記事
ITmedia 特集記事 2018/10/13 Copyright (C) M.Futagi

ちょっと休憩  2018/10/13 Copyright (C) M.Futagi

侵入検知と防御 Intrusion Detection / Prevention

セキュリティホールセキュリティ上の脆弱性（Vulnerability）ＯＳやサーバソフトウエアのバグによるもの
システムのミスコンフィグレーションによるものアプリケーションのバグによるものこれらの設計ミス 2018/10/13 Copyright (C) M.Futagi

セキュリティホールの影響システムへの侵入・乗っ取り情報窃取や改ざん、破壊サービス妨害行為コマンド実行権、システム管理権限の奪取
任意のコードの実行情報窃取や改ざん、破壊アカウント、パスワード情報の盗用データベース上の顧客情報、業務情報の窃取サイトの詐称やなりすまし、詐欺的行為サービス妨害行為システムダウンを引き起こしたり過負荷を発生ワーム、ウイルスの拡散 2018/10/13 Copyright (C) M.Futagi

侵入検知（Intrusion Detection）
「侵入」ではなく「攻撃」を検出する手法攻撃コード（Exploit）の特徴（signature）を利用する方法脆弱性（vulnerability）自体の特徴（signature）を利用する方法不正な挙動（behavior)を検出する方法利用ポリシーへの違反など統計的な異常（anomaly）を検出する方法日常とかけはなれたトラフィックの検出など 2018/10/13 Copyright (C) M.Futagi

IDS（侵入検知システム）と問題点アラームの信頼度が低いアラームを受けたら行動を起こすのは人間特定の脆弱性や攻撃コードの特徴検出
Signature の構成やチェックの深さによっては「誤認」「見落とし」が生じる攻撃であっても「有効」なものかどうかの判断ができない。（ノイズ的アラームが多い）基本的には「既知」の脆弱性もしくは攻撃が対象統計的異常の検出「既知」の脆弱性への攻撃に限らず検出できる可能性はあるが、確率的（非確定的）であるアラームを受けたら行動を起こすのは人間誤報排除や緊急対応 IDSは「対策」にあらず IDS + IRT （インシデント対応チーム） 2018/10/13 Copyright (C) M.Futagi

ガートナーレポートの衝撃（ネットワーク型）IDS に将来はないこれからはファイアウォールの時代
Information Security Hype Cycle (2003/06) （ネットワーク型）IDS に将来はない多くのユーザはノイズ的アラームに辟易しているプロテクション機能が貧弱もう誰も買わないだろう（投資に見合う効果なし）これからはファイアウォールの時代「言い過ぎ」、ではあるが重要なポイントを含んでいるのは確か。もちろん、IDSはなくならないが・・・・ファイアウォールという言葉の再定義が必要になる。 2018/10/13 Copyright (C) M.Futagi

侵入検知・防御システム(IPS）検出したら止めてしまおう、という発想インライン型（ファイアウォール的）導入モデル
「誤認」の減少によって可能にノイズ軽減のためのチューニングは必須ではない（無効な攻撃でも止めて問題なし）（但し、パフォーマンスへのインパクトは考慮が必要）インライン型（ファイアウォール的）導入モデル従来のIDSのTCPリセットやFW連携機能では不十分単発パケットやTCP以外での攻撃を防御困難インライン型ならば検査完了までパケットを保留しておけるネットワークモニタはパケットロスを発生インライン（ゲートウエイ）型は、少なくとも通過させた全パケットをモニタ可能　（ドロップが発生したら、相手に届かないという意味で）遅延やボトルネックの危険性とのトレードオフではあるが・・・・ 2018/10/13 Copyright (C) M.Futagi

通信をモニタリングして攻撃を検出・警告発生
IDSとIPS インターネット IDS 通信をモニタリングして攻撃を検出・警告発生メールサーバファイアウォール IPS ＩＤＳＷｅｂサーバ P-F/W ・IDS IPS ＩＰＳ通過する通信を検査・攻撃を阻止業務サーバグループウエアデータベースサーバ P-F/W ・IDS P-F/W ・IDS 2018/10/13 Copyright (C) M.Futagi

これってファイアウォールじゃ・・？ IPSは一種のファイアウォール従来よりも、より深い検査が可能なファイアウォールと言える
ファイアウォールに取り込まれるべき機能とみるべきかもしれない（実際に組み込まれつつある）ガートナーが言う「ファイアウォール」の形性能とのトレード・オフ問題は？（MPU高速化やASIC処理によるH/W化で克服可能？）障害耐性問題は冗長化による対応で充分か？基幹部分は従来型、内部サブネットやDMZ保護はIPS機能付きという使い分けも 2018/10/13 Copyright (C) M.Futagi

今のＩＰＳ機能で保護できるもの市販のプラットホーム、アプリケーションに対する攻撃からの保護
「既知」の脆弱性に対する「既知」の手法を用いた攻撃（Exploit ベースの検知）「既知」の脆弱性に対する一般の攻撃（脆弱性ベースの検知）アノマリー検出によるDoS攻撃などの緩和（但し、限定的）・ユーザが開発したアプリケーションは対象外・未知（未公開）の脆弱性に対する攻撃には対応できないと考えた方がよい・既知の脆弱性でも、新たな種類の攻撃方法には対応できない場合もある 2018/10/13 Copyright (C) M.Futagi

IDS/IPS：参考資料日本Snortユーザ会ホームページ主なIPS製品 http://www.snort.gr.jp/
Juniper (旧Netscreen) IDP McAfee（旧Intruvert）　IntruShield TippingPoint Unity One 2018/10/13 Copyright (C) M.Futagi

Beyond the IPS それでもまだ、攻撃対象は残る・・・・・・「Layer 7対応プロテクション」では不十分？
たとえば、Web アプリケーションには・・・・・ソフトウエアだから、バグはある・・・・・・設計ミスだってある・・・・・・コンフィグレーションミスだってある・・・・・・思わぬ裏口だってある・・・・かも・・・・つまり攻撃可能なセキュリティホールはまだ存在する IPS では、ユーザアプリの脆弱性までは面倒みきれない「Layer 7対応プロテクション」では不十分？ Layer 7の意味は？（プロトコル？、アプリケーション？） 2018/10/13 Copyright (C) M.Futagi

アプリケーション脆弱性と防御Ａｎｏｔｈｅｒ　“Ｆｉｒｅｗａｌｌ” 2018/10/13 Copyright (C) M.Futagi

プロトコル階層とソフトウエア階層コンピュータソフトウエアの階層ユーザアプリケーションアプリケーションサーバプロトコル階層（OSI）
Web サーバオペレーティングシステムデバイスドライバハードウエアプロトコル階層（OSI） HTTP FTP SMTP… TCP UDP IP Ethernet ７：アプリケーション層６：プレゼンテーション層５：セッション層４：トランスポート層３：ネットワーク層２：データリンク層１：物理層アプリケーション防御システム侵入検知防御システム従来型ファイアウォール 2018/10/13 Copyright (C) M.Futagi

アプリケーション脆弱性ユーザが開発したアプリケーション（業務用プログラム）のセキュリティホールそのアプリケーションに固有の問題
すべてのアプリケーションに存在しうる特に、Web系アプリケーションに顕著ステートレスプロトコルとセッション管理の問題 HTMLの柔軟性、ブラウザの高機能化を逆手にとった攻撃背後にあるデータベースへの攻撃 2018/10/13 Copyright (C) M.Futagi

Webアプリケーションの仕組みログインフォーム受信ユーザユーザ名を検索 futagi パスワードパスワードをチェック＊＊＊＊
エラー画面を作成ユーザー名またはパスワードが不正です。ユーザ情報検索情報表示画面作成二木真明さん、ようこそ最終ログイン：ＸＸ年ＸＸ月Ｘ日 2018/10/13 Copyright (C) M.Futagi

Webアプリケーションの処理処理すべきデータの受信応答ページの作成フォームの受信（GET/POST） URL 引数による受け渡し
アプレット、スクリプト処理による受け渡し応答ページの作成入力データに対する処理（検索、その他のデータ処理の実行）入力データもしくは処理結果を使って応答ページ（HTMLデータ）を作成、クライアントに送信 2018/10/13 Copyright (C) M.Futagi

危険が生じるポイント入力データの利用方法に注意入力データの一部を応答ページになんらかの形で転記する場合。
入力データを検索条件にしてデータベース等を検索する場合（SQLの構成）入力データを引数にして他の処理やコマンドを実行する場合入力データを使って、行う処理を選択する場合 2018/10/13 Copyright (C) M.Futagi

たとえば・・・・入力データを応答ページに転記入力データをSQL分の検索条件に使う場合入力データをコマンドの引数に使う場合
もし、入力データに<script …>….</script> などのHTMLタグが含まれていたら・・・・入力データをSQL分の検索条件に使う場合たとえば、”futagi or 1 = 1 “ というような値を入力データに与えたら、どんな動作をするだろうか。入力データをコマンドの引数に使う場合たとえば、”; rm –f /usr” などというデータを与えられても大丈夫だろうか・・・・ 2018/10/13 Copyright (C) M.Futagi

or によって以後の条件は無意味になってしまう
ＳＱＬインジェクションの例生成する検索条件　select * from user-table where user=User and password=Pass; Ｕｓｅｒ Futagi or 1=1 Ｐａｓｓ ********* select * from user-table where user=Futagi or 1=1 and password=“******”; or によって以後の条件は無意味になってしまう＊結果として、パスワードに関係なく問い合わせが成功してしまう。 2018/10/13 Copyright (C) M.Futagi

クロスサイトスクリプティング（ＸＳＳ）の一例
悪意のサイト Bad.jsを読み込んで実行 Web ブラウザ <HTML> ………………………. ……..<script src=“ ></script> ………………. </HTML> 処理結果　　ｘｘｘｘｘｘｘｘｘｘｘ　　ｙｙｙｙｙｙｙｙｙｙｙｙ善意のＷｅｂアプリ入力 <script type=javascript src= </script> 2018/10/13 Copyright (C) M.Futagi

たとえば・・・・隠し（hidden）パラメータを処理に使っている Cookie をセッション管理に使っている
フォームを保存し、パラメータを書き換えられて送信されても大丈夫？ Cookie をセッション管理に使っている Cookie の内容を見られても大丈夫？ Cookie の内容を改ざんして送られても大丈夫？古いページやデバッグ用ページが残っているリンクされていなくても直接アクセス可能では？思わぬトラブルや不正アクセスの元凶に 2018/10/13 Copyright (C) M.Futagi

Ｗｅｂアプリとセッション管理 Webを使ったアプリの特性 HTTPはステートレスなプロトコル（一回ごとに通信が簡潔）
認証からセッション管理の機構をユーザがアプリケーションで実現しなければいけないログイン処理選択～処理の実行（繰り返し）ログアウト 2018/10/13 Copyright (C) M.Futagi

Webアプリにおけるセッション管理の例ユーザ（ブラウザ）側サーバ（アプリ）側 2018/10/13
１回の通信で処理される範囲ユーザ（ブラウザ）側ユーザIDとパスワード入力入力操作１入力操作２認証フォームフォーム１ ID=123 フォーム２ ID=123 フォーム３ ID=123 　応答１ ID=123 　応答２ ID=123 ユーザID パスワード認証チェックセッションID の生成 ID = 123 ＩＤのチェック及びフォーム１の処理ＩＤのチェック及びフォーム２の処理サーバ（アプリ）側 2018/10/13 Copyright (C) M.Futagi

手口のおさらい URL パラメータやフォーム Cookie、セッションパラメータ隠し（消し忘れ）ページやファイル
Hidden パラメータ、URLパラメータ改ざんフィールドオーバーフロー SQL インジェクション（フィールドへのSQLコマンドや記号の入力）コマンドインジェクション（システムコマンドや記号の入力）クロスサイトスクリプティング（HTMLタグやスクリプトの挿入） Cookie、セッションパラメータ内容の窃取、改ざんセッションの乗っ取り隠し（消し忘れ）ページやファイルありがちな名前（debug, admin …..)で検索・・・・・など文書と一緒におかれたデータファイル（password.dat ….) 2018/10/13 Copyright (C) M.Futagi

アプリケーション攻撃対策第一義的に、「みつけて」「修正する」こと・・・だが攻撃を食い止める方法は・・・
バグはなくならないし、発見は難しい修正→テスト→リリースには時間がかかる古いアプリを直せるか・・・・（現実問題）攻撃を食い止める方法は・・・対策は個々のアプリケーションに依存する通信の内容の細部までをチェックできれば・・ 2018/10/13 Copyright (C) M.Futagi

アプリケーションファイアウォールアプリケーション保護に特化したF/W アプリケーションに対するIPSとして機能。
URLやフォームのようなアプリケーションに与えられるデータ、パラメータを監視 Cookie やセッションパラメータの監視、保護 Web Service (SOAP) などの通信の監視データベースへのリクエストの監視アプリケーションに対するIPSとして機能。シグネチャではなく、原理（方法論）的な防御 2018/10/13 Copyright (C) M.Futagi

アプリケーションファイアウォールの技術的困難さ
多種多様なアプリケーションへの対応ページ、フィールドごとに監視・保護ポリシーが異なる場合が多い設定が煩雑化しがち（サイトに依存して設定項目が多い）性能面での問題プロトコルの７階層の処理に加えて、さらに深いチェックが必要。ボトルネックになる危険性 2018/10/13 Copyright (C) M.Futagi

課題へのチャレンジポリシー、設定の煩雑化性能面の問題アプリケーションの自動学習機能ＰＣサーバH/Wの高性能化（消極策）
一定期間の通信監視によるもの（受動型）アプリケーションスキャナによる調査（能動型）性能面の問題ＰＣサーバH/Wの高性能化　（消極策） ASIC等の専用H/W化　（積極策） 2018/10/13 Copyright (C) M.Futagi

アプリケーションＦ／Ｗの将来最終的には「ファイアウォール」として統合されていくであろう
たとえば、従来型の機能を併せ持つDMZ用ファイアウォールといった形アクセスの多いサイトに使うには、性能面と管理のしやすさがポイント 2018/10/13 Copyright (C) M.Futagi

アプリケーション保護：参考資料・IPA セキュアプログラミング講座
　　　・IPA アクセス制御機構の機能不全を検出・検証するシステム（株）ソフテック、　独立行政法人産業技術総合研究所高木浩光氏　　　・OWASP Top 10 日本語訳（高橋聡氏訳）　　　・OWASP Guide to Building Secure Web Applications 　　　・安全なWebアプリ開発４０箇条の鉄則　　　独立行政法人産業技術総合研究所　高木浩光氏　　　　　　 2018/10/13 Copyright (C) M.Futagi

IPv6 とファイアウォールユビキタスネットワークの夢とセキュリティの葛藤・・・・・・・・・ 2018/10/13

ＩＰｖ６にしよう・・・・・・事実上無限のアドレス空間強化されたセキュリティ世界中のすべての機器を繋いでもまだ余る・・・・
可能なすべての機器をネットワークに・・・夢のユビキタスコンピューティング社会の実現強化されたセキュリティ IPSec の標準サポート（暗号通信の標準化） 2018/10/13 Copyright (C) M.Futagi

IPv6で何が変わるか・・・事実上無限のアドレス空間による「総グローバル化」（ユビキタスネットワークの真髄？）
接続されるデバイスの急増（数、種類）上位層プロトコルの種類の増加（映像、音声系のストリーミング、家電等の制御、複数ホストの協調動作・・） IPSecの標準的な利用による暗号通信の一般化 2018/10/13 Copyright (C) M.Futagi

セキュリティ屋の悩みネットワーク上の様々なデバイスをどう管理するのか情報機器以外の機器を接続した時の安全性はどう確保しようか
そもそも、なんでもかんでも繋がって、管理できるのか情報機器以外の機器を接続した時の安全性はどう確保しようか家電機器の貧弱なＣＰＵにあまり多くのセキュリティ機能を持たせるのも・・・お風呂を空だきされちゃったら嫌だよね・・・家電機器にもパッチが必要なのかな・・・・インターネットに繋がないと更新できなかったらどうしよう・・・ IPSecで安全というけれど、逆に・・・通信の内容を監視できなくなるのは困る IDS やモニタリングデバイスは「終わり」！？接続の管理、認証は個々のＰＣでやるの？ 2018/10/13 Copyright (C) M.Futagi

でも、IPv6はいいね・・・・だからどうやってセキュリティを守るかを考えよう既存の考え方で使えるものは何か？
使えなくなるものの代替策は？新しく必要になるものは？ 2018/10/13 Copyright (C) M.Futagi

ファイアウォールの場合そもそも必要なのか、という議論 IPS機能、アンチウイルスなど通信内容検査機能とIPSecの問題トラフィック量は？
アクセスコントロールはすべて認証ベースでやるのか？企業内のすべてのエンドポイントのポリシーをきちんと集中管理できるのか？（もしできれば、それもあり？）でも、Perimeter Defense （境界防御）の考え方は残る・・・ IPS機能、アンチウイルスなど通信内容検査機能とIPSecの問題そのままでは使えないなんらかの対応または代替策が必要トラフィック量は？接続されるデバイスが増えるので、当然増加するはず移行期におけるファイアウォール v4,v6 共存環境への対応は？ 2018/10/13 Copyright (C) M.Futagi

Perimeter Defense（境界防御）
対策防衛線を作って、そこで戦おうという考え方街の出入り口を限定し、そこに検問所を作ることで、不審な人物の出入りを規制すれば、街のパトロールは簡素化できるはず。ネットワークの場合は、入り口にあるファイアウォールと内部のネットワークの関係個々のエンドポイントに対する脅威を境界でコントロールすることで、全体としてのリスクを軽減する主要なセキュリティ対策の局所化よって、ファイアウォールの概念はなくならない脅威対策脅威境界 2018/10/13 Copyright (C) M.Futagi

IPSec問題とファイアウォール通信内容の検査は本当に不可能か？
鍵を持たせて復号（実用的かは？？）いずれにせよ、ファイアウォール内を平文で通ればよい・・・・ Proxy によるIPSec termination　（Just idea!) Proxy を使えば、通信は２つに分解される。それぞれは別個のIPSec通信となり、データはProxy内部では平文問題は、透過的に使えるかどうか・・・（利便性の課題）個々のサービス単位でProxyを用意する必要性エンドポイント間の相互認証はどうするかという問題も 2018/10/13 Copyright (C) M.Futagi

ProxyによるIPSec termination
Ｆｉｒｅｗａｌｌ IPv6 Stack Proxy （平文） IPv6 Stack Client Server IPSec通信　（１）通信内容の検査 IPSec通信　（２） 2018/10/13 Copyright (C) M.Futagi

移行期のファイアウォール v4, v6 の共存 v4←→v6 変換（必要なのでは？）デュアルスタックネイティブ、トンネル接続のサポート

v4,v6変換のアイデア IPv4 network v4による通信 Firewall v6 Host v4-v6 変換 v6による通信
DNS Server v4 問い合わせｖ６アドレス解決（v4互換アドレス） IPv6 内部ネットワーク 2018/10/13 Copyright (C) M.Futagi

そしてファイアウォールは進化する周辺機能の取り込みは続く正しい進化と誤った進化を見極めよう IPv6への対応を視野に
ファイアウォールメーカーの生き残り策セキュリティ企業の合併、吸収の影響もあり・・正しい進化と誤った進化を見極めようユーザが淘汰していくしかない IPv6への対応を視野にファイアウォールの v6 対応はv6の推進力にもなりうる・・・日本のメーカー、開発者にもっともっとがんばって欲しい！！！！ 2018/10/13 Copyright (C) M.Futagi

ご清聴ありがとうございましたご質問 ? ふたぎまさあき最終版資料は、後日、IW2004サイト及び以下に掲示する予定です。
ふたぎ　　まさあき住商エレクトロニクス（株）ネットワークセキュリティ事業部技術担当副事業部長最終版資料は、後日、IW2004サイト及び以下に掲示する予定です。 2018/10/13 Copyright (C) M.Futagi

ファイアウォール～知り尽くされたはずの言葉が変わる！？～

Similar presentations

Presentation on theme: "ファイアウォール～知り尽くされたはずの言葉が変わる！？～"— Presentation transcript:

Similar presentations

About project

フィードバック

ログインする

Auth with social network:

ファイアウォール ～知り尽くされたはずの言葉が変わる！？～

Similar presentations

Presentation on theme: "ファイアウォール ～知り尽くされたはずの言葉が変わる！？～"— Presentation transcript:

Similar presentations

About project

フィードバック

ファイアウォール～知り尽くされたはずの言葉が変わる！？～

Presentation on theme: "ファイアウォール～知り尽くされたはずの言葉が変わる！？～"— Presentation transcript: