Aruba SD-Branch Hardening Guide. コンテキスト: Aruba SD-Branchのセキュリティセキュリティは、Aruba SD-Branch ソリューションの不可欠な部分です。

参考訳

Aruba

SD-Branch Hardening Guide

Version: 1.0.0

改訂履歴

Version Date Modified By Samuel Perez Bunuel

1.0 2019-04-17 Samuel Pérez Buñuel First official version

著作権

© Copyright 2019 Hewlett Packard Enterprise Development LP.

オープンソースコード

この製品には、GNU 一般公衆利用許諾契約書、GNU 劣等一般公衆利用許諾契約書、および/またはその他の特定のオープンソースライ

センスの下でライセンスされているコードが含まれています。そのようなコードに対応するソースコードの完全な機械読み取り可能な

コピーは要求に応じて利用可能です。このオファーは、この情報を受け取ったすべての人に有効であり、Hewlett-Packard Company

によるこの製品バージョンの最終配布日から 3 年後に失効します。そのようなソースコードを入手するには、小切手または為替を US

$ 10.00 で送ってください。

Hewlett-Packard Company Attn: General Counsel 3000 Hanover Street Palo Alto, CA 94304

USA

ソースコードを要求している製品とバージョンを指定してください。このソースコードのコピーを [email protected]

で無料で要求することもできます。

目次

参考訳 ..................................................................................................................................................................... 1

1. コンテキスト: Aruba SD-Branch のセキュリティ .................................................................................................................. 4

1-1. セキュリティレイヤ ............................................................................................................................................... 4

2. はじめに: セキュリティテスト ........................................................................................................................................... 4

2-1. セキュリティテストと認定 ........................................................................................................................................ 5

2-1-1. 脆弱性管理プロセス ................................................................................................................................... 5

2-1-2. バグバウンティプログラム................................................................................................................................. 5

3. サービスの停止 ........................................................................................................................................................ 5

3-1. 暗号化.......................................................................................................................................................... 5

3-1-1. HTTPS .................................................................................................................................................. 5

3-1-2. SSH ..................................................................................................................................................... 6

3-2. IPsec ........................................................................................................................................................... 7

3-3. Diffie-Hellman............................................................................................................................................... 7

3-4. 認証された NTP ............................................................................................................................................... 8

3-5. SNMP........................................................................................................................................................... 8

3-6. 外部 syslog ................................................................................................................................................... 9

3-7. RADIUS 共有シークレット .................................................................................................................................. 10

3-8. コントロールプレーン防御 .................................................................................................................................... 10

4. 管理アクセスの制限 ................................................................................................................................................. 11

4-1. コンソールポートとパスワード回復 ........................................................................................................................... 11

4-2. コントロールプレーン保護 .................................................................................................................................... 12

4-3. 集中型の認証と認可 ........................................................................................................................................ 12

5. ネットワークアクセスの制限 .......................................................................................................................................... 13

5-1. WAN インタフェース保護 ..................................................................................................................................... 13

5-1-1. WAN 保護 ACL...................................................................................................................................... 14

5-1-1-1. WAN 保護 ACL のサンプル .................................................................................................................. 15

5-1-2. 位置情報とレピュテーションのフィルタリング .......................................................................................................... 16

5-2. LAN インタフェース保護 ...................................................................................................................................... 17

5-2-1. ユーザロールとファイアウォールポリシー ............................................................................................................... 17

5-2-2. ユーザ中心ポリシーの実装 ........................................................................................................................... 17

5-2-3. 有効な IP アドレス ACL ............................................................................................................................. 17

5-3. グローバルファイアウォール設定 .............................................................................................................................. 18

5-3-1. ユーザ間トラフィックの防止 ........................................................................................................................... 18

5-3-2. IP スプーフィングの禁止 ............................................................................................................................... 19

5-3-3. ARP スプーフィングの禁止 ............................................................................................................................ 19

5-3-4. DHCP の強制 ........................................................................................................................................ 19

A. Annex: 典型的な脆弱性スキャンの結果 ........................................................................................................................ 21

A-1. オープンポート ................................................................................................................................................ 21

A-2. 一般的な誤検知 ............................................................................................................................................ 22

1. コンテキスト: Aruba SD-Branch のセキュリティ

セキュリティは、Aruba SD-Branch ソリューションの不可欠な部分です。何よりもまず第一に、このソリューションは完全にポリシ

ー主導型 (または Aruba 用語ではロールベース)になるようにゼロから構築されているためです。次に、ほとんどの場合、ブランチは

インターネットに直接公開されるため、非常に堅牢な強化ポリシーが必要になります。そして最後に、ブランチネットワークも「最善

の」セキュリティから恩恵を受けるべきだという確信のためです。

Aruba SD-Branch ソリューションのセキュリティは、オペレーティングシステムの強化から最善のセキュリティパートナーとの統合ま

で、何層にもわたって構築されています。

図 1: SD-Branch セキュリティレイヤ

1-1. セキュリティレイヤ

まず第一に、Aruba のゲートウェイは堅固なプラットフォームであるバージョン ArubaOS を利用しています。以下を含んでいます:

• セキュアブート: ゲートウェイが Aruba Central から設定を受信するまで、通信を厳しく制限します。

• セキュアなゼロタッチプロビジョニング: Aruba ゲートウェイにロードされている TPM を利用して Aruba Central との通信を保護

します。

• ASE256 暗号化: すべてのブランチ~Hub とのトンネル。

• Aruba ロールベースのステートフルファイアウォール: ファイアウォールエイリアス、ALG、およびロールベースのポリシーを使用

したスケーラブルな設定をサポートします。

• DPI: 2600 を超えるアプリケーションを検出する機能を備えた DPI モジュール。

• Web コンテンツとレピュテーションのフィルタリング: WebRoot 社の機械学習技術を使用して、コンテンツ、評判、地理位置情報

を数十億の URL で分類します。

次に、Aruba SD-Branch ソリューションを ClearPass (または他の AAA サーバ) と統合して、真のポリシー駆動型ブランチを形成でき

ます。このモデルは、ポート、VLAN、および IP アドレスに基づいてこれらのポリシーを手動で割り当てる従来の方法とは対照的に、

ユーザおよびデバイスに基づいてポリシーを動的に割り当てます。このポリシー主導のブランチは、360 secure exchange プログラ

ムで 100 社以上のパートナーとの統合を活用することによって強化できます。そしてそれは Aruba Introspect for UEBA と統合する

ことによってさらに推進することができます。

最後に、Aruba SD-Branch ソリューションは、最善のサードパーティのセキュリティインフラストラクチャパートナーと統合できま

す。これらの統合により、Aruba SD-Branch アーキテクチャは、スケーラブルな方法でエンタープライズクラスの高度な脅威防御を

提供しようとしています。これを念頭に置いて、Palo Alto Global Protect クラウドサービス (GPCS) との統合は、ブランチネットワ

ークで高度な脅威保護を提供するためのシンプルでスケーラブルなソリューションを提供します。

この資料は SD-WAN ゲートウェイで動作する設定をいかに堅くするかに焦点を合わせます。ただし、ブランチのセキュリティをさら

に強化する方法についての (オプションの)提案もあります。厳密には「強化」を検討するのではありません。

2. はじめに: セキュリティテスト

この文書は Aruba の顧客とパートナーが最も安全な方法で Aruba SD-WAN ゲートウェイを構成するのを助けるために作成されまし

た。セキュリティの推奨事項にはしばしばトレードオフが含まれます。この文書のすべての推奨事項があらゆる状況に適していると

は限りません。

2-1. セキュリティテストと認定

Aruba は、自社製品の第三者によるセキュリティテストを実施するためにかなりの時間と費用を費やしています。このテストの大部分

は政府機関に関連しており、政府機関によって要求されていますが、あらゆるタイプのユーザにとって価値があります。場合によって

は、組織は独自の製品テストを実施するのではなく、承認されたセキュリティテスト機関に依存することを選択することがあります。

ArubaOS の各リリースでは、広範な品質保証テストが行われています。テストプロセスの一環として、いくつかの商用脆弱性スキャ

ナーが使用されています。これらが含まれます:

• QualysGuard

• nCircle

• Nessus

• Retina

これらのスキャナから返された結果はすべて、それらが本物の脆弱性であるのか、誤検知であるのかを判断するために検査されます。

実際の脆弱性によりバグが開かれるでしょう。

品質保証テストに加えて、Aruba Threat Labs と呼ばれる社内グループが、Aruba 製品に対する高度な脆弱性調査を提供しています。

Aruba Threat Labs は、ブラックボックステストとホワイトボックステストの両方(ソースコード分析も含む)を通じて侵入テストを実

施します。時々、Aruba Threat Labs は外部の第三者侵入テスト会社ともターゲットを絞ったテストを実施することを契約していま

す。

2-1-1. 脆弱性管理プロセス

Aruba は、http://www.arubanetworks.com/support-services/security-bulletins/に脆弱性対策ポリシーを公開しています。この

場所には、Aruba が発行したセキュリティ勧告もあります。このページから RSS フィードも入手できます。積極的なサポート契約を

結んでいる顧客は誰でも電子メールで脆弱性勧告を受け取ることになります。勧告を受け取りたいがサポート契約をしていない関係者

は、更新が投稿されたときに通知される http://community.arubanetworks.com/t5/AAA-NAC- Guest-Access-BYOD/Security-

vulnerability-advisories/m-p/176738 にあるスレッドに加入することができます。

2-1-2. バグバウンティプログラム

Aruba はバグ報奨金プログラムを運営しており、これを通じてセキュリティ研究者は Aruba 製品のセキュリティの脆弱性を発見し報告

することで報酬を得ます。このプログラムは、Aruba に代わって研究者プール、報酬の支払い、追跡および報告プロセスを管理するサ

ードパーティ企業、BugCrowd によって管理されています。詳細については、http://www.bugcrowd.com を参照してください。

3. サービスの停止

3-1. 暗号化

ArubaOS は、HTTPS、SSH、IPsec などを含むいくつかのサービスの一部として暗号化を採用しています。管理者は IPsec サービス

を設定する際に大きな柔軟性を持っていますが、他のサービスはほとんどまたはまったくオプションを提供しない傾向があります。

DES(56bits 強度)や MD5(<64bits 強度)などのアルゴリズムを使用できますが、これはデフォルトの設定ではありません。

3-1-1. HTTPS

Aruba Gateway のローカル UI はめったに使用されませんが、TLS 1.2 はサポートされているので可能な限り使用する必要がありま

す。これには、TLS 1.2 が確実に有効になるようにブラウザの設定が必要になる場合があります。最も強力なセキュリティ設定を行

うには、TLS 1.0 と TLS 1.1 を無効にする必要があります。これは [Gateway Management > System > Certificates] から行うこ

とができます。

図 2: TLS1.2 のみに制限

TLS 1.0 および 1.1 を無効にすると、ゲートウェイのローカル UI にアクセスするときに、古いブラウザとの互換性の問題が発生する可

能性があります。

3-1-2. SSH

ArubaOS バージョン 8.4.0.0-1.0.5.0 以降、Aruba SD-WAN ゲートウェイは ssh アクセスのためにデフォルトの AES-CTR になりま

す。 Aruba は SSH クライアントを希望する最高の強度をサポートするように設定することを推奨します。

特定の SSH 暗号と MAC の使用を制限することは可能です。デフォルトでは、使用可能な SSH 暗号は aes128-cbc、aes256-cbc、

aes128-ctr、aes192-ctr、aes256-ctr です。デフォルトでは、利用可能な SSH MAC は hmac-sha1 と hmac-sha1-96 です。これ

らは [Gateway Management > System > Admin] から無効にすることは可能です:

図 3: SSH 設定

NOTE: 一部の脆弱性スキャナは、HMAC-SHA1-96 および AES-CBC の使用に不満を持っており、そのような使用は弱いと主張してい

ます。これらの脆弱性スキャナは正しくありません。スキャナベンダは暗号化について十分に理解していないようです。完全な説明

はこのドキュメントの範囲外ですが、HMAC からの出力ビットの切り捨ては弱い MAC を生成しません (RFC 2104 と NIST SP 800-

107 を参照)。さらに、SHA1 の弱点が HMAC-SHA1 に変換されないことに注意してください。この 2 つは異なる特性を持つ異なるア

ルゴリズムです (NIST SP 800-107 と SP 800-111A を参照)。

3-2. IPsec

ArubaOS は IPsec のための広範な設定機能を提供します。 IAP-VPN トンネルと SD-Branch トンネルに使用される設定は自動です

が、他のユースケースの設定はピア機能を含む様々な要因によって異なります。一般的に、Aruba は IKEv2 と少なくとも 112bits の

セキュリティ強度の使用を推奨します。

次の設定は必要な強度を提供します:

3-3. Diffie-Hellman

IPsec と TLS の不可欠な部分は、Diffie-Hellman 鍵交換です。 2015 年 10 月、研究者のグループは、国家の資源を持つ事業体が大規

模な事前計算攻撃によって 1024bits の Diffie-Hellman パラメータを破ることができるかもしれないと推測しました。詳細について

は、https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf にある論文を参照してください。この論文は推測的ですが、Aruba

は、一般的な 1024bits DH グループから脱却するプロセスを開始することで対応しました。

ArubaOS は、主にパフォーマンス(TPM またはカスタム証明書を使用してネゴシエートされる SD-WAN トンネルの場合)および下位互

換性の理由から、引き続きデフォルトで DH グループ 2 を使用します。ただし、工場出荷時のデフォルトの IKE ポリシー(優先順位番

号が 10000 以上)は無効にして、管理者定義の IKE ポリシーに置き換えることができます。

パフォーマンス上の理由から特に示唆されていない限り、サードパーティのセキュリティソリューションとの統合では DH グループ 14

を使用する必要があります。これは 2048bits 暗号化を使用するため、より安全と見なされるためです。

HTTPS を介してモビリティゲートウェイと通信するときに、TLS 鍵交換中に Diffie-Hellman も使用されます。 Apache Web サーバで

使用されている一般的な DH グループは、Aruba が生成したカスタムの DH グループに置き換えられました。 1024bits のグループが

まだ使用されている間、それは Aruba に特有であるべきであり、したがって国民国家によって事前計算されることはまずないでしょ

う。 Aruba の将来の目標は、カスタム DH パラメータを管理者がインポートできるようにすることです。

3-4. 認証された NTP

監査ログに正確なタイムスタンプが含まれるようにするには、システムクロックが正しいことが重要です。 NTP は通常、インターネッ

トに接続されたデバイスの時計を同期させるために使用されます。より高度なセキュリティを確保するには、攻撃者が NTP 通信を傍

受して誤った時間データで応答するのを防ぐために、NTP の更新を認証する必要があります。 NTP 認証を有効にするには、[Gateway

Management > System > General > Clock] の順に選択します。

図 4: 認証された NTP

3-5. SNMP

SD-WAN ゲートウェイの設定と監視はすべて Aruba Central を介して行われますが、SNMP を使用してゲートウェイを監視することを

選択する顧客もいます。 SNMP は、ポート設定、ステータス、インタフェース統計などの情報についてデバイスをポーリングするため

に、ネットワーク管理システムで一般的に使用されています。しかし SNMP バージョン 1 と 2 はコミュニティストリングを超えてほ

とんどセキュリティを提供しません。攻撃者がデバイスへのネットワークアクセスを持ち、コミュニティストリングを推測できる場

合、機密情報の漏えいにつながる可能性があります。 Aruba は SNMPv3 の使用を強く推奨します。これには認証と暗号化によるはる

かに強力なセキュリティが含まれます。 SNMPv3 を設定するには、以下のように SNMP ユーザを追加します。 (NOTE: SNMP 設定の

詳細については、Aruba Central Documentation セクションから入手可能な SD-WAN ユーザガイドを参照してください)

図 5: SNMPv3 の有効化

3-6. 外部 syslog

システムが危険にさらされた場合、攻撃者が最初に行うことの 1 つは、システムログから侵入の証拠を削除することです。このため、

ログを外部システムに送信することが重要です。できれば、異常な活動を識別してフラグを立てることができる自動ログ分析ツールを

備えたシステムにログを送信することをお勧めします。 Aruba Branch ゲートウェイは、特定のデバイスで実行されたすべての管理操

作の監査証跡を提供する Aruba Central からのみ構成できます。

それにもかかわらず、ArubaOS は顧客ツールとの統合を容易にするために業界標準の syslog もサポートしています。外部ロギング設

定はいくつかのフィルタとオプションをサポートしますが、外部サーバへのすべてのログの送信を有効にすることは簡単です：

図 6: 外部 syslog の有効化

3-7. RADIUS 共有シークレット

RADIUS プロトコルは、暗号化キーの基礎として RADIUS 共有シークレットを使用する、弱い形式の暗号化を提供します。 Aruba

Gateway (および Aruba ClearPass)は RadSec をサポートしていますが、まだ多くの顧客環境に普及しているわけではありません。

そのため、RADIUS 共有シークレットはできるだけ長く、できるだけ複雑にしてください。ArubaOS は最大 63 文字の長さをサポート

します。この共有シークレットを人間が記憶に残す必要はないので、真にランダムな文字列を生成するには http://www.random.org

などのサービスを使用してください。

3-8. コントロールプレーン防御

ArubaOS のコントロールプレーンを攻撃から防御するための機能は数多くあります。現在の設定は、ArubaOS CLI から「show

firewall」コマンドを使用して表示できます。関連する出力は以下のとおりです。

Monitor/police CP attacks Enabled 20/30sec

Rate limit CP untrusted ucast traffic Enabled 9765 pps

Rate limit CP untrusted mcast traffic Enabled 3906 pps

Rate limit CP trusted ucast traffic Enabled 65535 pps

Rate limit CP trusted mcast traffic Enabled 3906 pps

Rate limit CP route traffic Enabled 976 pps

Rate limit CP session mirror traffic Enabled 976 pps

Rate limit CP auth process traffic Enabled 976 pps

Rate limit CP vrrp traffic Enabled 512 pps

Rate limit CP ARP traffic Enabled 3906 pps

Rate limit CP L2 protocol/other traffic Enabled 1953 pps

ゲートウェイ自体に属する IP アドレス宛てのトラフィックは、これらのルールに従います。たとえば、信頼できないインタフェース

から発信され、ゲートウェイの管理インタフェース宛てのユニキャストトラフィックは、上記のデフォルト設定の使用にレート制限さ

れます。「Monitor / police CP Attacks」値を設定するために、次の設定が使用されました。

図 7: CP 攻撃レートの監視

4. 管理アクセスの制限

Aruba ゲートウェイは、シングルサインオンのための独自のメカニズムを持つ Aruba Central によって管理されます。ただし、設定は

ローカル管理インタフェース(WebUI や CLI)から確認でき、トラブルシューティングはローカルインタフェースからも実行できます。

このため、ローカルの管理アクセスを保護することが重要なセキュリティ要素になります。

4-1. コンソールポートとパスワード回復

Aruba ゲートウェイのシリアルコンソールポートは特権付きインタフェースと見なされます。コンソールポートに物理的にアクセスす

る攻撃者は、ゲートウェイを簡単に侵害する可能性があります。

顧客が管理パスワードにアクセスできなくなったときに、Aruba Technical Support によって広く知られているパスワード回復手順を

使用して「admin」アカウントのパスワードを変更できます。ゲートウェイを再起動したり、他の設定を変更したりすることはありま

せん。

Aruba ゲートウェイに十分な物理的セキュリティを提供できない場合、Aruba はコンソールポートに改ざん防止ラベル(TEL)を付ける

ことをお勧めします。ただし、TEL は、ラベルが削除されているかどうかを確認するためにゲートウェイが定期的に検査されている場

合にのみ有効です。

ソフトウェアを介してコンソールポートを無効にすることが可能です。これにより、パスワード回復手順が利用できなくなります。

ただし、このコマンドは ArubaOS の実行中にのみシリアルポートを無効にします。ゲートウェイが再起動されても、ブート ROM に

はコンソールポートからアクセスできます。これは、代替設定ファイルの起動、代替ソフトウェアイメージの起動、またはフラッシュ

メモリからのデータの消去に使用できます。 ArubaOS からコンソールポートへのアクセスを無効にするには:

図 8: コンソールポートのブロック

4-2. コントロールプレーン保護

Aruba はファイアウォールのルールを使用して、許可された送信元からのみゲートウェイのコントロールプレーンへのアクセス(管理ア

クセスまたは BGW が提供するネットワークサービス)を許可することを推奨します。これは、許可された管理者によってのみ使用され

る特定のサブネットです。ネットワーク設計が許すなら、ネットワーク管理トラフィックだけを運ぶ専用の管理ネットワークを作成す

るのも賢明かもしれません。ゲートウェイ上の管理インタフェースのみが管理アクセスを許可します。

管理アクセスのためのアクセス制御を実装する最も簡単な方法は、「Service ACL」を使用することです。これは、ゲートウェイ内のコ

ントロールプレーン要素を宛先とするすべてのネットワークトラフィックに影響を与える一連のファイアウォールポリシーです。

Service ACL はゲートウェイ宛てのネットワークトラフィックを制御するために使用できますが、主に管理アクセスに使用されます。

デフォルトでは、ArubaOS 制御インタフェースへのすべてのトラフィックはどの宛先からも許可されています。これらのルールは、

「show firewall-cp internal」コマンドを実行して表示できます。

(Gateway) #show firewall-cp internal

CP firewall policies

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

IP Version Source IP Source Mask Protocol Start Port End Port Action hits contract

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

ipv4 any 6 1723 1723 Permit 545

ipv4 any 17 1701 1701 Permit 6

ipv4 any 6 23 23 Permit 523302 cpbwc-ipv4-telnet

ipv4 any 6 8084 8084 Deny 9

ipv4 any 6 3306 3306 Deny 175

ipv4 any 17 8209 8209 DenyNotSecure 0

ipv4 any 6 8211 8211 DenyNotMaster 0

ipv4 any 6 8212 8212 DenyNotMaster 2

ipv4 any 6 873 873 DenyNotSecure 961







…

これらのデフォルトルールは、管理者が設定したルールによって上書きされます。したがって、たとえば、上記の出力ではポート

22(SSH)宛ての TCP トラフィックが任意の送信元 IP から許可されることが示されていますが、管理者は [Security > Advanced >

ACL white list] に移動して追加のルールを指定できます。次の例は、SSH トラフィックを特定のサブネットだけに制限する方法を示

しています。

図 9: ファイアウォール CP

4-3. 集中型の認証と認可

複数の特権レベルを持つ可能性がある複数の管理者が存在する組織では、集中型認証を使用することでインサイダ攻撃を防ぐことがで

きます。集中型認証では、Aruba ゲートウェイはローカルの管理者アカウントを持つ必要はありません。代わりに、管理ユーザは

RADIUS または TACACS+サーバによってリモートで認証された資格情報でログインします。この認証プロセスはまた、潜在的にロー

ル情報を Aruba デバイスに返すことができ、ユーザを管理者特権レベル(例えば「root」や「read-only」)にすることを可能にします。

集中認証は、「aaa authentication mgmt」設定コマンドを使用して有効にします。次の設定例は、RADIUS サーバに対して管理ユー

ザを認証するための一般的な設定を示しています。

上記の設定が入力されたら、誰かがそれを使用できないようにするために、ローカルの「admin」アカウントにランダムに生成された

パスワードを設定する必要があります。緊急時には、「admin」パスワードはシリアルコンソールポートにアクセスしてパスワード紛

失手順を実行することによってリセットされるかもしれませんが、通常の状況下では誰もローカル管理者アカウントに対するパスワー

ドを知らないでしょう。

あるいは、次の方法により、ローカル認証を完全に無効にすることができます。

図 10: ローカル認証の無効化

ローカル認証が無効になっていると、認証サーバが利用できなくなってもゲートウェイの管理インタフェースにアクセスできなくなり

ます。このため、ローカル認証が無効になっている場合は、常に冗長認証サーバを使用する必要があります。それにもかかわらず、

デバイスがクラウドに接続されている限り、アクセスの回復は Aruba Central から設定された管理認証を変更するのと同じくらい簡単

です。

5. ネットワークアクセスの制限

従来の境界ファイアウォールとは異なり、Aruba ゲートウェイはセキュリティポリシーに対して非常にユーザ中心のアプローチをとっ

ています。主なニュアンスは、「Trusted」インタフェースと「Untrusted」インタフェースの違いです。一般的な境界ファイアウォ

ールでは、「Trusted」インタフェースは一般に企業のデバイスが存在する場所であり、

「Untrusted」インタフェースは、ゲストサブネット、インターネットなど、管理の程度が低い場

所です。これは、Aruba ロールベースのファイアウォールには当てはまりません。

• ゲートウェイは、Trusted インタフェース(ポート、VLAN、トンネル)を通過するトラフィック

に対してユーザセッションを維持しようとしません。その代わりに、ファイアウォールポリシ

ーがそのようなインタフェースに適用されます。これは一般的に WAN インタフェースの場合

です。

• ゲートウェイは、Untrusted インタフェース(ポート VLAN、トンネル)から着信するすべてのデ

バイスのユーザセッションを維持します。つまり、ロールアサインポリシー(AAA プロファイ

ル)は、AAA が有効か無効かに関係なく、信頼できないインタフェースに接続されているすべて

の VLAN に割り当てる必要があります。これは通常、LAN インタフェースの場合です。

5-1. WAN インタフェース保護

Aruba ゲートウェイは、しばしばインターネットに直接さらされています。そのため、工場出荷時の設定でも、デバイスが外部の脅威

から保護されるようにするために、追加のセキュリティメカニズムが導入されています。

5-1-1. WAN 保護 ACL

ゲートウェイに SD-WAN イメージがロードされると、GE0/0/1 を除くすべての銅線ポートが ZTP VLAN(4094)で開始されます。

GE0/0/1 は「サービスポート」として機能し、ゲートウェイをプロビジョニングするための UI ベースのワークフローを提供します。

BGW が常に外部の脅威から保護されるようにするために、すべての ZTP ポート(0/0/1 を除くすべての銅線ポート)を次の ACL で保護

します。

(Gateway) *#show ip access-list wan-uplink-protect-acl

ip access-list session wan-uplink-protect-acl

wan-uplink-protect-acl

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

Priority Source Destination Service Application Action TimeRange Log Expired Queue TOS 8021P Blacklist Mirror DisScan IPv4/6 Contract

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

1 any any sys-svc-dhcp permit Low 4

2 any any sys-svc-v6-dhcp permit Low 6

3 any any sys-svc-esp permit Low 4

4 any any sys-svc-natt permit Low 4

5 any any sys-svc-ike permit Low 4

6 any any sys-svc-icmp permit Low 4

7 any any sys-svc-icmp6 permit Low 6

(以前に確立されていないセッションの) すべてのインバウンドトラフィックを含め、それ以外のものはすべてブロックされます。

ゲートウェイがプロビジョニングされると、WAN ポートの設定は Aruba Central で設定したものになります。それにもかかわらず、

インタフェースを WAN としてマークするとすぐに、GUI は自動的に wan-uplink-protect-acl をそのポートに適用して、少なくとも基

本的な保護を提供します。デフォルトの ACL を編集するのではなく、新しいポリシーを作成して適用することをお勧めしますが、こ

のセキュリティポリシーはもちろん変更できます。

Aruba は、WAN インタフェースに適用されるファイアウォールポリシーを可能な限り厳しくすることをさらに推奨します。その際に

は、以下の点を考慮する必要があります。

• Aruba ゲートウェイのファイアウォールは、特定のトラフィックフローに対して 1 回しかヒットしません。つまり、ブランチネッ

トワークから送信されたトラフィックは、このポリシーの影響を受けません (LAN インタフェースに関連付けられたポリシーをすで

に満たしているはずです)。

• 企業ネットワークの他の部分(DC、HQ、他ブランチ等)から送信されたトラフィックは、オーバーレイネットワーク(IPSec トンネル)

を介してブランチに入ります。このトラフィックは WAN インタフェースによって NAT-T(UDP4500)として見られます。

5-1-1-1. WAN 保護 ACL のサンプル

BGW は IPSec トンネルを開始するためのものであるため、厳密に必要とされる唯一のトラフィックフローは、ゼロタッチプロビジョニ

ングのための発信 DHCP 要求を許可することです。 DNS 要求や Aruba Central との通信など、コントロールプレーンからのトラフィ

ックはデフォルトで許可されています。したがって、より制限的なものは、これに似たものになります:

ヘッドエンドゲートウェイは、BGW からの着信 IPSec トンネルを受け入れる必要があります。一方、DHCP はデータセンタ環境では

一般的に見られません。ポリシーは次のように制限される可能性があります(Aruba ゲートウェイは SD-WAN トンネルの確立に NAT-

T を使用します)。

NOTE: 上記のポリシーは参照としてのみ提供されています。環境が異なれば、追加のトラフィックフローを許可する必要がありま

す。

5-1-2. 位置情報とレピュテーションのフィルタリング

Aruba BGW は、Webroot 社の Brightcloud サービスとのコラボレーションを利用して、IP レピュテーションと位置情報データベース

を取得します。 IP レピュテーションデータベースには、様々な悪意のある活動/脅威(ボットネット、DOS、スパムソースなど)に関連

付けられている既知の IP アドレスが含まれています。 Geolocation IP データベースには、トラフィックの受信元または送信先の IP ア

ドレスの地理的な場所が含まれています。これにより、BGW はセキュリティスイートの一部として位置情報とレピュテーションのフ

ィルタリングを提供できます。

図 11: 位置情報と評判によるフィルタリング

新しいセッションが受信されると、送信元と宛先の IP がフェッチされ、両方の IP アドレスに対してテーブルルックアップが行われ

て、これらの IP のレピュテーション/位置情報が取得されます。テーブル検索が成功すると、セッションは分類済みとしてマークさ

れ、IP 分類ベースのファイアウォールポリシーに従います。テーブルの検索に失敗した場合は、IP 分類クエリメッセージがコントロ

ールプレーンに送信され、Webroot の Brightcloud サービスからダウンロードされたこれらの IP の分類が表示されます。クラウドル

ックアップが解決されると、エントリがデータパステーブルに追加されます。このテーブルには、最大 1M の IP または URLs の情報

をキャッシュできます。

レピュテーションおよび地理的位置に基づくポリシーは、Central の Gateway Management アプリの [Security > Applications >

Applications Visibility] メニューから設定できます。

図 12: 位置情報とレピュテーションの設定

5-2. LAN インタフェース保護

5-2-1. ユーザロールとファイアウォールポリシー

Aruba は、すべてのブランチユーザにロールベースのアクセス制御の展開を推奨します。万能のネットワークへのアクセスを許可する

のではなく、組織内でのそのユーザのロールに適したアクセスのみを許可してください。前述の例では、管理者以外のユーザがネット

ワーク機器の管理アクセスインタフェースにアクセスできないようにしました。別の例としては、一般ユーザが DHCP サーバや Web

サーバなどのローカルネットワークサービスを実行できないようにすることが挙げられます。すべての組織に有効な単一のアプローチ

はありません。管理者は自分のニーズと要件を評価する必要があります。

工場出荷時のデフォルトのファイアウォールルールの多くは、安全なネットワークには適していない場合があります。たとえば

「logon-control」ACL は NAT-T(UDP ポート 4500 上の IPsec)を許可し、デフォルトのキャプティブポータルロールには「logon-

control」ACL が含まれます。これにより、キャプティブポータルユーザがログインせずに IPsec セッションを確立できるようになり

ます。「show rights」コマンドを使用してデフォルトのルールを慎重に検討し、不要なものを削除します。

5-2-2. ユーザ中心ポリシーの実装

ArubaOS ファイアウォールは、クライアントデバイスが信頼できないインタフェースから来ていて、それらが来ている VLAN に関連付

けられているロール割り当てポリシー(または AAA プロファイル)がある場合に最適に機能します。 VLAN に関連付けられている AAA

プロファイルがあるという事実が、何らかの種類の認証が必要であることを意味するのではないことに注意することが重要です。認証

なしでロールベースのポリシーを使用するためのプロセスは次のとおりです。

• VLAN に関連付ける必要があるロールを作成します( [Security > Roles] から)。

• ロール割り当てポリシー(または AAA プロファイル)を作成し、以前に作成したロールを初期ロールとして使用する( [Security >

Role Assignment] から）。

• AAA プロファイルを VLAN に適用します( [Security > Apply Policy] から）。

この初期設定により、ブランチネットワークできめ細かいアクセス制御ポリシーを実装するための段階的なアプローチが容易になりま

す。初期ポリシーが設定されると、Aruba ゲートウェイはすべてのユーザセッションを追跡します。信頼できないインタフェースか

らゲートウェイに到達するすべてのデバイス(つまり一意の MAC アドレス)に対して MAC 認証/dot1X 認証を有効にすることで、セキュ

リティを徐々に強化できます。認証に失敗したデバイスは inital-role に配置されますが、認証に成功したデバイスは AAA サーバによ

って決定されたユーザロールに割り当てられます。

5-2-3. 有効な IP アドレス ACL

ArubaOS は無効な IP アドレスがユーザテーブルに表示されるのを防ぐ(「誤って」または「悪意のある」)「validuser」と呼ばれるデ

フォルトのファイアウォールポリシーを定義しています。セキュリティの観点から、不正な IP アドレスをユーザテーブルに挿入する

と、サービス拒否攻撃を受ける可能性があります。たとえば、ユーザが自分の IP アドレスをローカル DNS サーバと同じアドレスに静

的に定義している場合などです。デフォルトの有効なユーザーACL は次のとおりです。

ip access-list session validuser

network 127.0.0.0 255.0.0.0 any any deny



host 255.255.255.255 any any deny


any any any permit

ipv6 host fe80:: any any deny

ipv6 network fc00::/7 any any permit

ipv6 network fe80::/64 any any permit

ipv6 alias ipv6-reserved-range any any deny ipv6 any any any permit

デフォルト設定を使用すると、特定の IP アドレス範囲がユーザテーブルに表示されなくなります (たとえば、IP マルチキャストアドレ

ス範囲 224.0.0.0)。特定の「deny」エントリを除いて、他のすべての IP アドレスは無線ユーザに許可されています。最大限のセキ

ュリティを確保するために、無線クライアントに有効な IP アドレスのみが許可されるように、validuser ACL を変更する必要がありま

す。これを行う 1 つの方法は、許可されるべきエントリを手動で指定することです。たとえば、すべての無線クライアントがサブネ

ット 192.168.15.0/24 に属している場合は、デフォルト ACL を次のように変更します。

図 13: 有効なユーザ ACL

「show ip access-list validuser」を使用して出力を確認します。 IPv4 エントリは「4」で、IPv6 エントリは「6」で示されていま

す。 IPv4 と IPv6 のルールは同じ ACL にありますが、別々に処理されます。

「validuser」ACL は、インタフェースまたはロールには適用しないでください。この ACL は、ユーザがユーザテーブルに追加される

たびに自動的に参照されます。

同じ機能を設定するもう 1 つの簡単な方法は、グローバルファイアウォール設定で「local-valid-users」機能を使用することです。こ

の機能が有効になっている場合、ローカルに定義された VLAN インタフェースアドレス空間内の IP アドレスのみがユーザテーブルで許

可されます。ゲートウェイがすべての無線サブネットで定義された IP インタフェースを持っている限り(すなわち、各無線 VLAN の

「interface vlan x; ip address a.b.c.d」設定ステートメント)、この機能は自動的に機能します。ゲートウェイの各無線サブネットに

IP インタフェースがない場合は、上記の手動 ACL 方法を使用してください。 “ local-valid-users”を有効にするには:

図 14: ACL ローカルユーザ

5-3. グローバルファイアウォール設定

システム上のすべてのユーザトラフィックに適用される多数のファイアウォールオプションがあります。このセクションでは、セキュ

リティ設定を制限するときに重要になる可能性があるこれらの設定のいくつかについて説明します。他の設定も利用可能ですが(詳細

についてはユーザガイドを参照してください)、これらはセキュリティ管理を締めくくるのに最も有用で価値があると考えられていま

す。

5-3-1. ユーザ間トラフィックの防止

この設定を有効にすると、トンネリングされたユーザは互いに通信できなくなります。別のトンネルユーザ宛てのトンネルユーザから

発信されたトラフィックはすべてドロップされます。このオプションはネットワークの動作に大きな影響を与える可能性があることに

注意してください。あらゆる形式のピアツーピア通信が中断されます。機能を有効にするには:

(Gateway) (config) #firewall deny-inter-user-traffic

関連機能は、非 IP トラフィックのみをブロックしますが、ユーザ間の IP トラフィックは許可します(ユーザロールに適用されているフ

ァイアウォールポリシーの影響を受けます)。これは、前述した設定よりも制限の少ないオプションです。 ARP トラフィックは非 IP

と見なされるため、この設定は無線クライアント間の ARP も中断します。このため、ユーザ VLAN でプロキシ ARP を有効にすると、

無線ユーザに代わってゲートウェイがプロキシ ARP になります。

(Gateway) (config) #firewall deny-inter-user-bridging

(Gateway) (config) #interface vlan 1

(Gateway) (config-subif)#ip local-proxy-arp

「interface vlan 1; bcmc-optimize」の使用も proxy-arp を有効にします。どの機能がより適しているかを判断するには、ArubaOS

ユーザガイドを参照してください。

5-3-2. IP スプーフィングの禁止

IP スプーフィング攻撃は、ユーザがネットワーク上の別のデバイスに属する IP アドレスを使用してデバイスを静的に設定したときに発

生します。 ArubaOS には、特定の IP アドレスを特定の MAC アドレスでロックする機能があります。この機能を有効にすると、攻撃

者が他のユーザの IP アドレスを複製することを防ぐことができます。

proipit-ip-spoofing 機能を有効にするには:

図 15: IP スプーフィングの禁止

5-3-3. ARP スプーフィングの禁止

独自のものではない IP/MAC の組み合わせに対して、arp スプーフィング防止機能は無線クライアントが ARP 応答、または無償 ARP メ

ッセージを送信するのをブロックします。有効にするには:

図 16: ARP スプーフィングの防止

5-3-4. DHCP の強制

DHCP がクライアント IP アドレスの割り当てに使用されている環境では、トンネリングされたクライアントに DHCP を使用させる機能

があります。静的 IP アドレスの割り当てはサポートされません。この機能が有効になっていると、DHCP ネゴシエーションを完了し

ていないクライアント、および DHCP を介して IP アドレスを割り当てられているが別の IP アドレスを使用しようとしているクライア

ントからのトラフィックがドロップされます。この機能はロール割り当てポリシー(AAA プロファイル)を介して有効になります。ゲ

ートウェイで複数の AAA プロファイルが使用されている場合は、それぞれに対して有効にする必要があります。

A. Annex: 典型的な脆弱性スキャンの結果

顧客が Aruba デバイスに対して独自の脆弱性スキャンを実行することは一般的です。このセクションでは、一般的な結果について説明

し、よく寄せられる質問に答えます。

A-1. オープンポート

次の表に、Aruba のコントローラ、ゲートウェイ、スイッチ、またはアクセスポイントで使用されるすべてのポートを示します。この

表には、ポートの用途と、ファイアウォールのルールを使用してブロックされる可能性があるかどうかについての注記が含まれていま

す。

ポート番号説明メモ

17/TCP Nortel Contivity VPN クライアントをサポートする

ために使用されます

ほとんどのユーザにとって安全にブロックできます。脆弱性

スキャナはこれを「quote of the day」として報告し、

「quote of the day traffic amplification」の警告を出すこ

とができます。

21/TCP FTP このポートは安全にブロックされている可能性があります。

22/TCP SSH

ArubaOS コマンドラインへの管理アクセスに使用

されます。

このポートへのアクセスを信頼できるサブネットからのみ有

効にすることをお勧めします。

23/TCP Telnet

ArubaOS コマンドラインへの管理アクセスに使用

されます。

ポートはデフォルトで開いていますが、接続試行はすぐに閉

じられます。 Telnet は設定コマンド“ telnet cli”で有効にで

きます。 Aruba は telnet を有効にすることをお勧めしませ

ん。 telnet が必要ない場合、このポートはファイアウォール

のルールによってブロックされている可能性があります。

53/UDP DNS responder

このサービスは、ゲートウェイの IP アドレスを使

用してすべての DNS クエリに応答します。ブラン

チネットワークで DNS キャッシュと DNS リダイレ

クトが必要な場合によく使用されます。

ゲートウェイがどのブランチデバイスの DNS サーバとして

も機能していない場合は、ファイアウォールルールによって

ブロックされる可能性があります。脆弱性スキャナは

「DNS cache snooping」などのように、このポートに関す

る問題を報告することがよくあります。このポートは実際の

DNS サーバに接続しないため、警告は無視しても問題ありま

せん。

67/UDP DHCP server

ArubaOS は、そうするように構成されている場

合、DHCP サーバ機能を提供することができます。

DHCP サービスが有効になっていない場合は自動的に無効に

なります。

80/TCP HTTP

キャプティブポータル認証、WebUI 管理、の両方

の接続を受け入れます。 HTTPS を使用して他のポ

ートにリダイレクトします。

必要でなければブロックされるかもしれません。

123/UDP NTP

他のネットワーク機器に時刻同期を提供できます。

このポートは安全にブロックされている可能性があります。

161/UDP SNMP

SNMP 管理アクセスを提供します。

デフォルトで無効。 SNMP コミュニティが設定されている場

合に有効になります。このポートへのアクセスは、許可され

た SNMP 管理システムに制限されるべきです。 Aruba は

SNMPv3 の使用を推奨します。

443/TCP HTTPS

キャプティブポータル認証、WebUI 管理、および

VIA に使用されます。

“web-server web-https-port-443” が設定されていない限

り、WebUI は TCP/4343 にリダイレクトします。キャプテ

ィブポータルは TCP / 8081 にリダイレクトします。

VIA クライアントでは、プロファイルのダウンロードを実行

するため、および SSL fallback モードのために、このポート

が利用可能であることが必要です。

500/UDP ISAKMP/IKE

IPsec によって使用されます。

ゲートウェイが VPN サーバとして使用されていない場合はブ

ロックされる可能性があります。 VIA はデフォルトで

UDP/4500 を使用して IPsec トンネルを確立します。

514/UDP Syslog このポートはブロックされている可能性があります。

1701/UDP L2TP

VPN の終端に使用されます。

ゲートウェイが L2TP の VPN サーバとして使用されていない

場合、ポートは安全にブロックされる可能性があります。

1723/TCP PPTP

VPN の終端に使用されます。

ゲートウェイが PPTP の VPN サーバとして使用されていない

場合、ポートは安全にブロックされる可能性があります。

4343/TCP HTTPS

WebUI 管理管理に使用されます。

TCP/443 を介した WebUI アクセスが有効になっていない限

り、TCP/443 への接続はデフォルトでこのポートにリダイレ

クトされます。

4500/UDP ISAKMP/IKE NAT-Traversal

VIA クライアント、IAP-VPN および SD-WAN トン

ネルによって使用されます。

このポートはブロックしないでください。

8080/TCP HTTP

キャプティブポータルに使用されます。

キャプティブポータルが使用されていない場合はブロックさ

れる可能性があります。

8081/TCP HTTPS

キャプティブポータルに使用されます。

キャプティブポータルが使用されていない場合はブロックさ

れる可能性があります。

8082/TCP 他の Aruba インフラストラクチャとのシングルサイ

ンオンに使用されます。

シングルサインオンが使用されていない場合はブロックされ

る可能性があります。

9070~9080 ZMQ ポート(9070~9080)は OpenFlow コントロ

ーラによって開かれ、登録されたアプリで使用され

ます。

OpenFlow が使用されていないとブロックされる可能性があ

ります。

A-2. 一般的な誤検知

脆弱性スキャナに見られる最も一般的なタイプの誤検知は、スキャナがプロトコルハンドシェイクの一部として提示されたバージョン

番号のみを見たときに発生します。たとえば、コントローラの SSH サービスに対するスキャンは、SSH サーバが OpenSSH バージョ

ン 5.8 であることを示している可能性があります。スキャンツールのデータベースで OpenSSH 5.8 の既知の脆弱性が見つかった場

合、ゲートウェイに脆弱性があると報告されます。ほとんどの脆弱性スキャナは実際には脆弱性を悪用しようとはしないので、結果と

して得られるレポートは可能性のある脆弱性のリストとして表示されるべきです。 Aruba は、Apache や OpenSSH など、ArubaOS

内に多数のオープンソースパッケージを組み込んでいます。ソフトウェアの安定性の観点から、セキュリティの脆弱性が発見された場

合、Aruba は通常オープンソースパッケージを最新バージョンに更新しません。これは、セキュリティ上の修正に加えて、バグを引き

起こす可能性のある他の数千のソースコードの変更がある可能性があるためです。その代わりに、Aruba は欠陥自体だけを修正するこ

とによって特定の脆弱性にパッチを当てます。

次の表に、ArubaOS の一般的な誤検知の数を示します。

サービス CVE メモ

OpenSSH CVE-2016-10009 CVE-2016-6210

CVE-2015-6564 CVE-2015-6563

CVE-2015-5600 CVE-2015-5352

CVE-2014-1692 CVE-2014-2532

CVE-2014-2653 CVE-2011-5000

CVE-2011-4327 CVE-2010-5107

CVE-2010-4755 CVE-2008-3259

CVE-2007-4752 CVE-2007-2243

CVE-2007-2768 CVE-2004-1653

これらの脆弱性は、ソースコードに修正プログラムが適用されているか、

特定の機能の設定または使用が制限されているために ArubaOS には適用

されません。現時点でサポートされている ArubaOS のバージョンにこれ

らの脆弱性は含まれていません。

SSH CVE-2008-5161 SSH での AES-CBC の使用は安全ではないと多くの脆弱性スキャナが報告

しています。完全な説明については、

http://community.arubanetworks.com/t5/Unified-Wired-Wireless-

Access/SSH-and-AES-CBC/m-p/248919 を参照してください。

ArubaOS 6.5.4.4 以降では、AES-CBC を無効にすることが可能です。

sssd CVE-2009-2410 ArubaOS にはこのサービスは含まれていません

DNS /

Nameserver

CVE-2008-1447 ArubaOS には、UDP ポート 53 で待機する「DNS レスポンダ」が含まれ

ています。このレスポンダにクエリを送信すると、ゲートウェイの IP ア

ドレスを含むレスポンスが返されます。脆弱性スキャナは、このサービ

スが再帰クエリに応答すること、キャッシュスヌーピングを許可するこ

と、またはトラフィック増幅攻撃を可能にすることを報告する可能性があ

ります。このサービスは実際の DNS サーバではないことに注意すること

は重要です、そしてこれらの警告は安全に無視されるかもしれません。

Web server CVE-2002-0840 CVE-2012-0053 次のような警告が報告されることがあります。

• Apache サーバ mod_info は一般に公開されています

• ワイルドカード DNS を使用したエラーページ XSS

• PHP に関する警告

• WebGlimpse に関連する警告

• phpCMS に関連する警告

• WordPress に関する警告

• ComicPress に関する警告

• SodaHead に関する警告

非常に多くの場合、脆弱性スキャンは、ポート 8080、8081、8088 など

のモビリティコントローラのキャプティブポータルインタフェースに対し

て実行されます。これらのインタフェースは、すべての要求がリダイレ

クト/リフレッシュをもたらすという点で異常な特性を持っています。リ

クエストの内容はレスポンスに反映され、HTTP の「meta」タグにカプセ

ル化されます。多くの脆弱性スキャナは、リクエストに含まれるスクリ

プトコードがレスポンスに表示されることに基づいて、これらのレスポン

スを XSS(クロスサイトスクリプティング)として誤ってフラグ付けします

(それらは「meta」タグを解析しません)。

さらに、URL に関係なく、これらのインタフェースへのすべての要求が

(リダイレクト/リフレッシュを使用して)応答されるため、脆弱性スキャナ

は Web アプリケーションをこれらのポートに存在すると誤って識別しま

す。

Aruba は、これらの誤検知によって脆弱性スキャナがトリガされないよう

に、将来のソフトウェアバージョンでキャプティブポータルの動作を変更

するための対策を講じています。それまでの間、これらの警告は無視し

ても安全です。

TLS/SSL CVE-2009-3555 CVE-2011-3389

CVE-2013-0169

CVE-2011-3389 ("BEAST")はクライアントサイドの脆弱性であるため、

サーバサイドで"修正"することはできません。このガイドで説明されてい

るように、軽減するには、TLS 1.0 と TLS 1.1 の使用を無効にします。

緩和策として、クライアント側でも CBC 暗号化を無効にすることができ

ます。

CVE-2014-0160 CVE-2014-0224

CVE-2014-3566 CVE-2014-8730

CVE-2015-4000 CVE-2016-2183

CVE-2014-3566 (“Poodle”)は SSL 3.0 の脆弱性です。古いバージョン

の ArubaOS では SSL 3.0 を無効にすることができました。新しいバー

ジョンは SSL 3.0 を完全に削除します。 CVE-2015-4000 ("Logjam")は

ArubaOS の脆弱性ではありません。多数の脆弱性スキャナが、たとえそ

うでなくても、すべての TLS サーバが脆弱であると報告しているようで

す。一部の脆弱性スキャナは、ArubaOS が CVE-2016-2183

(“SWEET32”)に対して脆弱であると報告しています。 2016 年半ば以

降、3DES サポートは ArubaOS から削除されたため、これは誤検知で

す。

TLS/SSL

Certificate

次のような警告が報告されることがあります。

• 信頼できない TLS/SSL サーバ X.509 証明書

• X.509 証明書のサブジェクト CN がエンティティ名と一致しない

• TLS/SSL サーバ X.509 証明書の SHA-1 ベースの署名

• TLS サーバ証明書係数が 2048 ビット未満

• SSL 証明書名の不一致

ArubaOS には、工場出荷時のデフォルトの

「securelogin.arubanetworks.com」という X.509 証明書が付属してい

ます。この証明書は本番ネットワークでは使用しないでください。通

常、脆弱性スキャナによって生成される警告メッセージはこの証明書に関

連しています。このガイドで説明されているように、管理者はこれらの

警告を排除するために固有の X.509 証明書を正しくインストールする必要

があります。これらの警告は誤検知ではありませんが、問題を解決する

には管理者の処置が必要です。

IP stack CVE-2004-0230 CVE-2002-0510

CVE-1999-0524

これらの項目には、それぞれ次のようにラベルが付けられています。

• TCP シーケンス番号の近似

• UDP 固定識別フィールド/ UDP IP ID Zero

• TCP/ICMP タイムスタンプ応答

その性質上これらを修正することはできませんが、Aruba は搾取の危険性

は十分に低いと判断し、それ以上の措置は必要ありません。

Cryptography 次のような警告が報告されることがあります。

• 弱い MAC

• 使用中の弱い暗号

• TLS サーバは DES および IDEA 暗号スイートをサポート

• TLS サーバは暗号ブロック連鎖暗号をサポート

• TLS サーバはスタティックキー暗号の使用をサポート

• TLS サーバは安全でない TLS 1.0 をサポート

詳細については、以下の「暗号化」というタイトルのセクションを参照し

てください。一般的に、Aruba は様々な暗号化プロトコルの研究にかな

りの時間を費やしており、製品は安全な構成を使用していると考えていま

す。場合によっては、広範囲のクライアントシステムとの互換性

(TLS_RSA_*などの静的キー暗号スイートのサポート)を実現するために

最も安全な設定を使用できないため、結果として得られる設定は妥当なト

レードオフとなります。他の場合では、国際的なセキュリティ標準コモ

ンクライテリアはどの暗号スイートがサポートされなければならないと命

じます。

Documents

Aruba SD-Branch Hardening Guide. コンテキスト: Aruba SD-Branchのセキュリティ セキュリティは、Aruba SD-Branch ソリューションの不可欠な部分です。

Aruba SD-Branch Hardening Guide. コンテキスト: Aruba SD-Branchのセキュリティセキュリティは、Aruba SD-Branch ソリューションの不可欠な部分です。