ネットワークエンジニアの備忘録

トラブルや気になった点をメモしておきます。

SRX ClustrerIDの変更方法

Juniper HA SRX

SRXでHA構成を組む場合、以下のコマンドでClusterIDを指定する必要があります。

root> set chassis cluster cluster-id 1 node 0 reboot
root> set chassis cluster cluster-id 1 node 1 reboot

 ClusterIDはHAを組む機器同士で同一の値である必要があり、仮想IPに使用する仮想MACアドレスのベースになります。そのため、VRIDと同様に同一ネットワーク内に同一ClusterIDでHA構成を組んだSRXが存在することは許容されません。SRXの場合、以下の構成では仮想IPが別の値でもUntrustセグメントでMACアドレスが重複します。

 

f:id:hy0:20180401202148p:plain

ClusterIDの変更方法は、HA構成を組む際に使用した上記コマンドと同一であり、HA構成を組んだままClusterIDを変更することが出来ます。ただし、ClusterIDの変更には再起動が必要なため注意してください。

複数セグメントでのVRID重複問題

VRRP

VRRPの標準仕様では仮想IPアドレスに対する仮想MACアドレスを使用します。この仮想MACアドレスはVRIDから作られるため、VRIDが同一だとセグメントが違っていても同じMacアドレスが生成されてしまいます。この仕様は下記のようにL2SW等がVLAN毎にMacアドレスを学習してくれれば通常問題ありません。

f:id:hy0:20180317003938p:plain

しかし、以下のようにVlan単位でMacアドレスを学習できない場合は複数ポートに同一Macアドレスが見えるため、仮想Macアドレス宛のフレームをどのポートに転送するのかはスイッチ次第となり、動作が不安定となります。

f:id:hy0:20180317004235p:plain

では設定を変更して仮想IPのMacアドレスを仮想Macではなく物理Macアドレスを使用すれば良いか？と言われるとそうとは言い切れません。物理Macアドレスを使用するとRFCに準拠しなくなり、パケットロスにも弱くなってしまいます。また、VRRPの系切り替わり時にバッティングログも出てしまいます。昔NECのClusterPROで冗長化していたサーバも物理Macアドレスを使用していたので、よくNW機器にバッティングログが出ていました。

結論としては適切なVLAN設計がされているネットワークではセグメントが分かれていればVRIDが被っていても特に問題はありません。しかし客先ネットワークの一部しか構成を把握できないような案件では、一見セグメントが違う場合もVRIDはユニークなものにしたほうが良いかもしれません。間に何が挟まってるかわからないので。。。

 

SRX HA構成時に片系のみHAランプがオレンジ点灯

SRX HA Juniper

SRX340のHA構成でドはまりしたので備忘録として残しておきます。。。

以下のような構成でSRXでHAを組んだ際に、HAステータスが不安定になりました。具体的には片系のみHAのLEDランプがオレンジ点灯(Amber)となっています。この状態で系切り替えを起こすと通信が引き継がれず、show chassis cluster status コマンドを実行するとインターフェース監視を行っているRedundancy group: 1のみHAランプがオレンジ点灯機器のプライオリティが表示されません。

f:id:hy0:20180310230413p:plain

 

＃正常な出力結果
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

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サービスも契約が必要です。

f:id:hy0:20180306220719p:plain

ここで本題になりますが、特定の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構成構築

SRX Juniper

初めてSRX340でHA構成を組んだので、備忘録として残しておきます。SRXシリーズでHA構成を組む場合、機器同士でコントロールリンク(fxp1)とファブリックリンク(fab0/1)の最低２本の接続が必要です。ここで注意する必要があるのがコントロールリンクで使用するポートが機種ごとに違います。(ファブリックリンクは任意で決められます)

使用するポートは下記にまとめてあるので参照ください。SRX340ではge-0/0/1です。

www.juniper.net

脱線しましたが、設定手順を記載します。

(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 追加のセキュリティアップデートが公開

脆弱性 Cisco

2018/1/29に非常に深刻な脆弱性が発表されました。本脆弱性の回避策は存在せず、迅速なアップデートを呼び掛けています。本脆弱性の影響度はCisco社の影響度:Crirical に指定され、CVSSver3 深刻度評価10.0とかなり危険な評価となっています。

 

tools.cisco.com

本脆弱性は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 ssl

ProxyサーバとHTTPSデコードの関係について、ちょっと触らないとすぐ忘れるので書き出しておきます。

現在の通信はHTTPSが殆どであり、HTTPの通信はあまり見受けられません。これは2014年にGoogleがHTTPS対応サイトを優遇する（検索上位にする）といった常時SSL推奨化を明言したことが大きなきっかけの一つだと思われます。

HTTPSでは通信が暗号化されるため、ユーザのセキュリティの向上をもたらす一方で不正な通信も秘匿性を高めました。そのため、最近のProxyやUTMでは暗号化された通信を解析するためのHTTPSデコード機能が搭載されることが一般的となっています。このHTTPSデコード機能とProxyサーバ、URLフィルタにどう関連するのかというと、HTTPSでは以下のようにURLも暗号化されるため、基本的にURLフィルタを行うためにはHTTPSデコード機能が必須となります。

f:id:hy0:20180129225207p:plain

しかしProxyサーバを使用する場合は動作が異なります。端末はCONNECTメソッドを使いプロキシサーバと通信を行い、CONNETメソッドにはドメイン名が入ります。Proxyサーバはこのドメイン名でのみURLフィルタを利用することが可能です。

f:id:hy0:20180129225805p:plain

つまり同一ドメインで別サービスを提供しているようなサイトでは全て許可か全て拒否しか選択出来ません。そしてドメイン名の管理はサービス側に依存するため、柔軟なポリシー設計が出来ません。これらは（Proxyサーバには依存しませんが）証明書のCNからフィルタするときのも同様です。

URLフィルタは基本的にHTTPSデコードありきだとは思いますが、Proxyサーバがあれば（多少不自由ではありますが）フィルタリング出来ることを認識しておいて下さい。＃個人的には使い勝手が悪いのでやりたくありませんが、、、

 

アクセス数が高いシステムへのリアルタイムスキャンについて

障害 アンチウィルス

Webサーバなど高頻度のファイルアクセスがあるシステムへのリアルタイムスキャンは設計が非常に難しいです。理由としては頻繁にロードアベレージ高騰などの高負荷状態に陥り、最悪の場合ハングアップする事も想定されるからです。

一般的にウィルススキャンは検索結果をキャッシュとして保持し、同一ファイルの二回目以降のアクセスに対してはキャッシュを利用することで負荷低減を行います。しかし、パターンファイルがアップデートされるとキャッシュされた結果に信頼性が失われるため、それまでのキャッシュを破棄します。

新規のファイルアクセスに加え、今までキャッシュを使用していたファイルにも検査が行われるため、一時的にディスクI/OおよびCPU使用率が上昇します。これに加え平行してパターンアップデートに伴うDBアップデートも行われ、この処理でも前述したディスクI/OとCPU使用率が上昇します。これらの処理が重なりサーバの高負荷状態が発生することでスキャン要求がサーバの処理能力を超えた場合、サーバハングが起きてしまう場合があります。また、メモリの断片化が進みPae Allocation Failureが頻発する場合もあります。

本問題を解消するためにはリアルタイムスキャン対象の領域を絞るか、パターンアップの頻度を下げたり影響が少ない（アクセス数が低いなど負荷の高くない）時間帯に実行するように変更する必要があります。メモリ断片化に関してはカーネルパラメータのvm.min_free_kbytesをチューニングして改善する場合もありますが、このカーネルパラメータは低すぎても高すぎてもサーバの正常動作に支障をきたすため注意が必要です。

最も安牌なのはデメリットを説明し、リアルタイムスキャンを実行しないことですが、要件として必須であれば導入は慎重に行い、充分な検証を実施すべきです。

Stack構成のメリットとデメリット

Stack

ネットワーク機器のStack構成は2台以上のスイッチを論理的に1台に束ねる技術です。個人的にStack構成の最も優れていると思うところは、Stack構成を組むことで論理的に1台に出来るため、ループフリー構成となりSTPを使用しなくて良くなるところです。また、管理するConfigも1台となり、設計がシンプル化出来ます。

以前は、提案する際に可能であればStack構成を推奨していましたが、ISP事業者としてバックボーンの運用を行うようになり、考え方が変化してきました。

f:id:hy0:20180125202757p:plain

まずスタック構成のデメリットとして、Stack構成を組むスイッチではすべてのスタックメンバーでバージョンを合わせるため、ファームウェアにバグがあった場合に両系に影響が出てしまいます。バグが通信に大きく影響があるレベルであれば、完全に停止してしまう可能性もあります。そのため、たとえばルーティングを片寄して迂回を行い、片系ずつバージョンアップするなど問題発生時の経路迂回が難しく、完全な冗長性を担保することが出来ません。

また、スタックケーブルの半刺しやスタックモジュール障害時にリブートを繰り返してバタついてしまうケースも存在します。さらにOSPFやBGPのプロセスも一度切れて再接続をするケースもあるため、機器障害時の通信断時間がシビアに求められる環境では、L3機能を使う場合はStack構成を避けることも検討すべきだと感じました。

Stack機能は非常に便利ですが、運用まで視野に入れる場合はファームウェアのアップデート手順や障害時の経路迂回など、どの程度の通信断時間が許容されるかを考慮した導入検討が必要です。

 

セキュリティインシデント向けのテレワーク保険

マルウェア 脆弱性

東京海上日動火災保険及び日本マイクロソフトがテレワーク保険というものを発表しました。本サービスは2月から開始予定で、Windows 10 搭載 PC に商品付帯する販売方式を採用するため、保険契約等は不要のようです。

モバイルPCの利用時に発生する各種損害に対し、損害賠償金や原因調査費用等を補償するサービスでウイルス感染時の調査費用や、PCを紛失してしまい情報漏えいした際の損害賠償金や各種対応費用を補償するサービスとのことです。

気になる具体的な補填内容（金額）や補填対象の条件が不明ですが、手軽に取り入れられるようであれば提案材料の一つになると思いました。専用線などネットワークインフラでは停止時間があれば月額料金の何%を返金するといったSLAが提示されていることは珍しくありませんが、セキュリティ対策はどこまで補償（対象条件/金額）するのか、明示することが難しいため、詳細情報を待ちたいと思います。