Cisco Japan Blog

新機能満載の Cisco Firepower 6.3.0 をリリースしました その2

1 min read



NGIPS / NGFW / Anti-Malware である Cisco Firepower のソフトウェアバージョン 6.3.0 がリリースされました。前回に引き続き、今回も以下の新機能について、わかりやすく解説します。

  • エアギャップ環境でのライセンス
  • Snort プロセス再起動が必要なケースの削減
  • FTD デバイス設定のバックアップ & リストア

 

エアギャップ環境でのライセンス

Firepower Threat Defense(FTD)は、Cisco Smart License によるライセンス管理が行われています。Firepower Management Center(FMC)や FTD 自身が、インターネットを介して Cisco Smart Software Manager(CSSM)にアクセスするという仕組みです。これには、適切なライセンスが自動的に割り当てられ、障害時の機器交換におけるライセンスの再発行をご自身でスムーズに行っていただけるというメリットもあります。

しかしながら、初期インストール時のほか、定期的に FMC や FTD から CSSM へのアクセスが必要なため、NAT / PAT / Proxy / CSSM サテライト サーバといった補助機能を使っても、ポリシーとして FMC や FTD からインターネットに接続することは許されない、という環境(エアギャップ環境)には、この Smart License の仕組みが使えない、という問題がありました。

この問題を解決する仕組みが、FMC 利用時に限られますが、バージョン 6.3.0 より導入された「License Reservation」という機能です。これは、事前に当社の専門チームから承認を得た Smart Account を利用することで、FMC からインターネットを介して CSSM に接続しなくても、Smart License を利用できるようになるというものです。

License Reservation には、以下の 2 種類があります。

  • UPLR – Universal Permanent License Reservation
    全機能が利用可能になります。利用については厳密な審査が行われます。
  • SLR – Specific License Reservation
    機能を選択して利用可能にできます。UPLR ほど厳密ではありませんが、事前に申請が必要です。

具体的なイメージは以下の通りです。機器管理者は、UPLR か SLR を有効にした FMC(エアギャップ環境にある FMC)からリクエスト コードを取得し、インターネットに繋がる環境でそのリクエスト コードを CSSM に登録します。これで CSSM から承認コードを取得できますので、対象の FMC に繋がる環境で承認コードをその FMC に登録します。このオペレーションにより、FMC からはインターネットの先にある CSSM に一切アクセスすることなく、Smart License を利用できます。

License Reservation について、いくつか注意点をまとめておきます。

  • Firepower Device Manager(FDM)での管理、すなわち OnBox での FTD 管理を行っている場合、この方法は利用できません。
  • UPLR や SLR を利用するからといって、Smart Account の利用そのものがなくなるわけではありません。あくまでも FMC からの CSSM への接続を行わず、初期設定時に機器管理者がマニュアルで Smart License を利用できるようにするための機能です。
  • License Reservation はすべてのお客様に適しているわけではありません。FMC からインターネットに直接、あるいは NAT や PAT、Proxy 経由でアクセス可能なお客様は、従来の方法での Smart License の利用をお願いします。

そもそも、FMC がエアギャップ環境にあるということは、Advanced Malware Protection (AMP) for Network の際に Cloud Lookup ができなかったり、Snort Rule Update や Security Intelligence の自動更新もできない環境ということになるため、それほど多いパターンではないものと思われます。

 

Snort プロセス再起動が必要なケースの削減

Firepower は、ポリシーのデプロイ時に Snort のプロセスが再起動されることがあり、その際に、トラフィック断やバイパス(セキュリティチェックを行わずにトラフィックを通すこと)が発生する、と思われている方がいらっしゃるかもしれません。

Firepower は、ソフトウェア バージョンアップのたびに、できるだけ Snort プロセスの再起動が発生することがないよう、アーキテクチャの改善を重ねてきました。直近のバージョン 6.2.3 でも、Snort プロセスの再起動が行われるケースはかなり少なくなっていました。

今回のバージョン 6.3.0 において、新たに以下のケースでも、Snort プロセス再起動が発生しなくなるように、さらにアーキテクチャを改善しました。

  • バイナリ更新も含めた全ての Snort Rule アップデートのデプロイ
  • Vulnerability Database(VDB)アップデートの FMC へのインストール (FTD へのデプロイ時には Snort プロセス再起動が発生)

特に前者については、IPS 利用時には定期的に発生するタスクであるが故に、Snort プロセス再起動が不要となったという改善の意味は大きいと思われます。

バージョン 6.3.0 において、Snort プロセス再起動が発生するケースは、CPU 過負荷時という例外ケースを除き、初期設定時や不定期に発生する設定変更の一部だけになりました。また、FTD の冗長構成の作成および破棄の際も、Snort プロセス再起動が発生するケースに含まれます。ただし、後述の FTD デバイス設定のバックアップ & リストア機能を使うことで、障害が発生した FTD デバイスの機器交換時に “冗長構成の破棄” を行わなくて済むため、Snort プロセス再起動を避けることができます。

 

FTD デバイス設定のバックアップ & リストア

FMC で管理された FTD デバイスの場合、セキュリティ ポリシー、例えば、Intrusion Policy や Access Control Policy は FMC に保存されていますが、FTD 自身のインターフェイスやルーティングの設定は、FMC ではなくその FTD 自身に保存されています。そのため、バージョン 6.2.3 までは、FTD デバイス交換後にこれらの情報をリストアする手段がなく、障害発生時の機器交換作業が課題でした。FTD デバイス交換後にその FTD デバイスを FMC に再度ジョインさせた後に、マニュアルでこれらの設定を戻したり、あるいは API を使って設定を再度適用する必要があったからです。

バージョン 6.3.0 では、FMC に FTD デバイス設定をバックアップ & リストアする機能が新たに追加されました。これで、FMC に登録されている FTD の設定のバックアップ アーカイブを取得できるようになり、FTD の機器交換の際、バックアップ アーカイブ データを新たな FTD デバイスにリストアできるようになりました。リストア後の FTD デバイスは自動的に FMC に再接続されます。

これらの手順により、FTD デバイスに障害が発生した際、FMC からは一時的にその FTD デバイスがオフラインになり、その後、同じ FTD デバイスが再びオンラインになっただけのように見えます。実際にはその間に機器管理者が FTD デバイスを交換し、バックアップアーカイブデータをリストアするという作業を行っています。

この機能の大きな特長は、FTD の冗長構成にも対応している、ということです。冗長構成の FTD のバックアップ アーカイブ データを取得して保管しておけば、障害が発生した FTD デバイスを交換 & バックアップ アーカイブ データのリストアを行っても、FTD の冗長構成を破棄することなく、FMC にその FTD デバイスを戻すことができます。つまり、Snort プロセス再起動を避けることができるわけです。

FTD デバイス設定のバックアップ & リストアは以下の条件があります。

  • クラスタは未サポート。スタンドアロンか冗長構成のみ
  • パブリック クラウド版の FTDv は未サポート
  • マルチインスタンスの FTD は未サポート
  • Firepower 9300 / 4100 シリーズの Firepower eXtensible OS(FXOS)の設定部分は別オペレーションが必要
  • リストア先の FTD デバイスは、バックアップ アーカイブ データを取得した FTD デバイスと、ハードウェア モデル、ソフトウェア バージョン、VDB バージョンを合わせる必要がある
  • FTD デバイスのリストア後に、FlexConfig や VPN 設定の一部は、マニュアルでの再設定が必要。その場合には FMC にて警告が表示される
  • FTD デバイスのリストア後には、証明書の再エンロールメントが必要

今回は、バージョン 6.3.0 に実装された新機能の中から、特に日本のお客様やパートナー様から多く寄せられた機能改善要求をピックアップして解説しました。次回は FDM での機能拡張や VPN 周りの新機能等、残りの新機能で特にお伝えしたい内容を解説します。

 

P.S. 2019年12月現在、シスコの推奨バージョンは 6.4.0 系に移行しています。

Authors

小林 達哉

テクニカル ソリューションズ アーキテクト

セキュリティ事業

コメントを書く