About kkondo

※この記事は以下の記事の日本語訳です。 How to Set Up DoS Protection https://live.paloaltonetworks.com/t5/Tutorials/How-to-Set-Up-DoS-Protection/ta-p/71164   ルールベースのDoS protectionを使用する場合、管理者はポリシーを設定して、DoS攻撃者から防御設定できます。ルールベースの設定はPolicies > DoS Protectionからできます。これらのポリシーは、ゾーン、インターフェイス、IPアドレス、ユーザ情報などが一致するものを条件として設定できます。     DoS protectionを使用するには、DoSのルールをセキュリティ・ポリシーのように、設定された条件で流れているトラフックが一致するよう作成します。これらの設定はObjectsタブ> Security Profiles > DoS Protectionにて設定できます。   まず初めに、プロファイルのタイプを明示的にします。aggregateかclassifiedを選びます。   Aggregate: プロファイル上のDoSの閾値をこのプロファイルに設定した条件ルールに一致する全てのパケットに対して適応します。例えば、秒間10000パケットのSyn flood閾値のaggregateルールは、その特定のDoSルールにヒットする全てのパケットをカウントします。 Classified: プロファイル上のDoSの閾値は分類基準別（送信元IP、宛先IPもしくは送信元、宛先IPの組み合わせ別）にカウントします。   DoS protectionプロファイルは、いくつかの種類のDoS攻撃を緩和させるために利用することができます。   Flood protectionはゾーン protectionプロファイルの一つに似ています。Syn floodでは、SYN CookieとRandom Early Drop(RED)がオプションで選べます。他のタイプのfloodではREDが使われます。ゾーン protectionプロファイルでは同じ設定オプションになっていることにお気づきになるでしょう。加えて、Block Durationがあり、攻撃しているIPを何秒間Denyするか設定できます。   Flood protectionに加えて、リソースprotectionも選択できます。このタイプのprotectionは、ホストの使用率を強制します。 特定の送信元IPアドレス、宛先IPアドレス、またはIP送信元と宛先ペアに対して許可されるセッションの最大数を制限します。   次に、Policies > DoS Protectionに移動し、セキュリティ・ルールと同様の手順で、DoSポリシーを作成します。   お気づきのように、ほとんどのパラメータはセキュリティ・ルールと同様です。 ルール名を設定した後、送信元、宛先、およびサービスを設定したら、Aggregateドロップダウンを使用してルールにプロファイルを添付するか、New DoS Protectionをクリックして新しいポリシーを作成できます。   deny/allow/protectの3種類の異なるアクションがあります。   Deny – トラフィックを全て落とします Allow - トラフィックを全て通します Protect - このルールに適用されるDoSプロファイルの一部として構成された閾値で設定された保護を実施します。   Schedule プルダウンを使用して、特定の日時にDoSルールを適用するスケジュールを割り当てることができます。 Log Forwarding プルダウンを使用して、脅威ログエントリをsyslogサーバやPanoramaなどの外部サービスに転送するようにログ転送を設定できます。 このチュートリアルのために、分類されたDoS保護プロファイルタイプを作成しました。 チェックボックスをオンにすると、Profile プルダウンメニューをから分類されたプロファイルタイプを選択できます。 下のAddressプルダウンメニューにて、先ほど述べた分類基準（source-ip-only / destination-ip-only / src-dest-ip-both）を選択できます。   例として、aggregate DoS protectionプロファイルとclassified DoS protectionプロファイルの両方を同じDoSルールに設定できます。   OKを選択し、Commitで設定を保存します。   CLIの場合、設定したDoS ルールを以下のコマンドで確認できます:   > show dos-protection rule <name> settings   このサンプル例では、以下のDoSルールが参照できます。 name = DosRule aggregate profile = DosProtection classified profile = Dos_classified classification criteria = source-only action = Protect   出力結果では、プロファイルで設定した全ての閾値も確認できます。   他にもVideo上で話されているトピックや、サンプルに関連した便利なリンク集が以下となります :   Understanding DoS Protection How to Configure a policy with DoS protection to protect hosted services  Differences between DoS protection and zone protection Video Tutorial – Zone protection profiles Understanding DoS logs and counters   著者: Kim ... View more

※この記事は以下の記事の日本語訳です。 How to Shut Down an Interface from the Web GUI or the CLI https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Shut-Down-an-Interface-from-the-Web-GUI-or-the-CLI/ta-p/53877   Web GUI Web GUIから、Network > Interface 落としたいインターフェイス設定を選択し、AdvancedタブのLink Stateプルダウンメニューからdownを選択します。 Commitで変更を反映します。     CLI ※ ethernet1/1を落とす設定の、実行例です。   > configure Entering configuration mode [edit] # set network interface ethernet ethernet1/1 link-state down #commit   著者: ppatel ... View more

※この記事は以下の記事の日本語訳です。 Apply QoS for Youtube or Streaming Media https://live.paloaltonetworks.com/t5/Configuration-Articles/Apply-QoS-for-Youtube-or-Streaming-Media/ta-p/66036   この記事は、ストリーミング メディアサイトにQoSを設定する方法について述べています。   以下のようなトポロジーで、 Ethernet 1/3はLAN側に、Ethernet 1/1はWAN側に設定されています。   QoSプロファイルを作成します。 QoSプロファイルの作成 QoSポリシーでトラフィックを特定のクラスにカテゴライズ設定します。 QoSポリシー名 QoSポリシー送信元 QoSポリシ - 宛先 制限をかけたい全てのアプリケーションを追加します： QoSポリシー - アプリケーション 必要に応じて、URLフィルタリング・カテゴリーを設定します： QoSポリシー - URLカテゴリー そして最後に、作成したポリシーをQoSプロファイルで一致させたいクラスに設定します： QoSポリシー – クラス これは重要なステップです。QoS プロファイルは送出パケットに適応されますので、ファイアウォールから大きなデータストリームが出ていくインターフェイスにそのプロファイルを割り当てる必要があります。この例では、クライアントはストリーミングをインターネットから受け取っており、大量のデータ フローがインターネットからクライアントへ流れているため、QoSプロファイルをクライアント サイドに適応することによって、フロー制御をします。 QoS インターフェイス QoS統計情報を確認します。Network > QoSに移動し、statisticsをクリックします。 QoS帯域実行結果   QoSについてのさらなる情報については、以下のGetting Started記事をご参照ください：   Getting Started: Quality of Service   著者: pankaku   ... View more

※この記事は以下の記事の日本語訳です。 Backing Up and Restoring Configurations https://live.paloaltonetworks.com/t5/Featured-Articles/Backing-Up-and-Restoring-Configurations/ta-p/65781   パロアルトネットワークス次世代ファイアウォールのバックアップからの設定情報の復元方法、保存とコミットの違い、Device > Setup > Operations > Configuration Management配下の様々なアクションについて学びます。         保存とコミットの違い   変更を設定情報ファイルに保存することと、変更をファイルにコミットすることは大きな違いがあります。パロアルトネットワークスは管理者が将来利用目的で、変更したり、それらを保存したりすることができます。しかしながら、管理者が変更を設定ファイルにコミットした場合、変更は、実行中の設定に上書きされ、即有効となります。   それゆえに、設定変更を加える前に、 実行中の設定を保存することをお勧めします。シリアスな設定ミスをして、バックアップを取得しておかなかったために、変更を戻したり、前回の設定に引き戻しすることが困難になります。   設定の保存、リストアについて パロアルトネットワークスのオペレーティングシステムは管理者に以下のオプションを提供します：     検証 候補設定の検証 戻す 最後に保存した設定に戻す   実行中の設定に戻す 保存 名前付き設定スナップショットの保存   候補設定の保存 ロード 名前付き設定スナップショットのロード   設定バージョンのロード エクスポート 名前付き設定スナップショットのエクスポート   設定バージョンのエクスポート   デバイス状態のエクスポート インポート 名前付き設定スナップショットのインポート   デバイス状態のインポート   検証—候補設定の検証   候補設定のエラーをチェックします。パロアルトネットワークスOSでは、管理者がコミットしていない、保存した設定ファイルの検証をすることができます。検証プロセスでは、設定情報上の、可能性のあるエラー、競合を精査します。管理者には出力結果が提示されます。この機能は、設定ミスや、間違った設定情報ファイルをロードすることを避けるのに、役立ちます。   戻す   もし設定情報の間違いをしてしまった場合に、オペレーティングシステムは最後に保存した設定情報、実行中の設定に即座に戻すことができます。最後に保存した設定情報、実行中の設定に違いがある場合、これらの2つのオプションは、ワンクリック復元と呼びます。どのファイルから復元するかは選択できません。両方のオプションは、2つの違う情報ソースから設定を復元します：   保存した設定情報から戻すのは、xmlファイルから復元します。 実行中の設定から戻すのは、running-config.xmlファイルから復元します。   最後の保存した設定情報に戻す   戻すオプションは、ローカル装置上の最後に保存した候補設定から復元します。現在の候補設定は上書きされます。 候補設定が保存されていない場合、エラーが発生します。重要な装置を設定している際に、素早く復元する便利な機能です。   これは最初に表示されるプロンプトで、復元を継続していいか聞いています。   2個目のメッセージでは、どのファイルから復元したか通知します。     パロアルトネットワークスの装置は、実行中の設定のスナップショットを生成し、ハードディスク上に保存します。実行中の設定の新しいバージョンは、変更したり、コミットした際に毎回作られます。これはとても便利な機能で、管理者が意図していない変更を加えた場合に素早く設定情報を以前の状態に戻すことができます。   実行中の設定に戻す   このオプションは、running-config.xmlから設定を復元します。現状の実行中の設定は上書きされます。   これは最初に表示されるプロンプトで、復元を継続していいか聞いています。     2個目のメッセージでは、どのファイルから復元したか通知します。       設定ファイルを保存する   設定ファイルを保存する方法は２つあります。   名前付き設定スナップショットを保存する。 候補設定を保存する。   これらはどういう違いがあって、なぜ2つのオプションがあるのでしょうか？   名前付き設定スナップショットの保存オプションは候補設定をファイルに保存します。保存している設定情報ファイルは実行中の設定に上書きされません。この機能は、バックアップファイルを作成したり、将来的に変更、もしくはラボ環境で試験をするためにダウンロードされた試験用の設定情報ファイルとして利用するのにとても便利です。ファイルに名前付けすることも、既存のファイルに上書きすることも可能です。注意：実行中の設定(running-config.xml)には上書きできません。   候補設定を保存 候補設定をフラッシュメモリ(ページトップにある、Saveをクリックするのと同様の意味)に保存します。   名前付き設定スナップショットのロード   候補設定を実行中の設定(running-config.xml)もしくは、以前インポートされた、保存された設定情報からロードします。ロードすべきファイルを選択します。現行の候補設定は上書きされます。   設定バージョンのロード 特定バージョンの設定情報をロードします。   名前付きされた設定スナップショットのエクスポート 実行中の設定情報(running-config.xml)もしくは過去に保存、インポートされた設定情報をエクスポートします。エクスポートすべきファイルを選択します。ファイルを開く、もしくはネットワーク上のロケーションに保存します。   設定情報バージョンのエクスポート 特定バージョンの設定情報をエクスポートします。   Panoramaおよびデバイスの設定バンドルのエクスポート(Panoramaのみ) Panoramaと管理している各々のファイアウォールの最新バージョンの実行中の設定情報バックアップを手動で生成、エクスポートします。自動的に生成、エクスポートするバンドル設定情報を日次でSCPもしくはFTPサーバに保存する方法については“Scheduling Configuration Exports"を参照ください。   デバイス状態のエクスポート(ファイアウォールのみ) この機能は設定情報と動的情報をGlobalProtectポータルにて、大規模なVPN機能を有効設定しているファイアウォールからエクスポートする場合に使われます。もしポータルが失敗に遭遇している場合に、エクスポートされたファイルをインポートすることによって、ポータルの設定や、動的情報を復元することができます。   エクスポートされたファイルには、ポータルが管理しているサテライトデバイスリストや、エクスポートされたタイミングでの実行中の設定情報、そして、全ての証明書情報(Root CA, サーバ情報、サテライト証明書)が含まれます。   重要 ： 手動で、機器ステートのエクスポートを走らせるか、ファイルをリモートサーバにエクスポートするスケジュールされたXML APIスクリプトを作成する必要があります。サテライト証明書がしばしば変更になる可能性があるため、これは定期的に実施する必要があります。   デバイス状態ファイルをCLIから作成するためには、設定モードから、デバイス状態の保存を実行する必要があります。 ファイル名はdevice_state_cfg.tgzとなり、/opt/pancfg/mgmt/device-stateディレクトリに保存されます。ファイルをエクスポートするオペレーショナルコマンドは、scp export device-state(tftp export device-stateも利用可能)です。XML APIを使用した情報については、XML API Usage Guideを参照ください。   名前付き設定スナップショットのインポート 設定情報ファイルをネットワークのロケーションからインポートします。Browseをクリックし、設定すべき設定情報ファイルを選んでください。   デバイス状態のインポート (ファイアウォールのみ) エクスポートオプションを使ってエクスポートされたデバイス状態をインポートします。これは、実行中の設定、Panoramaテンプレート、共有のポリシーを含みます。もし装置がGlobal Protectポータル設定がある場合、エクスポートされたファイルは、証明局（CA）情報、サテライト装置のリスト、そしてそれらの認証情報を含みます。   著者: rchougale ... View more

※この記事は以下の記事の日本語訳です。 What are suspicious DNS queries? https://live.paloaltonetworks.com/t5/Threat-Vulnerability-Articles/What-are-suspicious-DNS-queries/ta-p/71454   PAN-OS装置にて、疑わしい(Suspicious)DNSクエリがトリガーした脅威ログを示しています。   Detail of Threat log with Suspicious DNS Query.   疑わしい(Suspicious)DNSクエリのシグネチャとは？ 疑わしい(Suspicious)DNSクエリのシグネチャは、潜在的にC2トラフィックに関連するドメインへのDNS名前解決をチェックします。このC2トラフィックはマシンが乗っ取られた兆候の可能性もあります。   疑わしいDNSクエリ・シグネチャは、多層防御を提供するために、キルチェーンの中のあらゆるポイントに保護を適用するPalo Alto Networks のアプローチのひとつです。これにより、攻撃者は攻撃を成功させるために追加の検査ポイントを回避する必要がでてきます。昨今の脅威環境は動的であるため、アンチウイルス、脆弱性エクスプロイトの検出、URLフィルタリングは有効ですが、さらに多くのことが可能です。 それは、潜在的な悪意のある接続先への接続を、名前解決が行われる前に切断することです。   疑わしいDNSシグネチャはアラート設定や、接続をリセットまたはドロップすることによって名前解決をブロックする設定、もしくは製品に備わっているDNSシンクホール機能を利用して被疑対象に接続しないような設定ができます。 パロアルト ネットワークスのベスト プラクティスは、疑わしいDNSクエリの送信元IPを特定できるように、シンクホールに設定することです。   不審なDNSクエリー・シグネチャはどのように機能しますか？ どのように提供されますか？ 疑わしいDNSクエリー・シグネチャ（以降、SDNSシグネチャ）は、シグネチャが存在するドメインへの名前ルックアップを検査するPAN-OSアプライアンスを通過するDNSトラフィックを元に動作します。 パケットのキャプチャがSDNSシグニチャで有効化されている場合、その中には単順に特定のドメインへのDNSクエリーが含まれます。     SDNSシグネチャは、パロアルト ネットワーク ス  バックエンドのインテリジェンス情報収集の結果です。 WildFireサンドボックスにて検体を走らせた際の結果、外部インテリジェンス フィード、および研究者からの分析、などがその例です。   作成されたシグニチャは、次の2つの方法でPAN-OS機器に送られます。   WildFireコンテンツ、脅威ID 3,800,000  - 3,999,999 。 デバイスのWildFireコンテンツ アップデート スケジュールの更新頻度の設定、およびシグネチャがまだ有効かどうかに応じて、15分ごとに更新することも可能です。 これらのシグネチャは、次のフォーマットで脅威ログに表示されます。Malwarefamilyname:domain（例: None:google[.]com）シグネチャを生成するために使用されたサンプルにファミリーネームが関連付けられていない場合は、「None」が代わりに使用されます。   アンチウイルス コンテンツ、 脅威ID  4,000,000  - 4,199,999 。 アンチウイルス  コンテンツは、通常、およそ午前7時（EST）に、24時間に1度リリースされます。これらのシグネチャは、次の形式で脅威ログに表示されます。 Suspicious DNS Query:  Malwarefamilyname:domain（例：Suspicious DNS Query: None:google[.]com）シグネチャを生成するために 使用されたサンプルにファミリーネームが関連付けられていない場合は、 「None」が代わりに使用されます。 シグネチャは、コンテンツの「スパイウェア」部分に表示されます。 シグネチャ の脅威ID番号によって識別できるものの詳細については、 このリンク（英文）を参照ください。 （※ 訳注：前述した脅威IDの範囲についても、最新情報はこのリンク先の記事を参照してください。）      以前に検知されたSDNS クエリー シグネチャは、脅威モニターで名前が変更されていることに気が付いているかもしれません。なぜ起こったのか疑問に思うかもしれません。   現在のSDNSシグネチャの実装について、コンテンツの場合は一般的に、現在のコンテンツ内で各脅威にはIDが割り当てられています。割り当てられるコンテンツ スペースは無限でないため、とある時点において、SDNSコンテンツ スペースで最もアクティブで危険な脅威を保つことが優先事項です。脅威の状況が急速に変化するため、シグネチャは置き換えられることがあります。   脅威モニターUIの現在の実装では、現在ファイアウォールにインストールされているコンテンツ データベースから直接「名前」フィールドが照会されます。これが意味することは、一旦脅威モニターがロードされると、あるドメインで読み取られた以前のシグネチャトリガーが、現在のシグネチャに関連されたものに置き換わって表示されるようになることです。   例： WildFireコンテンツ１では、Google[.]comがSDNS脅威ID 3,800,000に割当てられています。 この脅威が検知されると、 脅威ID  3,800,000 Google[.]com が脅威ログに記録されます。 WildFireコンテンツ２がインストールされます。 WildFireコンテンツ２では、Bing[.]comがGoogle[.]comに代わってSDNS 脅威ID  3,800,000が割当てられています。 以前、脅威ログに記録されていたものは、Bing[.]comとして誤って表示されます。   今のところ、最も単純な回避策は、DNSトラフィックが通過しているセキュリティ ルールに割り当てられたアンチスパイウェア プロファイルを開いて、SDNSシグネチャでパケット キャプチャ採取を有効にすることです。 パケット キャプチャは静的なデータであり、変更されません。     DNSシグネチャが変更される理由については この記事 を参照ください。   不審なDNSクエリー・シグネチャの発生を検知したらどうすべきですか？ SDNSシグネチャ トリガーは、必ずしもスパイウェア感染を指し示すものではありませんが、他のインジケーターと共に使用して、危険にさらされている可能性のあるホストを特定するのに利用できます。ホストは、悪意のある行為であると言い切れない外向けネットワーク接続パターンを表示している可能性があります。   ホストがSDNSシグネチャが存在するドメインへのトラフィックを生成すると、プロアクティブなセキュリティ アナリストは、ネットワーク上のトラフィックを特定して検査やその他のアクションを保証するのに役立ちます。 もしホスト・トリガーにてSDNSシグネチャが検知されたのと同時に、AV検出、脆弱性シグネチャー検出、またはマルウェアとして分類されたURLのWeb閲覧などが見受けられた場合は、SDNSシグネチャを使用したことにより、そのホストに対してさらなるアクションが必要であることに確信が持てます。   AutoFocusのご使用の場合は、WildFireサンプルやその他の公開サンプルを調べ、マルウェアの判定を受けかつ特定のドメインに到達したサンプルを検索することができます。これにより、アナリストは、インシデント レスポンス アクションに備えるために、シグネチャが存在する理由と、疑わしいドメインへのトラフィックを生成したサンプルの動作を理解するのに役立ちます。 AutoFocus showing a query on a suspicious DNS domain. そのシグネチャーをさらに調べるために、サードパーティーからのオープンソースの情報源は、セキュリティ コミュニティがどのような種類のインテリジェンスを、そのドメインに対して持っているかを調べるのに、とても良い方法です。   いくつかのサードパーティーを利用した調査サンプル例: VirusTotal URLスキャンを使用して、他のベンダーの検査結果を確認します。 PassiveTotalを使用して、ドメインのパッシブDNS履歴を確認します。 WHOISを活用して、ドメインの所有者、登録日時、その他のデータの詳細を確認します。   アラートが調査するに値すると決まったら、ホスト上のパケットキャプチャによって、ユーザのアクティビティや疑わしいトラフィックなどのコンテキストデータを参照することは、さらなるアクションが必要かどうかの追加設定の助けとなります。   上記のすべてを行っても、特定のSDNSシグネチャが大量のアラートを生成していて、かつ、あなたが確認する限りそのドメインに対してネガティブな活動が見受けられない場合はどうしたらいいでしょうか？   この場合、Palo Alto Networksのサポートは、シグネチャが無効にすべき候補であるかどうかを特定する手助けをいたします。多くのお客様にシグネチャが重大なノイズを生成しているように見える場合は、脅威ログの調査に時間を浪費しないようにして欲しいと思います。 ただし、そのシグネチャに対し確証がある場合は、スパイウェア プロファイルの例外機能を活用して、トラフィックを許可してアラートを停止することができます。   不審なDNSクエリー・シグネチャのサンプル例:   SHA256の”932836effd33218470e1c78dad3505d59af31ecff599e875ed79f47114552883”をサンプル例としてみてみましょう。   このサンプルはPEファイルで、一旦実行すると、いくつかの不審なC2 HTTPトラフィックを作り出します。     結果、該当ドメインへのトラフィックを止めるためのC2ドメイン・シグネチャが生成されました。   ... View more

※この記事は以下の記事の日本語訳です。 Getting Started: Layer 3 Subinterfaces https://live.paloaltonetworks.com/t5/Featured-Articles/Getting-Started-Layer-3-Subinterfaces/ta-p/67395   ファイアウォールを開梱して、Vlan（サブ・インターフェイス）の設定をしたい     現在、新しいパロアルトネットワークス・ファイアウォールが起動して、動作している状況です。作成した様々なLayer 3サブ・インターフェイスにタグ付けしたVLANを追加してみましょう。一連の導入設定ガイドでは、ファイアウォールの箱を開梱し、ソフトウェアのアップグレード、VWireもしくはLayer3モードの設定が終わった後の最初のステップについて記述しています。 I've unpacked my firewall, now what?  と  I've unpacked my firewall and did what you told me, now what?  を参照してください。   あなたの組織では、インターネット上のWeb Serverとユーザのワークステーションを分けるために複数のネットワークセグメントが存在しているかもしれません。これらのネットワークが相互に通信するのを防ぐには、コアスイッチにVLANを実装し、両方のバーチャルネットワークを接続するブリッジやゲートウェイなしで、1つのVLANにあるホストが別のVLANにあるホストと通信できないようにします。   まず、前回の導入設定ガイドの続きから見ていきましょう。ファイアウォールにはLayer3インターフェイスがあり、トランクインターフェイスと通信できるようにTrustインターフェイスを変更する予定です。   レギュラーもしくはアクセス・スイッチポートとトランク・スイッチポートの違いは、アクセス・ポートがいかなるパケットでもイーサネットヘッダーを改ざんしないのに対して、トランク・ポートは IEEE 802.1Q ヘッダーの形式でVLANタグを付加することです。これにより、パケットはスイッチ外でVLAN情報を保持し、これらのパケットを受信する次のホストによって違うLANネットワークとして扱われることが保証されます。   interface GigabitEthernet1/36  switchport  switchport access vlan 100  switchport mode access  switchport nonegotiate  spanning-tree portfast ...reconfigure... interface GigabitEthernet1/36  switchport  switchport trunk allowed vlan 100,200  switchport mode trunk  switchport nonegotiate spanning-tree portfast インターフェイス設定を、VLANタグ設定のサブインターフェイスに変更します。   1. サブインターフェイス設定   最初に物理ファイアウォールからIP設定を削除します。 Networkタブに移動。 左パネルのInterfacesに移動。 Interface設定を開く。 IPv4タブを開く。 ネットワークアドレスを選択。 Deleteをクリック。   サブインターフェイスを追加する準備ができました。   サブインターフェイス設定では、インターフェイス番号とタグを割り当てます。タグはVLANと一致している必要がありますが、インターフェイス番号は違っても構いません。管理を容易にするために、双方を同じにしたほうがよいでしょう。そしてインターフェイスをDefault Virtual Routerに割り当て、Trustセキュリティ・ゾーンに設定します。     次に、IPv4タブに移って、インターフェイスにIPアドレスを追加します。   次に、Advancedタブに移り、Management Profileで'ping'を選択します。     次に、Webサーバーを次の図のようにスイッチのVLAN 200に加えます。   第2のサブインターフェイス設定が必要で、それをVLAN 200タグに設定します。違うセキュリティ・ゾーンを作成し、違うセキュリティ・ポリシーを設定することができます。   'dmz'ゾーンを作成します。     そして、違うインターフェイスとIPサブネットを割り当てます。   そしてManagement Profileに'ping'を設定します。   インターフェイス設定は以下のようになっているかと思います。   2. DHCP再設定   前回設定したDHCPサーバー設定を新しいサブインターフェイス設定に移動します。 Networkタブに移動。 左パネルから、DHCPメニューを選択。 インターフェイスethernet1/2用のDHCP設定を開く。 インターフェイスをethernet1/2.100に新しいサブインターフェイス設定に一致するよう変更。   3. 新しいNAT ポリシー設定   次のステップは、ファイアウォールの外部アドレス経由で、インターネット上のWebサーバにホストが接続するためのNATポリシーを設定します。 Policiesタブに移動。 NAT設定を左側パネルから選択。 Addをクリックして、新しいNATポリシーを作成。     Original Packetタブでは送信元、宛先ゾーンをuntrustそして、宛先アドレスを、ファイアウォールの外部アドレスに設定します。宛先ゾーンがuntrustなのは、ファイアウォールは宛先ゾーンを受信パケットのルーティングテーブルベースで決定するからです。この場合、NAT変換前の宛先IPアドレスが適用され、untrustゾーンとなります。   Translated Packetタブでは、Webサーバーの物理アドレスを設定します。   4. Securityポリシーの追加   最後のステップでは、Webサーバーにアクセスするために、TrustからUntrustゾーンを許可するSecurityポリシーを追加します。 Policiesタブに移動。 左パネルからSecurityを開く。 Addをクリックして、access_to_webserverという名前のSecurityポリシーを追加。 ここでは、送信元ゾーンが'untrust'を選択、   宛先には'dmz'を選択、宛先アドレスには、ファイアウォールの外部IPアドレスを設定します。   アプリケーションにはweb-browsingを追加し、   攻撃者からWebサーバーを守るために、必要なSecurityプロファイルを選択します。   TrustゾーンからのSecurityポリシーのステップを繰り返し、追加のアプリケーションを設定します。   Destinationでは、Securityゾーンに'dmz'を、アドレスにはWebサーバーの内部アドレスを設定します。   追加の管理用Applicationsを加えます。   設定されたSecurityポリシーは以下の様になっています。   新しい設定をcommitした後に、インターフェイスethernet1/2がVLAN 100と200のタグ付きパケットを処理でき、Webサーバーが外部インターネットに対して公開されていることが確認できます。    もしこの記事に興味がありましたら、次のフォローアップ記事も併せてご参照ください。 I’ve unpacked my firewall, but where are the logs?   著者: reaper ... View more

※この記事は以下の記事の日本語訳です。 Tips & Tricks: Forward traffic logs to a syslog server https://live.paloaltonetworks.com/t5/Featured-Articles/Tips-amp-Tricks-Forward-traffic-logs-to-a-syslog-server/ta-p/71966   トラフィックログをPalo Alto Networks ファイアウォールからSyslog サーバに転送する必要がありますか？レポーティング、法令上、保存領域といった理由から、それらのログをファイアウォールからSyslog サーバに転送設定する必要があります。このステップ バイ ステップにそって設定してみてください。トラフィック ログをSyslog サーバに転送するには以下の4つのステップが必要です。   Syslog サーバ プロファイルの作成。 ログ転送プロファイルの作成。 作成したログ転送プロファイルをセキュリティ ポリシーに設定。 コミットにて変更を反映。 ステップ1. Syslog サーバ プロファイルの作成 WebUIからDevice > サーバー プロファイル (Server Profiles) > Syslogに移動。 2. 名前 (Name) : Syslog サーバ プロファイルの名前を入力 (最大31文字)。名前は大文字小文字を区別し、ユニークでなければなりません。      使える文字は、アルファベット、数字、スペース、ハイフンとアンダースコアです。 3. 追加 (Add) をクリックし、Syslog サーバ名を入力 (最大31文字)。名前は大文字小文字を区別し、ユニークでなければなりません。      使える文字は、アルファベット、数字、スペース、ハイフンとアンダースコアです。     Syslog サーバー (Syslog Server): Syslog サーバのIPアドレスを入力。 転送 (Transport): Syslog メッセージを送付するプロトコルをUDP、TCPもしくはSSLから選択。 ポート (Port): Syslog サーバのポート (スタンダードポート : UDPは514; SSLは6514; TCPは任意の番号を指定)を入力。 フォーマット (Format): 使用するSyslog フォーマット: BSD (デフォルト設定) もしくはIETFを指定。 ファシリティ (Facility):  Syslogのスタンダード値の一つを選択。Syslog サーバがFacility フィールドをどのように使ってメッセージを管理するかマッピングします。Facility フィールドの詳細については、 RFC 3164  (BSD format)もしくは RFC 5424 を参照ください。   あなたのSyslog サーバ プロファイルが、以下の設定例のように作成できました。     外部レポーティング ツールと連携するために、ファイアウォールはログ フォーマットをカスタマイズできます。さらに、カスタム キーの追加もできます。カスタム フォーマットは以下から設定できます。 Device > サーバー プロファイル (Server Profiles) > Syslog > プロファイル名 > カスタム ログ フォーマット (Custom Log Format):   ArcSightのCommon Event Format (CEF)に準拠したログフォーマットについては CEF Configuration Guides  を参照ください。   ステップ2. ログ転送 (Log forwarding) プロファイルの作成 WebUIからObjects > ログ転送 (Log forwarding)に移動し、追加 (Add)をクリックします。         名前 (Name): プロファイル名(最大31文字)。この名前はセキュリティ ポリシーに設定した場合に、ログ転送プロファイルの一覧に表示されます。名前は大文字小文字を区別し、ユニークでなくてはなりません。使えるのはアルファベット、番号、スペース、ハイフンそして、アンダースコアです。 Syslog : トラフィック ログを送付する宛先を指定するために、Syslog サーバ プロファイルを選択します。 設定を確認してOKをクリックします。   ログ転送プロファイルが作成できました。以下のサンプルのようになっていると思います。     ステップ3. 作成したログ転送プロファイルをセキュリティ ポリシーに設定   WebUIからPolicies > セキュリティ (Security)に移動。     ログの転送設定をしたいルールを選びます。画面サンプル例はAny Allowを選択。         次に、アクション (Actions) タブに移動し、ドロップダウンから作成したログ転送プロファイルを選択し、設定が完了したらOKをクリック。     OKをクリックした後、設定したセキュリティ ルールのオプション (Options)欄に、Forwarding アイコンが表示されます。     ステップ4. 設定が完了したら、コミット (Commit)し設定を反映する。   著者: Kim ... View more

※この記事は以下の記事の日本語訳です。 When Does Palo Alto Networks Firewall Send a TCP Reset (RST) to Terminate a Session? https://live.paloaltonetworks.com/t5/Learning-Articles/When-Does-Palo-Alto-Networks-Firewall-Send-a-TCP-Reset-RST-to/ta-p/56572   TCP リセットはTCPのセッションを即時クローズします。これにより、コネクションに割当てられたリソースを解放し、システムを再利用することができます。リセットを受け取る側は、クライアント側であり、セッションが突然閉じられることで、送ろうとしたデータを送付できなかったかもしれません。   Palo Alto Networks ファイアウォールがTCP リセットを送るのは、トラフィック・フローで脅威を感知した場合のみです。それ以外の場合のTCP リセットはファイアウォールからのものではありません。   著者: aprasanna ... View more

※この記事は以下の記事の日本語訳です。 How to Use Anti-Spyware, Vulnerability and Antivirus Exceptions to Block or Allow Threats https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Use-Anti-Spyware-Vulnerability-and-Antivirus-Exceptions/ta-p/66099   この記事は、アンチスパイウェア、脆弱性防御、アンチウイルスの例外設定において、Palo Alto Networks ファイアウォールで、特定脅威のアクションを変更する方法について記述しています。    アンチスパイウェア、脆弱性防御の例外設定 この例では、アンチスパイウェアの既存プロファイル名 "Threat_exception_test_profile" の例外設定に脅威ID番号30003を追加します。 Objects > セキュリティ プロファイル > 'アンチスパイウェア' もしくは '脆弱性防御' に移動します。 既存のプロファイルを選択 "例外 (Exceptions)"タブを選択 まず、画面左下にある"Show all signatures"チェックボックスを選択し、 検索フィールドで、検索したい文字列（例：'microsoft' ）もしくは脅威ID番号（例：30003）を入力し、改行ボタン、もしくは緑の矢印をクリックし、検索を実行します。 注意: もしシグネチャ検索がdynamic update直後で、検索結果が得られない場合は、GUIのキャッシュをクリアするために、WebUIをログアウトして、ログインしなおしてください。 "Microsoft Windows DCOM RPC Interface Buffer Overrun Vulnerability"（脅威ID番号30003）が表示されます。 注意: 脅威ID番号は、threatログから容易に見つけられます。 この例外を有効にするため'Enable'ボックスをクリックします。 既定の'アクション'を変更するため、通過させたい場合はAllow、落としたい場合は、Dropを選択します。 Threat Action detail - change default action. IPアドレスの例外欄は、脅威例外をIPアドレスでフィルターしたい場合に使います。もしIPアドレスが追加されれば、送信/宛先IPアドレスが例外設定と一致した場合のみ、シグネチャのルールアクションが適応されます。シグネチャ当たり100個までIPアドレスを追加できます。このオプション設定によって、特定のアドレス毎に、新しいセキュリティ・ルールを作る必要はありません。全てのトラフィックでなく特定のアドレスを除外したい場合、画面下の"IP Address Exemptions"をクリックして、追加したいIPアドレスを100個まで追加してください。 IP Address Exemption detail. IPアドレス例外設定詳細 アンチスパイウェアもしくは脆弱性防御プロファイルが適切なセキュリティ ポリシーに設定されていることを確認してください。 例外設定を有効にするためにCommitを実行します。   アンチウイルス例外設定 この例では、アンチウイルスの既存のプロファイル名 "AV_exception_test_profile" の例外設定に脅威ID番号253879を追加します。 （注意: アンチウイルスの例外設定は、全体に対して有効か無効かの設定であり、特定のIPアドレスに対しての例外設定はできません）   Objects > セキュリティ プロファイル > アンチウイルスに移動します。 既存のプロファイルを選択し、ウイルス例外 (Virus Exception) タブをクリック。 ID（この例では253879）をページ下の脅威 ID フィールドに入力し、追加をクリックします。 注意: 脅威 IDはthreat ログから見つけられます。 この例では、"Win32/Virus.Generic.koszy"の例外が作られました。 AntiVirus - Virus Excemption window detail. AntiVirus – Virus例外ウィンドウの詳細 アンチウイルス プロファイルが適切なセキュリティ ポリシーに設定されていることを確認してください。 アンチウイルス例外設定には特定IP アドレスを除外するオプションはありません。 変更を反映するためにCommitを実施します。   著者: kadak ... View more

※この記事は以下の記事の日本語訳です。 Configure Palo Alto GlobalProtect with Azure Multi-Factor Authentication https://live.paloaltonetworks.com/t5/Management-Articles/Configure-Palo-Alto-GlobalProtect-with-Azure-Multi-Factor/ta-p/79117   AzureのRADIUS認証で多要素認証 (MFA) を使ったGlobalProtectの設定方法について記述します。設定の注意点として、AzureはPAP と MSCHAPv2 認証のみのサポートなので、Palo Alto Networks GlobalProtectでは、PAP認証方式のみ設定が可能です。   Azure MFA設定は、オンプレミスのMFA Server RADIUS（Microsoft推奨）を使用します。 注意: MFA Serverが既にインストールされており、ADとユーザー情報がSync済みであることを前提としています。   Radius認証を有効にします。 クライアント タブでは、Azure Multi-Factor Authentication RADIUS serviceがRADIUS リクエストを受け付けるポートをスタンダードポート以外にする必要がある場合、認証、アカウンティングポートを変更します。これはPalo Alto Networks上の設定も同様です。 クライアント欄で、Addをクリック Palo Alto Networks ファイアウォールのManagement IPをAzure Multi-Factor Authentication Serverに認証するIPアドレスとして設定します。 名前を入力します（任意設定） 共有暗号鍵 (shared secret) を入力します。 'Require Multi-Factor Authentication user match' チェックボックスをクリック。 もしユーザがAzure Multi-Factor Authenticationモバイルアプリ認証を使用していて、OATHのパスコードを、外線通話、SMS、プッシュ通知の際に利用したい場合は、‘Enable fallback OATH token’ チェックボックスをクリックします。      8. Targetタブで、機器がドメインに参加している場合は‘Windows domain’を選択、そうでない場合は’LDAP bind’を選択します。       GlobalProtect設定 注意: Azure MFA SeverはPAPとMSCHAPv2のみのサポートです。GlobalProtectの設定で、PAP認証を設定する必要があります。デフォルト設定はAutoです。もし違う認証が選択された場合、authd.logに不正ユーザ名/パスワードのエラーメッセージのみが記録されます。 RADIUS CHAP認証モードをPAN-OS 7.0.3、それ以前で、CLI、WebUIから手動設定で外すオプションはありません。 PAN-OS 7.0.4以降では、以下のコマンドで、手動設定でRADIUS認証タイプを選択できます。 > set authentication radius-auth-type <auto|chap| pap >   Palo Alto Networks ファイアウォールにログインします。 Device> サーバー プロファイル > RADIUSに移動し、以下のプロファイルを作成します。 a. プロファイル名 (Profile Name) -  MFA serverの名前 b. 場所 (Location) - 共有 (Shared) c. タイムアウト (Timeout) – 30～60秒で、multi-factor認証、Radiusアクセス・リクエスト処理の送受信など、ユーザ認証に必要な時間（以下のスクリーンショットを参照） d. 再試行 (Retries) – 3回 e. 追加 (Add) をクリックし、RADIUS ServerにWindows Azure Multi-Factor Authentication serverのFQDNもしくはIP アドレスと、以前に設定したshared secretを入力 f. ポート (Port) - 1812 (デフォルト). Network > ゲートウェイ（ゲートウェイは設定済みであることが前提） 全般 > 認証プロファイルでステップ2で作成したプロファイルを選択           著者: smisra   ... View more

※この記事は以下の記事の日本語訳です。 How to Delete Unnecessary Downloaded Software Versions https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Delete-Unnecessary-Downloaded-Software-Versions/ta-p/66014   詳細 Palo Alto Networks ファイアウォールは、ダウンロード済みソフトウェア・バージョンを、いつでも古いバージョンに戻すことができるために保存しています。アップグレード後、ディスクスペースの確保のために、古い、不必要なソフトウェアを削除したいかもしれません。   WebGUIから WebGUI > Device > Softwareを選択し、内側のパネルから実行できます。内側のパネルには現在ダウンロード済みのソフトウェアが表示されています。そして現在使用していないソフトウェアを削除することができます。例えば、現在PAN-OS 7.1.2（ベースOSイメージとしてPAN-OS 7.1.0も必要です）にて起動しているとします。PAN-OS 7.0.1 or 6.1.0といった古いVersionが不必要だった場合、削除することができます。   Device > Software tab showing the installed versions. Use the X to delete a version that is not currently activated. Device > SoftwareタブではインストールされたVersionが表示されています。”X”ボタンで、未使用なVersionを削除できます。 内側のパネルに表示されている、未使用の各PAN-OSの右側に”X”ボタンがあり、それをクリックすることで削除することができます。システムの起動には現行Versionとベース Version（例：PAN-OS 7.1.3が現行Versionで、PAN-OS 7.1.0がベース Versionの場合、双方とも削除することができません）が必要です。それ以外のVersionは削除することができます。   CLIから 以下のコマンドで古いソフトウェアを削除することができます : > delete software version <filename> PAN-OS 5.0.8を削除するコマンドの例です : > delete software version 5.0.8   ?キーや<tab>キーを入力すると、その他のオプションが表示されます。   消したいVersionを選択してください。この例では、PAN-OS 6.0.6が現行Versionで、ベース VersionのPAN-OS 6.0.0は削除できません。   注意: これらのファイルが保存されているパーティションは”/opt/panrepo”です。”> show system disk-space”コマンドをファイル削除・前後で確認してみてください。古いVersionを削除後、スペースが確保されていることが確認できます。   著者: rborda ... View more

※この記事は以下の記事の日本語訳です。 Integrating Cisco ISE Guest Authentication with PAN-OS https://live.paloaltonetworks.com/t5/Integration-Articles/Integrating-Cisco-ISE-Guest-Authentication-with-PAN-OS/ta-p/98295     Cisco ISEがPAN-OSにユーザーID情報を送付する設定について記述したものです。この設定例では、Cisco ISE 1.4.0-253とPAN-OS 6.1/7.0を使用しています。  この設定例では、ユーザーIDがActive Directoryで既に動作しています。ゲスト情報のみをCisco ISEから得ることを設定者は考えています。この振る舞いは、正規表現にてサブネットを追加/削除することにより変更できます。   Cisco ISEはネットワーク上のユーザーを認証するためのRADIUSサーバーとして動作します。RADIUS認証、アカウンティングログをPAN-OSに送付することができます。   — 詳細   Cisco ISE上で新規Remote Log Targetを設定します。デバイスはPAN-OS装置になります: Administration > System > Logging > Remote Logging Targets を選択します。 Addをクリックします。 Nameにご自由に名前を入れて、Target TypeにはUDP Syslogを選択します。IP addressには、PAN-OS管理インターフェイスのIPアドレスを入力します。 Submitをクリックします。   他にUser-IDログ情報を送りたいデバイスがある場合は、操作を繰り返します。   ISEでPassed Authentication Syslog Messages転送設定をします。 Administration > System > Logging > Logging Categoriesを選択します。 Passed Authenticationsをクリックします。 先程作成したremote log targetを選んで、“Available”欄から、“>”をクリックして、“Selected”欄に移します。 Saveをクリックします。    ユーザー ID Syslog リスナー UDPをPAN-OS上で有効にします。 Device > セットアップ > 管理インターフェイス設定を選択します。 ユーザー ID Syslog リスナー UDP のチェックボックスを選択します。 OKをクリックします。   Syslog 解析プロファイルを送付されてくるsyslog messagesとマッチするように設定します。 Device > ユーザー ID > ユーザー マッピングを選択します。 Palo Alto Networks ユーザー ID エージェント設定を編集、Syslog のフィルタをクリックします。 追加を選択します。 下記のようにすべての情報を入力します。   ここは注意が必要な個所です。-- 無線装置には、Cisco ISEはUser-ID情報を認証ログのみに、そして有線装置にはUser-ID情報をアカウンティングログのみに送付します。   参照例としては、   10.10.130.0/24 = 無線ゲスト 10.10.30.0/24 = 無線ゲスト 10.10.140.0/24 = 有線ゲスト イベントの正規表現は以下のようになります。   Syslog 解析プロファイル: Cisco ISE イベントの正規表現: ([A-Za-z0-9].*CISE_Passed_Authentications.*((Framed-IP-Address=10\.10\.130)|(Framed-IP-Address=10\.10\.30))|([A-Za-z0-9].*CISE_RADIUS_Accounting.*(Framed-IP-Address=10\.10\.140))) ユーザー名の正規表現: (?<=UserName=|User-Name=)[\w-]+ アドレスの正規表現: Framed-IP-Address=([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})  OKをクリックします。   Cisco ISE 2.1のsyslog 解析プロファイルは以下のようになります。 Event Regex ([A-Za-z0-9].*CISE_Passed_Authentications.*Framed-IP-Address=.*)|([A-Za-z0-9].*CISE_RADIUS_Accounting.*Framed-IP-Address=.*) Username Regex User-Name=([a-zA-Z0-9\@\-\\/\\\._]+)|UserName=([a- zA-Z0-9\@\-\\/\\\._]+) Address Regex Framed-IP-Address=([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1 ,3}\.[0-9]{1,3})   ISEサーバーをサーバー モニタリングに追加します。 Device > ユーザー ID > ユーザー マッピングを選択します。 サーバー モニタリングにて、追加をクリックします。 名前と内容は自由に入力します。 タイプでは、Syslog Senderを選択します。 ネットワーク アドレスにはCisco ISEのIPアドレスを入力します。 接続タイプはUDPを選択します。 フィルタにはCisco ISEを選択します。 デフォルト ドメイン名にはNetbiosドメイン名、もしくは、環境に即した情報を入力します。 OKをクリックして閉じ、Commitをクリックします。     準備ができました。PAN-OS装置はCisco ISEからUser-ID情報を受け取れているはずです。以下のコマンドで動作確認をすることができます。   show user server-monitor state  show user ip-user-mapping all type SYSLOG test user-id user-id-syslog-parse tail follow yes mp-log useridd.log   参考情報 Configuring Cisco ACS to send RADIUS Accounting directly to the firewall using Syslog Configuring ISE to Forward User Login Events to CDA   著者: Marcos ... View more

※この記事は以下の記事の日本語訳です。 Getting Started: Network Address Translation (NAT) https://live.paloaltonetworks.com/t5/Tutorials/Getting-Started-Network-Address-Translation-NAT/ta-p/116340   Getting Started seriesを参照しながら、ファイアウォール設定が完了した後、次にサーバー類の設定をしたいと思うかもしれません。全ての内部ホストを賄うほどの潤沢なパブリックIPを有していない限り、以下のネットワークアドレス変換(NAT)設定方法もしくはポートアドレス変換(PAT)設定詳細が内部ホストが外部へ、特定のアドレスを使ってインターネット接続する方法となります。   この設定仕様では、NATもしくはPATをあなたの要求要件を満たすのか、いくつかのシナリオを交えで解説します。     ポートアドレス変換, 送信元NAT   基本的にはポートアドレス変換が広範囲によく使われているアドレス変換手法です。内部サブネットを外部の1つのアドレスでカバー変換します。設定例は以下になります。 このNATポリシーは、全てのTrustゾーンからのセッションを変換し、Untrustゾーンへ送り出します。そして、送信元アドレスを、外部物理インターフェイスに設定されたアドレスに変換します。それらはランダムなソースポートを使用します。返ってくるパケットはファイアウォールでメインテナンスされているステートテーブルで、全てのアクティブセッション、NAT変換により自動的に逆変換されます。   ダイナミックNAT   ポートアドレス変換のバリエーションの一つで、送信元アドレスを追加して可用性を高めます。もしあなたのISPがパブリックアドレスとしてサブネット/29もしくはもっと多くのアドレスを提供した場合、かつあなたの内部ネットワークが広大な場合、NATプールのオーバーサブスクリプションoversubscription を防ぐのに役立つかもしれません。 アドレスタイプの設定で、インターフェイスから、変換アドレスに変更します。そして、有効なIPアドレスとして、IPレンジかIPサブネットを指定します。 ファイアウォールは送信元IPアドレスのハッシュテーブルを利用して、利用可能なプールからIPアドレスを選択します。この送信元アドレスは、この送信元アドレスからくる全てのセッションで利用されます。送信元ポートはランダムになります。   もし送信元ポートが変換前と同様である必要がある場合(いくつかのアプリケーションでは、特定の送信元ポートである必要があるかもしれません)、変換タイプをダイナミックIPに設定すれば、クライアントの送信元ポートをセッション毎に等変換します。変換アドレスは次の割り当て可能なアドレスが供給されます。 連続した32000個以上のIPアドレスはサポートされません。 変換されるアドレスプールは、内部ホストアドレスの数と同じ、もしくは多い必要があります。それぞれの内部ホストが変換後のアドレスを割り当てるためです。   上記の要件をたいていは満たしているが、時々満たさないケースがあるという場合、バックアップとして、ダイナミックNAT、ポートアドレス変換にフォールバック設定ができます。変換アドレス、インターフェイスアドレスオプションが可能です。デフォルトは未設定となっています。   1対1 NAT、静的NAT   もし、ローカルのSMTPサーバーやWebサーバーのようにインターネットからサーバーの存在を明確にする必要がある場合、1対1NATポリシーを特定のサーバー向けに設定する必要があります。いくつかの違った方法により実現する方法があります。   双方向ポリシー:   双方向ポリシーでは、上記で示したように通常の外部向け静的NATを作成し、双方向フラグを設定します。これによりシステムは（暗黙的に）インバウンドポリシーを作成することができます。   このポリシーでは、送信をtrustゾーン、宛先をUntrustゾーン、送信元アドレスを内部サーバー、送信元アドレス変換を外部NATアドレスに設定されています。送信をUntrustゾーン、宛先を全て、宛先IPアドレスを外部NATアドレス、そして宛先変換として、サーバーのアドレスとした暗黙のポリシーが作成されます。 この手法が、複数の1対1変換して、サーバーが各々単一のパブリックIPを所有している場合、有効に働きます。   片側方向のポリシー:   片側方向NATは双方向の場合よりも多少制御でき、PATやポートアドレス変換が可能です。PATは1個のパブリックIPを複数の内部サーバーでシェアできます。   次の3つのルールでは、3つの異なった内向きの静的NATサンプルです。 1番目のNATルールは従来の1対1ルールで、全ての内部サーバ向けポートを変換し、宛先ポートをメンテナンスします。 2番目のNATルールは内部向け通信で、宛先ポートが80番ポートを、内部サーバの8080番ポートに変換します。 3番目のNATルールは内部向けセッションで、2番目のルールと同じですが、宛先ポート25番だけは違う内部サーバーにリダイレクトされます。 注意事項:    なぜ宛先ゾーンがUntrustに設定され、宛先インターフェイスは何になりますか？ 'any'を内向けNAT（UntrustからUntrust）の宛先アドレスとして使用できますか？   セキュリティポリシーは、送信ゾーンをUntrustゾーン、宛先ゾーンを（最終的な宛先ゾーン）をtrustと設定すべきです。そして、宛先アドレスは、NAT変換前のパブリックアドレスと設定してください。     Source and Destination NAT   いくつかのケースにおいて、送信元、宛先NATを同時に実行する必要があるかもしれません。一つの例として、Uターンの場合で、内部ホストが、内部サーバーにアクセスする必要があり、クライアントと同じセグメントにいながら、パブリックアドレスを使用する場合です。 Uターンと詳細について、記事と、チュートリアルビデオがありますが、大まかな説明としては、   パブリックアドレスでインターナルリソースにアクセスするために、新たに、trustからUntrustへ変換するNATポリシーが必要になります。   もし、送信元変換がこのポリシーに含まれていない場合、サーバーはオリジナルのソースアドレスでパケットを受け取り、サーバーは直接クライアントにパケットを返信します。   これにより、非対称ループが作られ、TCPサニティチェックに違反され、ファイアウォールでセッションが終了されます。   解決方法としては、例として、ファイアウォールのIPに送信元変換のするルールを追加することです。そうすることによりサーバーの返信はファイアウォールに戻され、ステートフルセッションとして動作します。       追記: VwireにおけるNAT     NATはルーターでルーティングテーブルを編集することができれば（ISPのルーターでは許可されないかもしれませんが）VwireにもNAT設定が可能です。理想的には、Vwireの両端にルーターがあれば単純な設定にできますが、上位側のルーターだけでも、難易度は上がりますが、設定することができるでしょう。   2つのルーター間で、ポイントツーポイントのサブネット（例：10.10.10.0/30）を作成し、各々のルーターにIPを設定し、変換後IPアドレスのルートテーブルを、変換する側の対抗ルータのアドレスでポイントします（例：198.51.100.1をUntrustルーターに、trustルーターのIPでポイントします）。ファイアウォールは残りの部分を処理します。       注意事項   ゾーン解決はルートのルックアップで実施します。パケットがファイアウォールに到着した時、送信元と宛先サブネット、セッションに割当てられた適切なゾーンのルーティング・ルックアップ・チェックが実施されます。インターネットから内向けのトラフィックの場合、送信元ゾーンはUntrustとなり、デフォルトルート（0.0.0/0）はUntrustインターフェイスをポイントします。そして、宛先IPアドレスは、NAT変換前となり、Untrustインターフェイス所属となります（上記例では198.51.100.0/24）。   NATポリシーで宛先インターフェイスを使用すると、類似NATポリシーを使用した場合、競合が発生することを防ぐ助けになります。例えば、もし2つの外部インターフェースが存在して、2つのISP接続があり、違うパブリックアドレスを使用している場合、2つの同様の外向けNATルールが設定できます。   NAT IPの場合、インターフェースに物理的に設定されていないアドレスを使用します（例、インターフェースは51.100.1で、サーバーに使用するNATでは198.51.100.5を使用）。ファイアウォールはGARPを対向機器に送付して通知し、上位機器に対して、ARPリクエストの応答をします。GARPは以下のコマンドで手動で実施することもできます。 admin@MyFW> test arp gratuitous interface ethernet1/1 ip 198.51.100.6 1 ARPs were sent 注意事項: もしNATルールで、変換するサブネットがインターフェイスに設定されていない場合、ファイアウォールは全てのIPアドレスのサブネットに対してGARPを送付します。   ファイアウォールは宛先NAT（内向き）にリストされている宛先アドレスのProxy ARP解決を提供するので、宛先アドレスは、宛先変換サブネットに一致する必要があります。宛先アドレスに'any'を使用することはできません。   内部クライアントが、DMZもしくは信頼できるネットワークにパブリックアドレスを介して接続するNATポリシーを作る場合は、どのような場合でも上記の1ポートアドレス変換NATポリシーを参考にご使用ください。   オーバーサブスクリプション   オーバーサブスクリプションはファイアウォールが作成されるセッションの量に対するパブリックIPアドレスが少なすぎる場合に、同じIPアドレスとポートのペアに変換した現行のセッションを共有し、スケーラビリティを提供します。例えば、通常、最大の現行セッションは、64,000（65,000ソースポート - 1,024サーバーポート）ですが、プラットフォームによっては、8倍の512,000セッションまでオーバーサブスクリプションすることができます。   以下のKBをご参照ください: How to Change the NAT Oversubscription Rate How to Check the Oversubscription on a NAT Rule   著者: Reaper ... View more

※この記事は以下の記事の日本語訳です。 Controlling Skype using App-ID https://live.paloaltonetworks.com/t5/Learning-Articles/Controlling-Skype-using-App-ID/ta-p/149689   Skypeとは?     Skype （スカイプ）はよく知られているインターネット電話サービスで、 Niklas Zennstrm と Janus Friis によって開発されました。ピア・ツー・ピアのファイル共有ソフト Kazaa と新しいピア・ツー・ピアのテレビ アプリケーション Joost の創業者でもあります。 Skype は、従来の POTS から VoIP サービスまで、既存の電話サービスと競い合います。強みとしては、ファイアウォールや NAT 変換を介して接続性を提供でき、多くのアクティブ ユーザーをサポートし、強力な暗号化技術によりプライバシーを保護しています。さらに、インスタント メッセージ、チャット、ファイル転送、ビデオ会議、グローバル ディレクトリーなどをサポートしています。   スカイプの基礎となる技術は、分散型 ピア・ツー・ピア  アーキテクチャを利用して、マルチメディア パケットを中央サーバ型ではなくユーザ間でやりとりします。 ピア・ツー・ピア  ネットワークは接続性とスケーラビリティを向上させると同時に、ファイアウォール トラバーサルや、ダイナミック ルーティングによって、会社に設置されたファイアウォールを回避します。独自のプロトコルに基づくクローズド ソース アプリケーションであるにもかかわらず、Skype の独自でかつ回避的な動作は、特に、可視性や制御なしにファイルや情報を転送する能力を備えているため、エンタープライズ ネットワークにとってセキュリティ上の課題となっています。詳しくは以下の URL をご参照ください。 - https://www.skype.com/en/about/   Skypeをネットワーク上で許可するには、以下のApp-IDをパロアルトネットワークス・ファイアウォールで許可する必要があります。   office365-consumer-access rtcp rtp skype skype-probe ssl websocket stun web-browsing windows-azure-base apple-push-notifications   Policies > Security にて以下のスクリーンショットの例にあるように、Skypeを許可するためのセキュリティ ポリシーを追加します。     Skype For Business:   最小設定では、以下のApp-IDを、Skype For Businessが正しく動作するために許可する必要があります。   Ms-lync-base (matches the core functionality of the application) ms-lync-online rtcp stun (for media negotiation) rtp (for media streaming) ms-office365-base (core functionality of O365 applications) ssl web-browsing ms-lync-audio/video   クライアント端末では、固定の証明書を使用しており、 Skype For Business でも、「 *.online.lync.com 」や「 *.infra.lync.com 」を例外リストに追記し（ Device > Certificate Management の SSL 復号化例外より）、復号化の除外すべきです。     著者: vsathiamoo  ... View more

※この記事は以下の記事の日本語訳です。 Understanding HTTP Evasion Detection Signatures https://live.paloaltonetworks.com/t5/Threat-Vulnerability-Articles/Understanding-HTTP-Evasion-Detection-Signatures/ta-p/79218   セキュリティ アプライアンスによる検出を回避するためにネットワーク上で活用される方法の1つとして、受信側のユーザーエージェントがデータを解釈できるようにしたうえで、トラフィックを検査するアプライアンスがデータを解釈できないようにHTTP通信を難読化し隠蔽する手法があります。これは一般に「回避」戦術と呼ばれます。   異なるHTTPクライアントの実装はそれぞれで動作が異なり、また多くの場合、標準規格（RFC）に準拠しておらず、独自の実装を使用するデコーダやスキャニング エンジンをバイパスするために利用されます。 PAN-OSはこれを次の2つの方法で処理します。まず、デコーダがトラフィックをhttpとしてデコードできない場合、アプリケーションは「unknown-tcp」に設定されます。または他のアプリケーションとして認識される場合もありえます。 さらに、HTTP回避に対応するために、以下のような脆弱性シグネチャを使用して保護します。 • Suspicious Abnormal HTTP Response Found (38304, 38358, 38307, 38476, 38305, 38310, 38841, 38742, 38302, 38870, 38767, 38840, 39041, 38824, 38920, 38303, 38839, 38741) • HTTP Non RFC-Compliant Response Found (32880) • Suspicious HTTP Evasion Found (39004, 39022, 38306, 38919, 38635) • HTTP Request Pipeline Evasion Found (36767) • HTTP Request Line Separator Evasion (36398, 36422) • HTTP response data URI scheme evasion attempt (33127) • HTTP various charset encoding html response evasion (33125) • HTTP utf-7 charset encoding html response evasion (33126)   標準準拠していないサーバーやWebアプリケーションは、不正な形ではあるが悪意のない応答をするときがあり、これに対応するために、脆弱性プロファイルの例外処理を利用して、細かく調整することができます。デコーダが標準コンプライアンスをシステム全体に対して実施していたら、これは可能ではなかったかもしれません。 セキュリティ全体として、ネットワーク管理者は、悪意のあるコンテンツが許可されるリスクと、正当なコンテンツが拒否される可能性のバランスを保つ必要があり、かつセキュリティ ベンダーは広まっている回避テクニックに対してシグネチャを提供する必要があります。   パロアルトネットワークスの脅威研究チームは、これらの脅威を常に監視しております。また、 大切なお客様から得られた貴重な詳細情報を元に、未対応の回避手法に対応しています。   著者: rcole ... View more

※この記事は以下の記事の日本語訳です。   TCP MSS adjustment for IPSec traffic https://live.paloaltonetworks.com/t5/Learning-Articles/TCP-MSS-adjustment-for-IPSec-traffic/ta-p/74988   IPSec 通信において、パロアルトネットワークス・ファイアウォールは 3ウェイ ハンドシェイクを介して TCP MSSを 自動 調整します。これは、 VPNの外部インターフェース設定で、 TCP MSS 調整機能オプションを有効に設定しているのとは関係なく動作するものです。   MSS 計算結果は以下の 2つの値の小さい方を使用します。   トンネル・ インターフェースの MTU - 40 bytes インターフェイス MTU、 暗号化、 認証アルゴリズムをベースに計算した MSS値   オリジナル パケット サイズ、暗号化アルゴリズム、認証アルゴリズム、インターフェイスの MTUとの関連性   以下の構成について考えてみます :   クライアント  ——— パロアルト ——— インターネット  ——— 対向ファイアウォール ——— サーバー                               　　　\____ __ __ __ ______(IPSec) __ __ __ __________/   クライアント MTU : 1500 サーバー MTU: 1500 終端 VPN 装置インターフェイスの MTU : 1500 トンネル・インターフェースの MTU : 1500 暗号化アルゴリズム : AES-256-CBC 認証アルゴリズム : SHA1   ESP オーバーヘッド : ( 全ては bytes 表示 )   Outer IP Header 20 Sequence Number 4 SPI 4 Initialisation Vector 16 ESP Padding [0-15] Padding Length 1 Next Header 1 Authentication Data 12     Total [58-73]   暗号化アルゴリズム ( AES-256) と 認証アルゴリズム ( SHA1) は最大 73 bytes のオーバーヘッドを生成します。   オリジナル パケット サイズ + 最大オーバーヘッド  <= 1500 TCP セグメント + TCP ヘッダー + IP ヘッダー + 最大オーバーヘッド  <= 1500 TCP セグメント + 20 bytes + 20 bytes +  73 bytes <= 1500 TCP セグメント <= 1387 bytes   もし MSS が 1388 bytes 使用する場合、 ESP ヘッダーは 1496 bytes となります。 (パディングは10 bytes のみです )     上記から、   トンネル・ インターフェース MTU からの MSS 計算結果 = 1500 - 20 Bytes (IP ヘッダー ) - 20 bytes (TCP ヘッダー ) = 1460 Bytes インターフェイス MTU, 暗号化 , 認証アルゴリズムによる MSS 計算結果 = 1388 Bytes   最終的な MSS 計算結果 : 小さい方 (1460, 1388) = 1388.   同様の計算手法は、様々な暗号化/ 認証アルゴリズム の組み合わせに対して使うことができます。いくつかのよく使われる値は :   初期ベクターのサイズ AES : 16 bytes DES : 8 bytes   認証データのサイズ MD5/ SHA-1 :  12 bytes SHA-256 : 16 bytes SHA-384 : 24 bytes SHA-512 : 32 bytes   パディングされる最大値 AES : 15 bytes DES : 7 bytes   注意 :   上記の値は、 PAN-OS 6.0 以降のバージョンで試験されたものです。 上記の例にて、もしインターフェイスの MTU が 1400 に設定されていた場合、 MSS の結果は 1388 でなく、 1360 になるでしょう。   上記の計算様式は、IPSecトンネルのMSS調整の計算にも使われます。もしファイアウォールがESPオーバーヘッドを考慮して自動調整をしなければ、 TCP調整のために 適切なMTUの値をトンネル・インターフェースに設定します。   例えば、上記の例で、ファイアウォールが ESP オーバーヘッドを考慮してMSS値を調整しないのであれば、トンネル・インターフェースの MTUに 1387 + 40 = 1427 bytes を 設定することもできます。これは結果的に MSS 値が、 1387 bytes に調整されるのと同じになります。   これらは、IPSecト ン ネル上で動作する、TCPアプリケーションのパフォーマンスを向上させます。   著者: abjain ... View more

※この記事は以下の記事の日本語訳です。 Firewall Showing as Disconnected on the Panorama https://live.paloaltonetworks.com/t5/Management-Articles/Device-Showing-as-Disconnected-on-the-Panorama/ta-p/76666   現象 パロアルトネットワークス・ファイアウォールをPanoramaで中央管理している際に、新しく追加したファイアウォールが管理画面（Panorama > Managed devices）で、Disconnectedと表示される。     診断 ## 1つのよくある事例として、セキュリティ ポリシー上で、ファイアウォールとPanorama間で通信するTCPポート、アプリケーションが不許可設定になっている可能性があります。 もしくは ## ファイアウォール、Panorama間で通信するTCPポートが中継装置でブロックされている可能性があります。   解決方法 ほとんどのケースでは、ファイアウォールの管理インターフェイスとPanorama間でSSLトンネルが作られます。 ファイアウォールは、ファイアウォールとPanorama間の通信でTCPポート番号3978を宛先として使用します。 もしセキュリティ ポリシーでTCPポート番号3978 / アプリケーションPanoramaを明示的に許可していない場合、対象機器はPanorama上で接続 (Connected) ステータスとして表示されず、トラフィックは最終的なポリシーによって拒否されます。 トラフィック ログを、 送信元を 管理インターフェースのIPアドレスで、宛先をPanoramaのIPアドレスでフィルター設定してみてください。もし、Panoramaセッション用にサービスルート設定を使用している場合は、適切なデータープレーン・インターフェースのIPアドレスを用いてください。 もし、セキュリティ ポリシーでアクションが拒否表示されていた場合、既存のセキュリティ ポリシーを、前述したように適切に変更してください。該当のファイアウォールがPanoramaで接続 (Connected) ステータスになるか確認してください。           セキュリティ ポリシー変更後、トラフィック ログ上で許可されています。     注意事項 -- もしファイアウォールの管理インターフェースとPanoramaにパブリックIPアドレスを使用していて、かつセッションが、マネージメント プレーンで管理されている場合（もしそのパケットがファイアウォールのデータポートを経由していない場合）、管理インターフェースで  TCP dump をとり 、宛先TCPポート3978でフィルター設定して、宛先に到達しているか確認してみてください（中継装置によって、通信に必要なポートがブロックされているかもしれません）。    著者: Tarang ... View more

※この記事は以下の記事の日本語訳です。 Mitigate Vulnerabilities Through Proper Application of Threat Prevention https://live.paloaltonetworks.com/t5/Management-Articles/Mitigate-Vulnerabilities-Through-Proper-Application-of-Threat/ta-p/194158   問題 脆弱性漏洩を防御、検知を行うために、PAN-OS装置を適切に設定する必要があります。 パロアルト ネットワークスは、PAN-OS装置を含む全ての脆弱な装置に対して、セキュリティ勧告に明記されている修正パッチ適用を推奨アクションとしていますが、緊急コンテンツ リリースに含まれるシグネチャはPAN-OSを保護するのに役立ちます。   解決方法 解決方法は細かなステップを踏む必要があります。 最新のコンテントをインストール 脆弱性プロファイルで、シグネチャパターンマッチに適切なアクション（例 : Reset-both）を設定 設定した脆弱性プロファイルをセキュリティポリシーに設定 内向きSSL復号化設定   詳細 最新のコンテントをインストール コンテントを最新のバージョンに更新してください。 脆弱性プロファイルの設定 このセクションでは、セキュリティ勧告に関連した脅威IDの検知を防御する脆弱防御プロファイル設定をする方法について大まかに説明します。 2つの設定方法があります。 この設定例では、脆弱防御プロファイル"strict"設定に重要度の高いシグネチャ（脅威ID : 38902, 38903, 38904）の検知に対して、RESET-BOTHアクション設定をしています。このようなプロファイルはファイアウォール向けの内向きの通信に合致するセキュリティルールに適応できます。 この3つのシグネチャをRESET-BOTHに設定したカスタム脆弱防御プロファイルです。設定の詳細についてはリンクを参照ください。   脆弱防御プロファイルをセキュリティルールに設定する このセクションでは以前設定した脆弱防御プロファイルをグローバル・プロテクト、データポート経由したマネージメント向け通信にマッチするセキュリティルールに設定します。 この作業では、グローバル・プロテクトが"Untrust"ゾーンのインターフェースでホストされていて、VPNトラフィックも"Untrust"ゾーンから送信されていると推測します。   データポート経由したグローバル・プロテクト、もしくは他のサービスに対する脆弱行為から保護するために、脆弱防御プロファイルを"Untrust"ゾーンから"Untrust"ゾーン通信検査をするセキュリティルールに設定する必要があります。 上記のスクリーンショットでは、プロファイル欄のアイコンは、前のステップで示したように脆弱防御プロファイル"strict"になっています。送信元、宛先ゾーン共に"Untrust"ゾーン設定となっています。 以下のステップではデータポート経由でのデバイス管理をする場合に必要なステップです。 内向きSSL復号化設定 内向きSSL復号化設定については以下のKBをご参照ください。 Configure SSL Inbound Inspection  How to Implement and Test SSL Decryption ... View more

※この記事は以下の記事の日本語訳です。 How to Secure the Management Access of your Palo Alto Networks Device https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Secure-the-Management-Access-of-your-Palo-Alto-Networks/ta-p/194154   問題 管理インターフェイス、ネットワークを悪意から防御するために保護することはとても重要です。管理者がリモート管理するためにデータプレーンにて管理プロファイルを適応いただくかどうかに関わらず、我々はいかなる装置の管理インターフェイスをインターネットに公開しないことを、強く推奨しています。しかしながら、インターネットに公開する必要がある場合、以下のガイドラインに沿って、あなたの管理インターフェイス、ネットワークを保護してください。   解決方法 いくつかの動作環境では管理ネットワークがインターネットに接続する必要性は理解しています。キーポイントとしては、攻撃者に対して攻撃が難しいターゲットと認識させること、そしてファイアウォール／Panoramaを保護することです。以下の知見はあなたの管理インターフェイスを公開することを留めることができるでしょう。 管理インターフェイス専用ネットワーク（管理専用VLAN ）で VPN を経由して接続する。 管理ネットワークIP にアクセスするために、サーバーを経由する、リモートデスクトップ接続を経由してのみファイアウォール／ Panorama に接続できる。 管理インターフェイスへの特定IP アドレスのみの接続許可、接続するプロトコルも SSH/HTTPS に限定する。 管理インターフェイスへのアクセスをファイアウォールのデータポート経由にして、ファイアウォールの検査を行う。   詳細   管理インターフェース専用ネットワーク(VLAN) この手法が提示している4つの中で最もセキュアです。VPNを経由して、企業、管理ネットワークに接続し、管理IPに接続しなければなりません。この手法は、外部公開を限定し、ファイアウォール管理ネットワークへのアクセスを、特定ユーザーもしくはネットワークに限定することができます。これはVPN接続による管理専用ネットワークへのアクセスを要求します。管理ネットワークへのアクセスをデータ ポート経由にし、パロアルト ネットワークス・ファイアウォールからVPNアクセスを提供させることもできます。以下のKBは、サイトtoサイトのVPNトネルの設定資料となります。併せてご参照ください。 Set Up an IPsec tunnel サーバーを経由する サーバーを経由することによって、装置の管理インターフェイス アクセスを保護することができます。管理ポートへのアクセスはサーバーを経由してのみアクセスできます。 管理インターフェイスへの特定IPアドレスのみの接続許可 管理インターフェイスへの特定IPアドレス、サービスのみの接続許可を設定することができます。 WebUI管理インターフェイス上で、Device > Setup > Interfaces > Managementと移動し、”Management”をクリックして編集してください。Addをクリックして、管理者がファイアウォールにアクセスできるIPアドレスを“Permitted IP addresses”に追加していきます。“Permitted IP addresses”が空白（デフォルト）の場合、全てのIPアドレスからアクセス可能となります。   重要！ 空白設定のままにしないでください、ファイアウォール管理者IPアドレスのみ設定し、非承認アクセスを防御してください “Network Connectivity Services”設定では、HTTPS、SSHなど、セキュアな接続のみ設定します。 管理ネットワーク接続は、データポート経由 これは最初に紹介した手法のVPN接続がない場合に似ています。VPN接続設定ができない場合、少なくともファイアウォール検査を全てのマネージメント・インターフェース向けのトラフィックに実施します。マネージメントアクセスを制限するセキュリティポリシーを作り、攻撃者が管理ネットワークから侵入することを防ぐセキュリティプロファイルを追記します。さらにSSL復号化設定をし、暗号化通信を検査します。セキュリティプロファイルによるネットワーク保護については、以下の記事をご参照ください。  Create Best Practice Security Profiles   追加情報 以下は、SSL 復号化設定、テストに関する記事です。併せてご参照ください。 Configure SSL Inbound Inspection How to Implement and Test SSL Decryption ... View more

※この特別勧告はパロアルトネットワークス・PSIRT(Product Security Incident Response Team ：製品のセキュリティや脆弱性対応を行う専門チーム)より報告された「Urgent action recommended regarding recent security advisory PAN-SA-2017-0027」を、日本のユーザー様向けに和訳したものとなります。当勧告と合わせてPSIRTの原文もご確認いただきますようお願い申し上げます。 https://live.paloaltonetworks.com/t5/Community-Blog/Urgent-action-recommended-regarding-recent-security-advisory-PAN/ba-p/194220   パロアルトネットワークスのお客様へ   2017年12月5日、パロアルト ネットワークス・PSIRTはセキュリティ勧告PAN-SA-2017-0027を公開すると共に、PAN-OS 6.1.18とそれ以前にリリースされたバージョン、PAN-OS 7.0.18とそれ以前にリリースされたバージョン、およびPAN-OS 7.1.13とそれ以前にリリースされたバージョンが緊急性の高い脆弱性(CVE-2017-15944)の影響を受けることの情報公開を行い、推奨されるベストプラクティスを提案すると共に、修正版メンテナンスバージョンをリリースしています。   この勧告の公表以降、 Web 管理インターフェイスをインターネットに公開しており、かつ、修正版メンテナンスバージョンをご適用頂いていない極一部の環境において、この脆弱性(CVE-2017-15944)を突いた悪意のある行動が確認されておりますことをここに報告申し上げますと共に、弊社製品 (PA シリーズ、 Panorama) をご利用のお客様におかれましては、この特別勧告に沿ったご対応を改めてご確認の上、実施頂くことを推奨致します。     緊急対処が推奨される場合： 修正パッチを含むPAN-OS へのアップグレードが完了していない環境 PAN-OSにおいて、Web管理インターフェイスがパブリックIPをSourceとするアクセスを許可している(インターネット側から直接接続できる状態)環境 修正版メンテナンスリリースが未適用、かつWeb管理インターフェイスがインターネットから直接接続可能な状態の場合、リスクは極めて高くなりますので早急に対処する必要があります。   恒久的対応策、および運用回避策 修正版メンテナンスリリースのPAN-OS にアップグレード 管理インターフェイスへアクセス可能なアドレスを限定するためのベストプラクティスの適用   2017年12月5日に発行した初期の勧告にて、この脆弱性の対応は、PAN-OS 6.1.19とそれ以降にリリースされたバージョン、PAN-OS 7.0.19とそれ以降にリリースされたバージョン、およびPAN-OS 7.1.14とそれ以降にリリースされたバージョンにて完了している旨をご案内しております。従いまして、可能な限り速やかに修正版メンテナンスリリースを適用することを強く推奨致しております。 修正版メンテナンスリリースの適用が困難であり、Web管理インターフェイスがインターネットから直接接続可能な状態の場合は管理インターフェイスを防御するためのベストプラクティスを実施して頂くよう推奨致します。   注意: もしWeb管理インターフェイスを意図してインターネットに公開してない場合、例えばグローバルプロテクトのポータルもしくはゲートウェイのインターネット向けインターフェイスに誤って、HTTP もしくは HTTPS のマネージメントプロファイルを適応していただいているケースがございます。これについての詳細は、 Best Practices for Securing Administrative Access（英語版の管理者ガイド、2018/1/17時点で日本語管理者ガイドには翻訳されていません）をご参照いただくか、ご質問があればパロアルト ネットワークス・サポートチーム(https://support.paloaltonetworks.com)にケースオープン頂くようお願いします。   弊社が提案するベストプラクティスとしては、すべてのお客様において、Web管理インターフェイスをインターネットに公開(インターネット側から直接接続できる状態）する運用を回避するよう強く推奨しております。 特に修正版メンテナンスリリースを適用していない環境においては、脆弱性に伴うリスクが加算されます。弊社が提案するベストプラクティスは以下の要点についての対応を推奨致しております。   Web管理インターフェイスへの接続を制限するため、管理ネットワーク専用のVLAN、管理インターフェイスへの特定IPアドレス、もしくはその両方からのみ接続を許可する。 インターネットを介したWeb管理インターフェイス接続が必要な場合は、セキュアなVPN接続を構成する。 インターネットに直接接続可能な管理インターフェイスを設置する場合、管理インターフェイス向けトラフックに対して、SSL復号化と、脅威防御を適用頂く。［セキュリティ勧告PAN-SA-2017-0027を公開した際に、CVE-2017-15944脆弱性攻撃を防御する IPSシグネチャ（40483と40484番）をリリースしています。これらのシグネチャ設定を”Block”に設定して、攻撃を防御するよう設定して下さい。]   詳細については以下のKB もご参照ください。 PAN-OSアップグレードのベスト プラクティス パロアルト ネットワークス装置の管理アクセスを保護する方法 適切な脅威防御適用による脆弱性緩和   本件についてご不明点な点やご質問がある場合は、パロアルト ネットワークス・サポートチーム(https://support.paloaltonetworks.com)にケースオープン頂き、ケースの件名に “CVE-2017-15944”を追記して頂けますようお願いします。   敬具 パロアルトネットワークス・PSIRT    ---------------------------------------------------------------------------------------------------------------------------------------------   よくある質問   質問1 : 何の問題ですか？   2017 年 12 月上旬に修正パッチを既に提供させていただいているこの脆弱性 (CVE-2017-15944 / PAN-SA-2017-0027) は攻撃者が修正パッチをあててないファイアウォール、かつ保護策を設定していない管理インターフェイスに対してコードをリモート実行することができます。   この脆弱性はWeb 管理インターフェイスをインターネットに公開しているお客様が対象です。修正パッチをあててない、かつ Web 管理インターフェイスを公開しているお客様はシステム侵害を受ける可能性があります。さらにいくつかの事例で、グローバルプロテクトの誤った設定によって、意図せず Web 管理インターフェイスを公開しているケースが報告されています。以下の KB 記事は推奨設定のガイダンスを提供します。   How to Configure GlobalProtect How to Secure the Management Access of your Palo Alto Networks Device     質問2 : この脆弱性のリファレンスは何ですか？   PAN-SA-2017-0027 はパロアルトネットワークス・PSIRT(Product Security Incident Response Team ：製品のセキュリティや脆弱性対応を行う専門チーム ) より報告されたセキュリティ勧告です。 (https://securityadvisories.paloaltonetworks.com/に掲示されています)  CVE-2017-15944 は実際の脆弱性に対するCVE (Common Vulnerabilities and Exposures)です。このシステムは独自に脆弱性を調査するセキュリティ・コミュニティです。 このセキュリティ勧告 PAN-SA-2017-0027 は脆弱性CVE-2017-15944情報を提供するとともに、提供させていただいている修正パッチにて脆弱性を修正する方法についても明記されています。     質問3 : どのパロアルトネットワークス製品が影響を受けますか？   パロアルトネットワークス・ファイアウォールで最新のPAN-OS でない場合、もしくは、 Web 管理インターフェイスをインターネットに公開している場合にリスクが生じます。最新の PAN-OS にアップグレードしてない場合でも、以下のベストプラクティスにて Web 管理インターフェイスを保護している場合、この脆弱性から十分に保護することができます。パロアルトネットワークス・セキュリティ勧告にて影響のあるプロダクト一覧が参照できます。 https://securityadvisories.paloaltonetworks.com/Home/Detail/102     質問4 : Web管理インターフェイスのベストプラクティスは？   Web管理インターフェイスを保護するベストプラクティスは以下のリンクをご参照ください。 パロアルト ネットワークス装置の管理アクセスを保護する方法     質問5 : もしWeb管理インターフェイス公開を避けられない場合、どうすればいいですか？   意思決定はファイアウォールの管理者に委ねられます。パロアルト ネットワークス装置の管理アクセスを保護する方法をご参照ください。     質問6 : 修正パッチを含む最新バージョンにアップグレードすることによって引き起こされる別の問題はありますか？   最新バージョンへのアップグレートはベストプラクティスで推奨しています。しかしながら一部のお客様ではすぐに実施することが難しい場合がございます。Panorama や他のオートメーションツールをご使用いただくことで、大規模、複雑な環境下でのアップグレードを簡素化し、実行することを支援することができます。   さらに、 最新バージョンへアップグレートすることによって、ファイアウォールと他の機器との関連性や、設定ポリシーに影響を及ぼす変更がなされる可能性があります。そのようなケースの場合、常に最新バージョンのPAN-OS にして、想定される影響を最小限にする必要があります。PAN-OSの変更、アップグレードにより影響を受ける可能性を最小化するために、全ての PAN-OS リリースノート（ https://support.paloaltonetworks.com > TOOLS > Software Updates ）を ご参照いただけます。       質問7 : Panorama 管理サーバも最新バージョンに上げる必要がありますか？   Panorama 管理サーバも攻撃者のリスクを最小化するためにアップグレードしていただくことを推奨します。アップグレートしようとしている PAN-OSバージョン によっては、 Panorama 管理サーバもアップグレートする必要があります。一般的なガイダンスとして、 Panorama 管理サーバのバージョンは、管理しているファイアウォールの中で利用している最も新しい PAN-OS バージョンに合わせる必要があります。       質問8 : User ID のために、ファイアウォールを syslog serverとして指定している場合に、Web 管理インターフェイスをアクセスリストにて制限した場合、 syslog 情報を送ってくるサーバも含める必要がありますか？   はい、User IDのために情報を送ってくるサーバ群のIP アドレスを全て含める必要があります。加えて全てのファイアウォール管理者、 Panorama 管理サーバ、 SNMP モニター用のサーバの IP アドレスを加えたほうがいいでしょう。管理用セグメントがある場合、そのネットワークセグメント（例 : 192.168.1.0/24を許可）を追加することもできます。しかしながら、セキュリティ・リスクをできるだけ軽減したい場合、特定アドレスを追加したほうがいいでしょう。ただし、多くのネットワーク管理ではDHCPを使用しているので、許可した特定アドレスがタイミングによっては変わっている可能性があるので注意してください。   ... View more

※この記事は以下の記事の日本語訳です。 What is the Default Login Credential? https://live.paloaltonetworks.com/t5/Management-Articles/What-is-the-Default-Login-Credential/ta-p/56871   初期設定（ファクトリーデフォルト直後）のPalo Alto Networks装置のログインユーザーIDとパスワードは（WebGUI、CLI共通）:   Username:  admin Password:   admin   著者: jnguyen ... View more

※この記事は以下の記事の日本語訳です。 DNP3 New App-ID Release https://live.paloaltonetworks.com/t5/Management-Articles/DNP3-New-App-ID-Release/ta-p/166893   背景： DNP3 (Distributed Network Protocol)は、SCADA（Supervisory Control and Data Acquisition）システムのコンポーネント間で使用されるコミュニケーション プロトコル セットです。電力および水道施設でよく使用されます。このプロトコルは様々な種類のデータ取得、機器のコントロールなどのコミュニケーション用に開発されたものです。SCADAシステムは、DNP3を使用して、マスタステーション、リモート端末（RTU）、Intelligent Electronic Device（IED）の間の通信を行います。   現在Palo Alto Networks社では5種類のアプリケーションIDがあり、全てのDNP3機能コードに拡張する計画があり、32種類のアプリケーションIDになります。SCADAやICSシステムで使われる重要なプロトコルのため、我々はこれらの変更を、お客様が既存のDNP3アプリケーションIDをご使用している既存環境に影響を及ぼすことなく、スムーズに変更を吸収できるようにご紹介します。   リリース計画: 2017年8月21日の週に、Palo Alto Networks社は、27種のアプリケーションIDをDNP3機能コードに追加します。2017年8月に追加されるアプリケーションID一覧は以下です。   dnp3-confirm dnp3-select dnp3-direct-operate-no-resp dnp3-freeze dnp3-freeze-no-resp dnp3-clear dnp3-clear-no-resp dnp3-freeze-at-time dnp3-freeze-at-time-no-resp dnp3-cold-restart dnp3-warm-restart dnp3-initialize-data dnp3-initialize-application dnp3-start-application dnp3-stop-application dnp3-save-configuration dnp3-enable-unsolicited dnp3-disable-unsolicited dnp3-assign-class dnp3-delay-measurement dnp3-record-current-time dnp3-open-file dnp3-close-file dnp3-delete-file dnp3-get-file-information dnp3-authenticate-file dnp3-abort-file   これらの27個のアプリケーションIDリリースには2フェーズでリリースします。    2017年7月 DNP3仮設定のアプリケーションIDがリリースされます。リリース時期は7月17日の週 2017年8月 27個のDNP3アプリケーションIDが有効になります。リリース時期は8月21日の週   仮設定のアプリケーションID はお客のファイアウォールに事前設定を施すことができます。この仮設定はアプリケーションIDをセキュリティポリシーに追加する計画を支援するために十分な時間を提供できます。    よくある質問   質問: なぜパロアルトネットワークス社はこの変更を実施したのですか？ 回答:  SCADA や ICS の多くのお客様でと意見交換した結果、  DNP3 アプリケーション ID にて、脅威に関する進歩が日々増している背景があります。そのことを認識したうえで、 SCADA エリアにおいて、継続的なアプリケーション視覚化を提供する必要性が増したので、 DNP3 に関連した 27 個のアプリケーション ID をリリースすることを決定しました。   質問: どのポリシー変更が必要ですか？ 回答:  もしアプリケーションIDベースのポリシーをご利用いただいて、dnp3-base にて、DNP3関連アプリケーショントラフィックを許可している場合、このポリシーに”追加”にて、DNP3に関連した27個のアプリケーションIDから加える必要があります。”追加”と書かさせていただいたことに注意してください。既存のdnp3-baseを削除せずに、既存のポリシーにDNP3機能のアプリケーションIDを追加することを推奨します。   幾分簡素化された、細かくないアプローチでは DNP3 に関連したアプリケーション ID を許可することにより、全ての DNP3 アプリケーション ID を単純に許可します。     しかしながら、もっと細かなアプローチとして、お客様はDNP3 のどのようなタイプのトラフィックやそれらの特定の DNP3 機能コードのアプリケーション ID のみを許可する評価を実施していただくこと推奨します。以下のセキュリティポリシーはサンプル例です。全てのお客様の設定は異なるべきです。お客様のネットワークに存在する DNP3 フローに関するナレッジ、ご自身の判断により、正しいポリシーを構築してみてください。     質問: DNP3に関連するポートベースのポリシーを使っている場合どうなりますか？ 回答:   もしポートベースのポリシーを使って、正常に DNP3 トラフックを許可している場合、この変更の影響を受けることはありません。しかしながら DNP3 に関連するトラフィックを許可するために、 DNP3 アプリケーション ID をご使用いただくことを推奨します。   質問: もしセキュリティポリシー上のdnp3-baseが、1 つ、もしくは複数の DNP3 機能のアプリケーション ID で網羅できてない場合はどうなりますか？ 回答:   8月21日の週に、全ての DNP3 に関連した 27 個のアプリケーション ID が有効化されます。 dnp3-baseと認識されていたアプリケーションID がもし新しいシグネチャーにマッチした場合、 27 個のアプリケーション ID のいずれかに識別されます。もし既存の dnp3-baseを明示的に許可していたポリシーで、27 個の アプリケーション ID にマッチングした場合、そのトラフィックが落とされる可能性があります。   ... View more

※この記事は以下の記事の日本語訳です。 How to Troubleshoot High Dataplane CPU https://live.paloaltonetworks.com/t5/Featured-Articles/How-to-Troubleshoot-High-Dataplane-CPU/ta-p/73000   データプレーン CPU 負荷が高騰、高い状況が継続、負荷が徐々に増える要因として、新しいサービス、リソース、追加ネットワーク セグメント、ホスト接続の追加など様々な要素があります。これらの要素に加えて、パケットレート、パケットバッファー使用率、毎秒当たりの新規セッションの接続率の高騰により、データプレーン CPU がクリティカル レベルに到達してしまいます。   データプレーン CPU の高負荷トラブルシューティングを学ぶために、この文章では、データプレーン CPU の実際の負荷状況を確認して、ネットワークに何らかの影響を及ぼす可能性について判断する手助けを示します。   データプレーン CPU の高負荷を理解することはとても重要です。データプレーン CPU の高使用率は即時の関心事ではないかもしれませんが、何が起因して CPU が高くなっているのか、可能性について理解しておくことは正しい対応をするために手助けとなるでしょう。   対処する前に特定化が必要な、いくつかの要因があります。 一部の、全体のもしくはファイアウォールを通過しない通信が影響しているか ユーザーは遅延を体感できているか、もしそうであれば、その遅延は全体の通信か特定のアプリケーションのみか 問題が報告されたとき、それらの報告は特定の時間帯か、定期な間隔、それとも完全にランダムに発生しているか   データプレーン高CPU負荷を識別する方法   show running resource-monitor コマンドはデータプレーン CPU の使用率をレビューするのに使われます。時間オプションを追加することによって、レビューしたい時間帯を反映させます。   'second'は直近60秒の1秒当たりのCPU使用率を表示します。 'minute'は直近60分の1分当たりのCPU使用率を表示します。 時間オプションを指定しなければ、秒単位、分単位を一度に表示します。   > show running resource-monitor > day Per-day monitoring statistics > hour Per-hour monitoring statistics > ingress-backlogs show statistics > minute Per-minute monitoring statistics > second Per-second monitoring statistics > week Per-week monitoring statistics   実際の表示はこれと似ていますが、ご使用になられているシステムのデータプレーンとコアの数によって若干表示が異なります。     > show running resource-monitor DP dp0: Resource monitoring sampling data (per second): 最初のパートは、データプレーン上で動作しているプロセスが利用するCPU 負荷率です。 CPU load sampling by group: flow_lookup : 0% flow_fastpath : 0% flow_slowpath : 0% flow_forwarding : 0% flow_mgmt : 0% flow_ctrl : 1% nac_result : 0% flow_np : 0% dfa_result : 0% module_internal : 0% aho_result : 0% zip_result : 0% pktlog_forwarding : 0% lwm : 0% flow_host : 1% この出力のパートは、データプレーンの個々のコアの負荷率です。使用率が定量的に75% を越えている場合、 調査する必要があるかもしれません。 CPU load (%) during last 60 seconds: core 0 1 2 3 4 5 6 7 8 9 10 11 0 39 47 38 46 73 81 73 81 82 88 83 0 39 46 38 45 73 82 73 82 82 89 82 0 39 46 39 45 73 81 73 81 83 88 83 0 38 52 37 50 71 81 71 80 82 98 82 0 40 46 39 45 74 82 74 82 83 89 83 0 40 50 39 49 74 85 74 84 83 90 83 0 39 46 38 45 72 81 72 81 81 88 81 0 42 52 41 50 75 86 75 86 84 91 84 0 42 76 79 85 75 10075 100100100 85  >>> CPU 高負荷を示している例です。 0 44 51 43 50 78 85 78 86 86 91 86 0 42 51 41 50 76 86 76 86 85 92 85 0 43 53 43 52 77 89 77 89 86 93 86 0 38 46 37 45 71 81 72 81 81 88 81 0 42 50 41 50 76 85 76 85 85 90 85 ... 以下省略                    このセクションはセッションテーブルの使用率を示します。プラットフォームがサポートする最大アクティブ セッション数に対する比率です。80%を越える場合は調査する必要性があるかもしれません。 Resource utilization (%) during last 60 seconds: session:   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0 次の３つのセクションは、パケットバッファーの使用率です。 パケットバッファーはコアやプロセスで処理中待ちで、継続するパケットを失わないために使用されます。 80%を越える場合は調査する必要性があるかもしれません。 packet buffer:   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   packet descriptor:   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   packet descriptor (on-chip):   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   2   なぜリソースモニターのいくつかの値が、閾値より越えているのかを識別するのに助けるいくつかのコマンドがあります。   show session info 幾つのセッションがサポートされているかに関する全ての情報表示です。幾つのアクティブセッションがあり、パケットレート、新しいセッション確立レート、スループットが表示されます。いずれかの値が以上に高い場合、データプレーン CPU 負荷が上がる原因の可能性があります。   > show session info target-dp: *.dp0 -------------------------------------------------------------------------------- Number of sessions supported: 262142 Number of active sessions: 3 < 数字がsupported sessions数を越えている場合、 Number of active TCP sessions: 0 筐体の上限値に到達しています。 Number of active UDP sessions: 1 Number of active ICMP sessions: 0 Number of active BCAST sessions: 0 Number of active MCAST sessions: 0 Number of active predict sessions: 0 Session table utilization: 0% Number of sessions created since bootup: 332481 Packet rate: 28/s 異常な、突然の高パケットレートはDoS アタックを指示してるかもしれません。 Throughput: 13 kbps New connection establish rate: 0 cps -------------------------------------------------------------------------------- Session timeout もしtimeouts値が極端に短かったり、猶予がある場合、システムはリソース不足になる可能性も。 TCP default timeout: 3600 secs TCP session timeout before SYN-ACK received: 5 secs TCP session timeout before 3-way handshaking: 10 secs TCP half-closed session timeout: 120 secs TCP session timeout in TIME_WAIT: 15 secs TCP session timeout for unverified RST: 30 secs UDP default timeout: 30 secs ICMP default timeout: 6 secs other IP default timeout: 30 secs Captive Portal session timeout: 30 secs Session timeout in discard state: TCP: 90 secs, UDP: 60 secs, other IP protocols: 60 secs -------------------------------------------------------------------------------- Session accelerated aging: True もしaccelerated agingが未設定で、いくつかのセッションが不必要に長くアクティブのままテーブル 上で滞留するとリソースを消耗しがちです。 Accelerated aging threshold: 80% of utilization Scaling factor: 2 X -------------------------------------------------------------------------------- Session setup トラブルシューティングで以下のいくつかの設定が未設定にしてそのままにしておくと、 それらの設定は破棄すべき不正パケットの検査に追加のリソースを消耗します。 TCP - reject non-SYN first packet: True Hardware session offloading: True IPv6 firewalling: True Strict TCP/IP checksum: True ICMP Unreachable Packet Rate: 200 pps -------------------------------------------------------------------------------- Application trickling scan parameters: Timeout to determine application trickling: 10 secs Resource utilization threshold to start scan: 80% Scan scaling factor over regular aging: 8 -------------------------------------------------------------------------------- Session behavior when resource limit is reached: drop ファイアウォールが限界のリソース枯渇した時のファイアウォールの振る舞いを示します。 -------------------------------------------------------------------------------- Pcap token bucket rate : 10485760 -------------------------------------------------------------------------------- Max pending queued mcast packets per session : 0 --------------------------------------------------------------------------------     debug dataplane pool statistics システムに使われている全てのバッファーステータスを返します。   左側の数字は現在未使用のバッファー数です。 右側の数字はバッファーの最大値です。 もし左側の数字が0になると、バッファーが空になっています。   > debug dataplane pool statistics Hardware Pools [ 0] Packet Buffers : 57223/57344 0x8000000030c00000 [ 1] Work Queue Entries : 229315/229376 0x8000000037c00000 [ 2] Output Buffers : 1007/1024 0x800000000fc00000 [ 3] DFA Result : 3995/4000 0x8000000039800000 [ 4] Timer Buffers : 4096/4096 0x8000000039be8000 [ 5] PAN_FPA_LWM_POOL : 1024/1024 0x800000000fd00000 [ 6] ZIP Commands : 1023/1024 0x800000000fd40000 [ 7] PAN_FPA_BLAST_PO : 1024/1024 0x800000000ff40000 Software Pools [ 0] software packet buffer 0 ( 512): 32767/32768 0x8000000043b2a680 [ 1] software packet buffer 1 ( 1024): 32768/32768 0x8000000044b4a780 [ 2] software packet buffer 2 ( 2048): 81920/81920 0x8000000046b6a880 [ 3] software packet buffer 3 (33280): 20480/20480 0x8000000050bba980 [ 4] software packet buffer 4 (66048): 304/304 0x80000000795cea80 [ 5] Shared Pool 24 ( 24): 560000/560000 0x800000007a8f6780 [ 6] Shared Pool 32 ( 32): 530000/530000 0x800000007b7eaa80 [ 7] Shared Pool 40 ( 40): 70000/70000 0x800000007ca1cf00 [ 8] Shared Pool 192 ( 192): 1269999/1270000 0x800000007cd0cf80 [ 9] Shared Pool 256 ( 256): 140000/140000 0x800000008ba70880 [10] ZIP Results ( 184): 1024/1024 0x80000000a1827300 [11] CTD AV Block ( 1024): 32/32 0x80000000be43d380 [12] Regex Results (11544): 8000/8000 0x80000000be466100 [13] SSH Handshake State ( 6512): 64/64 0x80000000c580c680 [14] SSH State ( 3248): 512/512 0x80000000c5872480 [15] TCP host connections ( 176): 15/16 0x80000000c5a08e80   show counter global filter delta yes コマンド発行した間の差分情報を表示します。グローバルカウンターの一定期間、現在と、前回分の差分で、異常な数の破棄されたパケット数などを表示させるかもしれません。   > show counter global filter delta yes Global counters: Elapsed time since last sampling: 2.981 seconds name value rate severity category aspect description -------------------------------------------------------------------------------- pkt_recv 89 29 info packet pktproc Packets received pkt_recv_zero 87 29 info packet pktproc Packets received from QoS 0 pkt_sent 3 1 info packet pktproc Packets transmitted session_allocated 1 0 info session resource Sessions allocated session_freed 1 0 info session resource Sessions freed session_installed 1 0 info session resource Sessions installed flow_arp_pkt_rcv 83 27 info flow arp ARP packets received flow_host_pkt_rcv 2 0 info flow mgmt Packets received from control plane flow_host_pkt_xmt 2 0 info flow mgmt Packets transmitted to control plane flow_host_service_allow 2 0 info flow mgmt Device management session allowed appid_ident_by_icmp 1 0 info appid pktproc Application identified by icmp type dfa_sw 2 0 info dfa pktproc The total number of dfa match using software aho_sw 1 0 info aho pktproc The total usage of software for AHO ctd_pkt_slowpath 2 0 info ctd pktproc Packets processed by slowpath pkt_flow_np 87 29 info packet resource Packets entered module flow stage np pkt_flow_host 2 0 info packet resource Packets entered module flow stage host -------------------------------------------------------------------------------- Total counters shown: 16 --------------------------------------------------------------------------------   show system statistics session コマンドは、パケットレートや、データプレーンを通過するスループットを自動更新でライブ表示します。   System Statistics: ('q' to quit, 'h' for help) Device is up : 0 day 2 hours 34 mins 57 sec Packet rate : 32/s Throughput : 92 Kbps Total active sessions : 14 Active TCP sessions : 8 Active UDP sessions : 4 Active ICMP sessions : 2 'a'を押すと、'top 20 applications'に切り替わります。's'で元の表示に戻ります。 Top 20 Application Statistics: ('q' to quit, 'h' for help) Virtual System: vsys1 application sessions packets bytes -------------------------------- ---------- ------------ ------------ ssl 349 47051 53368023 firefox-update 4 32503 31679603 google-base 57 19879 17687367 ms-update 30 2513 2413399 tor 1 715 710161 web-browsing 60 1140 588357 ping 2920 5840 572320 windows-push-notifications 57 819 266737 apt-get 6 662 260149 dns 728 1484 185056 dhcp 124 248 86800 ms-spynet 3 71 45382 ocsp 9 215 33311 google-update 2 28 8624 ntp 45 90 8100 ipv6 2 64 5248 sip 5 5 2283 ldap 8 9 2241 insufficient-data 5 13 780 icmp 6 6 520   さらに重要なことは、どのようなタイプの通信、設定の複雑性もCPU負荷に影響します。それ上に、通信パターンを分析し、CPU負荷に影響を及ぼすようなアプリケーションを理解することが重要です。   著者: Aditi Pasupulati ... View more

FAQ - Office 365アプリケーションのアクセスコントロール ※この記事は以下の記事の日本語訳です。 FAQ - Office 365 Access Control https://live.paloaltonetworks.com/t5/Management-Articles/FAQ-Office-365-Access-Control/ta-p/94949   2016年8月29日週、Palo Alto NetworksはMicrosoft ®  Office 365™アプリケーションID変更をリリースしました。我々のお客様に、変更の準備と、変更による問題を避けるために、Palo Alto Networksは以下の代理アプリケーションIDとデコード・コンテキストをアプリケーション、脅威コンテンツアップデート597でリリースします。既存のOffice 365ポリシーが8月29日週以降も有効に働くために、このドキュメントを読み、深く理解することを推奨します。   新アプリケーション(現時点で、仮設定のみ): office365-enterprise-access office365-consumer-access  新デコード・コンテキストカスタムアプリケーション・シグネチャーのパターンマッチング (現時点で、仮設定のみ): http-req-ms-subdomain   よくある質問とその回答:   Q. なぜPalo Alto Networksこの変更を実施したのか? A. 現在はOffice 365を安全に使用にするために、我々のお客様は、 “ms-office365”と“ms-onedrive”アプリケーションIDをご使用いただいています。しかしながら、我々は、お客様が以下の目的を達することを求められていることを認識しています。   企業向け、一般ユーザー向けOffice 365をネットワーク内で可視化する必要性 特定の承認された企業向けOffice 365 アカウントを許可し、承認されていないOffice 365 アクセス（承認されていない企業向けOffice 365アカウントもしくは、一般ユーザーアカウント）をブロックする 一般ユーザーアカウントでのOffice 365 サービスへのアクセスをブロック “sharepoint-online” 共有機能でcross-tenantをコントロールまたは制限したい   Q. この変更によって得られる新しい機能は何ですか? A. お客様がこの変更によって得られる新しい変更は以下になります: 企業向け、一般ユーザー向けOffice 365をネットワーク内で可視化 特定の企業向けOffice 365ログイン用のカスタムアプリケーションを作ることができます。このアプリケーションIDはドメイン名を使った企業向けoffice 365ログインアカウントで、例えば、ユーザーがoffice 365にuser@mydomain.org、user@mydomain.comもしくはuser@mydomain.onmicrosoft.comといったログイン名でアクセスした場合に、カスタムアプリケーションは “mydomain” といったドメイン名をチェックできます。作成されると、このアプリケーションIDは既存のOffice 365アプリケーションIDに設定することができ、このアプリケーションは認証された企業アカウントを使ったOffice 365へのアクセスに限定します。 一般ユーザーアカウントでのOffice 365 サービスへのアクセスをブロック “sharepoint-online” 共有機能でcross-tenantをURLフィルタリングかカスタムアプリケーションIDによる制御   Q. この機能を利用するためにSSL復号化機能を有効にする必要がありますか? A. はい、SSL複合化機能を有効にする必要があります。   Q. SSL復号化機能をOffice 365 トラフィックで使用していない場合、この変更の影響をうけますか? A.  SSL複合化機能をOffice 365 トラフィックで使用していない場合この変更の影響を受けません。   Q. 上位ネットワークでSSL復号化機能が動作し、ファイアウォールが複合化トラフィックを受信している場合、影響を受けますか？ A. はい、この変更の影響を受けます。以下に示している推奨設定変更を実行してください。   Q. Office365 インスタンスの特定アカウントの “Custom Application” はどのようにつくりますか？ A. ステップ 1. Objects > Applicationsと進み、 “Add” をクリックして以下のように値を設定します。        ステップ 2.  “Signatures” タブをクリックし、以下のように値を設定します。     ステップ 3. 設定を保存し、コミットします。   Q. この変更によりどのような影響をうけますか? どのようにしてOffice 365 アプリケーションを継続して使用することを保証できますか? A. 7月6日のコンテンツアップデートによって、Palo Alto Networksは “office365-enterprise-access” と “office365-consumer-access” を仮設定のアプリケーションIDとしてアプリケーション・カタログに追加します。これらのアプリケーションID配布は仮設定用で、我々のお客様に事前に必要な設定変更を事前に行うことができます。これらの2つの仮設定用アプリケーションIDは、8月29日の週のコンテンツアップデートが発生して動作し始めるまで、ファイアウォールのポリシーチェックに何ら動作影響はいたしません。 Palo Alto Networksはこれらの仮設定を正式なアプリケーションID “office365-enterprise-access” と “office365-consumer-access” 8月29日の週に変更します。               この移行期間による、Palo Alto Networksのタイムラインの概要は以下です: 2016年7月5日の週: Palo Alto Networksは仮設定用の “office365-enterprise-access” と “office365-consumer-access” アプリケーションIDをコンテンツアップデートで提供します。このリリースバージョンでは、仮設定用のカスタム・デコード・コンテキスト “http-req-ms-subdomain” も提供されます。 上記で示したように、これはカスタムアプリケーションIDがOffice 365にアクセスする特定の承認された企業向けアカウントを特定する目的で使われます。これらの2つのアプリケーションIDとカスタムアプリケーションIDはファイアウォールのポリシーにアップデートされこの変更アナウンスの準備としてご使用いただくことができます。 全てのOffice 365アクセスを許可する暫定のポリシー例     承認された企業アカウントによるOffice 365アクセスのみを許可するカスタムアプリケーションIDのポリシー例        全ての企業アカウントによるOffice 365アクセスのみを許可するポリシー例     8月29日週のコンテンツ・アップデートによりPalo Alto Networksは “office365-enterprise-access” と “office365-consumer-access” アプリケーションIDが動作します。これらのアプリケーションIDは設定されたポリシーによってOffice 365サービス宛のトラフィックにチェック、実行されます。もし上記のガイダンスのように変更されれば、Office 365サービスに対するアクセスコントロールを実施できます。   Q. もし “office365-enterprise-access” を追加しなかったり、Office 365企業向けログイン、カスタムアプリケーションIDを作らなかったらどうなりますか? A . もし “office365-enterprise-access” やOffice 365企業向けログイン、カスタムアプリケーションIDを許可しなかった場合、Office365サービスが動作しません。我々は8月29日週に配布されるアップデートの準備として、上記の設定に携わることを強くお勧めします。   Q. “office365-consumer-access” アプリケーションIDをポリシーに追加しなければどうなりますか? A. “office365-consumer-access” を明確に許可しない場合、ユーザーは一般ユーザー向けのOffice 365サービスにアクセスできなくなります。我々は8月29日週に配布されるアップデートの準備として、上記の設定に携わることを強くお勧めします。   Q. 既存の “ms-office365” と “ms-onedrive” アプリケーションIDにどのような影響がありますか? A. 既存のアプリケーションIDは8月28日まで動作します。しかし、8月29日週のコンテンツ・アップデートにより、ms-office365アプリケーションID向けのユーザーログインは、 “office365-enterprise-access” もしくは “office365-consumer-access” と識別されます。そのため、これらのアプリケーションIDが存在するセキュリティポリシーを上記の推奨のように設定変更してください。   Q. どのバージョンのPAN-OSがこの変更の影響を受けますか? A. すべての現行のサポートバージョンのPAN-OSが8月29日週のコンテンツ・アップデートによって影響を受ける可能性があります。   Q. 上記の設定変更をおこなったが、新しいアプリケーションIDや起因するカスタムアプリケーションIDが見えません A. これらは、8月29日週のコンテンツ・アップデートにより、仮設定のアプリケーションIDやデコード・コンテキストが有効動作します。それまで、これらの仮設定は8月29日週の変更のアシスタント、アイデアとしてご利用になれます。   See also Microsoft Office 365 Access Control Field Support Guide   著者: msandhu ... View more

QUICプロトコルのブロック方法 ※この記事は以下の記事の日本語訳です。 How to Block QUIC Protocol https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Block-QUIC-Protocol/ta-p/120207   QUIC とは ?   QUIC (Quick UDP Internet Connections 、「クイック」と発音 ) とはGoogleが開発している実験的なトランスポート レイヤー ネットワーク プロトコルです。User Datagram Protocol (UDP)上の2つのエンドポイント間の多重化接続の集合体に対応していて、TLS/SSLと同等のセキュリティ保護を提供するだけでなく、接続と転送のレイテンシ削減やネットワーク輻輳を避けるために各方向で帯域幅推定を行う。主な目標は現在TCPを使用するウェブアプリケーションの接続指向を最適化することである。Googleの開発チームによって、Chrome ブラウザー に実験的な実装がされている。   QUIC がブロックされないとどうなる ?   Chromeブラウザーは QUIC プロトコルが既定設定で有効化されています。ユーザーが ChromeブラウザーでGoogleアプリケーションにアクセスすると、Googleサーバーへのセッションは、 TLS/SSL ではなく QUIC プロトコルを使用します。 QUIC プロトコルは開発初期段階の実験的なプロトコルで、独占所有権のある暗号化方法を使用しています。もし、 QUIC アプリケーション IDがセキュリティポリシーでホワイトリストに登録されている場合、そしてもしユーザーがChromeブラウザーでGoogleアプリケーションにアクセスすると、全てのそれらのセッションは QUIC アプリケーションとして、 Palo Alto Networks ファイアウォールの App-ID エンジンで識別されます。 Googleアプリケーションの可視化とコントロールが、 QUIC アプリケーション IDをホワイトリストに登録することによって失われます。   推奨設定:   Palo Alto Networks はセキュリティポリシーで QUIC アプリケーションをブロックすることを推奨します。ファイヤーウォールで QUIC トラフィックをブロックすることで、 Chromeブラウザーは TLS/SSL にフォールバックするからです。このことにより、ユーザーがブラウザー上で使用する機能を何も失うことはありません。ファイヤーウォールは、 SSL複合化を有効にしていても、しなくても、Googleアプリケーションに対するより良い可視化とコントロールを取り戻すことができます。   QUIC アプリケーションをセキュリティポリシーで禁止する設定例 :   最新の Chromeブラウザーバージョンでは、Googleは彼らの 実験的な QUICプロトコルを更新しました。それにより、"quic" アプリケーション IDが誤って、 "unknown-udp"と識別されます。Palo Alto Networks社は Google が加えた変更を、追加でカバーする "quic" アプリケーション ID をリリースしています。Google が彼らのプロトコルに変更を加えた場合、我々は、追記で QUIC UDPトラフィック (UDP/443 and UDP/80) をブロックする設定をセキュリティポリシーに加えることを推奨します。        著者: vsathiamoo ... View more

※この記事は以下の記事の日本語訳です。 Connect Linux Machine to GlobalProtect https://live.paloaltonetworks.com/t5/Management-Articles/Connect-Linux-Machine-to-GlobalProtect/ta-p/77307   ubuntu 14.04ユーザーはstrongswan (OpenSource VPN Client) を使って、GlobalProtectに接続できます。   Palo Alto Networks ファイアウォール上で、Enable X-Auth Supportを有効にして、Group nameとGroup passwordを設定します。残る要件としては、ソフトウェアインストールがubuntu上で完了していることです。     以下をubuntu上で実行してください:   1. ubuntu 14.04にRoot権限でログインし、以下のコマンドで関連ソフトウェアをインストールする apt-get install strongswan-starter apt-get install strongswan-plugin-xauth-generic   2. /etc配下の、ipsec.confとipsec.secretsファイルを編集します   ipsec.conf:       上記の設定でleftフィールドはGlobalProtectクライアントのIPアドレスを、もしIPアドレスがDHCPから提供される場合left=%anyと記述してください。 RightフィールドはGlobalProtectポータルの設定値を記述してください。   ipsec.secrets:   3. 以下のコマンドをubuntu上で実行し、接続します:   Ipsecサービスをubutnu上で起動 #ipsec start   以下のコマンドでipsec tunnelをUPさせます ipsec up gateway --> gateway部分にはipsec.configファイルで設定した名前を使用します。   c) 以下のコマンドで、ipsec tunnelのステータスを確認します。 ipsec status       著者: pankaj.kumar ... View more

※この記事は以下の記事の日本語訳です。 The Difference Between Receive Errors for Hardware and Logical Interface Counters https://live.paloaltonetworks.com/t5/Learning-Articles/The-Difference-Between-Receive-Errors-for-Hardware-and-Logical/ta-p/59039   Hardware interface counters read from CPUの受信エラーは物理インターファイスの受信した全てのエラー数です。その値は、主に、L2-L4の構文解析、ヘッダーエラーで、カウンターはハードウェアとしながら、 大部分は論理的なエラー（CRC、フレーミング、もしくはハードウェア外の他のエラー）によるものです。よくあるタイプとして、VLANタグの長さが不正、期待されていないVLANタグ、サポートされていないL2プロトコル、間違ったIPチェックサム、TCP/UDPチェックサム・エラー、TCP/UDPポート0、間違ったTCPフラグなどです。継続的に計上する原因として、よくあることとして、STP/LLDP/UDLDフレームがL3ファイアウォールポートに送付されている場合があります（これらのプロトコルはL3ポートではサポートされていないので、ドロップされ、受信エラーとしてカウントされます）。   Logical interface counter read from CPUの受信エラーはHA2インターフェイスで生じるエラーのみです。このカウンターはHA2 High Availabilityインターフェイスを設定したときにのみカウントします。 例） show interface ethernet1/xコマンドでカウンター値を表示した場合の参照例です。 > show interface ethernet1/3   -------------------------------------------------------------------------------- Name: ethernet1/3, ID: 18 Link status:   Runtime link speed/duplex/state: 1000/full/up   Configured link speed/duplex/state: auto/auto/auto MAC address:   Port MAC address 00:1b:17:47:38:12 Operation mode: layer3 Untagged sub-interface support: no ... --------------------------------------------------------------------------------   Hardware interface counters read from CPU: -------------------------------------------------------------------------------- bytes received                           206948822 bytes transmitted                        7785678 packets received                         2471785 packets transmitted                      50916 receive errors                           7820 packets dropped                          0 --------------------------------------------------------------------------------   Logical interface counters read from CPU: -------------------------------------------------------------------------------- bytes received                           164031355 bytes transmitted                        7785678 packets received                         2287119 packets transmitted                      50916 receive errors                           0 packets dropped                          47064 packets dropped by flow state check      32 forwarding errors                        0 no route                                 0 arp not found                            2 neighbor not found                       0 neighbor info pending                    0 mac not found                            0 packets routed to different zone         0 land attacks                             0 ping-of-death attacks                    0 teardrop attacks                         0 ip spoof attacks                         0 mac spoof attacks                        0 ICMP fragment                            0 layer2 encapsulated packets              0 layer2 decapsulated packets              0 -------------------------------------------------------------------------------- 著書: ncackov   ... View more

※この記事は以下の記事の日本語訳です。 Resolving Routing Issues when Using NAT over VPN           https://live.paloaltonetworks.com/t5/Management-Articles/Resolving-Routing-Issues-when-Using-NAT-over-VPN/ta-p/62823   詳細 IPsec トネリングでNATを使用しているうえで、プロキシーIDsを変換している場合、トネルインターフェイスを介したNATを変換したルートへの宛先指定が必要です。   プライベートアドレスを、パブリックアドレスとNATにより外部から見えなくする典型的な構成図は以下です。     On the PA 2020: 172.17.20.0/24セグメントは2.2.2.0/24ネットワークセグメントにNAT変換されます。   On the PA 5050: 172.17.30.0/24セグメントは 3.3.3.0/24ネットワークセグメントにNAT変換されます。   NATは常に1対1のマッピングは必要ないです。設定者は一つのパブリックアドレスを使って、ポートベースの変換を設定することも可能です。これらのIPアドレスは、VPNにてプロキシーIDが使われます。PAN-OSのセッションセットアップ毎に、ファイヤーウォールはESPパケットを解読し、パケット内の送信元、宛先アドレス双方のフォワーディングルックアップを実行し、ゾーンとインターフェイスを決定します。これらのアドレスのルートがトネルインターフェイスを指示していなく、フォワーディングルックアップがデフォルトゲートウェイを指示しています（特定ルートのスタティックルートや、ダイナミックルートが無い場合）。両方のアドレスルートがuntrustゾーン、インターフェイスを指示している場合、トネルインターフェイスが所属するゾーンからの通信を許可するポリシーに一致しないので、パケットがドロップされます。   NAT、VPN設定に加えて、必要なルート設定は以下です： admin@PA-2020# set network virtual-router default routing-table ip static-route local-site-NAT destination 2.2.2.0/24  interface tunnel.1 admin@PA-2020# set network virtual-router default routing-table ip static-route local-site-NAT destination 3.3.3.0/24  interface tunnel.1   同様に、対向側で必要なルート設定は以下です：  admin@PA-5050# set network virtual-router default routing-table ip static-route local-site-NAT destination 3.3.3.0/24  interface tunnel.1 admin@PA-5050# set network virtual-router default routing-table ip static-route local-site-NAT destination 2.2.2.0/24  interface tunnel.1 ... View more

※この記事は以下の記事の日本語訳です。 GlobalProtect Client Stuck at Connecting when Workstation is on the Local Network https://live.paloaltonetworks.com/t5/Management-Articles/GlobalProtect-Client-Stuck-at-Connecting-when-Workstation-is-on/ta-p/53795   症状 GlobalProtectクライアントがインストールされた端末が、社内ネットワークに接続している際に、GlobalProtectゲートウェイ、ポータルに接続できないことがあります。一方で、インターネットからの接続は問題なくできます。   問題 典型的な状況として、GlobalProtectクライアントは社内ネットワーク接続する時に、GlobalProtectゲートウェイ、ポータルの外部インターフェイスに接続しようとします。接続が失敗する理由としては、ファイアウォールが内部ゾーンから外部ゾーンへの通信として識別し、それが外部IPアドレスへの接続である為、ソースアドレスをNAT変換します。パケットの宛先は既に外部インターフェイスのIPであり、宛先と送信元アドレスが同じになり、意図しないLAN攻撃を作り出します。それによりファイアウォールはこれらのセッションを破棄します。詳しくはUnable to Connect to or Ping a Firewall Interfaceを参照ください。   解決方法 GlobalProtectポータルのライセンスがファイアウォール上で有効である場合、最適な方法としては、内部ゲートウェイを設定し、GlobalProtectクライアントにその内部ゲートウェイを検索させ、接続させることです。そうすることにより社内ネットワーク接続にトラフィックをトンネリングしないようにします。詳しくはGlobalProtect Configuration Tech Noteをご参照ください。   しかしながら上記の設定では、内部ユーザの外部GlobalProtectポータルへの接続が有効になりません。 もしポータルへの接続が必要な場合、もしくはライセンスがない場合、ファイアウォールの外部インターフェイス接続に使用する、例外的に動作するデフォルトの外部NATルールとして設定できます。 外部向けNATルールをクローンで作成します。 そのルールを既存の外部向けNATルールの上位に移動します。 ルールの名前を変更します。 外部インターフェイスのIPアドレスを、元のアドレスの宛先アドレスフィールドに追加します。 送信元アドレスの変換をNoneに変更します。 この設定により内部ユーザが外部ゲートウェイ、ポータルに対してソースアドレスの変更、パケットドロップなしに接続することができます。ユーザが外部ゲートウェイに接続している場合、そのトラフィックは暗号化され、内部ネットワークから外部インターフェースへ送られています。 著書: astanton ... View more