ナレッジドキュメント

[ This document is written in Japanese. ]   PAN-DB のカテゴリリストです。   URLカテゴリ名 カテゴリ説明 サイト例 備考 Abortion (人口中絶) 中絶に反対または賛成、中絶手続きに関する詳細、中絶を援助またはサポートするフォーラムに関する情報やグループのサイト、中絶推進の結果/効果に関する情報を提供するサイト。 www.prochoiceamerica.org , www.abortbypill.com 　 Abused Drugs (乱用薬物) 合法および非合法を問わず薬の乱用を促進するサイト、薬物関連の道具の使用や販売、薬の製造や販売に関連するサイト。 www.bombshock.com , www.friendsofcannibas.com 　 Adult (アダルト) 性的に露骨な内容、文章（言葉を含む）、芸術、または本質的に性的表現がきわどい製品、オンライングループやフォーラム。ビデオチャット、エスコートサービス、ストリップクラブを含むアダルトサービスを宣伝するサイト。 ゲームやコミックであれアダルトコンテンツを含むものはすべてadultにカテゴリ化される。 www.playboyplus.com , www.furrytofurry.com 　 Alcohol and Tobacco (アルコールとタバコ) アルコールやたばこ製品、関連用品の販売、製造、使用に関連するサイト。 www.wine.com , www.thompsoncigars.com , www.cigarsinternational.com , www.thegoodwineguru.com , www.webtender.com 　 Auctions (オークション) 個人間での商品売買を促進するサイト。 www.ebay.com 　 Business and Economy (ビジネスと経済) マーケティング、経営、経済、起業や事業経営に関するサイト。 広告・マーケティング企業も含まれます。企業サイトは、各企業の分野で分類されるべきで、このカテゴリに含むべきではない。fedex.comやups.comといった運送サイトが含まれる。 http://cox.netとhttp://directv.comはケーブル会社であり、"business and economy" でなければならない（タイムワーナーケーブルとコムキャストも同様）。ストリーミング用に個別のサイトがある場合（コムキャストではxfinity.comcast.net）、"streaming media" カテゴリとする。 www.bothsidesofthetable.com/ , www.ogilvy.com , www.geisheker.com/ , www.imageworksstudio.com/ , www.linearcreative.com/ 　 Command and Contorol (コマンド&コントロール) マルウェアに使用されているURLやドメイン、もしくは攻撃者のリモートサーバーから不正なコマンドや意図しないデータを受け取るなどマルウェアに感染しているシステム     Computer and Internet Info (コンピュータとインターネット情報) コンピュータとインターネットに関する一般的な情報。 コンピュータサイエンス、エンジニアリグ、ハードウェア、ソフトウェア、セキュリティ、プログラミングなどに関するサイトも含まれる。プログラミングはreferenceと重複するかもしれないが、メインカテゴリはcomputer and internet infoとなる。 www.redhat.com , www.freebsd.org , www.microsoft.com , www.symantec.com , www.oreilly.com , www.build-your-own-computers.com , www.alexa.com 　 Content Delivery Networks (コンテンツ配信ネットワーク) 広告、メディア、ファイルなどのようなコンテンツを第三者に配信することを主に行うサイト。 画像サーバを含む。 www.netdna.com , www.edgecast.com 　 Copyright infringement (著作権侵害) 著作権を侵害したビデオや映画、その他のメディアファイルをダウンロードにより提供する専用のウェブサイトやサービス。 www.moviexk.net   Dating (出会い系) 出会い系、オンラインデートサービス、アドバイス、その他個人的な広告を提供するウェブサイト。 www.match.com , www.eharmony.com , www.okcupid.com 　 Dynamic DNS (ダイナミックDNS) 提供されたまたは動的なドメイン名とIPアドレスを関連付けるためにダイナミックDNSサービスを利用しているサイト。 ダイナミックDNSサイトは、サイバー攻撃者に対するC&C通信および、他の悪意のある目的のために使用される場合がある。 no-ip.com dyndns.org 　 Educational Institutions (教育機関) 学校、短期大学、大学、学区、オンラインクラス、その他の学術機関用の公式Webサイト。 小学校、高校、大学など大規模な制定された教育機関を指す。個別指導塾もこのカテゴリとなる。 www.ucla.edu , www.phoenix.edu , www.sfusd.edu 　 Entertainment and Arts (娯楽と芸術) 映画、テレビ、ラジオ、ビデオ、プログラミングガイド・ツール、マンガ、芸能、博物館、アートギャラリーのサイト。エンターテインメント、有名人、業界のニュースに関するサイトも含まれる。 www.variety.com , www.tmz.com , www.moma.org 　 Extremism (過激主義・思想) テロや人種差別、ファシズムや人種、異なる民族的背景、宗教や信仰を判別する過激主義・思想を促進するウェブサイト。 　   Financial Services (金融サービス) オンラインバンキング、ローン、住宅ローン、債務管理、クレジットカード会社、保険会社などの個人金融情報やアドバイスに関するWebサイト。株式市場、証券会社、取引サービスに関するサイトは含まれない。外国為替取引関連サイトを含む。 www.chase.com , www.bofa.com , www.salliemae.com 　 Gambling (ギャンブル) 本物または仮想のお金の交換を容易にする宝くじやギャンブルのWebサイト。賭けのオッズやプールに関する情報、ギャンブルに関する指導や助言を提供するサイト。ギャンブルを行わないホテルやカジノの企業サイトはTravelにカテゴリ化される。 www.fulltiltpoker.com , www.vegasbettinglines.com 　 Games (ゲーム) ビデオやコンピュータゲームをオンライン再生やダウンロードできるサイト、ゲーム批評、ヒント、裏技を提供するサイト。非電子ゲームの教育、ボードゲームの販売や交換、関連する出版物やメディアに関するサイト。オンライン懸賞や景品を扱うサイトを含む。 www.gamespot.com , www.xbox360.ign.com , www.1up.com 　 Government (政治) 地方自治体、州政府、国家政府の公式Webサイト。関係機関、サービス、法律に関するサイトを含む。 公共図書館は除く。 www.ca.gov , www.sfgov.org , www.dmv.ca.gov 　 Hacking (ハッキング) 通信機器やソフトウェアに対して、違法または疑わしいアクセスや利用に関するサイト。ネットワークやシステムが侵害される可能性のあるプログラムの開発や配布、手順の助言やヒントに関するサイト。また、ライセンスやデジタル著作権システムをバイパスさせるサイトも含まれる。 www.hackspc.com , www.hackthissite.org 　 Health and Medicine (健康と医療) 一般的な健康に関する情報、問題、伝統医学や現代医学の助言、治癒、治療に関する情報を含むサイト。さまざまな医療分野、慣行、設備、専門家のためのサイトが含まれる。医療保険、美容整形に関するサイトも含まれる。 動物病院を含む。 www.kaiserpermanente.org , www.webmd.com , www.24hourfitness.com 　 Home and Garden (住まいと庭) 住まいの修繕や管理、建築、設計、建設、装飾、ガーデニングに関する情報、製品、サービスを提供するサイト。 www.bhg.com , www.homedepot.com 　 Hunting and Fishing (ハンティングとフィッシング) 狩猟や釣りの情報、説明、販売、関連装置や関連用品に関するサイト。 www.wildlifelicense.com , www.outdoorlife.com 　 Insufficient content (識別困難なWebサイト) テストページやコンテンツが存在しない場合やユーザ向けではないAPIアクセス用のサイト、コンテンツの表示に認証必要などカテゴリ分類が困難なWebサイト。 　   Internet Communications and Telephony (インターネット通信と電話) ビデオチャット、インスタントメッセージ、電話機能のサービスをサポートまたは提供するサイト。 www.skype.com 　 Internet Portals (ポータルサイト) 通常、広範なコンテンツやトピックをまとめることでユーザーに対して開始点となるサービスを提供するサイト。 www.yahoo.com , www.qq.com 　 Job Search (職探し) 求人情報や雇用評価、面接のアドバイスやヒント、雇用主と候補者の両方に対する関連サービスに関するサイト。 www.monster.com , www.linkedin.com/jobs 　 Legal (法律) 法律、法律サービス、法律事務所、その他法律関連の問題に関する情報、分析、助言に関するサイト。 www.probono.net , www.childlaw.org , www.litigationweb.com 　 Malware (マルウェア) 悪意あるコンテンツ、実行可能ファイル、スクリプト、ウイルス、トロイの木馬、コードを含むサイト。 　 　 Military (軍事) 軍事部門、軍人募集、現在や過去の作戦、関連道具に関する情報や解説のサイト。 www.goarmy.com , www.pentagon.mil 　 Motor Vehicles (モータービークル) 自動車、オートバイ、ボート、トラック、RVに関して批評、販売、取引、改造、部品、その他関連する議論に関する情報。 www.edmunds.com , www.carfax.com , www.audi.com 　 Music (音楽) 音楽の販売、配布、情報に関するサイト。音楽アーティスト、グループ、レーベル、イベント、歌詞、音楽ビジネスに関するその他の情報に関するWebサイトを含む。 ストリーミング音楽は含まない。 www.U2.com , www.itunes.com 　 News (ニュース) オンライン出版物、ニュースワイヤー（オンラインでニュースを送受信するシステム）サービス、その他、現在のイベント、天候、時事問題を集約したサイト。新聞、ラジオ局、雑誌、ポッドキャストを含む。 reddit, delicious, diggのようなソーシャルブックマークサイトを含む。 www.reuters.com , www.abcnews.com , www.weather.com 　 Not-resolved (未解決) 対象のURLがローカルURLフィルタリングデータベースに存在せず、ファイアウォールがクラウドのデータベースへ接続できない場合。     Nudity (裸体) 作品として性的な意図や意味があるかによらず、人体のヌードやセミヌードを含むサイト。参加者の画像を含むヌーディストやヌーディストサイトも含まれる。 www.nudistbeaches.nl , www.fineartnude.com 　 Online Storage and Backup (オンラインストレージとバックアップ) ファイルの無料オンラインストレージをサービスとして提供するWebサイト。 flickr.comやshutterfly.comのような写真共有サイトを含む。 www.dropbox.com , www.box.net 　 Parked (パークドメイン) 限られたコンテンツやクリックスルー広告をホストするURL。ホストに対して収入を生むことがあるが、一般にはエンドユーザにとって有用なコンテンツやサイトが含まれていない。工事中のサイトやフォルダのみのページを含む。 www.parked.com 　 Peer-to-Peer (ピアツーピア) ターゲットファイルへのデータ、ダウンロードしたプログラム、メディアファイル、その他ソフトウェアアプリケーションへのピアツーピア共有アクセスまたはクライアントを提供するサイト。 シェアウェアやフリーウェアサイトは含まない。bittorrentダウンロード機能を持つサイトが主に含まれる。 www.thepiratebay.org , www.emule-project.net , www.bitcomet.com 　 Personal Sites and Blogs (個人サイトとブログ) 個人やグループによる、私的なWebサイトやブログ。 最初のコンテンツに基づいて分類されるべき。たとえば誰かがクルマについてのブログを持っている場合は、そのサイトは"motor vehicles"に分類されるべきである。サイトが純粋なブログである場合は、" Personal Sites and Blogs " となります。 www.blogspot.com , www.wordpress.com , www.greatamericanphotocontest.com 　 Philosophy and Political Advocacy (哲学と政策支援) 哲学や政治的見解に関する情報、視点やキャンペーンを含むサイト。 www.protectmarriage.com , www.bradycampaign.org 　 Phishing (フィッシング) フィッシングやファーミングによりユーザーから個人情報を取得する、見かけ上は信頼できそうなサイト。 　 　 Private IP Addresses (プライベートIPアドレス) このカテゴリにはRFC1918 "Address Allocation for Private Intranets" で定義されたIPアドレスを含む。 10.0.0.0 - 10.255.255.255 (10/8 プレフィックス) 172.16.0.0 - 172.31.255.255 (172.16/12 プレフィックス) 192.168.0.0 - 192.168.255.255 (192.168/16 プレフィックス) 169.254.0.0 - 169.254.255.255 (169.254/16 プレフィックス) また*.localのような公共のDNSシステムに登録されていないドメインが含まれる。 　 　 Proxy Avoidance and Anonymizers (プロキシ回避と匿名プロキシ) プロキシサーバやその他方式でURLフィルタリングやURL監視をバイパスするサイト。 www.proxify.com , www.proxy-anonymizer.com 　 Questionable (疑わしいサイト) 下品なユーモア、特定層の個人やグループをターゲットにした不快なコンテンツ、犯罪行為、違法行為、手早く金持ちになれる、といったものを含むサイト。 www.collegehumor.com , www.holytaco.com 　 Real Estate (不動産) 不動産賃貸、販売、関連する助言や情報に関するサイト。不動産業者、企業、レンタルサービス、不動産情報、リフォーム関連のサイトが含まれる。 www.realtor.com , www.redfin.com , www.prudentialproperties.com 　 Recreation and Hobbies (レクリエーションと趣味) レクリエーションや趣味に関する情報、フォーラム、団体、グループ、および出版に関するサイト。 www.cross-stitching.com , www.modelplanes.com 　 Reference and Research (参考と調査) 個人、専門家、学術系のリファレンスポータル、コンテンツ、サービス。オンライン辞書、地図、年間、国勢調査、図書館、系譜、科学情報が含まれる。 公共図書館であれば.govで終わるサイトも含む。 www.wikipedia.org , www.reference.com , www.m-w.com 　 Religion (宗教) 各種宗教、関連活動やイベントに関する情報。宗教団体、関係者や礼拝場所に関するWebサイトを含む。 占星術、星占い、占いに関するサイトを含む。 www.vatican.va , www.sjkoreancatholic.org , www.biblesociety.ca 　 Search Engines (サーチエンジン) キーワード、フレーズ、その他パラメータを使用して検索インタフェースを提供するサイト。検索結果として情報、ウェブサイト、画像、ファイルを返す。 www.google.com , www.baidu.com 　 Sex Education (性教育) ⽣殖、性的発育、安全な性⾏為慣⾏、性病、避妊、より良いセックスに関する情報、関連する製品や道具に関する情報。関係するグループ、フォーラムや組織のためのウェブサイトを含む。 www.plannedparenthood.org , www.sexandahealthieryou.org 　 Shareware and Freeware (シェアウェアとフリーウェア) 無料または寄付を受け付けるソフトウェア、スクリーンセーバー、アイコン、壁紙、ユーティリティ、着メロ、テーマ、ウィジットへのアクセスを提供するサイト。また、オープンソースプロジェクトが含まれる。 www.download.com , www.sourceforge.net 　 Shopping (ショッピング) 商品やサービスの購入を促進するサイト。オンライン小売業者、百貨店、小売店、カタログ販売のWebサイト、価格を集約してモニタするサイトも含まれる。 ここに記載されているサイトは、さまざまな商品を販売するオンライン商店、または主な目的がオンラインセールスです。オンライン購入を可能にする化粧品会社のWebページはcosmeticsではなくshoppingに分類される。 食料品店のサイトも含まれる。 ポイントを商品と交換するサイトも含まれる。 www.amazon.com , www.pricegrabber.com , www.lightningdrops.com 　 Social Networking (ソーシャルネットワーキング) ユーザーが互いにメッセージや写真を投稿したり、人々のグループとコミュニケーションしたりするユーザーコミュニティやサイト。ブログや個人サイトは含まれない。 www.facebook.com , www.twitter.com , www.linkedin.com 　 Society (社会) 一般住民に関連するトピック、ファッション、美容、慈善団体、社会、または子供など多種多様な人々に影響のある論点に関するサイト。 子供向けに作成されたWebサイトを含む。 薬物依存、性的中毒、ギャンブルなどの相談サービスに特化したWebサイトを含む。 レストラン、UFOに関するサイトを含む。 www.style.com , www.redcross.org 　 Sports (スポーツ) スポーツイベント、選手、コーチ、関係者、チームや団体、スポーツのスコア、スケジュール、関連ニュース、関連用具に関する情報。ファンタジースポーツや仮想スポーツリーグに関するサイトも含まれる。 ペイントボールや各種武道といったスポーツも含まれる。 www.espn.com , www.nba.com , www.fantasysports.yahoo.com 　 Stock Advice and Tools (株式情報とツール) 株式市場に関する情報、株式やオプション取引、ポートフォリオ管理、投資戦略、相場、関連ニュースに関する情報。 www.thestreet.com , www.cramers-mad-money.com 　 Streaming Media (ストリーミングメディア) 無料または有料のストリームオーディオまたはストリームビデオコンテンツサイト。テレビ局のWebサイトはentertainment and artsにカテゴリ化される。 オンラインラジオ局やその他ストリーミング音楽サービスを含む。 www.hulu.com , www.youtube.com , www.pandora.com , www.spotify.com , www.grooveshark.com 　 Swimsuits and Intimate Apparel (水着と下着) 水着や下着、その他きわどい衣服の情報や画像を含むサイト www.victoriassecret.com , www.brazilianswimwear.com 　 Training and Tools (トレーニングとツール) オンライン教育とトレーニング、関連資料を提供するサイト。 自動車教習所、職業研修などを含めることができる。学習塾や試験対策は技術的にはtraining and tools となる。 www.directdegree.com , www.trafficschoolonline.com 　 Translation (翻訳サイト) ユーザー入力やURL翻訳の両方を含む翻訳サービスを提供するサイト。これらサイトは、目的ページのコンテンツが翻訳URLの一部に表示されるものとして、ユーザーにフィルタリング回避させることもできます。 www.translate.google.com , www.microsofttranslator.com , www.babelfish.yahoo.com 　 Travel (旅行) 旅行の助言、お得な情報、価格情報、旅先情報、観光、関連サービスに関する情報のサイト。ホテル、現地の観光スポット、カジノ、航空会社、クルージング、旅行代理店、レンタカーに関して価格情報や予約ツールを提供するサイトを含む。 エッフェル塔、グランドキャニオン、テーマパーク、動物園、国立公園などの現地観光スポットに関するサイトを含む。タクシー会社を含む。 www.kayak.com , www.farecompare.com , www.jetblue.com 　 Unknow (不明) まだカテゴライズされていないためにファイアウォールもしくはクラウドのURLデータベースに存在しないWebサイト。     Weapons (武器) 兵器やその使用に関する、販売、批評、説明、取扱のサイト。 www.israeli-weapons.com , www.nunchuckguy.com 　 Web Advertisements (ウェブ広告) 広告、メディア、コンテンツ、バナーが含まれる。 www.webtraffic2night.com , www.doubleclick.net 　 Web Hosting (ウェブホスティング) Web開発、出版、販売促進、トラフィックを増やすためのその他方法に関する情報を含む、無料または有料のWebページのホスティングサービス。 www.godaddy.com , www.fatcow.com 　 Web-based Email (ウェブメール) 電子メールの受信ボックスへのアクセスを与えるか、電子メールを送受信できるWebサイト。 www.hotmail.com , www.mail.google.com 　    

※この記事は以下の記事の日本語訳です。 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

※この記事は以下の記事の日本語訳です。 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ドメイン・シグネチャが生成されました。  

※この記事は以下の記事の日本語訳です。 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

※この記事は以下の記事の日本語訳です。 Meaning of Error Codes When Content Update Fails With "Auto update agent failed to download content" https://live.paloaltonetworks.com/t5/Management-Articles/Meaning-of-Error-Codes-When-Content-Update-Fails-With-quot-Auto/ta-p/54109   詳細 コンテンツの更新に失敗すると、システムログに次のような内容が表示されることがあります: xx/xx 04:30:17  Connection to Update server: staticupdates.paloaltonetworks.com completed successfully, initiated by xx.xx.xx.xx xx/xx 04:30:27  Connection to Update server closed: , source: xx.xx.xx.xx xx/xx 04:30:28    Auto update agent failed   to download content version xxxx-xxxx   ms.logでエラーの詳細が確認できます: --2014-xx-xx xx:xx:x-- https://staticupdates.paloaltonetworks.com/Updates/UpdateService.asmx/CheckForSignatureUpdate Resolving staticupdates.paloaltonetworks.com... 199.167.52.15 Connecting to staticupdates.paloaltonetworks.com|199.167.52.15|:443... connected.   2014-07-09 04:30:17 (4.00 MB/s) - `/tmp/.contentinfo.xml.tmp' saved [4215/4215] NO_MATCHES NO_MATCHES xxx xx 04:30:28   updater error code:-8 xxx xx 04:30:28 Error: pan_jobmgr_downloader_thread(pan_job_mgr.c:2080): DOWNLOAD job failed xxx xx 04:30:28 Error: _pan_mgmtop_finish_download_content(pan_ops_content.c:1351): Failed to download file   エラー コード 8 は Palo Alto Networks ファイアウォールがダウンロード サーバーに接続した後に予期しない応答または不正な応答を受け取ったことを示します。   以下によく見られるエラー コードと一般的な意味について記述します: 一般的な通信エラー（DNSの名前解決失敗など） パースエラー（‘.wgetrc’ や ‘.netrc’ などのコマンドライン オプションを解析する時など） ファイル I/O エラー ネットワーク障害 SSL検証失敗 認証失敗 プロトコル エラー サーバーからのエラー応答   著者: kkondo  

※この記事は以下の記事の日本語訳です。 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

※この記事は以下の記事の日本語訳です。 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

※この記事は以下の記事の日本語訳です。 How to Implement ECMP (Load Balancing) on the Firewall https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Implement-ECMP-Load-Balancing-on-the-Firewall/ta-p/110339   概要   等コスト負荷分散(ECMP) はPAN-OS7.0で導入された新機能です。これは「等コスト」である同じ宛先に対して複数のルートを提供します。最大で4つの等コストルートがサポートされます。   この機能を使用しない場合、同じ宛先に複数の等コストルートがあると、仮想ルーターはルーティングテーブルからそれらのルートの1つを選択し、それを転送テーブルに追加します。選択されたルートに問題がない限り、他のルートは使用されません。   ECMPロードバランシングは、パケットレベルではなく、セッションレベルで実行されます。新しいセッションの開始は、ファイアウォール（ECMP）が等価コストパスを選択したときです。   この記事では、ファイアウォール上でECMPを実現するための基本的な設定に焦点を当てます。   詳細   この記事で使用するトポロジ： =======================     インターフェイス設定：     注：ethernet1/1およびethernet1/11はそれぞれ異なるゾーンであるL3-UntrustおよびVPNで構成されたISPインターフェイスです。ただし、これらのインターフェイスは同じゾーンでも構成できます。     両方のデフォルトルートが「等コスト」を持つルート設定：       インターネット経由でトラフィックをルーティングするためのNATポリシー：     注：両方のISPインターフェイスが同じゾーンにある場合、宛先インターフェイスを次のスクリーンショットのようにNATポリシーに追加する必要があります。       トラフィックを許可するセキュリティポリシーの設定：（インターフェイスが同じゾーンまたは異なるゾーンにある場合のどちらのシナリオにも対応します）       ファイアウォールでのECMPの有効化：     注： - Max Path 2 は、2つの等コストパスのみがFIBテーブルにインストールされることを意味します。 FIBテーブルにインストールする必要がある等価コストパスが2つ以上ある場合は、Max Path値を変更します。サポートされている最大値は4です。 - ロードバランス方式は、要件に応じて選択できます。負荷分散アルゴリズムの詳細については、ここをクリックしてください - Request パケットが来たインターフェイスと同じインタフェースから Reply パケットを送信する必要がある場合は、Symmetric Return を有効にします。       ECMP動作の確認：   Monitor > Traffic Logs (異なるゾーンの場合)       Monitor > Traffic Logs (同じゾーンの場合)       ECMPとしてインストールされたルートには「E」フラグがあります：         注：ECMPの詳細については、ここをクリックしてください   著者: hagarwal 

※この記事は以下の記事の日本語訳です。   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

PAシリーズファイアウォール製品 PPPoE 機能サポートに関する情報です。   [基本情報]   RFC1661, RFC2516 および NTT東西 PPPoE 技術仕様に準拠 PA-VMシリーズを含む全てのPAシリーズファイアウォールで利用可能 PPPoE 機能利用時の PAN-OS 推奨バージョン (2018年3月末時点) PAN-OS 7.1.14 以上, PAN-OS 8.0.6-h3 以上, (PAN-OS 8.1.0 以上 ※ETAC推奨バージョンの利用を推奨) 注: PAN-OS 7.1.10 以下, PAN-OS 8.0.3 以下のバージョンの場合トラブルシューティングに必要な 　　PCAP 機能が正しく動作しないため、推奨バージョンへのアップグレードを強く推奨 注: PAN-OS 8.1.0 以外のPAN-OSは PPPoE debug PCAP 動作不可 (2018年3月末時点) PPPoE は物理インターフェイス単位でのみ利用可能 システム全体で設定可能な PPPoE インスタンスの数は物理インターフェイス数と同一 単一の物理インターフェースで設定可能な PPPoE インスタンスは１つのみ 注: 802.1Q VLAN タグ付きサブインターフェイスは未サポート PPPoE リダンダントパスは複数の物理インターフェイスを使用することで利用可能 注: リダンダントパス機能を使用する場合は PBF (ポリシーベース・フォワーディング) 設定が必要 静的 IPアドレスの設定について PPPoE を使用するインターフェイスに設定する IPアドレスは32ビットマスクのみ 8 IP, 16 IP などLAN型払い出しIP構成の場合、PPP IPCPプロトコルにより先頭のIPアドレスがPPPoEインターフェイスに割り当てられる PPPoE Unnumbered (DMZ など内部セグメント側でGlobal IPアドレスを使用する) 構成をサポート PAP/CHAP 認証をサポート 通常はデフォルト値の "auto" を使用 PPPoE 回線に対するキープライブ処理について PAN-OS は3秒ごとに LCP keep-alive フレームを送信し、5回連続で失敗した際に PPPoE 接続を切断 keep-alive フレームの送信間隔の設定変更は不可 PPPoE が切断時、PAN-OS は10秒間隔で再接続を実行 ルーティング処理について PPPoE 経由で学習したデフォルト経路情報は動的ルーティングプロトコルへの再配布(re-distribute)が可能 PPPoE 回線が切断した場合デフォルト経路は即座にパージされる HA冗長化構成について HA フェイルオーバー発生時、パッシブ側デバイスにおいて PPPoE コネクション処理が継続される HA フェイルオーバー発生に伴う PPPoE の再接続の必要はない   [GlobalProtect Portal/Gateway 機能を使用する場合]   固定IPアドレスの契約が必要 (1 IP, 8 IP, 16 IP など) PPPoE 回線側に割り当てられたグローバル IPアドレス 1つを GlobalProtect Portal/Gateway で共有可能 GlobalProtect Portal, Gateway それぞれに別のグローバルIPアドレスを割り当てることも可能 この構成の場合はいずれか一方の機能で Loopback インターフェイスを使用   [PPPoE 機能使用時の留意事項]   PPPoE を利用する物理インターフェースのMTUは必ずデフォルト値から変更 通常時：1454 / NTT西日本 光プレミアムを使用する場合：1438 PPPoE 接続開始時、ネットワークループやネットワーク構成ミスにより PPPoE セッション開始時に送信されるPADIパケットが大量(最大20回/5分)に送信された場合、網からのPADOパケット送信が抑制され一定期間 PPPoE回線接続が出来なくなる場合がある。この場合はしばらく待ってから再度接続を実施する。 注 : PADO送信が抑制される具体的な時間は非公開 PPPoE 回線側終端装置(AC)がNTT 東西の技術仕様に準拠しない動作をした場合、PAファイアウォールとのPPPoE 回線接続が正しく行われない場合あり。この場合PA側不具合ではないため、回線契約者からNTTに対して改善依頼する必要あり 8 IP, 16 IP など LAN型接続を利用する場合、ISPから割り当てられたIPグローバルアドレスの４バイト目が0 (例: 203.0.113.0/29 ) の場合、PAからインターネット向けN対1 NAT外部アドレスのホストアドレスが”0”になり、特定の宛先に対する通信が正しく行われない可能性がある。そのため PA導入前にISPへ連絡し割り当てられた IPアドレス４バイト目が”0”ではない別のIPグローバルアドレスの再割当てを申請すること   [PPPoE のユースケース]   中小規模拠点における最もベーシックな セキュアなインターネットアクセス 利用形態 　　　　　 セキュアなインターネットアクセスと公開サーバ保護の実現 セキュアなインターネットアクセスとPPPoE Unnumbered 接続による公開サーバ保護の実現 多拠点VPN接続、セキュアなインターネットアクセスと集中管理による管理負荷軽減の実現 GlobalProtect によるモバイルユーザに対する利用場所に依存しないセキュアなネットワーク環境の実現 Office365などSaaSトラフィックの分離によるユーザレスポンス向上(Proxyサーバの負荷軽減)の実現       以上

PAN-OS PPPoE Unnumbered 設定例です。   なお、PAN-OS における PPPoEのLAN型接続における回線側インターフェースは、厳密にはUnnumberedではなく、ISPからPPP IPCPで割り当てられたIPアドレス(ISPから割り当てられたグローバルIP ネットワークアドレス)が割り当てられますが、このアドレスはネットワークアドレスであり、DMZ側や内部ネットワーク側でインターフェイスに設定するなどして直接的に利用することが出来ないため、PPPoE Unnumbered 構成の本質的な目的である、割り当てられたグローバルIPアドレスをDMZセグメントなどのホストで直接利用する構成における実質的な影響はありません。

PPPoE 構成における基本的なトラブルシューティングガイドです。

PPPoE 環境におけるPAクイックコンフィグレーションガイドです。 このガイドでは、次の６つのシナリオにおけるPAN-OSの設定手順と設定後のログなどの情報をスクリーンショットベースでシンプルにまとめました。   最もベーシックな接続構成 DMZ公開サーバセグメントがある構成 Global IP アドレスを直接使用するDMZ公開サーバセグメントがある構成（PPPoE Unnumbered 接続） 拠点間 VPN接続構成 GlobalProtect ポータル/ゲートウェイ機能を使用する構成 EDLを使用したローカルブレイクアウト構成   なお、本番環境に適用される場合は、PAシリーズファイアウォールの中核機能である各種脅威防御・リスク軽減機能の設定を必ず実施する様にして下さい。     本資料について、今後より良いものにして行きたいと思いますので、ご気軽に評価やフィードバックなどお願い出来れば幸いです。

※この記事は以下の記事の日本語訳です。 Occasionally forwarding fails for specific traffic that matches a PBF rule with symmetric return https://live.paloaltonetworks.com/t5/Management-Articles/Occasionally-forwarding-fails-for-specific-traffic-that-matches/ta-p/198119   事象 "対称リターンの適用" オプションを有効にして、ネクスト ホップ アドレスを設定せずにポリシー ベース フォワーディング（PBF）を設定すると、転送が失敗する場合があります。   参考: シンメトリック リターンの設定方法     診断 問題が発生しているときに、show pbf return-mac all コマンドを実行すると、return MAC エントリが上限に達していることが確認できます。このエントリが上限に達している場合、新たにreturn MAC エントリの追加ができず戻りのパケットがDropされる原因となります。 user@firewall> show pbf return-mac all current pbf configuation version:   1 total return nexthop addresses :    0 index   pbf id  ver  hw address          ip address                      return mac          egress port -------------------------------------------------------------------------------- maximum of ipv4 return mac entries supported :     1000 total ipv4 return mac entries in table :           1000 total ipv4 return mac entries shown :              1000 status: s - static, c - complete, e - expiring, i - incomplete pbf rule        id   ip address      hw address        port         status   ttl --------------------------------------------------------------------------------   注：このARP テーブルがサポートするエントリの最大数は、ファイアウォール モデルによって上限値が設定されており、この値はユーザー側で設定できません。 お使いのモデルでの上限値を確認するには、CLI コマンド: show pbf return-mac all を使用します。     解決方法 この問題は、対称リターンが有効になっているPBFルールに「ネクスト ホップ アドレス」が設定されていない場合にのみ発生します。したがって、ネクスト ホップ アドレス リストに有効なピア IP アドレスを設定して、問題を回避してください。 Add a Next Hop Address ネクスト ホップ アドレスを設定すると、適切なリターン MAC アドレスが対称リターンのために学習されます。 >show pbf return-mac all maximum of ipv4 return mac entries supported : 16000 total ipv4 return mac entries in table : 12800 total ipv4 return mac entries shown : 12800 status: s - static, c - complete, e - expiring, i - incomplete pbf rule id ip address hw address port status ttl -------------------------------------------------------------------------------- symmectric 1 8.0.0.2 00:1b:17:05:f1:17 ethernet1/1 c 737 symmectric 1 8.0.0.3 00:1b:17:05:f1:17 ethernet1/1 c 742 symmectric 1 8.0.0.4 00:1b:17:05:f1:17 ethernet1/1 c 741 symmectric 1 8.0.0.5 00:1b:17:05:f1:17 ethernet1/1 c 743 symmectric 1 8.0.0.6 00:1b:17:05:f1:17 ethernet1/1 c 746 symmectric 1 8.0.0.7 00:1b:17:05:f1:17 ethernet1/1 c 743 symmectric 1 8.0.0.8 00:1b:17:05:f1:17 ethernet1/1 c 742 symmectric 1 8.0.0.9 00:1b:17:05:f1:17 ethernet1/1 c 741 symmectric 1 8.0.0.10 00:1b:17:05:f1:17 ethernet1/1 c 745 symmectric 1 8.0.0.11 00:1b:17:05:f1:17 ethernet1/1 c 746      著者: tsakurai

※この記事は以下の記事の日本語訳です。 How Can IP Overlaps be Prevented with GlobalProtect https://live.paloaltonetworks.com/t5/Configuration-Articles/How-Can-IP-Overlaps-be-Prevented-with-GlobalProtect/ta-p/54406     問題 リモートのユーザーが社内ネットワークにGlobalProtectで接続する際、コンピューターにはゲートウェイに設定されたプールからIPアドレスが割り当てられます。このIPアドレスが該当するワークステーションが既にいるサブネットと重複している場合、問題が発生しえます。   例：リモートの従業員がホテルの部屋から、10.0.0.0/8のレンジでローカルに割り当てられたIPアドレスを用いて接続しています。GlobalProtectクライアントが利用できるIPプールは10.1.1.0/24です。これはIPプールがローカルのサブネットに包含されるため、問題が発生するでしょう。 この場合、 "Assign Private IP address failed"のエラーがファイアウォールのシステムログに生成されます。   解決方法 推奨される解決方法は異なるサブネットの新しいIPプールを作成し、新しいプールをリストの下に配置することです。IP プールは上から使用されますが、もしクライアントのサブネットが最初のIP プールと衝突する場合は、ファイアウォールは自動的に2つ目のプールからIPアドレスをアサインします。   著者: tpiens

※この記事は以下の記事の日本語訳です。 What does "TCP Session Timeout after FIN/RST" mean? https://live.paloaltonetworks.com/t5/Learning-Articles/What-does-quot-TCP-Session-Timeout-after-FIN-RST-quot-mean/ta-p/54653   概要 Palo Alto Networks機器において"TCP session timeout after FIN/RST"とは、TIME-WAIT状態の長さを指定する値です。show session infoコマンドで値が表示されます。 > show session info -------------------------------------------------------------------------------- Session timeout   TCP default timeout:                           3600 secs   TCP session timeout before SYN-ACK received:      5 secs   TCP session timeout before 3-way handshaking:    10 secs   TCP session timeout after FIN/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 --------------------------------------------------------------------------------   詳細 TIME_WAIT状態に移行するトリガーとなる最初のFINを送信する端末は、最後のACKを送信する端末でもあります。もう一方の端末から送信されるFIN、あるいは最後のACKがロストした場合に備えて、この端末は最後のFINを再送するために必要なコネクションの状態と十分な情報を維持します。   TIME_WAIT状態の長さは 2*MSL (Maximum Segment Lifetime)となります。パケットがネットワーク内を通信するのに要する最大の時間をMSL秒とします。パケットの往復のためその2倍とします。当初推奨されていたMSLの値(RFC1337)は120秒でした。Berkeleyから派生した実装では、通常30秒が使用されています。   現在、TIME_WAITの値は各ベンダーによって様々で、一般的なネットワーク機器においてはその範囲は30から60秒です。Palo Alto Networks機器ではTIME_WAITの値は30秒となっています。   設定のオプション PAN-OS 4.1.x および 5.0.x では、TIME_WAITは以下の CLI コマンドを実行することで変更が可能です。 > set session timeout-tcpwait <1-60> PAN-OS 4.1.14 および 5.0.6 では、タイマーは最大で 10 分まで設定可能となりました。 > set session timeout-tcpwait <1-600> この設定はWebGUI上で、Device > セットアップ > セッション > セッション タイムアウト > TCP Wait からも設定できます。   参照 詳細については、RFC 1337, TIME_WAIT Assassination Hazards in TCP もご確認下さい。   著者: kkondo

※この記事は以下の記事の日本語訳です。 How to Check for Logical Errors on an Interface https://live.paloaltonetworks.com/t5/Learning-Articles/How-to-Check-for-Logical-Errors-on-an-Interface/ta-p/62023   論理インターフェイス用のSNMPトラップについて。   RFC 1213ではMIBは標準のインターフェイス テーブルのみ含みます。トラップはそのシステムとMIBに組み込まれているインターフェイス グループのためのもので、それらがサポートされます。     PAN-OS 7.0 は論理インターフェイスをサポートします。   PAN-OS 6.1.ｘまでは物理インターフェイスのインターフェイスグループの情報のみ送付し、論理インターフェイスに対しては行いません。netflowを有効化しての情報取得がワークアラウンドとなります。     PAN-OS 5.0とそれ以前   特定のインターフェイス上での論理エラーをチェックするには（例ではethernet1/3を使用します）CLIコマンドを入力します。 admin@Ironhide> show interface ethernet1/3 -------------------------------------------------------------------------------- Name: ethernet1/3, ID: 18 Link status:   Runtime link speed/duplex/state: 1000/full/up   Configured link speed/duplex/state: 1000/auto/auto MAC address:   Port MAC address b4:0c:25:f8:e5:12 Operation mode: layer3 Untagged sub-interface support: yes -------------------------------------------------------------------------------- Name: ethernet1/3, ID: 18 Operation mode: layer3 Virtual router default Interface MTU 1500 Interface IP address: 192.168.9.1/24 Interface management profile: allowall   ping: yes  telnet: yes  ssh: yes  http: yes  https: yes   snmp: yes  response-pages: yes  userid-service: no Service configured: Interface belong to same subnet as management interface: Yes Zone: trust_9999, virtual system: vsys1 Adjust TCP MSS: no --------------------------------------------------------------------------------   -------------------------------------------------------------------------------- Physical port counters read from MAC: -------------------------------------------------------------------------------- rx-broadcast                  0 rx-bytes                      1775076722 rx-multicast                  0 rx-unicast                    13635670 tx-broadcast                  110085 tx-bytes                      6992300789 tx-multicast                  0 tx-unicast                    11299072 --------------------------------------------------------------------------------   これらは次世代ファイアウォールのデータプレーンが起動した時からのインターフェイス カウンターです。これらのカウンターはデータプレーンの再起動のみでクリアされます。   -------------------------------------------------------------------------------- Hardware interface counters read from CPU: -------------------------------------------------------------------------------- bytes received                          360 bytes transmitted                        0 packets received                        6 packets transmitted                      0 receive errors                          6 packets dropped                          0 --------------------------------------------------------------------------------   L2-L4解析チェックに失敗したパケットは上記のreceive errorsカウンターを増加させて破棄され、CPUに到達しません。最も一般的なケースは不正な宛先MAC、不正なVLANタグ、不正なIP、不正なTCP/UDPポートなどです。上記の例では 6 receive errors (TCP packet too short)を確認することができ、それらは破棄されCPUレベルに到達せず論理インターフェイスカウンターの表示では以下の通りゼロとなります。   Logical interface counters read from CPU: -------------------------------------------------------------------------------- bytes received                          0 bytes transmitted                        84 packets received                        0 packets transmitted                      2 receive errors                          0 packets dropped                          0 packets dropped by flow state check      0 forwarding errors                        0 no route                                0 arp not found                            0 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 --------------------------------------------------------------------------------   L2-L4解析に成功した後、パケットにはさらなるセキュリティチェックが行われます。セキュリティ ルールによる破棄や、Non-Syn TCPチェックやその他の理由で破棄は、上記の"packet dropped"カウンターの増加の原因となります。   パケット破棄の正確な理由はグローバル カウンターで行えます。例えば以下の例では、L2-L4解析にてグローバルカウンターでハイライトされた箇所の理由により、破棄されています。   admin@Ironhide> show counter global filter delta yes   Global counters: Elapsed time since last sampling: 1.150 seconds   name                                  value    rate severity  category  aspect    description -------------------------------------------------------------------------------- pkt_recv                                  41      35 info      packet    pktproc  Packets received pkt_recv_zero                            41      35 info      packet    pktproc  Packets received from QoS 0 pkt_sent                                  7        6 info      packet    pktproc  Packets transmitted pkt_alloc                                  1        0 info      packet    resource  Packets allocated flow_rcv_err                              1        0 drop      flow      parse    Packets dropped: flow stage receive error flow_rcv_dot1q_tag_err                    5        4 drop      flow      parse    Packets dropped: 802.1q tag not configured flow_no_interface                          5        4 drop      flow      parse    Packets dropped: invalid interface flow_fwd_l3_mcast_drop                    11        9 drop      flow      forward  Packets dropped: no route for IP multicast flow_parse_l4_hdr                          1        6 drop      flow      parse    Packets dropped: TCP (UDP) packet too short   カウンターは以下のCLIコマンドでクリアできます: > clear counter all All counters cleared   著者： panagent

※この記事は以下の記事の日本語訳です。 Policy-based forwarding doesn't work for traffic sourced from the Palo Alto Networks firewall https://live.paloaltonetworks.com/t5/Management-Articles/Policy-based-forwarding-doesn-t-work-for-traffic-sourced-from/ta-p/58821     問題 あるゾーンからISP経由でインターネットへ向かうすべてのトラフィックを転送するためにポリシー ベース フォワーディング (PBF) ルールを設定している場合、そのルールは、Palo Alto Networksファイアウォールの背後にある端末にだけ適用されるが、ファイアウォール自身を送信元とするトラフィックには適用されない。   原因 PBFルールに加えてルートがルーティング テーブルにある場合、最初にPBFルールだけが上から順番に評価されます。しかし、これはファイアウォールの背後にある端末にだけ適用されます。PBFがTrustゾーンからUntrustゾーンへ向かうすべてのトラフィックを転送するよう設定されていると、Palo Alto Networksファイアウォールの背後にある端末を送信元とするトラフィックにのみ、ルールが適用されます。しかしファイアウォールを送信元とするトラフィックは、PBFテーブルの評価をバイパスし、代わりに出力インターフェイスからトラフィックを転送するルートに合致するかのルーティング テーブルの評価が開始されます。   WebGUIから、[ Network ] > [ インターフェイス ] > [ Ethernet ] を開きます。続くシナリオでは、インターフェイスは以下の通り設定されています：   [ Network ] > [ 仮想ルーター ] > [ スタティック ルート ] 内に、デフォルト ルートが以下の通り設定されています：   端末から来ているトラフィックである場合、セッション情報は以下の通り表示されます：   WebGUIから、[ Policies ] > [ ポリシー ベース フォワーディング ] を開き、以下のデフォルト ルートと同じPBFルールを作成します：   端末から来ているトラフィックの場合、セッション情報は以下の通り表示されます(デフォルト ルートがあるにもかかわらず、PBFルールだけがまず評価されています)：   ファイアウォールの背後にある端末からや、ファイアウォールの信頼済みインターフェイスから、パブリックなIPアドレス 4.2.2.2 へ継続的なPingをすると、どちらもPingは成功しました。これはPBFルールを使用する端末からのトラフィックであるため、そしてルーティング テーブルを使用しているファイアウォールからのトラフィックであるためです：   デフォルト ルートだけが削除し、端末からのトラフィックはPBFルールを使用して通過することに成功していますが、デフォルト ルートが削除されたため以下の通りファイアウォールからのトラフィックは失敗しました：   PBFは、ファイアウォールの背後にいる端末からのトラフィックに対してのみ動作し、ファイアウォールからのトラフィックに対しては動作しません。   以下が既知の制限事項となります： PBFは、Palo Alto NetworksファイアウォールへのIPsecトンネルのトラフィックには機能しません。 PBFは、フェーズ1トンネルに対して機能しないので、IKEを開始するためにルーティング テーブルのデフォルト ルートを使用する必要があります。 PBFは、GlobalProtect接続に対して機能しません。 PBFルールのためにアプリケーションを使用している場合、TCPトラフィックに合致するアプリケーションのシグネチャは、3ウェイ ハンドシェイクの後に識別されます。そのため、PBFルールは、最初の3ウェイ ハンドシェイクには合致しないかもしれず、ルート探索にだけ基づいてファイアウォールを通過します。   著者：dantony

JPのIPアドレスの問題に特化したトラッカーです。   日付 報告バージョン IPレンジ 変更内容 修正バージョン （内部 ID） 2016-01-03 548 158.198.0.0/16 CN -> JP 551 89899  2016-06-02 586 158.198.140.0 - 158.199.140.255 CN -> JP 587 97237 2016-08-11 603 210.226.32.0- 210.226.35.255 AU -> JP 607 102212 2016-08-23 607 (603) 210.140.196.0/22 CN -> JP 609 103035 2016-08-18 606 (603) 158.199.128.0/19 158.199.192.0/19 160.16.192.0/20 210.140.64.0/21 210.140.96.0/21 210.140.55.00 - 210.140.79.255 210.140.85.00 - 210.140.109.255 CN -> JP 609 102755 2016-08-30 607 (603) 153.126.145.0 - 153.126.159.255 CN -> JP 615 103506 2016-08-30 607 (603) 158.199.192.0 - 158.199.200.255 CN -> JP 615 103506 2016-08-30 607 (603) 160.16.195.0 - 160.16.199.255 CN -> JP 615 103506 2016-08-30 607 (603) 160.16.243.0/24 CN -> JP 615 103506 2016-08-30 607 (603) 210.129.19.0 - 210.129.26.255 CN -> JP 615 103506 2016-08-30 607 (603) 210.152.241.0 - 210.152.250.255 CN -> JP 615 103506 2016-09-01 610 (603) 210.129.18.0/24 CN -> JP 615 103807 2016-08-30 608 (603) 210.140.193.128/27 210.140.191.0 - 210.140.199.255 CN -> JP 615 103495 2016-09-06 610 (603) 210.151.32.0/20 CN -> JP 615 103913 2016-08-30 608 (603) 160.16.224.0/19 160.16.224.0 - 160.16.255.255 CN -> JP 626 103496 CON-25963 2016-09-23 615 153.126.128.0 - 153.126.144.255 210.129.27.0 - 210.129.31.255 CN -> JP 622 105312 CON-26226 2016-09-23 615 158.199.217.85 158.199.212.115 158.199.201.0 - 158.199.210.255 158.199.211.0 - 158.199.224.255 CN -> JP 622 105303 CON-26224 2016-08-18 606 (603) 158.199.158.129 158.199.137.0 - 158.199.191.255 CN -> JP 622 102755 103506 105101 CON-26184 2016-09-23 615 158.199.157.0 - 158.199.159.255 CN -> JP 622 CON-26184 2016-10-17 623 (603) 210.170.99.178 210.170.99.179 210.148.58.0 - 210.175.255.255 SG -> JP 626 CON-26461 2016-10-26 625(625) 160.16.200.0 - 160.16.255.0 CH -> JP 626 -  

※この記事は以下の記事の日本語訳です。 ARP Entries Stay Cached for 30 Minutes https://live.paloaltonetworks.com/t5/Management-Articles/ARP-Entries-Stay-Cached-for-30-Minutes/ta-p/55717   概要 Palo Alto Networks ファイアウォールの ARP キャッシュタイムアウトは全てのインターフェイスの ARP エントリに対して30分 (1800秒)です。これは固定値であり設定変更により調整することはできません。   タイムアウト値を表示するには CLI にて "show arp all" コマンドを使用します。以下はPA-5060でのコマンド出力結果を抜粋したものです: > show arp all maximum of entries supported :      32000 default timeout:                    1800 seconds total ARP entries in table :        97 total ARP entries shown :           97 status: s - static, c - complete, e - expiring, i - incomplete   必要に応じて次の CLI コマンドを実行することでインテーフェイス毎に ARP エントリをクリアすることが可能です: > clear arp ethernet1/1   また、次のコマンドを実行すると全インターフェイスのARP エントリをクリアすることが可能です: > clear arp all   著者: gwesson  

この記事は以下の記事の日本語訳です。 Incorrect QoS Configuration Caused Network Traffic Outage https://live.paloaltonetworks.com/t5/Configuration-Articles/Incorrect-QoS-Configuration-Caused-Network-Traffic-Outage/ta-p/62576 問題 特定のクラスに対してQoSプロファイルにて帯域を制限しようとすると、QoS機能により通信障害が発生する。   詳細 以下の例は、QoSを使用するインターフェイスに関連付けられた誤った設定の例です。 この例のシナリオでは、10Gbインターフェイスが使用されており、上記のスクリーンショットは最大保証帯域 出力側を100Mbpsと設定していることを示します。プロファイル部の最大保証帯域 出力側には、この10Gbインターフェイスを通過するトラフィックのための、すべてのクラスに対しての最大の出力帯域を設定します。   多くの場合に、上記の設定がユーザーより重度の輻輳や通信断の振る舞いとして報告される問題の原因となっています。   解決策 QoSプロファイルを設定するときは、該当のインターフェイスに流れ込む総合的な帯域を考慮し、最大保証帯域 出力側を慎重に設定する必要があります。前述の意図した設定は、class7 のトラフィックを最大保証帯域 出力側を100、そして最低保障帯域 出力側を10とすることでしたが、他のすべてのトラフィックも該当インターフェイスの残りの帯域を使用します。   以下のスクリーンショットは、プロファイルの最大保証帯域 出力側を10000Mbpsとし、class7 トラフィックの最大保証帯域 出力側を100、最低保障帯域 出力側を10とした 正しい設定です。   該当のQoS インターフェイス設定も正しい値で最大保証帯域 出力側が設定されている必要があります。   注: 必要なクラスのみをQoS プロファイルで設定するだけで構いません。他のトラフィックはデフォルトのclass4となります。   著者: fkhan

※この記事は以下の記事の日本語訳です。 How to Set Up Shared Gateway and Inter VSYS https://live.paloaltonetworks.com/t5/tkb/articleeditorpage/tkb-id/ConfigurationArticles/message-uid/57370   概要 Palo Alto Networksは多くの組織にて必要とされる柔軟性のため、複数の仮想システムと、仮想システム間の通信機能をサポートしています。この文書では、業務用と家庭用に別の仮想ファイアウォールを必要とするのものの、仮想システムが同じISPを外部接続に共有する典型的な在宅勤務者の状況の2つの例を紹介します。両方のシナリオとも、双方の仮想システムが外部のISP接続を共有する状況をカバーし、相互の仮想システム（WORK_192とHOME_10）間の通信を許可します。   この文書ではこれらの機能を設定するための手順を示します。       論理構成 手順 パート1：仮想システムと共有ゲートウェイのセットアップ 最初に[Device] > [セットアップ] > [管理] > [一般設定] に移動し、マルチ仮想システム機能が有効になるようにチェックします。 2つの内部のインターフェイス ethernet1/2 (WORK_192) とethernet1/3 (zone: HOME_10)は別の仮想システムに設定されるべきです。 外部インターフェイス(ethernet1/1; zone: SHARED_UNTRUST)は手順4で共有ゲートウェイに設定するため、仮想システムに組み込まないでください。 注：この文書でインターフェイスをどう設定するか理解するために、概要に記載の論理構成をレビューしてください。 仮想システムの定義のため、Deviceタブで仮想システムを選択してください。[認識可能な仮想システム]列で互いの仮想システムが認識できるようにしてください。例えばvsys1 workはvsys2 homeが見えるように設定する必要があり、逆もまた可能なよう設定しなければなりません。 共有ゲートウェイを追加するため、[Device] > [共有ゲートウエイ]で名前とIDを割り当てます。インターフェイスを割り当てるため、[Network] > [インターフェイス]を選択し、仮想システムメニューから共有ゲートウェイを選択してください。この例ではethernet 1/1はISPからIPアドレスを提供された外部インターフェイスであり、従ってこれが設定される必要があります。 Networkタブからインターフェイスを選択してして、インターフェイスが適切に設定されていることを確認してください。 [Network] > [インターフェイス] 各インターフェイスが同じ仮想ルーター（この例ではAll-Routesという名称）に加わります。すべてのゾーンを同じ仮想ルーターに加えますが、その仮想ルーターは共有ゲートウェイや他の仮想システム間の通信を許可しません。これは後でStep8とパート2で紹介しますが、セキュリティポリシーで制御します。 [Network] > [仮想ルーター] 単一のISP上のネクストホップへのデフォルトルートを設定することが本文書の目的です。もし他にもルートが必要であれば、この仮想ルーターに追加してください。上記のスクリーンショットの3列目で"none"となっているとおり、仮想ルーターはどの仮想システムのメンバーにもなっていないことに注意してください。 Networkタブの下にあるゾーンを選んで、HomeからUntrust、WorkからUntrustの外部ゾーンを作成します。これらの2つの外部ゾーンは、内部ゾーン（例 HOME_10 and WORK_192）からSHEARED_Untrustへのトラフィックを許可あるいは禁止するポリシーを設定するためのものです。それらは効果的に内部から外部へのトラフィックの移動を、経由のゾーンで見ることができます。この例では共有ゲートウェイ ゾーンです。タイプを外部として設定し、そのゾーンに向けて通信経路が設定されているよう定義することが重要です。 ポリシーを設定する際は、内部のネットワークから共有ゲートウェイに向かうトラフィックをファイアウォールのuntrust側で許可するルールを作成します。これでHome-to-UntrustとWork-to-Untrustがともに有効に働きます。加えて、SHARED_UNTRUSTを持つShared_External_GW仮想システムに設定するNATが必要になります。 そのポリシーを設定するには[Policy] > [セキュリティ]に移動します。ポリシーを設定したい仮想システムを選ぶようにしてください。 前述したとおり、NATはShared_External_GW仮想システムに設定します。PoliciesタブのNATに移動して、WORK_192  とHOME_10のゾーンに属するホストから隠蔽する、共有ゲートウェイ外部インターフェイス（例：外部ISPアドレスがethernet1/1に割り当てられている）を使用する隠蔽用NAT設定します。このデザインではすべてのNATの設定は、仮想システムとして Shared_External_GW を選択して行われていること確認してください。この例ではどの仮想システムも外部ゲートウェイを共有するコンセプトのため、送信元ゾーンは'any'と設定します。以下は内部ホストの送信元アドレスを外部IPアドレスに変換するシンプルな隠蔽NATの例です。 テストのため、 WORK_192とHOME_10からインターネットへ向かうトラフィックを生成し、トラフィックログで観察してください（[Monitor] > [ログ] > [トラフィック]）。   パート2：仮想システム間通信 仮想システム間通信のコンセプトは共有ゲートウェイのセットアップと似ています。それらの仮想システムは互いに通信できる必要があり、個々の外部ゾーンの設定とそのトラフィックを許可するポリシーが必要です。 仮想システム間通信のためには  HOME_10ゾーンはWORK_192に、またその逆も到達できる必要があります。そのため2つの外部ゾーンと、ゾーン間のトラフィックを制御するポリシーの設定が必要です。ゾーンを設定するにはNetworkタブに移動し、ゾーンを選択します。 すべての共有ゲートウェイと仮想システム間通信のためのすべてのゾーンの一覧です。 ポリシーを設定する際は、ゾーン間の通信を許可するルールを作成します。 これでHome-to-Work とWork-to-Home 外部ゾーンが、ともに有効に働きます。これらのゾーンのホスト間のトラフィックは外部ゾーンを経由のために使い、従ってポリシーを設定する必要があります。 ポリシーを設定するには[Policies] > [セキュリティ]に移動します。 ポリシーを設定したい仮想システムを選ぶようにしてください。 テストのため、 WORK_192とHOME_10のホストから相手のゾーンへ向かうトラフィックを生成し、トラフィックログで観察してください（[Monitor] > [ログ] > [トラフィック]）。   著者：jhess  

※この記事は以下の記事の日本語訳です。 Unable to Connect to or Ping a Firewall Interface https://live.paloaltonetworks.com/t5/Management-Articles/Unable-to-Connect-to-or-Ping-a-Firewall-Interface/ta-p/62505     問題 あるサービスを利用するために、ファイアウォールのインターフェイスのIPアドレスに接続しようとした際に、あるいはそのインターフェイスにPingしようとした際に、その通信が失敗してしまう。HTTPSやSSHでデバイスを管理しようとしたり、GlobalProtect ポータルやNetConnect webポータルに接続しようとしたり、あるいは単にインターフェイスにPingしようとしているだけでも起きる可能性があります。   解決方法 インターフェイスが必要なサービスを有効にしたり、接続元からのIPアドレスを許可する適切な管理プロファイルを持っていることを確認します。 管理プロファイルが疑われる場合、以下の"counter"コマンドを実行し、"counter"の増加を確認します： > show counter global name flow_host_service_deny トラフィック ログを確認することにより、インターフェイスに向かうトラフィックをブロックしているセキュリティ ポリシーがないことを確認します。宛先アドレスにファイアウォールのインターフェイスのIPアドレスとなるようにフィルタ対象となるように設定をします。一般的に、セキュリティ ポリシーは接続をブロックしませんが、ブロックしてしまう可能性はあります。 パケットが到達するインターフェイスが、開始パケットがファイアウォールに入っていくインターフェイスと異なり、それら2つのインターフェイスが異なるゾーンにある場合、それはインター ゾーン（ゾーン間）のセッションだと考えられるため、そのセッションを許可するセキュリティ ポリシーが必要です。 パケットが到達するインターフェイスが、開始パケットがファイアウォールに入っていくインターフェイスと同じ場合、それはイントラ ゾーンのセッションだと考えられ、イントラ ゾーン（ゾーン内）のセッションはデフォルトで許可されているので、セキュリティ ポリシーは必要ありません。しかし、明示的に定義された"deny any to any zone"のセキュリティ ポリシーがあると、デフォルトの許可を上書きしてしまいます。そのため、ファイアウォールのインターフェイスに対して初期化セッションを許可する、より明確なポリシーを保持する必要があります。 注：インターフェイスのセッションのログが何も観測されていない場合、デフォルトのアクションがインター ゾーンやイントラ ゾーンのセッションで取られている時、拒否、許可のどちらについても、トラフィック ログは生成されない動作によることが考えられます。 問題がまだ解決できない場合は別の可能性として、送信元NATで開始パケットの送信元アドレスを、パケットが到達するインターフェイスのアドレスへ変換していることが考えられます。これはファイアウォールに、パケット処理の早い段階でのパケットのドロップを引き起こします。なぜならアドレス変換後にそのパケットは、送信元と宛先が同じとなるLAND攻撃のように見えてしまうからです。 これは外部インターフェイスと検証機が内部ネットワークにあり、GlobalProtectポータルへの接続を検証している時によく見られる振る舞いです。開始パケットは外部ゾーンにアクセスするための送信元NATによって外部インターフェイスに変換されてしまいます。 ログ プロセスの前にこの仕組みが動き出すため、この場合はトラフィックのログは何も見られません。 以下のコマンドを入力して、これが問題なのかどうかを確認するためにカウンタの増加分を確認します： > show counter global name flow_policy_nat_land この問題を解決するために、原因となるNATポリシーのクローンを作成し、[送信元アドレスの変換]を"none"に変更し、[宛先アドレス]を該当のインターフェイスのIPアドレスに変更します。そして問題のNATポリシーの直上に新しいポリシーを置きます。この措置により、宛先が該当インターフェイスの場合のみ、新しいNATポリシーが適用されます。 NATポリシーによって引き起こされる別の問題は、宛先NATが、サーバーのアドレスに向かう該当のインターフェイスのアドレスを宛先アドレスを持つパケットを、変換する場合です。一般的にこの宛先NATは、外部インターフェイスのパブリックなIPアドレスを含みます。この問題を引き起こす可能性のあるNATの設定は2つ考えられます。 宛先NATをすべてのサービスのために設定している場合、該当するインターフェイスの宛先アドレスを持ちNATポリシーに該当するパケットはすべて変換されます。たとえその意図がリモート ホストではなく、該当インターフェイスにパケットを到達させるためであったとしてもです。以下の方法で、この問題を解決できる可能性があります： サーバーが特定のサービス、あるいはファイアウォールのインターフェイスに届く必要のあるポートとは異なるポートを使用する場合、必要なサービスだけを変換してサーバーへ転送するために、NATポリシーの適用範囲を狭くします。 その宛先NAT用に特定のサービスが指定して、それらのサービスの宛先ポートに合致するパケットだけが宛先変換されますが、443番ポートの変換を例として挙げると、宛先NATポリシーに合致するパケットであるからといって、ファイアウォールのインターフェイスの443番ポートへ接続されることはありません。以下の方法で、この問題を解決できる可能性があります： 利用可能なアドレスがある場合、別のアドレスをファイアウォールのインターフェイスに追加します。同じサブネット内にアドレスを追加する場合、そのサブネット マスクは"/32"である必要があります。 ファイアウォールのインターフェイスのアドレスは変更するか、サーバーのアドレスを変更するべきです。 上記の選択肢のどちらも相応しいアクションでない場合、問題は、サービスが提供されるために十分なパブリックなアドレスを持っていないことである可能性があります。より手の掛かる解決策ではありますが、パブリックなアドレスを追加で入手する必要があるかもしれないということです。 上記の解決方法でも問題を解決できない場合、通信を開始するコンピュータとファイアウォールのインターフェイス間において、ネットワーク上のルートを確認する価値は大いにあります。他のコンピュータがファイアウォールに接続できるかどうかを確認します。必要に応じて、開始パケットがファイアウォールに届いているかどうかを確認するために、ファイアウォール上でパケット キャプチャをします。   Trustゾーンのホストが、外部インターフェイスのIPアドレスへの接続を防ぐ送信元NATの例： インターネットからの外部インターフェイスのIPアドレスへのすべての接続を防ぐ宛先NATの例：   注：この解決方法は、ファイアウォールの管理インターフェイスには適用されません。     著者：astanton

※この記事は以下の記事の日本語訳です。 How to Configure Symmetric Return https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-Symmetric-Return/ta-p/59374     概要 このドキュメントは PAN-OS 5.0 でのシンメトリック リターンの簡易的な設定方法について記載します。   詳細 この機能は S2C フローの戻りパケットを最初の SYN を発信した MAC アドレスに向かって送出します。 これにより戻りのトラフィックはセッションが作られたインターフェースを使うので非対称ルーティングやデュアル ISP の環境には有効的です。   例：トポロジー 上記の図では、クライアントの 5.1.1.1 からインターナルサーバー 192.168.83.2 へは二つのパブリック IP 1.1.1.83 と 2.1.1.83 を使って通信できます。 この両方の IP は 宛先 NAT でインターナルサーバー IPの 192.168.83.2 へ変換されます。 ISP1 の Ethernet 1/1 にインターナルサーバー向けの通信が来た場合、シンメトリックリターンが設定されていると下記の図のように戻りトラフィックはデフォルトルートの Etherenet 1/2 ではなく Ethernet 1/1 を使います。   NAT INCOMING_NAT-ISP-1 と INCOMING_NAT-ISP-2 のルールはインターナルサーバー IP の 192.168.83.2 の変換用です。 ISP1NAT と ISP2NAT は ISP1 と ISP2 へのアウトバウンドトラフィック用です。   ネットワーク   ルーティング firewall上には ISP2 を宛先とするデフォルトルートが一つあります。   ポリシーベースフォワーディング (PBF) シンメトリックリターンの作成はポリシーベースフォワーディングの設定内でおこないます。 サーバー宛トラフィック用の PBF ルールを作成します。 シンメトリックリターン機能はインターフェースに基づくもののため Source Type で Interface を選択します。   追記：Zoneでの設定はできません。なお、Tunnel インターフェースも MAC アドレスが無いため使用できません。   Destination IP address をサーバーのインターナル IP アドレスに設定します。 送信先ネットワークが直接接続されてなければ Next Hop の IP アドレスに設定します。 egress interface はインターナルサーバーが同じセグメントにある為 Ethernet 1/6 に設定します。 サーバーが直接接続されていなければ、サーバーのあるネットワークへの Next Hop の IP アドレスを設定します。 Enforce Symmetric return を有効にし、Next Hop Address を ISP1 (1.1.1.84) に設定します。 シンメトリックリターンが正しく動作していることを確認する場合は次のコマンドを実行します： > show session id 6149 Session            6149           c2s flow:                 source:      5.1.1.1 [DMZ]                 dst:         1.1.1.83                 proto:       1                 sport:       13812           dport:      3                 state:       INIT            type:       FLOW                 src user:    unknown                 dst user:    unknown                 pbf rule:    ISP1-PBF 1           s2c flow:                 source:      192.168.83.2 [L3-Trust]                 dst:         5.1.1.1                 proto:       1                 sport:       3               dport:      13812                 state:       INIT            type:       FLOW                 src user:    unknown                 dst user:    unknown                 pbf rule:    ISP1-PBF 1                 symmetric return mac: 00:1b:17:05:8c:10           start time                    : Tue Jan  8 16:23:55 2013         timeout                       : 6 sec         total byte count(c2s)         : 98         total byte count(s2c)         : 98         layer7 packet count(c2s)      : 1         layer7 packet count(s2c)      : 1         vsys                          : vsys1         application                   : ping         rule                          : all         session to be logged at end   : True         session in session ager       : False         session synced from HA peer   : False         address/port translation      : source + destination         nat-rule                      : INCOMING_NAT-ISP-1(vsys1)         layer7 processing             : enabled         URL filtering enabled         : False      作成された PBF ルールにマッチしていることがわかります。   （訳注： シンメトリックリターンが設定された PBF ルールにマッチしていた場合、S2C flow に宛先 MAC が表示されます。） 下記のコマンド出力から戻りのトラフィックがどこに送られているのか調べることができます。   > show pbf return-mac all   current pbf configuation version:   0 total return nexthop addresses :    8   index   pbf id  ver  hw address          ip address                      return mac          egress port -------------------------------------------------- ------------------------------ 7       1       2    00:1b:17:05:8c:10   1.1.1.84                      00:1b:17:05:8c:10   ethernet1/1   2       1       0    00:00:00:00:00:00   1.1.1.84                      00:1b:17:05:8c:10   ethernet1/1   6       1       1    00:1b:17:05:8c:10   1.1.1.84                      00:1b:17:05:8c:10   ethernet1/1   8       1       2    00:00:00:00:00:00   1.1.1.84                      00:1b:17:05:8c:10   ethernet1/1   5       1       1    00:00:00:00:00:00   1.1.1.84                      00:1b:17:05:8c:10   ethernet1/1   9       1       3    00:1b:17:05:8c:10   1.1.1.84                      00:1b:17:05:8c:10   ethernet1/1   1       1       0    00:1b:17:05:8c:10   1.1.1.84                      00:1b:17:05:8c:10   ethernet1/1   10      1       3    00:00:00:00:00:00   1.1.1.84                      00:1b:17:05:8c:10   ethernet1/1   maximum of ipv4 return mac entries supported :     500 total ipv4 return mac entries in table :           2 total ipv4 return mac entries shown :              2 status: s - static, c - complete, e - expiring, i - incomplete   pbf rule        id   ip address      hw address        port         status   ttl -------------------------------------------------- ------------------------------ ISP1-PBF        1    1.1.1.84        00:1b:17:05:8c:10 ethernet1/1    s      1603 ISP1-PBF        1    5.1.1.1         00:1b:17:05:8c:10 ethernet1/1    c      1800           session via syn-cookies       : False         session terminated on host    : False         session traverses tunnel      : False         captive portal session        : False         ingress interface             : ethernet1/1         egress interface              : ethernet1/6         session QoS rule              : N/A (class 4)   著者：sdurga

※この記事は以下の記事の日本語訳です。 How to Display Interface MAC Addresses https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Display-Interface-MAC-Addresses/ta-p/61225   概要 このドキュメントではインターフェイスの MAC アドレスを表示する方法ついて記述しています。   詳細 以下のコマンドを実行することで HA クラスターを含むファイアウォール上のインターフェイスのMACアドレスを表示できます。 例えばファイアウォール上の全てのインターフェイスの MAC アドレスを表示する場合、次のコマンドを実行します： > show interface all total configured hardware interfaces: 15 name                    id    speed/duplex/state        mac address -------------------------------------------------- ----------------------------- ethernet1/1             16    1000/full/up              00:1b:17:05:2c:10 ethernet1/2             17    1000/full/up              00:1b:17:05:2c:11 ethernet1/3             18    unknown/unknown/down      00:1b:17:00:0b:12 ethernet1/4             19    unknown/unknown/down      00:1b:17:00:0b:13 ethernet1/5             20    1000/full/up              00:1b:17:00:0b:14 ethernet1/6             21    1000/full/up              00:1b:17:00:0b:15 ethernet1/7             22    unknown/unknown/down      00:1b:17:00:0b:16 ethernet1/8             23    100/full/up               00:1b:17:00:0b:17 ethernet1/9             24    100/full/up               00:1b:17:00:0b:18 ethernet1/10            25    100/full/up               00:1b:17:00:0b:19 ethernet1/11            26    unknown/unknown/down      00:1b:17:00:0b:1a ethernet1/12            27    unknown/unknown/down      00:1b:17:00:0b:1b vlan                    1     [n/a]/[n/a]/up            00:1b:17:00:0b:01 loopback                3     [n/a]/[n/a]/up            00:1b:17:00:0b:03 tunnel                  4     [n/a]/[n/a]/up            00:1b:17:00:0b:04   total configured logical interfaces: 21   特定のインターフェイスを表示する場合、次のコマンドを実行します： > show interface ethernet1/1   例： > show interface ethernet1/1 -------------------------------------------------- ----------------------------- Name: ethernet1/1, ID: 16 Link status:   Runtime link speed/duplex/state: 1000/full/up   Configured link speed/duplex/state: auto/auto/up MAC address:   Port MAC address 00:1b:17:05:2c:10 Operation mode: ha -------------------------------------------------- ----------------------------- Name: ethernet1/1, ID: 16 Operation mode: ha Interface IP address: 2.2.2.2/24 Interface management profile: N/A Service configured: Zone: N/A, virtual system: N/A -------------------------------------------------- ----------------------------- Physical port counters read from MAC: -------------------------------------------------- ----------------------------- rx-broadcast                  0   HA クラスターの MAC アドレスを表示する場合、次のコマンドを実行します： > show high-availability state   For example: > show high-availability state Group 1:   Local Information:     Version: 1     State: active     Priority: 200     Preemptive: False     Platform Model: PA-4050     Version information:       Build Release: 3.0.5       URL Database: 3233       Application Content: 160-463       Threat Content: 160-463       VPN Client Software: 1.0.2     Passive Hold Interval: 10 ms     Passive Link State: auto     Hello Message Interval: 1000 ms     Management IP Address: 10.30.14.7; netmask: 255.255.255.0     HA1 IP Address: 1.1.1.2; netmask: 255.255.255.0     HA1 MAC Address: 00:30:48:5d:45:f7     HA1 encryption enabled: False     HA2 MAC Address: 00:1b:17:01:18:06     Running Configuration: synchronized     State Synchronization: synchronized     Application Content Compatibility: Match     Threat Content Compatibility: Match     VPN Client Software Compatibility: Match   Peer Information:     Connection status: up     Version: 1     State: passive     Priority: 1     Preemptive: False     Platform Model: PA-4050     Version information:       Build Release: 3.0.5       URL Database: 3233       Application Content: 160-463       Threat Content: 160-463       VPN Client Software: 1.0.2     Management IP Address: 10.30.14.6     HA1 IP Address: 1.1.1.1     HA1 MAC Address: 00:30:48:5d:0c:c1     HA2 MAC Address: 00:1b:17:01:14:06   HA クラスターの L3 インターフェイスの場合、show interface all コマンドで表示される MAC アドレスは仮想 MAC になります。 仮想 MAC のフォーマットは次の様になります：00-1B-17-00-xx-yy 00-1B-17: ベンダーID 00: 固定 xx: HAグループ ID yy: インターフェイス ID   次のコマンドは Active-Active の HA クラスターの仮想 MAC と仮想 IP を表示します： > show high-availability virtual-address   例： > show high-availability virtual-address Total interfaces with virtual address configured:   2 Total virtual addresses configured:                 2 -------------------------------------------------- ------------------------------ Interface: ethernet1/1   Virtual MAC:               00:1b:17:00:05:10   Virtual MAC from the peer: 00:1b:17:00:85:10   107.204.232.53                          Active:yes    Type:floating -------------------------------------------------- ------------------------------ Interface: ethernet1/6   Virtual MAC:               00:1b:17:00:05:15   Virtual MAC from the peer: 00:1b:17:00:85:15   192.168.90.1                            Active:yes    Type:floating -------------------------------------------------- ------------------------------   次のコマンドは Active-Passive の HA クラスターの仮想 MAC を表示します： > show interface all ethernet1/5             20    1000/full/up              00:1b:17:00:0b:14   上記の例では HA グループ ID ＝ 0b (16進数) ＝ 11 (10進数)、インターフェイス ID　＝　14 (16進数) ＝ 20 (10進数) となります。     著者：gcapuno

※この記事は以下の記事の日本語訳です。 How to Configure a Layer 2 to Layer 3 Connection on the Palo Alto Networks Device https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-a-Layer-2-to-Layer-3-Connection-on-the-Palo/ta-p/52787   レイヤー2からレイヤー3へのファイアウォール上での設定 レイヤー3インターフェイスを設定し、レイヤー3ネットワークに接続します。 仮想ルーターとレイヤー3のゾーンを設定します（レイヤー3インターフェイスを仮想ルーターとゾーンに追加する）。仮想ルーターには適切なデフォルト ゲートウェイを設定していることを確認してください。 レイヤー2インターフェイスを 設定し、レイヤー2ネットワークに接続します。またそのインターフェイスを追加したレイヤー2のゾーンも作成します。 レイヤー2ネットワークと同じブロードキャスト ドメインのIPアドレスを持つVLANインターフェイスを設定します。このVLANインターフェイスは手順2と同じ仮想ルーターに入れてください。該当のVLANインターフェイス用のゾーンを作成し、作成したVLANインターフェイスを追加してください。 VLANを作成し、レイヤー2インターフェイスとVLANインターフェイスをそれに追加します。 注：PAN-OS 5.0以前ではこのVLANにてL3 転送を有効にします。 VLANインターフェイスを持つゾーンからレイヤー3インターフェイスを持つゾーンへの通信を許可するポリシーを設定します。 レイヤー3インターフェイスを持つゾーンからVLANインターフェイスを持つゾーンへの通信を許可するポリシーを設定しても構いません。 以下の図は、PCがインターネットクラウドに到達でき、またインターネットからPCへのアクセス（リモート デスクトップ）を許可するシナリオを示しています。このようにインバウンドNATルール（宛先NAT）とアウトバウンドNATルール（送信元NAT）を設定します。NATルールについては、図の下にあるスクリーン キャプチャを参照してください。 コミットを実施します。   レイヤー2からレイヤー3へ通信する環境のネットワーク概要図 Networkタブでの物理インターフェイスとVLANインターフェイスの設定（  1/3、1/9とvlan.1を使用しています ）。 必要なセキュリティーポリシー。 設定したNATポリシー。   著者：swhyte

※この記事は以下の記事の日本語訳です。 How to Configure a DHCP Relay on Palo Alto Networks Firewall  https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-a-DHCP-Relay-on-Palo-Alto-Networks-Firewall/ta-p/59544     概要 この資料では、Palo Alto Networksファイアウォールにおける、DHCPリレーを設定する手順を記載しています。下記図のシナリオを例に、設定を手順を説明します。 手順 DHCPリレーをするインターフェイスを設定します (例：Trust E1/5) ： Web UI画面から[ Network ] > [ DHCP ] > [ DHCP リレー ]を開きます。 追加をクリックし、DHCPサーバーのIPアドレスを設定します。 注：DHCPサーバーのIPアドレスは、4つまで設定することができます。 ゾーン間のDHCPトラフィックを許可するために、セキュリティ ルールを設定します： Trust to Trust - クライアント用の、DHCPリレー インターフェイスへの／からの通信 (ブロードキャスト／ユニキャスト) Trust to DMZ - DHCPリレー インターフェイス用の、DHCPサーバーへの／からの通信 (ユニキャスト) 下記のダイアグラムは、典型的なDHCPセッションに基づいています。ダイアグラムは、DHCPリレー インターフェイスとDHCPサーバー間の通信はすべてユニキャストであることを表しています。 下記のスクリーンショットは、DHCPサーバー側における、DHCP動作例のパケットキャプチャです： 下記図は、設定されているセキュリティ ポリシーの例です： コミットをクリックして、設定を反映させます。   動作確認 クライアント上での動作確認を行います。例えば、Windowsクライアントにて以下を実行します： ipconfig /release ipconfig /renew ipconfig /all 注：DHCPサーバーは、この設定が動作するように、DHCPトラフィックをPalo Alto Networksファイアウォールへルーティングする必要があります。 DHCPサーバーがPalo Alto Networksファイアウォールの代わりに他のデフォルト ゲートウェイを持っている（あるいは、DHCPサーバーが直接接続されておらず、どこかへ返信トラフィックをルーティングする）場合、問題が起きる可能性があります。その場合、DHCPトラフィックは非対照であると考えられます。DHCPサーバーのトラフィックが非対照である場合、セッションはファイアウォール上で正しく構築されず、完全なDHCP通信は完了することはありません。   著者：jlunario

※この記事は以下の記事の日本語訳です。 How to Add Exempt IP Addresses from the Threat Monitor Logs https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Add-Exempt-IP-Addresses-from-the-Threat-Monitor-Logs/ta-p/58391     概要 この資料は、特定の脅威に対して除外をするIPアドレスを追加する手段を記載します。   手順 [ Monitor ] > [ ログ ] > [ 脅威 ] を表示します。 目的の脅威名をクリックします。この脅威に対して、除外するIPアドレスが追加することになります。 セキュリティ ポリシーに関連した脆弱性ポリシーがあるかどうかを確認します。今回の例では、脆弱性プロファイル'test123'が適用されています。プロファイルのチェックボックスにチェックを入れてハイライトし、IPアドレスを下記図のように追加します。OKボタンをクリックします。 注：下記のログ中に表示されているように、IPアドレス (送信元アドレス、あるいは宛先アドレス) は被害者にも攻撃者にもなり得ます。 脆弱性防御プロファイル画面を開き、例外タブをクリックすることで、更新されていることを確認します。この画面内の"IP Address Exemptions"をクリックしてアプレットを表示し、下記図に表示されているように、変更を確認します。 "IP Address Exemptions"ダイアログ ボックスを閉じ、アクションの下に表示されている"default (reset-both)"をクリックします。アクションを許可に変更します。     著者：rkalugdan

※この記事は以下の記事の日本語訳です。 Setting a Service Route for Services to Use a Dataplane Interface from the Web UI and CLI https://live.paloaltonetworks.com/t5/Configuration-Articles/Setting-a-Service-Route-for-Services-to-Use-a-Dataplane/ta-p/59433   概要 標準ではファイアウォールはDNS、Email、Palo Alto Updates, User-ID エージェント, Syslog, Panorama 等を含む様々なサービスの通信にマネジメント インターフェイスを使用します。サービスルートを使用することでファイアウォールとサーバー間の通信についてデータプレーンを通過するように設定することができます。   詳細 Web UIでの設定 Device > セットアップ > サービス > サービス ルートの設定 へ移動し、適切なサービスルートを設定します。   以下に示すように、事前に定義されていないサービスのサービスルートを設定する場合は、宛先アドレスを手動で入力することで設定できます: 上記の例では、10.66.22.245 または 10.66.18.252 宛てのサービスルートがそれぞれ 10.66.22.88 およびマネジメント インターフェイスを送信元として設定されています。   CLI での設定 コマンドのオプションを表示するために次のコマンドを実行します。 set deviceconfig system route service : > configure # set deviceconfig system route service <tab or '?' key>   dns                DNS server(s)   email              SMTP gateway(s)   netflow            Netflow server(s)   ntp                NTP server(s)   paloalto-updates   Palo Alto update server   panorama           Panorama serve   proxy              Proxy server   radius             RADIUS server   snmp               SNMP server(s)   syslog             Syslog server(s)   uid-agent          UID agent(s   url-updates        URL update server   wildfire           WildFire service   <value>            Service name   Palo Alto Networks のアップデートを受信するためにサービスルートとして利用可能なデータプレーン インターフェイスを表示するコマンド: # set deviceconfig system route service paloalto-updates source-address   10.10.10.2/24     10.10.10.2/24   10.140.59.2/30    10.140.59.2/30   10.30.14.59       mgmt 10.30.14.59   10.30.6.59/24     10.30.6.59/24   172.15.1.2/24     172.15.1.2/24   192.168.59.1/16   192.168.59.1/16   <value>           Source IP address to use to reach destination   以下の例示コマンドでは特定のデータプレーン インターフェイスを使用する Palo Alto Networks のアップデート通信に対するサービスルートを設定しています: # set deviceconfig system route service paloalto-updates source-address 10.140.59.2/30   事前に定義されていないサービスのサービスルートはCLIを通して設定することも可能です。 例: # set deviceconfig system route destination 10.66.22.245 source-address 10.66.22.88/23   注: セキュリティ ルール ベースで通信を許可しログに記録するための明示的なポリシーが必要となります。   著者 :  pchanda

※この記事は以下の記事の日本語訳です。 RADIUS Vendor-Specific Attributes (VSA) https://live.paloaltonetworks.com/t5/Configuration-Articles/RADIUS-Vendor-Specific-Attributes-VSA/ta-p/60273   概要 この文章ではRADIUSベンダー識別子(VSA: Vendor-Specific Attributes)をPalo Alto Networks次世代ファイアウォール、Panoramaサーバーに設定する方法について記述します。Palo Alto Networks ファイアウォール機器と、Panoramaサーバー設定は基本的に同じです。 注: Palo Alto Networksはベンダーコード25461を使用します。   属性には、以下の5つがあります。 PaloAlto-Admin-Role: 属性第1 – 初期のadmin role名かcustom admin role名のいずれかです。 PaloAlto-Admin-Access-Domain: 属性第2 - Palo Alto NetworksデバイスにてマルチVsysを有効にした場合に使用します。これはDevice > Access Domainsで設定されたアクセス ドメイン名です。 PaloAlto-Panorama-Admin-Role: 属性第3 – Panoramaの初期のadmin role名かcustom admin role名のいずれかです。 PaloAlto-Panorama-Admin-Access-Domain: 属性第4 - これはPanoramaのDevice > Access Domainsで設定されたアクセス ドメイン名です。 PaloAlto-User-Group: 属性第5 – 認証プロファイルで使用するグループ名です。   RADIUSサーバが準備されていない場合、作成を完了してください。グループ情報を取り出すのはベンダー識別子（VSA）特有機能で、通常のRADIUS設定では不必要です。 認証プロファイルの作成します。RADIUS認証でログインできるユーザーをグループ名でフィルターしたい場合、追加ユーザーのAllow Listウィンドウにグループ名を入力します。この例で使われているグループ名はtestgroupです。 注: Allow Listの追加はオプショナルです。 Panorama設定 PanoramaアクセスのAdmin Role設定します。これによりユーザー アクセスがどのような権限を持っているかPanoramaに知らせることができます。 Device > Admin RoleにアクセスしAdmin Roleを作成します。このロールは、ユーザーがログインした時に正しい権限を譲渡します。この設定例では、testroleを使っています。 "デバイス グループとテンプレート" のオプションは、アクセス ドメイン中の特定のデバイスに対するアクセス許可を与えるように、必ずチェックしてください。 アクセス ドメインの設定はPanoramaにユーザーがどのような権限を持っているか知らせます。 認証プロファイルをPalo Alto Networksデバイス、もしくはPanoramaに適用する場合、Palo Alto Networksデバイスの場合は、Device > Setup > Management > Authentication Profile、Panoramaの場合は Panorama > Setup > Management > Authentication Profileに移動します。   Windows 2003: Palo Alto Networksベンダー識別子を(VSA)をWindows 2003サーバーに設定する。 想定 : RADIUSクライアントとRemote Access Policyが既に設定されていること。 既存のRemote Access Profileを編集します。 Remote AccessプロファイルのEdit Profileボタンをクリックします。 Advancedを選択し、Addをクリックします。 Vendor-Specificまでスクロールし、Addをクリックします。 次のウィンドウで、Addをクリックし必要な属性を作ります。 ベンダー識別子（Vendor-Specific Attribute）情報ウィンドウでVendorコードを選択し、25461を右側フィールドに入力します。続いて、"Yes, It conforms," を選択し、 "Configure Attribute…"をクリックします。 次のウィンドウで、このドキュメントの冒頭に説明した、ベンダー識別子番号（Vendor-assigned attribute number）を入力します。識別子のフォーマットは "String" であるべきです。識別子の値は、設定次第になります。 以下が Palo Alto Networks デバイスに設定した、ロール (testrole) の例です。   以下が、Palo Alto Networks装置のVsys (vsys1)設定例です。   以下が、Panoramaサーバーに設定した、ロール(testrole)の例です。   以下が、Panoramaサーバーに設定したアクセス ドメイン(Domain1)の例です。   以下が、Palo Alto Networks装置、Panoramaサーバーに設定したグループ(testgroup)の例です。   以下が、カスタムAdmin Role(testrole)とグループ(testgroup)を認証プロファイルでPalo Alto Networksデバイスに設定した例です。これらはこの文章の冒頭部分で設定されています。   Windows 2008ネットワーク ポリシー サーバー: Palo Alto Networksベンダー識別子(VSA)をWindows 2008サーバーに設定する。 想定: RADIUSクライアントとネットワーク ポリシーが既に設定されていること。 既存のNetwork Policiesを右クリックから編集を選択し、プロパティを選択します。 Settingsタブから、Vendor Specificを選び、Addボタンをクリックします。 Attributesボックスをスクロールダウンし、Vendor-Specificを選びます。 Addボタンをクリックします。 Vendor-Specific Attribute Informationウィンドウで、Enter Vendor Codeを選び、25461を右側フィールドに入力します（以下の図を参照）。次に"Yes, It conforms,"を選択し、"Configure Attribute…"をクリックします。 次のウィンドウで、この文章の冒頭部分で説明したようにベンダーが割当てた識別番号を入力します。識別フォーマットは "String" であるべきです。識別子の値は、設定次第です。以下の設定例では、Palo Alto Networks デバイス、Panoramaサーバーの識別子の設定が可能です。 以下が、Palo Alto Networksデバイスのロール (testrole)設定例です。   以下が、Palo Alto NetworksデバイスのVsys (vsys1)設定例です。   以下が、Panoramaサーバーのロール (testrole)設定例です。   以下が、Panoramaサーバーのアクセス ドメイン (Domain1)設定例です。   以下が、Palo Alto Networksデバイス、Panoramaサーバーのグループ(testgroup)設定例です。   以下が、カスタムAdmin Role(testrole)とグループ(testgroup)を認証プロファイルでPalo Alto Networksデバイスに設定した例です。これらはこの文章の冒頭部分で設定されています。   Cisco ACS 次にベンダー識別子（VSA）をCisco ACS 4.0 サーバーに設定します。 想定: RADIUSが設定され、Panoramaサーバー上で動作していること。   palalto.ini という名前のファイルをCisco ACS サーバーのUtilsフォルダーに作成します。   以下がiniファイルに記述するサンプル例です。 iniファイルを保存し、ACSサーバーのbinフォルダーにあるCSUtil.exeコマンドを起動して、それをACSサーバーに反映させます。 コマンド例: CSUtil.exe –addUDV 0 C:\Program Files\CiscoSecure ACS v4.0\Utils\paloalto.ini ACS サーバーにて、Interface設定ページを選び、"RADIUS (PaloAlto)"をクリックします。 使用したい識別子を選びます。以下のサンプル例ではすべてを選択しています。Submitをクリックします。 ACS Groupの識別子を編集します。testgroupというグループを作成します。 グループ設定で、以下の図のように、jump toで"RADIUS (PaloAlto)"が選択できます。 ご使用になられたいオプションを設定します。カスタムAdmin Role(testrole)とグループ(testgroup)を認証プロファイルでPanoramaサーバーに設定した例です。これらはこの文章の冒頭部分で設定されています。   参考 Configuring Cisco ACS 5.2 for use with Palo Alto Vendor Specific Attributes  (英文)   著者: rnit