カテゴリー別アーカイブ: SDP

SPA （Single Packet Authorization）解説

2019年8月27日
CSAジャパン
諸角　昌宏

本ブログは、SDP(Software Defined Perimeter)の中核の技術であるSPA （Single Packet Authorization）が、どのようにゼロトラスト環境で有効であるかについて説明します。特に、インターネット上に安全なサービスを提供するため、認証が取れるまでは全てのアクセスを拒否する”Deny-ALL”が、どのように実現できているかについて説明します。

インターネットのアクセスにおける課題とSPA

リクエスト-レスポンス型であるインターネットのアクセス方法は、クライアントからのリクエストを受け取るために必ず口（ポート）を開けて待っています。これは、正しいユーザだけでなく、悪意のある人にも開いているということで、セキュリティ上の問題を引き超す可能性を高めています。悪意のある人は、ポートスキャン等を行って、インターネット上に開いているポートを探し、それに紐づくサービスを特定し、そのサービスの脆弱性を突いて攻撃を仕掛けることができます。また、開いているポートに対してSYNフラッド攻撃によりDoS/DDoS攻撃を行い、サーバを接続不能にすることができます。
このようにインターネットがもともと抱えている課題に対して、アクセスが許可されるまでは全てのポートを閉じておくという、いわゆる”Deny-All”を実現することで対処することが求められています。このための方法として、大きく以下の2つがあります：

ポートノッキング
SPA

これらについて、以下で説明していきます。

ポートノッキング

ポートノッキングは、決められたポートを決められた順番でアクセスすることでファイアーウォールに穴を空ける仕組みです。例えば、ポート1000、2000、3000に対して順番にTCP SYNパケットを送った場合のみ、ポート22 (SSH) へのアクセスが許可されるというような設定ができる機能になります。この場合、最初の状態ではポート22は閉じられており、ポートノッキングに定義されたTCP SYNのシーケンスが来た時のみ、一定時間ポート22を開放します。クライアントは、この開放している時間内にポート22に対してアクセスすることで接続できます。これにより、通常はDeny-Allの状態を維持しつつ、決められたポート番号に決められた順番でパケットが送られてきた時のみアクセスを許可するということが実現できます。

したがって、ポートノッキングには以下のようなメリットがあります。

パケットはデフォルト・ドロップ
サーバに送られてくるパケットは、デフォルトでは全てドロップすることが可能になります。つまり、Deny-allを実現できます。これにより、サーバが提供しているサービスを非可視化することができ、サービス自体を悪意のあるアクセスから保護することができます。
ポートスキャンしても空きポートを見つけることができない
悪意のある攻撃者がポートスキャンを行っても、開いているポートや稼働しているサービスを見つけることができません。したがって、悪意のある攻撃が非常に困難になります。
DoS/DDoS攻撃を最小化できる
ポートノッキング用のシーケンスにならないパケットは全てドロップされますので、SYNフラッド攻撃のようにもともと開いているポートに対する攻撃を行うことができなくなります。

一方、ポートノッキングには以下のようなセキュリティ上の問題があります。

リプレイ攻撃に弱い
ポートノッキングに利用するパケットは、暗号化されずにそのままネットワーク上を流れます。したがって、ネットワークを盗聴し、クライアントからのパケット・シーケンスをそのまま送ることで接続できてしまいます。
悪意のある第三者によるポートノック用のシーケンスの破壊
正しいクライアントに代わってポートノック用のシーケンスの一部を送ることで、シーケンスそのものを破壊することができます。
IDSあるいはポートスキャンによるポートノック用のシーケンスの探索
ポートノック用のシーケンスは一連のパケットの流れになるので探索が可能です。

SPA

SPAは、ポートノッキングの利点を持ちながら、ポートノッキングの課題に対処したものになります。” Software-Defined Perimeter: Architecture Guide”では、SDPの最も重要な要素の1つである「接続前認証（authenticate-before connect）」を実現するために、SPAを通してこれを実現していると述べています。また、このガイドでは、SPAはデバイスまたはユーザの身元を検証し、それから追加のアクセス制御を実施するシステムコンポーネント（コントローラまたはゲートウェイ）へのネットワークアクセスを許可するだけの軽量プロトコルで、これは、TCP / IPの根本的にオープンな（そして安全でない）性質を補うものとしています。SPAにより、要求者のIPアドレスを含むリクエスト情報は、単一のネットワークメッセージの中で暗号化および認証が行われ、デフォルトドロップのファイアウォールを通してサービスを見えなくすることができます。

SPAはプロトコルとして、SDP 1.0の中に仕様として記述されていますが、従わなければならないというような厳格な仕様では無いようです。したがって、SPAは実装の仕方においていくつかの異なる方法が取られています。ただし、SPAを実装するにあたっては、以下の3つの共通の原則を備えることを要求しています。

SPAパケットは、暗号化し、認証機能を持たなければならない。
SPAパケットは、必要な情報をすべて１つのパケットの中に含めなければならない。
SPAパケットを受け取ったサーバは、応答しないし、何も送信しない。

ここでは、SPAの実装方法を説明するにあたって、fwknopが提供するオープンソフトウエアを参照します。これは、LINUX JOURNAL Issue #156, April 2007 ” Single Packet Authorization fills the gaps in port knocking.”の内容を元にしてします。

SPAパケットの構成
fwknopが用いるSPAのパケットは、以下の構成になります。
- 16バイトのランダムデータ
- クライアント・ユーザ名
- クライアント・タイムスタンプ
- fwknop　バージョン
- モード (アクセス、あるいは、コマンド)
- アクセス (あるいは、コマンドストリング)
- MD5　チェックサム

これらのフィールドの内容について以下に説明します：

16バイトのランダムデータ、および、MD5　チェックサム
16バイトのランダムデータを含み、パケット全体のMD5チェックサムを持つことで、１つ１つのSPAパケットが必ずユニークになることを保証します。これにより、サーバ側では、以前来たことのあるパケットと同じパケットが来た場合には、リプレイ攻撃であると判断し、接続を許可しないということができます。
クライアント・ユーザ名、クライアント・タイムスタンプ
クライアント・ユーザ名、クライアント・タイムスタンプは、もう一段のレベルの認証・認可をサーバ側で行うのに用いられます。
fwknop　バージョン
fwknopとして、SPAのバージョン管理、特にバックワード互換性に用いられます。
モードとアクセス
サーバ側に、クライアントからの要求が、サービスへのアクセスなのかコマンドの実行なのかを示します。たとえば、SPAでコネクションが許可された後、SSH（TCPポート22）のアクセスを許可するように設定できます。アクセスの場合には、アクセス・フィールドに直接ストリングを含めます。

この例を元に、SPAの特徴をまとめると以下になります：

Deny-Allの実現
SPAパケットがクライアントからサーバに送られても、サーバがこれに応答することはありません。サーバは単にネットワーク上送られてくるパケットをスキャンする（たとえばlibpcapなど）だけで、SPAパケットでないものは全てドロップし、SPAパケットを受け取ると、その内容に基づいてクライアントとの接続を許可するかどうかを判断します。
リプレイ攻撃への対処
上記の例では、1パケットの中に16バイトのランダムデータを含み、全体のパケットのハッシュ値を入れています。これにより、SPAパケットがユニークになることを保証します。サーバ側では、今まで来たパケットと同じパケットが来た場合には、リプレイ攻撃であると判断し、接続を許可しないということができます。
DDoS攻撃への対処
Deny-Allであること、また、SPAパケットは1パケットであり、シーケンスではないことにより、DDoS攻撃の可能性を非常に下げることができます。
パケット・シーケンスの探索や破壊への対応
SPAパケットは1パケットであることから、スプーフィングしたり解析したりすることが難しくなります。
様々な認証情報の送信が可能
SPAパケットの中には、様々な情報を含めることが可能なため、クライアントのユーザ名など、ユーザに対応した追加の認証等の処理が可能になります。

以上のように、SPAは、ポートノッキングのメリットを維持しつつ、課題を解決し、ゼロトラスト環境における最適なネットワーク環境を提供できるものと考えています。また、ここでは触れませんが、SDPが他に提供している機能(mTLS等)とSPAが組み合わされることにより、ゼロトラスト環境におけるさらに強固なネットワークセキュリティが提供できます。

なお、SPAは、fwknopからオープンソースとして提供されていますので、さらに理解を深めていただければと思います。

本当のSDPよ立ち上がれ！ ~ Will the real SDP please stand up?

コメントをどうぞ

本ブログは、Optiv Security Inc.が公開している “Will the real SDP please stand up?” の日本語版になります。本ブログは、著者およびOptiv Security Inc.の許可を得て翻訳し、公開するものです。本ブログの内容と原文の間で相違があった場合には、原文が優先されます。

本当のSDPよ立ち上がれ！

原文：　2019年7月10日
日本語版：　2019年7月23日

Software Defined Perimeter（SDP）という用語は、ゼロトラスト（Zero Trust）モデルで安全なアクセスを提供するための新たなアジャイルな方法として最近普及してきています。SDPは、クラウドセキュリティアライアンス（CSA）によって定義された要件で、VPN /ファイアウォール/ NACの組み合わせよりも効果的で安全な方法でリモートアクセス機能を提供します。

ただし、SDPはアーキテクチャ的に異なる点があるため、多少新たな考え方が必要です。SDPは、データプレーンとコントロールプレーンを分離するネットワークの概念に基づいて作られています。これは、認証コンポーネントを拡張したポリシー決定ポイント（PDP）とポリシー実行ポイント（PEP）モデルになります。SDPの認証プロセスにおいては、「コントローラ（Controller）」はアクセスを認証するためのポリシー決定ポイントであり、「ゲートウエイ（Gateway）」はサービスへのアクセスに許可または拒否を与えるポイントになります。ゲートウェイから分離されたPDPトラフィックを使用することで、ハイブリッドクラウド環境全体でユーザーが同時にアクセスを許可される集中型のポリシーモデルと認証をサポートしているため、この機能は他のアプローチとの大きな違いになります。接続が確立され、ゲートウェイがユーザーに対して識別されると、ゲートウェイは、コントローラからの変更を定期的に確認しながら、デバイスの状態(device posture)や定義された条件に基づいてリアルタイムで決定を行うというハイブリッドな役割を果たします。これにより、コントローラが停止した場合の可用性が向上するだけでなく、障害ゾーンの分離とコントーラ/ゲートウェイのスケールアウトによりパフォーマンスも向上します。

SDPモデルは包括的で、アーキテクチャ的に異なる点があるため、従来のアクセスメカニズムやトンネリングには依存しません。つまり、SDPに加えてVPNやファイアウォールを必要とするものがあるとすれば、パフォーマンス、セキュリティ、アジリティに制限をかけるようなものであり、今日のリモートアクセスやハイブリッドクラウドにおけるワークロードの要求を満たさない可能性があります。

通信前の認証

SDPのもう1つのユニークな要素はSingle Packet Authorization（SPA）です。これは、すべてのネットワークセッションの最初のパケットで暗号化認証を要求し、許可されたクライアントだけがネットワークにアクセスできるようにします。

もともと2007年に作成されたSPAは、最初のネットワークパケットを暗号検証することで、DDoSに対する認証メカニズムを提供します。また、許可されたデバイスのみにサービスが公開されるため、エクスプロイトに対する保護も提供します。SPAで開始されていないTCPストリームはSDPによってドロップされ、コントローラまたはゲートウェイによって処理されることはないため、DDoSの影響を軽減します。SPAは、なりすまし防止や不正なデバイスによる保護されたリソースへのアクセスの防止など、DDoS防止以外の追加のセキュリティ対策を提供します。これにより、ユーザー名とパスワードが危険にさらされた場合に、資格情報を再利用する攻撃から保護されます。

SDPはどのくらい強力ですか？

2014年2月、CSAはSoftware Defined Perimeter ハッカソンのスポンサーとして、Black HatとDEFCONにSDPセキュリティを破ろうと挑戦する人のため環境を提供しました。世界全体で100億パケットを突破しましたが、攻撃は成功せず、賞品は求められませんでした。これは、SDPアプローチの長所をよく示しています。

私たちは、CSAのSDPワーキンググループに深く参加し、SDPソリューションをまとめることを経験しているSDP分野のリーダーです。ForresterとGartnerの業界調査の専門家が、今後数年間で安全なアクセス環境を大きく変えるであろうと予測しているゼロトラスト・ジャーニーにご参加ください。

原文 “Will the real SDP please stand up?” は、こちらを参照してください。

SDPと2015年度データ漏洩/侵害調査報告書の報告（第13回CSA勉強会）

コメントをどうぞ

SDPと2015年度データ漏洩/侵害調査報告書の報告（第13回CSA勉強会）

2015年7月1日
日本クラウドセキュリティアライアンス　諸角昌宏

６月29日に行われた第13回CSA勉強会について報告します。テーマは、「SDPと２０１５年度データ漏洩/侵害調査報告書」ということで、ベライゾンジャパンの皆様に講師をやっていただきました。SDPは、Software Defined Perimeterということで、５月のCSA Summit Japan 2015でJim　Reavisが触れていたクラウドセキュリティの新しい潮流の１つです。ベライゾンは、SDP仕様書V1.0の作成を中心となって行っており、SDPに関しては事例も含めて先進的に進めている会社になります。また、ベライゾンはセキュリティの調査レポートを毎年出しており、今回は8回目として”2015 DATA BREACH INVESTIGATIONS REPORT”を公開しています。

それでは、まずSDPについて勉強会の内容を報告します。

そもそもSDPとは？ということですが、”Temporal Network”ということで「一時的なネットワーク」という表現をされています。つまり、伝統的な固定ネットワークではなく、ダイナミックに接続先が決まることで攻撃のターゲットが明確にならないようにして守っていくという手法になっています。個人的には別のスライドで使われていた” Secure Non Discoverable Network”、つまりデバイスやIDが認証されるまでネットワーク上で見ることができないという表現の方がわかり易い感じがしますが、いずれにしろ、サーバのどこにアクセスするかは認証して接続するまで決まらないことでネットワーク上のセキュリティを保つためのアーキテクチャということになります。以下のような特徴を持っています。

ネットワークベースの攻撃からアプリケーションを守るためのセキュリティ・フレームワーク
“Need-To-Know”という形で、ダイナミックなネットワーク構築に基づいた「必要な時」に接続するモデル
DNSやIPアドレスをあらかじめ見せない

また、SDPは既存の標準に基づいて設計されているため、非常に安定したものであるということが言えます。また、CSAがオープンスタンダードとして使用を公開しているため、誰でも利用することができます。

さて、実際にSDPがどのように動作するかということですが、簡単に言うと以下の流れになります：

デバイス(ブラウザなど)から、SDP Controllerにアクセス
デバイスの認証を実施
ユーザ認証および使用するアプリケーションの認可を確認
アプリケーション・サーバをダイナミックにプロビジョニング
デバイスがアプリケーションを利用

勉強会では、SDPを用いたいくつかの事例について紹介されました。また、CSA Conferenceで行われたハッカソンについての説明もあり、世界中からの150億アタックに対して、一度も破られなかったということでした。また、勉強会参加者から、SDPのユーザーズガイドやインプリメンテーションガイドが欲しいという意見、SDP Controllerでのポリシー管理に対する質問等が出され、活発なディスカッションになりました。今後、CSAジャパンを中心として幅広い情報共有や実装に向けての議論を進めることが必要であることを感じました。

次に、２０１５年度データ漏洩/侵害調査報告書について報告します。

まず、ベライゾンが強調していたのは、実際のデータに基づいたレポートとなっている点です。一般的に、このようなレポートはアンケート結果に基づくものがほとんどで、データに基づいた調査結果であり非常に信頼性が高いということができるようです。2015年の情報漏洩データとして、2,122件の漏洩事故および79,790件のセキュリティインシデントを分析したとのことで、特に今回はJPCERTのデータとして日本でのデータを含めたレポートとなっているとのことです。

この中で、いくつか特徴的な点として感じた点を以下にあげます。

フィッシングメールへの対応フィッシングメールの添付ファイルをクリックする確率が11%ということで、10通送れば1通は開かれるという状況とのことで、攻撃者から見ると非常に効率的な攻め方のようです。対策として最も重要なのはトレーニングで、セキュリティ対策では人が最終的な検知装置であることを認識する必要があるとのことです。
脆弱性脆弱性を突いた攻撃の97%は、わずか10個の脆弱性に対する攻撃だそうです。さらに、攻撃の99.9%が、CVEの公表から1年以上経過したものだそうです。脆弱性に関する情報をきちんと入手および管理することと、パッチ適用などの伝統的な対策をきちんと行うことが重要になります。
情報漏洩情報漏洩の原因として、Webアプリケーションを狙った攻撃はかなり少なくなっていて、反対に人をターゲットにした攻撃が増えていて、全体の90%以上を占めているとのことです。
業界業界別では、製造業、小売業に対する攻撃が目立っているとのことです。また、教育機関への攻撃も多いとのことです。

その他、実際のデータに基づく非常に詳細な分析が行われています。このレポートの日本語版も近々公開されるとのことですので、期待したいと思います。

以上、非常に概略になりますが、勉強会の報告といたします。