キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 
cancel
4027
閲覧回数
20
いいね!
1
コメント
Takuya Yasumi
Level 1
Level 1

 

─────────────────────────────

2022年4月 追記:

Firepower System version 7.0以降でサポートする Snort 3.0 を利用することで、ポリシーデプロイ時の Snort Restartは殆ど発生しないよう改善されています。 SSLや VDBアップデート時の Snort Restartを抑えたい場合は、Firepower Syetem version 7.0以降にアップグレードをご検討ください。

─────────────────────────────

 

検知エンジンの再起動の種類と確認方法

Firepower において、検知エンジン(Snort)のプロセスの再起動には、restartまたはreloadがございます。
   restart: snortプロセスが再生成され、プロセスIDが変更されます。通信影響が発生する恐れあり
   reload: snortプロセスの再生成は行われず、プロセスIDの変更はございません。通信影響発生リスクはほぼ無し

プロセスIDが変化しているかどうかは pmtoolコマンド、もしくは topコマンドで確認できます。 設定変更直前と後で以下コマンドの出力を比較することで、プロセスIDが変わっているかどうか確認できます。 pmtoolコマンドについて詳しくは、pmtoolのご紹介 を参照してください。

admin@firepower:~$ sudo pmtool status | grep -i 'de,snort' --colour
c810308c-7ba4-11e9-a74a-fbecc485cd67-d01 (de,snort) - Running 22103
c810308c-7ba4-11e9-a74a-fbecc485cd67-d02 (de,snort) - Running 22104

仮にSnort Restartが発生した場合、以下の通り Snortプロセスの プロセスIDが変化します。設定変更前後で比較することで、Snort Restart発生有無を確認できます。

admin@firepower:~$ sudo pmtool status | grep -i 'de,snort' --colour
c810308c-7ba4-11e9-a74a-fbecc485cd67-d01 (de,snort) - Running 12742
c810308c-7ba4-11e9-a74a-fbecc485cd67-d02 (de,snort) - Running 12743

Snort restartのより詳しい確認方法は、FirePOWER: ACP 適用時の snort restart有無、及び ACP 適用開始・終了を確認する方法 を参照してください。

 

Snortの Restartの発生シナリオと影響

設定変更によりSnortが"restart"されると、バージョン 6.2.3未満を使用時は、通信断が発生する場合がございます。これはSnortがもっていたコネクションの情報が"restart"に伴う初期化処理により失われ、新しく生成されたSnortのプロセスが、それまでのコネクションを管理できないために発生します。バージョン 6.2.3以降(もしくは 6.2.0.2)を使用時は、snort preserve-connection機能のサポートにより既存コネクションは保護され通信継続可能ですが、そのRestart中の新規コネクションは保護されず通信断が発生する場合がございます。Snort restartによる影響時間は多くの場合 20~40秒ほどとなり、適用している設定や機能(IPSやURLフィルタリング、AMP、SSLポリシーなど)が多いほど長くなる傾向です。

以下に、Snort Restartを引き起こす例を紹介します。基本、Snort動作の大きな変更が発生する際、Snort Restartは発生します。

1.  Firepower Management Center(FMC)のアップデート後にAccess Control Policy (ACP)を適用したとき (FMCのアップデートによりSnortのバージョンが更新された場合)

2.  (Firepower System version 6.3未満の場合) Shared object ruleを含むsnort ruleをインポートした後にACPを適用したとき (詳しくはコチラ)

3.  VDB をアップデートしたとき 

4.  デバイスのインターフェイスの設定を変更し、その設定変更を適用するとき

5.  ファイルポリシーで マルウェアクラウドルックアップや ブロックマルウェアで Spero分析やローカルマルウェア分析、ダイナミック分析 もしくは ストアファイル、Inspect Archivesを有効化したポリシーを初回デプロイ、もしくは 削除したとき

6. ”Inspect traffic during policy apply”の無効化、もしくは 有効化したとき

Snort Restartを引き起こすシナリオは 利用バージョンや製品により異なることがありますため、より詳しくは ご利用バージョンの 設定ガイドの Snort Restart Scenariosを確認してください。 例えば 以下は Firepower System Version 6.2.3の Snort Restart ScenariosのURLです。

https://www.cisco.com/c/en/us/td/docs/security/firepower/623/configuration/guide/fpmc-config-guide-v623/policy_management.html#concept_33516C5D6B574B6888B1A05F956ABDF9

 

Snortの Reloadの発生シナリオと影響

通常のACP変更の適用時(つまり大部分の設定変更)や、Shared object ruleを含まないsnort ruleをインポート時、セキュリティインテリジェンスのWhite/Blacklist変更時などはSnortの"reload"が行われますが、こちらについてはコネクションの情報などが保持されるため、以下のデフォルト設定が有効のままであれば、ACPの適用中のコネクション断は発生せず、通信影響も基本発生しません()。設定適用は既存のSnortプロセス内で高速に適用されるためです。 (※高負荷環境などでは Snortプロセス内の切り替え処理による影響で僅かなパケットドロップが発生することがあります。ただ、アプリケーション通信ではドロップされたパケットは通常再送されるため 高負荷環境であっても通信影響となることは基本稀です。)

[デフォルト有効設定の確認方法]
Policies > Access Control > 該当のポリシーの編集アイコンをクリック > Advancedタブ と進み ”Inspect traffic during policy apply”有効かを確認。 当設定がYes(デフォルト)の場合、ポリシー適用時の通信影響を最大限 回避可能
snort-reload.JPG

   

ベストプラクティス

設定デプロイ時の通信影響有無の事前確認方法 (6.2.3+)

Firepower System バージョン 6.2.3以降、かつ FTDを利用の場合、デプロイ時に Inspect Interruption欄をチェックすることで、その設定デプロイにより通信影響が発生するかの目安にすることができます。Inspect Interruption欄が Yesの場合は通信影響発生懸念が、Noの場合は影響発生懸念が基本ない(※厳密にはセッションは保護されますが 負荷状況により瞬断レベルのパケットドロップが発生することはありますが 極わずかなパケットドロップは通常ネットワークでは通信影響は基本 無視できます)ことを確認できます。 Yesの場合は、設定変更リストを開き 通信影響を引き起こす設定個所を確認し、デプロイを一旦キャンセルし 問題のある設定変更を取り除くことで 影響発生リスクを下げる事も可能です。 当機能について詳しくは、Restart Warnings for Firepower Threat Defense Devices を参照してください。

[通信影響発生懸念が基本ない場合]
Risk.JPG

[通信影響発生懸念のある場合]    
Inspect-Interruption-Yes.JPG

 

信頼できる新規コネクションのRestart時の通信影響からの保護 (FTDのみ)

FTD利用時の場合、例えば 信頼された送信元と宛先の監視用のPING通信や、暗号化されており詳細検査が困難なVPN通信は、PrefilterのFastpathに指定することで、L3/L4レベルでの通信許可が可能となり、Snort Restart発生時の通信影響も回避できます。Prefilter機能について詳しくは以下ドキュメントを参照してください。

FTD: Prefilterの役割と設定と動作確認

FTDを経由するICMP通信の、Snort検査を行わない許可方法 (Prefilter)

 

設定デプロイの推奨時間帯とスケジューリング機能

上述の通り 設定デプロイ内容によって通信影響は異なり ある程度予測が可能ですが、シスコでは 設定デプロイは メンテナンスタイム、もしくは 通信影響の少ない 時間帯(お昼休みや 夜間、休日など)に実施を推奨しています。 

スケジューリング機能を利用することで 任意時間帯での設定デプロイも可能です。スケジューリング機能について詳しくは以下ドキュメントなどを参照してください。

FirePOWER: Scheduling機能の活用例 (URL DBや VDBの自動更新 等)

  

参考情報

Firepower System / Firepower Threat Defense (FTD) トラブルシューティング
https://community.cisco.com/t5/-/-/ta-p/3161733

コメント
Taisuke Nakamura
Cisco Employee
Cisco Employee

Firepower System 6.2.3以降の情報も含め 加筆・修正をしました。

Getting Started

検索バーにキーワード、フレーズ、または質問を入力し、お探しのものを見つけましょう

シスコ コミュニティをいち早く使いこなしていただけるよう役立つリンクをまとめました。みなさんのジャーニーがより良いものとなるようお手伝いします