SRX HA構成時に片系のみHAランプがオレンジ点灯
SRX340のHA構成でドはまりしたので備忘録として残しておきます。。。
以下のような構成でSRXでHAを組んだ際に、HAステータスが不安定になりました。具体的には片系のみHAのLEDランプがオレンジ点灯(Amber)となっています。この状態で系切り替えを起こすと通信が引き継がれず、show chassis cluster status コマンドを実行するとインターフェース監視を行っているRedundancy group: 1のみHAランプがオレンジ点灯機器のプライオリティが表示されません。
#正常な出力結果
node0 primary
root >show chassis cluster status
Node Priority Status Preempt Manual Monitor-failures
Redundancy group: 0 , Failover count: 1
node0 200 primary no no None
node1 1 secondary no no None
Redundancy group: 1 , Failover count: 1
node0 101 primary no no None
node1 1 secondary no no None
#問題発生時の出力結果
node0 primary
root >show chassis cluster status
Node Priority Status Preempt Manual Monitor-failures
Redundancy group: 0 , Failover count: 1
node0 200 primary no no None
node1 1 secondary no no None
Redundancy group: 1 , Failover count: 1
node0 101 primary no no None
node1 0 secondary no no IF
なんじゃこりゃ、、何分放置しても正常にはならず、HAランプもオレンジ点灯のままだ、、、しかも面倒なのがごくまれに両系再起動すると正常になるんですよね。
色々模索した結果、物理リンクはLEDが点灯していますが、HAランプがオレンジ点灯している機器のみshow chassis cluster interface コマンドを実行すると監視対象インターフェースがダウンしてました。
#HAランプがグリーンの機器での表示結果
node0 Primary
root >show chassis cluster interface
Interface Monitoring:
Interface Weight Status Redundancy-group
ge-0/0/2 100 Up 1
ge-5/0/2 100 Up 1
ge-0/0/4 100 Up 1
ge-5/0/4 100 Up 1
#HAランプがオレンジの機器での表示結果
node1 secondary
root >show chassis cluster interface
Interface Monitoring:
Interface Weight Status Redundancy-group
ge-0/0/2 100 down 1
ge-5/0/2 100 down 1
ge-0/0/4 100 down 1
ge-5/0/4 100 down 1
もしかしてデフォルトでRSTP動いている??と思ったら当たりでした。。。設定からRSTPを無効にし、起動しなおすとHAランプもグリーンとなり、素直にHA構成を組んでくれました。試しにプライマリに電源断を起こしても早々に切り替わってくれ、起動するとそそくさとHAも組んでくれたので一安心です。とはいってもSRXは起動自体が遅いので、起動した機器のHAランプがグリーンになり、コマンド出力結果が正常になるまで7分程度かかりました。SRXの結合試験は起動が遅すぎるから億劫ですね。。。
ipv6パケットを阻害するL2SW
ipv6 IPoE環境ではPPPoEのように認証を行う必要がないため、フレッツ・v6オプションとISPのv6サービスを契約すれば接続するだけでipv6アドレスが払い出されます。
なぜ認証していないのに特定のipv6アドレスを取得できるか?というと、v6サービスを契約することで物理回線(ONU)と払い出されるipv6アドレスが紐づけられます。そのため、v6サービスを提供するにはISP側からCAF番号を求められます。ONUはDHCPv6PDによりプレフィックスを保持しており、ONU配下のipv6 ClientはRAによりipv6アドレスを取得します。PPPoEと違ってセッション制限があるわけではないので、理論上はハブで分岐すればプレフィックス分のホストをつなげることが出来ます。
注意が必要なのはフレッツ・v6オプションを契約すればISPのv6サービスを契約しなくてもipv6アドレスを取得できます。これはNGN/Flets網でのみ使用でき、インターネット網には接続できないipアドレスのため、NGN/Flets網のサービスまたはNGN網での折り返し通信にしか使えません。さらにNTTのNGN/Flets網は東西で分離されているため、ロケーションによっては網内折り返し通信も出来ません。基本的にipv6によるインターネット接続を利用したい場合はISPのv6サービスも契約が必要です。
ここで本題になりますが、特定のL2SWをハブ替わりにしてipv6 Client(PC)を複数接続したときにipv6アドレスを取得出来ませんでした。。。事象が発生したL2SWはWS-C2960S-24TS-L ver:15.0(2)SEです。デフォルト設定で使用してもうまくいかず、ソフトウェアバグなのかな、、、切り分けのためにスイッチをWS-C3560V2-24TS ver:12.2(55)SE8にすると問題なく分岐できました。事象が発生したL2スイッチでパケットキャプチャをしてみるとipv6 ClientはRSを出しているのに、同一Vlanの別ポートではRAはおろかRSもキャプチャ出来ませんでした。ちなみに100均のJJで伸ばしても受け取れなくなり、ハブを使用すれば分岐できました。まだ原因はわかっておらず、まだまだipv6の勉強が足りないと痛感しました。
SRX340でのHA構成構築
初めてSRX340でHA構成を組んだので、備忘録として残しておきます。SRXシリーズでHA構成を組む場合、機器同士でコントロールリンク(fxp1)とファブリックリンク(fab0/1)の最低2本の接続が必要です。ここで注意する必要があるのがコントロールリンクで使用するポートが機種ごとに違います。(ファブリックリンクは任意で決められます)
使用するポートは下記にまとめてあるので参照ください。SRX340ではge-0/0/1です。
脱線しましたが、設定手順を記載します。
(1)コントロールリンクであるge-0/0/1同士を接続し、リンクアップさせる。
(2)Primaryに以下の設定を実施
root# delete interface
root# delete security
root# set system root-authentication plain-text-password
New password:"root Password"
Retype new password:"root Password"
root# commit
root# quit
root> set chassis cluster cluster-id 1 node 0 reboot
(3)Slaveに以下の設定を実施
root# delete interface
root# delete security
root# set system root-authentication plain-text-password
New password:"root Password"
Retype new password:"root Password"
root# commit
root# quit
root> set chassis cluster cluster-id 1 node 1 reboot
両系立ち上がればHA構成を組むことが出来ます。起動してもしばらくは両系ともに{hold:nodex}と表示されてしまいます。HA構成を組むには両系が起動してから数分待つ必要があるので注意してください。
構成後は各機器でEnterを押すと{primary:node0}、{secondary:node1}と表示が変化します。
本設定以降もファブリックリンクの設定やプライオリティの設定等がありますが、特に難しい作業はないので省略します。
CiscoASAに深刻な脆弱性( CSCvg35618) 18/2/7 追加のセキュリティアップデートが公開
2018/1/29に非常に深刻な脆弱性が発表されました。本脆弱性の回避策は存在せず、迅速なアップデートを呼び掛けています。本脆弱性の影響度はCisco社の影響度:Crirical に指定され、CVSSver3 深刻度評価10.0とかなり危険な評価となっています。
本脆弱性はwebvpn機能が有効になっている製品が対象となり、攻撃者が複数の細工したXMLパケットをwebvpnで設定されたインターフェースに送信することで、攻撃者は遠隔から認証を回避して機器を乗っ取ることが可能になります。
以下に影響を受ける対象製品を記載します。
- 3000 Series Industrial Security Appliance (ISA)
- ASA 5500 Series Adaptive Security Appliances
- ASA 5500-X Series Next-Generation Firewalls
- ASA Services Module for Cisco Catalyst 6500 Series Switches and Cisco 7600 Series Routers
- ASA 1000V Cloud Firewall
- Adaptive Security Virtual Appliance (ASAv)
- Firepower 2100 Series Security Appliance
- Firepower 4110 Security Appliance
- Firepower 9300 ASA Security Module
- Firepower Threat Defense Software (FTD)
Cisco ASA Major Release | First Fixed Release |
---|---|
8.x1 | Affected; migrate to 9.1.7.20 or later |
9.01 | Affected; migrate to 9.1.7.20 or later |
9.1 | 9.1.7.20 |
9.2 | 9.2.4.25 |
9.31 | Affected; migrate to 9.4.4.14 or later |
9.4 | 9.4.4.14 |
9.51 | Affected; migrate to 9.6.3.20 or later |
9.6 | 9.6.3.20 |
9.7 | 9.7.1.16 |
9.8 | 9.8.2.14 |
9.9 | 9.9.1.2 |
Cisco FTD Major Release | First Fixed Release |
---|---|
Prior to 6.2.2 | Not vulnerable |
6.2.21 | Cisco_FTD_Hotfix_AB-6.2.2.2-4.sh.REL.tar (All FTD hardware platforms except 21xx) Cisco_FTD_SSP_FP2K_Hotfix_AC-6.2.2.2-6.sh.REL.tar (21xx FTD hardware platform) |
2018/2/7追記
Ciscoが同製品に対して追加でセキュリティアップデートを行いました。どうやら以前のパッチで防げない新しい攻撃手法が発見されたとのことです。本脆弱性もアップデート以外に対処方法がないため、以前アップデートを行った製品であっても、再度アップデートを行う必要があります。
Proxyサーバを利用したURLフィルタ
ProxyサーバとHTTPSデコードの関係について、ちょっと触らないとすぐ忘れるので書き出しておきます。
現在の通信はHTTPSが殆どであり、HTTPの通信はあまり見受けられません。これは2014年にGoogleがHTTPS対応サイトを優遇する(検索上位にする)といった常時SSL推奨化を明言したことが大きなきっかけの一つだと思われます。
HTTPSでは通信が暗号化されるため、ユーザのセキュリティの向上をもたらす一方で不正な通信も秘匿性を高めました。そのため、最近のProxyやUTMでは暗号化された通信を解析するためのHTTPSデコード機能が搭載されることが一般的となっています。このHTTPSデコード機能とProxyサーバ、URLフィルタにどう関連するのかというと、HTTPSでは以下のようにURLも暗号化されるため、基本的にURLフィルタを行うためにはHTTPSデコード機能が必須となります。
しかしProxyサーバを使用する場合は動作が異なります。端末はCONNECTメソッドを使いプロキシサーバと通信を行い、CONNETメソッドにはドメイン名が入ります。Proxyサーバはこのドメイン名でのみURLフィルタを利用することが可能です。
つまり同一ドメインで別サービスを提供しているようなサイトでは全て許可か全て拒否しか選択出来ません。そしてドメイン名の管理はサービス側に依存するため、柔軟なポリシー設計が出来ません。これらは(Proxyサーバには依存しませんが)証明書のCNからフィルタするときのも同様です。
URLフィルタは基本的にHTTPSデコードありきだとは思いますが、Proxyサーバがあれば(多少不自由ではありますが)フィルタリング出来ることを認識しておいて下さい。#個人的には使い勝手が悪いのでやりたくありませんが、、、
アクセス数が高いシステムへのリアルタイムスキャンについて
Webサーバなど高頻度のファイルアクセスがあるシステムへのリアルタイムスキャンは設計が非常に難しいです。理由としては頻繁にロードアベレージ高騰などの高負荷状態に陥り、最悪の場合ハングアップする事も想定されるからです。
一般的にウィルススキャンは検索結果をキャッシュとして保持し、同一ファイルの二回目以降のアクセスに対してはキャッシュを利用することで負荷低減を行います。しかし、パターンファイルがアップデートされるとキャッシュされた結果に信頼性が失われるため、それまでのキャッシュを破棄します。
新規のファイルアクセスに加え、今までキャッシュを使用していたファイルにも検査が行われるため、一時的にディスクI/OおよびCPU使用率が上昇します。これに加え平行してパターンアップデートに伴うDBアップデートも行われ、この処理でも前述したディスクI/OとCPU使用率が上昇します。これらの処理が重なりサーバの高負荷状態が発生することでスキャン要求がサーバの処理能力を超えた場合、サーバハングが起きてしまう場合があります。また、メモリの断片化が進みPae Allocation Failureが頻発する場合もあります。
本問題を解消するためにはリアルタイムスキャン対象の領域を絞るか、パターンアップの頻度を下げたり影響が少ない(アクセス数が低いなど負荷の高くない)時間帯に実行するように変更する必要があります。メモリ断片化に関してはカーネルパラメータのvm.min_free_kbytesをチューニングして改善する場合もありますが、このカーネルパラメータは低すぎても高すぎてもサーバの正常動作に支障をきたすため注意が必要です。
最も安牌なのはデメリットを説明し、リアルタイムスキャンを実行しないことですが、要件として必須であれば導入は慎重に行い、充分な検証を実施すべきです。
Stack構成のメリットとデメリット
ネットワーク機器のStack構成は2台以上のスイッチを論理的に1台に束ねる技術です。個人的にStack構成の最も優れていると思うところは、Stack構成を組むことで論理的に1台に出来るため、ループフリー構成となりSTPを使用しなくて良くなるところです。また、管理するConfigも1台となり、設計がシンプル化出来ます。
以前は、提案する際に可能であればStack構成を推奨していましたが、ISP事業者としてバックボーンの運用を行うようになり、考え方が変化してきました。
まずスタック構成のデメリットとして、Stack構成を組むスイッチではすべてのスタックメンバーでバージョンを合わせるため、ファームウェアにバグがあった場合に両系に影響が出てしまいます。バグが通信に大きく影響があるレベルであれば、完全に停止してしまう可能性もあります。そのため、たとえばルーティングを片寄して迂回を行い、片系ずつバージョンアップするなど問題発生時の経路迂回が難しく、完全な冗長性を担保することが出来ません。
また、スタックケーブルの半刺しやスタックモジュール障害時にリブートを繰り返してバタついてしまうケースも存在します。さらにOSPFやBGPのプロセスも一度切れて再接続をするケースもあるため、機器障害時の通信断時間がシビアに求められる環境では、L3機能を使う場合はStack構成を避けることも検討すべきだと感じました。
Stack機能は非常に便利ですが、運用まで視野に入れる場合はファームウェアのアップデート手順や障害時の経路迂回など、どの程度の通信断時間が許容されるかを考慮した導入検討が必要です。
セキュリティインシデント向けのテレワーク保険
東京海上日動火災保険及び日本マイクロソフトがテレワーク保険というものを発表しました。本サービスは2月から開始予定で、Windows 10 搭載 PC に商品付帯する販売方式を採用するため、保険契約等は不要のようです。
モバイルPCの利用時に発生する各種損害に対し、損害賠償金や原因調査費用等を補償するサービスでウイルス感染時の調査費用や、PCを紛失してしまい情報漏えいした際の損害賠償金や各種対応費用を補償するサービスとのことです。
気になる具体的な補填内容(金額)や補填対象の条件が不明ですが、手軽に取り入れられるようであれば提案材料の一つになると思いました。専用線などネットワークインフラでは停止時間があれば月額料金の何%を返金するといったSLAが提示されていることは珍しくありませんが、セキュリティ対策はどこまで補償(対象条件/金額)するのか、明示することが難しいため、詳細情報を待ちたいと思います。
ipv6 source address selection
ipv6には送信元アドレスの選択に優先順位が存在します。本記事で記載するものは一時期話題となったipv4とipv6の優先順位ではなく、ipv6のみに限ったものとします。
まずipv6の自動アドレス設定には大きく2つの方法が存在します。
- ステートフル自動設定
- ステートレス自動設定
ステートフル自動設定ではDHCPv6サーバからipv6アドレスを取得します。ipv4との大きな違いはデフォルトゲートウェイを配信出来ないことにあります。この仕様からDHCPv6のみでクライアントに必要なipv6アドレス(ip/subnet/gw/dns)を付与することは出来ません。
一方ステートレス自動設定ではRAによってipv6アドレスを取得します。ステートフル自動設定とは違い、クライアントに必要なipv6アドレスをすべて付与することが可能です。ただし、RAで割り当てるのはプレフィックスのみでインターフェースIDはクライアント側で自動生成します、つまり割り当てるipv6アドレスはクライアントに依存します。また、RAでのDNSの配信にはRDNSS機能に対応している必要があります。RDNSS機能はIOS XE 3.9S以降( iosの場合15.4(1)T, 15.3(2)S.以降)で対応します。
ipv6RT(config-if)#ipv6 nd ra dns server x:x:x:x:x:x:x
1. 2.を見比べるとステートレス自動設定(2)であればDHCPv6サーバが不要で便利に感じますが、クライアントに割り当てるアドレスを管理出来ない欠点があります。つまりクライアントに割り当てるipv6アドレスを管理したいのであれば、ステートフル自動設定(1)を利用するしかありません、しかしステートフル自動設定はデフォルトゲートウェイを配信出来ないため、RAも併用する必要があります。前置きが長くなりましたがここからが本題です。実際に1. 2.を組み合わせてWindows7でIPを取得してみるとipv6アドレスを3つ保持します。
※残念なことにMフラグを有効化してもRAでipは取得します。
クライアントはこれらのipv6アドレスから決められた優先順位に従って送信元ipv6アドレスを使用します。クライアント側で特に設定変更をしない場合、3→2→1の順に使用します。つまりDHCPv6サーバを使用する目的である「クライアントに割り当てるipv6アドレスを管理」が出来ても実際に通信を行うipv6アドレスを管理出来ません。
本問題を解消するためにクライアント側で優先順位を変更しても良いのですが、台数が多い場合はあまり現実的ではありません。無難なのはRAを送信するインターフェースで以下のコマンドを設定することで プレフィックスを送信せず、クライアント側で自動生成することを無効化出来ます。RAで自動生成されないと一時ipv6アドレスも生成されないため、結果的にDHCPv6サーバから取得したipv6アドレスが送信元アドレスになります。
ipv6RT(config-if)#ipv6 nd prefix default no-advertise
注意点として、RAでプレフィックスを取得する前提の機能がないか確認が必要です。また、ipv4と違ってグローバルipv6アドレスはインターネットに出るのに途中でNATする必要がないため、通信先にクライアントの実ipアドレスが把握されてしまいます。そのため、インターネットに出るためではなくセキュリティの観点からNATを行うなど、ipv6はipv4以上にクライアントおよび途中経路での適切なセキュリティ設計が求められます。
ipv6化による速度向上
利用ユーザの急激な増加に伴い、フレッツ回線の遅延が目立ってきました。この問題はipv6化することで解消できる可能性があります。ただし、勘違いしがちなのですが、決してipv6自体が高速な訳ではないです。また、必ず速度が早くなるわけではないです。
まず一般的にフレッツが遅延する大きな理由としてはPOI(Point of Interface)の帯域不足が挙げられます。POIとはNTTとISPの相互接続点で、NTTのフレッツ網から各ISP(インターネット)への経路です。
POIの帯域を増強出来れば良いのですが、これにはNTTからの制約が厳しく、非常に高い費用が発生するので中々出来ないのが現状です。ipv6に速度向上が期待できるのは、ipv6のPOI(VNE)が帯域に余裕があること、同ipv4に比べ制約が緩く、帯域の増強が行い易いことにあります。
また、NGNのipv6契約同士であればNGN網内で折り返し通信が出来るため、通信距離が短くなり速度向上が期待できます。
ipv4でこれが出来ないのはインターネット網に各キャリアのPPPoEサーバがあり、必ずPOIを経由する必要があるためです。経由するPOIの帯域が不足している場合は速度が低下してしまいます。つまり経由するPOIの帯域に余裕がある場合、ipv6化しても大きな恩恵を得られない可能性があります、どのPOIを経由するかはONUの設置位置(住所)に依存するため、注意が必要です。
また、ipv6を使用してインターネット接続を行う場合、通信を行う相手がipv6に対応しているか確認が必要です。導入前には通信要件を正しく把握し、ipv6化しても問題ないか見定めましょう。VNEまでipv6トンネルを形成し、ipv4パケットをカプセル化するようなサービスを利用することで帯域に余裕があるVNEを中継したipv4通信が可能です。さらにIPoEではPPPoEを利用しないため、MTUサイズを1500にすることができ、一度に送信できるパケットサイズが増加します。
結論としてipv6化することで多くの場合は速度向上が期待できます。しかしPOIの遅延が起きているかはキャリア側でしか把握出来ないため注意が必要です。それ以外にも利用しているサービスがipv6化しているか確認が必要です。まだ普及が進まないipv6化ですが、早めに移行することで、より恩恵を受けることが出来るため、検討の価値はあると思います。