WLC5520以降のライセンス追加手順
WLC5520以降ではWLC5508シリーズと違いライセンス追加手順が大きく変更になっています。WLC5508ではライセンスファイル(.lic) をTFTP サーバ等でWLCにインストールしていたの対して、WLC5520以降ではRTUライセンスを適用します。
WLC5520以降のライセンス適用手順を以下に記載します。
「Management」 →「 Software Activation」→ 「 Licenses」を押下し、「Adder License」 の「License Count」に追加するライセンス数を入力します。
「Set Count」をクリックすると下記のように再起動を促されますが、再起動は不要です。
その後、EULAが表示されるため、「I Accept」を押下します。
ライセンスが追加されたことを確認後、最後に「Save config」をして保存すれば完了です。
このようにWLC5520以降のライセンス追加は紳士協定となりますが、ライセンスを購入しないといざというときにサポートが受けられなくなるため注意してください。また、Virtual WLC , 5520 , Flex7500 , 8510 , 8540, 3504も同様の手順となります。
Fortigate HA構成 Slave機の時刻同期について
FortigateでHA構成を組んだ場合、Slave系のntpについて注意する必要があります。
NTPサーバとの接続性に問題ない場合、Master機では時刻同期について特に悩むことはないと思われますが、Master機で時刻同期できるNTPサーバに対して、Slave機では以下のように時刻同期できていないような実行結果を得てしまいます。
Fortigate#diagnose sys ntp status
synchronized: no ntpsync: enabled, server-mode: disabled
まず前提としてFortigateをHA構成で組んだ場合、Slave機の時刻同期先はMaster機となります。さらに、Slave側では明示的に時刻同期が行われている旨を示すコマンドや機能はありません。
上記から、Slave機での時刻同期確認は以下の2パターンのどちらかで実施する必要があります。
- 両機の[WebUI] ー [ダッシュボード] ー [システム情報(ウィジェット)] ー [システム時間]を確認して比較する。
- 両機のCLIで[config glonbal] - [execute time]コマンドを実行して比較する。
default interfaceコマンドを実施する際の注意点
Cisco機器のdefault interfaceコマンドは該当インターフェースの設定値を初期化してくれるため、特定のインターフェースの設定をクリーニングするのに便利なコマンドです。
Test(config)#default interface x/x
しかし、このコマンドを実施する際には注意が必要です。
まずSwitch Portはデフォルトで有効化(no shutdown状態)のため、shutdownコマンドも消えてしまい、想定外のリンクアップが発生する可能性があります。Routed Portの場合はデフォルトで無効化（shutdown状態）のため、shutdownコマンドはdefault interfaceコマンドの影響を受けません。
ではshutdownコマンドが消えることでどのような影響があるかというと、先ほど記載した想定外のリンクアップによりルーティングテーブルに余計なエントリーが浮上する可能性があります。また、１番気にしないといけないのはVlan1のSTPが有効な場合、BPDUを送信してしまい、例えば対抗機器でBPDU Guardが設定されているとerror-disableとなってしまいます。こうなってしまうとshutdown no shutdownコマンドを実行せねばならず、対抗機器が管理対象ですぐにコマンドを実行出来れば問題ありませんが、管理者に調整が必要な場合、余計な手間と時間を取らせる可能性があります。
このような理由からdefault interfaceコマンドを実行する場合は、対象ポートに物理的にケーブルが接続されていないことを事前に確認することが望ましいです。
また、運用上実施する場合はケーブルが接続されていないことを確認したうえで、shutdownコマンドと併用する習慣をつけていったほうが良いと思われます。
Test(config)#default interface x/x
Test(config)#interface x/x
Test(config-if)#shutdown
Fortigate HA構成 Slave系へのログイン
HA構成を組んだFortigateではMasterからSlaveにログインすることが可能です。この手法を使えば、仮にSlave系の管理IPを間違えて設定しまい、Slave系に直接ログインできない状態であってもMaster系からログインが可能です。
# execute ha manage [?]
[？] キーを入力すると HA メンバーの Index が 表示されます。
この時表示されたメンバーのインデックスを入力し、Standby にログインします。
(例) Fortigate-master# execute ha manage
please input peer box index.
<1> Subsidary unit FG100A390750xxxx
fortigate-master# execute ha manage 1
fortigate-slave$ ←Slave 機のホスト名が表示されれば成功です。
「exit」と入力することで Slave 機からログアウトすることができます。
当然ですがHA構成が組めていなければ実施できません、しかしFortigateでHA構成を組む場合は管理IPのコンフィグ同期は除外することが可能なため、管理IPを間違って設定してしまってもHA構成が崩れることはないと思います。
Static Routeのnext-hopにVlan Interface(SVI)を入れる理由
Static Routeのnext-hopについて、Vlan Interfaceを入れる理由の1つを教えてもらったので備忘録として残しておきます。
Static Routeを設定する際に、以下のようにVlanを設定してもしなくても、結果としては同じようにルーティング設定は実現できます。
(1) Switch(config)#ip route 0.0.0.0 0.0.0.0 172.16.0.254
(2) Switch(config)#ip route 0.0.0.0 0.0.0.0 172.16.0.254 Vlan255
同じ動作を実現出来るのに末尾にVlan-IDを入れる理由は、該当のVlan Interfaceを停止した際に、ルーティングテーブルから削除されるかどうかです。
勿論(1)の設定であっても、next-hopに到達性のあるSVI(本例では仮にVlan255)をshutdownすればルーティングテーブルから削除されますが、ダイナミックルーティングにより、next-hopまでの到達性が確保されてしまえば、(1）のルーティングは再度浮上してきます。上記から、(1)の設定ではルーティングの移行作業などでSVIをshutdownするだけでは不十分になってしまうことがあるため、Static Routeのnext-hopにはVlan Interfaceを入れる癖付けをしたいと思いました。
Cisco製品におけるicmp redirectとCoPP機能の有効化時の制約
icmp redirect機能とはL3デバイスがパケットの送信元ホストに、特定の宛先ネットワークに対する最適なゲートウェイアドレスを通知する事が出来る機能です。
一般的にはセキュリティ上も有効化されることは珍しい機能ですが、デフォルトで有効になってしまっているため、無効化するのを忘れて運用されている場合があります。
＃WindowsファイアウォールでICMPをブロックしている場合はWindows端末でicmp redirect機能によるルーティングの書き換えは発生しません。
このicmp redirectとコントロール プレーン ポリシング（CoPP）機能が有効化されている場合、注意が必要です。
コントロール プレーン ポリシング（CoPP）とは、ネットワーク機器のCPUを守る機能であり、多くのネットワーク機器はデータ転送を行なう「データプレーン」とルーティングなどのソフトウェア処理を行なう「コントロールプレーン」の二階層に分かれます。
ルータが保有するIPアドレス宛のパケットや非IPはコントロールプレーンで処理されるため、上記の宛先に大量のパケットを送付すれば、ルータのCPU使用率を上昇させ、DOS攻撃が成立してしまいます。CoPPではコントロールプレーン向けのパケットを制限することでルータのCPU使用率を下げることが可能です。
このCoPPとicmp redirectを有効化しているどのような注意（弊害）があるかというとCiscoにはicmp redirectを送信出来ないと受信したパケットを処理出来ない仕様があります。つまり、icmp redirect機能を有効化することでicmp redirectメッセージの送信にコントロールプレーンの処理が行われ、CoPPによりコントロールプレーンで処理する流量を制限されます。その結果、icmp redirectメッセージの送信が一定数(CoPPの制限値）に達するとそれ以降のメッセージが送信されず、パケットも処理されなくなります。
経験則ですがicmp redirect機能が必須とされる要件はあまり見受けられず、CoPPはCPU負荷を上げないためにも無効化することは難しいため、素直にicmp redirectを無効化するほうが良いと考えています。icmp redirectは各SVIかRouted Portにて以下のコマンドで無効化出来ます。
(config-if)#no ip redirect
DNS KSKロールオーバーの実施日が確定
昨年10月に実施されず延期していたKSKロールオーバー作業が10月12日午前1時（日本時間）に決定しました。
以前も当ブログで記載しましたが、以下に当てはまる場合は注意が必要です。
- DNSSECによる署名の検証機能を有効にしたキャッシュDNSサーバーを運用している
当てはまる場合、2018年10月12日午前1時（日本時間）のルートゾーンKSKの更改後48時間以内に、未処置のキャッシュDNSサーバーを利用する者によるウェブサイトへのアクセスやメールの送信ができなくなるなどの問題が生ずる可能性があります。
DNSSECによる署名の検証機能を有効にしたキャッシュDNSサーバーについて、トラストアンカーのルートゾーンKSKの公開鍵の情報が更新されているか確認してください。
[手動更新]
BINDの場合、named.confのtrusted-keysディレクティブで鍵を指定します。
Unboundの場合、/etc/unbound/root.keyとして鍵を置きます。 またはunbound-anchorコマンドを利用して更新します。
[RFC5011による自動更新]
BINDの場合、 まずnamed.confのmanaged-keysディレクティブで現在の鍵を指定します。 そして、 作業ディレクトリ中のmanaged-keys.bindに更新後の鍵が追加されているか確認します。
Unboundの場合、 auto-trust-anchor-fileで現在の鍵を指定します。 更新後の鍵が上記ファイルに追記されるので確認します。
また、KSKロールオーバーの更新作業中に発生するDNS応答のサイズ増大に対応しているか確認が必要です。以下のサイトで5番目以外がPASSになるか確認してください。
Catalyst3850におけるHSRPのTimerについて
HSRPによる冗長構成を実施する際に、障害検知と切り替わりを迅速にするためにHSRPのTimerをデフォルト値から変更することはよくあることだと思います。
しかし、Catalyst3850シリーズにおいてShort TimerにすることでMacFlappingが起こり両Actになる場合があります。
下記ページによると以下の設定をしていると本事象が発生するようです。
#standby 1 timers 1 3
本問題に対する現時点の恒久対処は存在せず、CSCuz98375にてshort timerを設定している場合のコントロールパケットの取り扱い機能が強化されていますが、不具合修正というより機能強化の位置づけのため、short timerの動作を保証するものではないようです。
また、以下のようにCiscoの公式ページを見るとhold timerを4秒未満にすることは推奨していないようです。
PaloAlt 7.1以降へのバージョンアップ時の注意
PaloAltのPAN-OS 7.1以降ではバージョンアップに伴い特定のポリシーの動作が変更されるため、既存のポリシーが該当しているか確認が必要です。
この変更により、サービス設定 に「application-default」が設定されている場合はアプリケーションで指定したプロトコルに応じて許可されるポート番号が自動的に決まってしまいます。(DNSでれば53番など）
上記から社内用に独自のポート番号を割り当てたアプリケーションが使用不可能になる可能性があります。やっかいなことにファイアウォールのログを見てもBlockログが表示されず、切り分けが面倒です。また、設定値を確認してもapplication-defaultで定義されたポート番号一覧は表示されないため、以下のコマンドでグループごとに確認が必要です。
#show predefined application <application>
ちなみにアプリケーションに「Any」を定義した場合、PaloAlt側で通信を独自にグループ分けし、該当グループのapplication-defaultで定義されたフィルタが実施されているような気がします。。。
PaloAltのメジャーアップデートはたまにポリシーを変更を実施しないと通信影響が出るような動作変更が入ることがあるので注意が必要です。
旧シマンテック社のSSLサーバ証明書移行について
以前から話題となっている旧シマンテック社のSSLサーバ証明書について、ついに特定のブラウザにおいて無効化される期間が近づいてきました。
- Google Chrome70 (2018/09/13頃ベータ版リリース予定）
- Mozilla Firefox 63 (2018年10月23日頃にリリース予定
ブラウザによる無効化が実施された場合、該当する証明書をインストールしているサーバへのアクセスを行った際、セキュリティ警告が表示され、サーバが利用できないなどの問題が発生する可能性があります。
さらに、Apple社からも2018年秋ごろを目安にApple製品で該当証明書を無効化する施策が発表されました。
現在デジサート社には申請が殺到しているようで、証明書の発行に通常より時間がかかる可能性があります。特にGoogle Chromeのリリース予定から一か月を切っているため、該当顧客がある場合は早急に対応が必要です。
