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

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

Always SSL(常時SSL化/AOSSL)について

TLS ssl

f:id:hy0:20180816224009p:plain

昨今では当たり前のようになってきたAlways SSL(常時SSL/TLS化）について、メリットだけでなくデメリット（弊害）がないか考えてみました。

SSL/TLSによる通信はデータ傍受の危険から身を守ってくれる手段としてとても有用です。しかし、以前と比べてhttps化による恩恵が減ってきたようにも見えます。特に証明書の信頼性が以前より低くなってきたのでは？と疑問に感じます。

httpsによって向上するセキュリティとは以前は以下のようなことが考えられました。

  1. https化はコストがかかるため、その手間をかけている信頼
  2. 証明書による相手の見極め
  3. 通信経路の暗号化による盗聴防止

1.について、以前は証明書が非常に高価だったため、不正なサイトがわざわざそのコスト、手間をかけることは考えづらいという考え方でしたが、現在は非常に安価な証明書やLets Encryptが登場し、この考え方は成り立たなくなりました。

2.について、これまた以前は相手の存在確認がある程度行われていましたが、DV証明書やLets Encryptoはこれらの機能をほぼ持っていないため、成り立たなくなりました。もちろんEV証明書であれば厳格に確認を実行されていますが、一般的に利用者がDV証明書を使っているかEV証明書を使っているか確認するとは考えづらいためです。

3.について、こちらは2.の相手の確認ありきだったため、いくら通信経路が暗号化されていても、不正なサイトと通信を行っては意味がないと考えられます。また、最近の不正な通信は検知を逃れるために暗号化を行うことが一般的になってきたため、エンドポイントセキュリティやSSL復号化に頼らざるを得ないのが現状です。※そしてその設備投資にコストがかかってしまう。。。

また、最近はブラウザベンダーが力を持っているような印象を受けます。Symantecの件もそうですが、ChomeがこのCAは信頼ならない！と判断して排除するなど、ブラウザベンダー様の言いなりになる傾向があるのもよくないかと考えています。

しかし、セキュリティを担保するうえでSSL/TLS化は必須であることに変わりはないため、求められているのはユーザのITリテラシーなのかもしれません。そもそも正常なサイトとよく似たドメインでサイトを立ち上げる所謂フィッシングサイトかどうかをCAが担保するべき範囲か？と言われるとそれは違うかなと思います。

やはりユーザによる見極めが必要な時代になってきたのかな～と思いました。

 

 

WLC Config Converter

Cisco WLC WiFI

WLC5508シリーズは2018年5月4日にEOLの計画が発表されました。今後リプレイスにあたって、後継機にあたるWLC5520シリーズへの移行計画を検討する必要があります。個人的にCiscoのWLCシリーズは（Arubaなどと違って）更改時にコンフィグのコンバートが非常に煩雑な印象でしたが、先日Ciscoのエンジニアの方に面白いものを紹介頂きました。

f:id:hy0:20180724201403p:plain

Cisco.com Login Pag

基本的には現行機の「GUIから取得したバックアップ」または 「show run-config commands」などをコンバートツールにアップデートし、変換を実行するだけのようです。まだ実際に使用していませんが、移行作業の負荷が減りそうで何よりです。

f:id:hy0:20180724201740j:plain

 

簡単な使い方が以下のページに紹介されています。

WLC Config Converter - Cisco Community

WPA3（Wi-Fi Protected Access 3)が正式発表

WPA3 WiFi

米国時間の6/25にWPA3が正式発表されました。WPA3でもWPA2以前と同様に家庭向けの「WPA3-Personal」と、企業・組織向けの「WPA3-Enterprise」が存在します。

f:id:hy0:20180629224221j:plain

WPA3-Personalはパスワードベースの認証のため、おそらくPSK相当のものであると思われます。WPA3-Enterpriseは802.1x認証がベースになると思われます。WPA3はセキュアになりますが、いまだソフトウェアアップデートだけで対応出来るか不透明です、さらにTLS1.3同様にソフトウェアで対応してもハードウェアが専用品でないとスループットが出ない恐れがあるため、ハードウェアレベルでの対応製品の購入が必須になってくると思われます。

また、無線LANの接続を簡易化する「Wi-Fi Easy Connect」も発表されています。

f:id:hy0:20180629224920j:plain

これは主にディスプレイを持たないIoTデバイス向けで、スマートフォンなどでQRコードを読み込むだけで読み込んだ機器が設定用デバイスとなり、そこに複数のIoTデバイスを登録することで無線LANへ接続させることが出来るそうです。これは非常に便利だなと思いました。

さらに、公衆無線LANにありがちなパスワードが未設定や共通キーが公開されており、盗聴のリスクが高いWiFiをセキュアにする「Wi-Fi CERTIFIED Enhanced Open」が発表されています。

f:id:hy0:20180629231351p:plain

この技術は無線LANの管理フレームを暗号化する802.11w(PMF)やOWE(Opportunistic Wireless Encryption(RFC8110))を使用することで、認証無しで通信の暗号化を可能にしてくれます。ただし、OWEを使用するには今まで以上にAPの負荷が増えるため、通常のPSKに比べてAPのスペックを考慮する必要があります。また、中間者攻撃には無力のため、中間者攻撃対策は別途考慮が必要です。

 

 

Cisco PIのバックアップとリストア

Cisco Prime Infrastructure WiFI

Cisco Prime Infrastructureのバックアップとリストアの手順を記載します。注意点としてPrime InfrastructureはOracleを搭載しているため、システムやサービスの再起動には時間を要します。バージョンアップ等の作業を実施する際は、作業時間を多めに見積もることをお勧めします。また、検証用にメモリが12G必要な最低構成をメモリが16Gほど空いている仮想サーバにデプロイしてみましたが、重くて使えませんでした。よほどリソースに余りがない限り、アプライアンス版の購入したほうが良いかなと思いました。

【バックアップファイルの作成】

バックアップファイルを作成する際は、FTPサーバを用意することでバックアップファイル作成時に自動的にFTPでアップロードされます。

CiscoPI/admin# conf t 
Enter configuration commands, one per line. End with CNTL/Z. 
CiscoPI/admin(config)# 
CiscoPI/admin(config)# repository backup-repo-180628 
CiscoPI/admin(config-Repository)# 
CiscoPI/admin(config-Repository)# url ftp://x.x.x.x
CiscoPI/admin(config-Repository)# user admin password pallain Cisco123
CiscoPI/admin(config-Repository)# 
CiscoPI/admin(config-Repository)# end 
CiscoPI/admin# show repository backup-repo-180628 
backup_area.txt 
CiscoPI/admin# 
CiscoPI/admin# backup pibackup repository backup-repo-180628 application NCS  

DO NOT press ^C while the backup is in progress 

Aborting backup with ^C may terminate the backup operation or the backup file may be corrupted 
Backup Started at : 06/26/18 15:49:28 
Stage 1 of 7: Database backup ... Database size: 20G 
-- completed at 06/26/18 15:50:36 
Stage 2 of 7: Database copy ... 
-- completed at 06/26/18 15:50:36 
Stage 3 of 7: Backing up support files ... 
-- completed at 06/26/18 15:50:36 
Stage 4 of 7: Compressing Backup ... 
-- completed at 06/26/18 15:50:38 
Stage 5 of 7: Building backup file ... 
-- completed at 06/26/18 15:51:19 
Stage 6 of 7: Encrypting backup file ... 
-- completed at 06/26/18 15:51:31 
Stage 7 of 7: Transferring backup file ... 
-- completed at 06/26/18 15:51:50 
% Backup file created is: PI-Back-180626-1549__VER3.1.0.0.132_BKSZ9G_CPU16_MEM4G_RAM23G_SWAP15G_APP_CK613141954.tar.gpg 
Total Backup duration is: 0h:2m:22s

 

【バックアップファイルからのリストア】

CiscoPI/admin# restore PI-Back-180626-1549__VER3.1.0.0.132_BKSZ9G_CPU16_MEM4G_RAM23 G_SWAP15G_APP_CK613141954.tar.gpg repository backup-repo-180626 application NCS 


* NOTE * If the system console is disconnected or got cleared on session timeout 
run 'show restore log' to see the output of the last restore session. 

Restore will restart the application services. Continue? (yes/no) [yes] ? yes 

DO NOT press ^C while the restoration is in progress 
Aborting restore with a ^C may leave the system in a unrecoverable state 

Initiating restore. 
Please wait... Restore Started at 06/26/18 15:58:33 
Stage 1 of 9: Transferring backup file ... -- completed at 06/26/18 15:58:40 
Stage 2 of 9: Decrypting backup file ... -- completed at 06/26/18 15:59:01 
Stage 3 of 9: Unpacking backup file ... -- completed at 06/26/18 15:59:01 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Estimated time for completion of the remaining stages : 06/26/2018 16:41:30 
Systems with faster disk throughput may finish earlier than the estimated time 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Stage 4 of 9: Decompressing backup ... 
-- completed at 06/26/18 16:01:30 
Stage 5 of 9: Restoring Support Files ... 
-- completed at 06/26/18 16:01:31 
Stage 6 of 9: Restoring Database Files ... 
-- completed at 06/26/18 16:04:10 
Stage 7 of 9: Recovering Database ... 
-- completed at 06/26/18 16:05:58 
Stage 8 of 9: Updating Database Schema ... 
-- completed at 06/26/18 16:05:58 
Stage 9 of 9: Re-enabling Database Settings ... 
-- completed at 06/26/18 16:08:16 
Total Restore duration is: 00h:09m:43s 
INFO: Restore completed successfully.

Starting Prime Infrastructure... 

This may take a while (10 minutes or more) ...

Prime Infrastructure started successfully. 
Completed in 613 seconds

今回のテストではバックアップ～リストアまで約30分弱でした。あまりデータが入っていない状態で実施したため、データ量に応じて時間を追加計上しておいたほうが良いです。ちなみにライセンス追加では再起動は不要でした、ただし反映に再ログインが必要です。

WLC HA構成(SSO)のバージョンアップ手順

Cisco WLC WiFi

HA(SSO)構成を組んだ状態でバージョンアップ作業を行ったので、作業の備忘録を残しておきます。

基本的なバージョンアップ手順はシングル構成と変わらず、プライマリ機にアップロードすると自動的にセカンダリ機に転送されます。

GUIの場合、「Download File」を押下し、各パラメータを指定します。

＃検証時の環境ではプライマリ機のアップロードに約5分ほどかかりました。

  • File Type：「Code」
  • Transfer Mode：「TFTP」
  • IP Adress：「TFTPサーバのIP」
  • File Path：「/」
  • File name：「アップロードするOSファイル名」

f:id:hy0:20180614222304p:plain

各パラメータ投入後、右上の「Download」を押下するとプライマリ機にアップロードが開始します。アップロード完了後、セカンダリ機に転送が始まります。ここまでは通信断も起きませんでしたが、セカンダリ機に転送中はWiFiクライアント端末からのPingが不定期に重くなり、それまで4～6ms以内だったものが500ms程度になることがありました。アップロードでは明確な通信断は発生しませんでしたが、クライアントに負荷をかけることが許容されない場合は作業時間を検討する必要があります。

セカンダリ機への転送が完了後、転送が完了したメッセージが同一ページ下部に表示されるため、「Config Boot」を押下し、アップロードしたOSが「default」となっていることを確認し、両WLCを再起動をします。ここから通信断が発生します、再起動はWLC,APそれぞれ約5分程度の合計約10分です。

f:id:hy0:20180614220803p:plain

再起動完了後、APが再帰属して新OSを取得して再起動後、通信が復旧します。WLC5000シリーズでは6.0以降から同時に100APアップグレード可能だそうです。

結果的に明確な通信断が発生したのはWLCの再起動で約5分、その後APの再起動で約5分の10分程度でした。また、全体の作業時間はtftpによるアップロードが約5分、セカンダリ機に転送が約10分で合計約25分～程度となりました。

今回の検証環境ではAPの台数が1台でかつWLC、AP、tftpサーバが同一セグメントの環境だったため、帯域やAP台数でもう少しバッファを見込んだほうが良いと思います。

 

 

 

マルチエリアOSPF環境の通信迂回時の注意点

ospf マルチエリア

先日マルチエリアOSPF環境のルータでモジュール故障被疑が発覚したため、コストアップで経路迂回しようとしたら失敗したので備忘録として残しておきます。環境イメージは以下のとおりです、故障被疑はRT#01です。

f:id:hy0:20180526224557p:plain

通常のトラフィックフローは以下となります。

f:id:hy0:20180526224729p:plain

ここからRT#01とRT#03間のインターフェースコストを10000追加し、経路迂回を実施しました。トラフィックフローを見てみると、RT#03からの経路は迂回出来ているけどBGP Networkからの通信は迂回出来ていない。。。。

 RT#03からの発信経路f:id:hy0:20180526225100p:plain

BGP Networkからの発信経路

f:id:hy0:20180526225108p:plain

 なんでだろうってコンフィグをよく見たらRT#01、RT#02間はArea0でRT#01、RT#03間はArea100でした。OSPF ルートの選択ルールでは、エリア内ルートがエリア間ルートより優先され、エリア間ルートが外部ルートより優先されます。そのため、今回の構成ではコスト値より同一Areaからのルートを優先してしまいます。RT#03から発信する通信はコストに従ってRT#02経由へ迂回できましたが、BGP Networkからの通信はRT#01がRT#03と同一Areaのため、コスト度外視でRT#03に向かってしまいました。

う～ん、マルチエリアはあまり経験がなく、初歩的なことでつまづいてしましました。。OSPFのマルチエリア環境ではシングルエリアとは違う迂回手順が必要なため、注意して下さい。多分RT#01でPassiveにするしかなさそうです。ちなみにPassive化のほうが該当インターフェースのシャットダウンよりダウンタイムが少なったです。

 

 

 

ロードバランサーのTLS1.3対応状況

LB SSL

ちょっと前にA10やF5のエンジニアのかたとお話しする機会があったため、TLS1.3の対応状況を伺ってみました。

基本的に両社とも同様の回答で、現在ラインナップしている機器はファームウェアアップグレードで対応予定であるとのことでした。

しかし、注意点としてSSLに関しては専用のSSLチップでオフロードしており、このチップがTLS1.3に対応していないため、ソフトウェア処理によるスループットの低下が想定されるとのことです。現在と同等のスループットを期待する場合は、暗号化チップがTLS1.3に対応した製品買い替えることを検討しなければなりません。

本内容はUTMやプロキシなど、SSLデコードを行う機器では同様のことが想定されるため、TLS1.3が正式対応される直前では機器のリプレイスを控えるなど、各社がハードウェアレベルでTLS1.3に対応する時期を抑えて顧客に提案する必要性があると感じました。

※2018/8/17追記

セイコーの担当者ともお会いしました、セイコーのロードバランサーは低価格に抑えるために必要最低限の機能搭載としているため、Office365の迂回機能やTLS1.3の対応については現行ラインナップではなく次期製品から対応予定とのことでした。

SRX　ポリシー変更時のセッション断について

Juniper

SRXでFWポリシーを変更する場合、許可しなければいけないポリシーを消してしまうことや、ポリシーの順番を変更する際に、許可したい通信がDenyポリシーにヒットしないか注意する必要があります。その他にも、以下のポリシー操作をすることでセッション断が発生してしまうので注意が必要です。

  • src dest serviceのいずれかをシングルセルからマルチセルへ変更
  • src dest serviceのいずれかをマルチセルからシングルセルへ変更

シングルセルはオブジェクトが単体の状態を指し、マルチセルは複数のオブジェクトが指定されている状態を指します。

例として以下のポリシーを変更する場合、(1)～(3)では影響の有無が異なります。

f:id:hy0:20180502234904p:plain

  1. Src:192.168.0.0/24を削除する場合、マルチセルからシングルセル変更されるため、セッション断が発生します。

  2. Dest:133.243.238.163を削除する場合、マルチセルから変更されないため、セッション断は起きません。

  3. Serviceにプロトコルを追加する場合、シングルセルからマルチセルに変更されるため、セッション断が発生します。

 

MTUの設計

mtu

最近MTUの設計方法をド忘れしていたので、備忘録を残しておきます。

MTUとは1フレームで送信できるデータの最大値を示す伝送単位であり、一般的に使われるイーサネットであればイーサネットフレームの最大値である1518byteからEthernetヘッダ ( 14byte ) と FCS ( 4byte ) は除くため、IPとして通信できるサイズは1500byteとなります。

f:id:hy0:20180412230530p:plain

基本的にはこのMTUサイズが大きければ大きいほど、一度に送信できるデータ量が増えるため、（間の経路でフラグメントを考慮しなければ）通信の効率化が見込めます。そのため、間の経路でPPPoEやカプセル化などのヘッダ追加がないのであれば、実際に機器に設定するMTUも1500にしておけば問題ありません。実際にはローカル環境でない限り1500にすることはあまり無いと思います。その理由はMTUの最適値が間の経路を含めた最小値になるためです。MTUより大きなサイズのパケットがくるとフラグメント化して送信する必要があり、フラグメントの処理はハードウェア処理ではなくソフトウェア処理になってしまい、断片化したパケットを元に戻すのにも処理が必要で負荷が高くなるためです。

例えばGreヘッダは24byteの構成要素があるため、MTUの計算は-24しなければならず1476byteとなります。つまり実際に一度に送れるデータ量が1456byteです。

f:id:hy0:20180412231216p:plain

また、MTUサイズはフラグメントを避けるために小さくすれば良いか？と問われると答えはそうではありません、フラグメントを禁止したパケットがドロップしてしまうためです。このドロップを防ぐためにはいくつかの方法が存在します。

「mtu path discovery」という機能を使えばパケットサイズが超過していた場合に、フラグメントせずに済むサイズで再送するように要求を行うことが出来ます。ただし、mtu path discovery機能はICMPを使用するため、ルータのACLやFWでICMPが全て無効になっていると使うことが出来ません。また、通信を行う相手側（サーバ等）も対応している必要があるため、この機能だけで救えない場合も存在します。

「crypto ipsec df-bit」コマンドを使用すれば強制的にdf-bitを上書きすることも可能です。しかし、各パケットがプロセス レベルで再アセンブルされるため、高いデータ レートでパフォーマンスに大きな影響が生じます。プロセススイッチングによる通信速度低下が起こるうえに、再アセンブル キューが満杯になるとフラグメントが強制的に廃棄されることがあります。また、SSLなどの通信がフラグメント禁止にしているのはハッシュ値が変わることを防ぐためでもあります。これを強制的にフラグメントすることで想定外の挙動になる可能性があります。

 

新たな公開DNSサーバ「1.1.1.1」

dns

APNICとCloudflareが無料の公開DNSサーバの提供を始めました。

このサービスのメリットとしてユーザーのIPアドレスを記録せず、これを証明するためにKPMGによる監査を毎年行うことを名言しています。これは昨今のセキュリティを重視する流れに沿っていて良いと思います。

さらに、公式ページによれば他の公開DNSサーバより高速だとうたっており、一時期流行ったインターネットを高速化するためにDNSサーバのIPを8.8.8.8に変更する手法も、今後は1.1.1.1に変更してみる流れになるかもしれません。

f:id:hy0:20180404222726p:plain

個人的にはお客さんの環境がインターネットへ接続できているかの確認のために、8.8.8.8へpingを打ってもらって切り分けすることがあるので、今後は1.1.1.1に打ってもらうことがあるかもしれません。