ASA-5515X ファームアップデートについて

[りょうまろ]

先日セキュリティ団体より脆弱性の問題からアップデートをするようにという連絡があり

確認しているところです。

簡単な構成としてですが、ASA-5515X上に3つの仮想FWを作成して運用しているところなのですが、

本体部分で動作している部分もあります

本体実機部をアップデートした際に、再起動が必要なのですが、当然一緒に再起動が実施されると思われるのですがこの場合どの様に対処するのがいいのでしょうか？

仮想をすべアップデート→再起動待ち→本体アップデート→再起動

これが一番無難なのでしょうか？

どうぞよろしくお願いします。

[Akira Muranaka]

こんにちわ。

Multiple Contextモードをご利用かと思いますが、当モードを利用の環境で 脆弱性対応済みバージョンにアップグレードすると、その上に動作してる仮装Firewall(セキュリティコンテキスト)もすべて対応済みになります。

厳密には、Multiple Contextの場合、１つのASAソフトウェアの"上"で 管理用のスペース(システム実行スペース)や 仮想Firewall(セキュリティコンテキスト)が動作しており、それら全ての設定や管理をしてるのがASAソフトウェアです。 そのため、ベースのASAソフトウェアを脆弱性対応済みバージョンにアップグレードすれば、アップグレード時は再起動が必要なので、再起動完了後にそのシステム全体(*システム実行スペースやセキュリティコンテキスト)は脆弱性対応済みの状態になります。

[りょうまろ]

ご連絡遅れて申し訳ありません。

本体にアップデートしたら仮想も同じようにアップデートされること理解できましたありがとうございます。

本体冗長化という点お伝えするのを忘れておりましたのですが。。

activeにアップデートすれば、standbyもアップデートされると考えて良いのでしょうか？

standbyにアップデート後⇒standbyの再起動⇒フェイルオーバー⇒元activeにアップデート

⇒元active再起動⇒フェイルオーバー

こんな感じが無難な手順でしょうか。

[Akira Muranaka]

りょうまろさん、こんにちわ。

ファイルやバージョン管理は 各ASA筐体毎に行われるため、バージョンアップ実施する場合は、各ASA筐体(Primary機とSecondary機)に 任意アップグレード先のASAバージョンのイメージファイルのアップロードが必要です。

利用バージョンの指定コマンド (boot systemコマンド)と 次回起動時のバージョン指定の環境変数保存(write memory)はActive機で実行すると自動でStandby機に保存されます。 

後のアップグレード方法はりょうまろさんの方法で大丈夫ですが、Primary機もSecondary機も ミラー設定で同じように動作するため、最後の"元Active機をActiveに戻すためのフェイルオーバーの実施"をするかは、運用ポリシーや 通信構成、設定、あとはシステム管理者の方の好みなどによって変わってきます。

「運用時はPrimaryが Activeのほうが 管理しやすく 上位スイッチのスイッチング経路も最短になるので、バージョンアップ後はPrimaryをActiveに戻したい！」派の方もいれば、「ファイルオーバー回数は最小限にしたいので、Secondary/Activeのまま戻さない！ 」派の方もおり、最終決定はお好みで。 個人的には複雑なVPNを多用する環境の場合は ClientlessVPNなどフェイルオーバーで引き継げない通信もあるので後者、FirewallやNATとしてシンプルなASA利用の場合は フェイルオーバー時の通信影響も殆どないので 前者の選択でいいのかなぁ、とおもいます。

[りょうまろ]

丁寧にご回答いただきましてありがとうございます。

Active、Standbyと申し上げおりますが、実際にはStandby状態の機器には、ログインができません。

Activeに障害が起こらないとStandbyには接続ができないようです。

これがsingleモードでなくMultiple Contextモードの意味なのでしょうか。

この状態だとアクセスができるActiveでアップデートを実施するとアップデートがされ、

フェイルオーバーでなく機器の再起動のみが必要になるということなのでしょうか。

すいませんがご回答よろしくお願いします。

[Akira Muranaka]

りょうまろさん、こんばんわ。

Standbyに接続できないというのは、恐らく、ASAの問題ではなく、中継の経路機器のRoutingやACLの設定などの影響で、Active機のIPアドレスにしか管理アクセスができないのが原因ではないでしょうか。 もしくは、Standby(Secondary)機側でRSAキーを生成してない、や、管理上のアクセス制限、など。 仮に管理者権限をお持ちの場合は、運用上 不便かと思いますので、Standby IPにも管理アクセス可能にして頂くといいのかな、と思います。 もしくは、コンソールケーブルをASAに接続すれば、両方操作できるかと思います。

なお、Standby機から外部へのIP到達性が無い場合、アップグレードファイルは ActiveとStandbyに別々にアップロード必要なので、Standby機へのアップグレード用のファイルの アップロード or ダウンロードも難しくなってしまいます。 

ちなみに、failover exec mate コマンドを実行すれば、Active機から Standby機のコマンド確認や再起動も可能です。 以下ドキュメントも参考になるかと思います。

https://supportforums.cisco.com/t5/-/-/ta-p/3164093

[りょうまろ]

>Standbyに接続できないというのは、恐らく、ASAの問題ではなく、中継の経路機器のRoutingやACLの設定などの影響で、Active機のIPアドレスにしか管理アクセスができないのが原因ではないでしょうか。 もしくは、Standby(Secondary)機側でRSAキーを生成してない、や、管理上のアクセス制限、など。 仮に管理者権限をお持ちの場合は、運用上 不便かと思いますので、Standby IPにも管理アクセス可能にして頂くといいのかな、と思います。 もしくは、コンソールケーブルをASAに接続すれば、両方操作できるかと思います。

→ありがとうございます。最もであります。

今後の検討としては行いたいと考えますが、現状でStandbyに接続ができない状態で行うとすれば

Activeでアップデートを実施し、再起動(フェイルオーバー含む動き？)→フェイルオーバーしたStandyで

アップデート再起動(フェイルオーバー含む動き？)という形になるのでしょうか？

すいません何から何までうかがってるようですが、ご回答よろしくお願いします。

[Akira Muranaka · Accepted solution]

りょうまろさん、こんにちわ。

残念ながら、Standby機にIP到達性がない場合、そもそもStandby機にアップグレード用のファイルもアップロードできませんので、アップグレードを実施する以前の状態です。 一度構成や 運用上 問題が発生していることを、設計や導入された会社さん(?)に確認いただき、Standby機にも正しくアクセス可能にしていただいたほうが良いかと思います。。もしくは、別途管理用のStandby機も操作可能な端末やIPがある場合は、そこから操作をしていただければいいのかなと思います。