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

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

ipv6 source address selection

ipv6

ipv6には送信元アドレスの選択に優先順位が存在します。本記事で記載するものは一時期話題となったipv4とipv6の優先順位ではなく、ipv6のみに限ったものとします。

まずipv6の自動アドレス設定には大きく2つの方法が存在します。

  1. ステートフル自動設定
  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つ保持します。

  1. DHCPv6サーバから取得したipv6アドレス
  2. RAから取得したプレフィックスから生成したipv6アドレス※
  3. 一時ipv6(匿名)アドレス

※残念なことに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化することで解消できる可能性があります。ただし、勘違いしがちなのですが、決してipv6自体が高速な訳ではないです。また、必ず速度が早くなるわけではないです。

まず一般的にフレッツが遅延する大きな理由としてはPOI(Point of Interface)の帯域不足が挙げられます。POIとはNTTとISPの相互接続点で、NTTのフレッツ網から各ISP(インターネット)への経路です。

POIの帯域を増強出来れば良いのですが、これにはNTTからの制約が厳しく、非常に高い費用が発生するので中々出来ないのが現状です。ipv6に速度向上が期待できるのは、ipv6のPOI(VNE)が帯域に余裕があること、同ipv4に比べ制約が緩く、帯域の増強が行い易いことにあります。

f:id:hy0:20180117225802p:plain

また、NGNのipv6契約同士であればNGN網内で折り返し通信が出来るため、通信距離が短くなり速度向上が期待できます。

f:id:hy0:20180117225849p:plain

ipv4でこれが出来ないのはインターネット網に各キャリアのPPPoEサーバがあり、必ずPOIを経由する必要があるためです。経由するPOIの帯域が不足している場合は速度が低下してしまいます。つまり経由するPOIの帯域に余裕がある場合、ipv6化しても大きな恩恵を得られない可能性があります、どのPOIを経由するかはONUの設置位置(住所)に依存するため、注意が必要です。

また、ipv6を使用してインターネット接続を行う場合、通信を行う相手がipv6に対応しているか確認が必要です。導入前には通信要件を正しく把握し、ipv6化しても問題ないか見定めましょう。VNEまでipv6トンネルを形成し、ipv4パケットをカプセル化するようなサービスを利用することで帯域に余裕があるVNEを中継したipv4通信が可能です。さらにIPoEではPPPoEを利用しないため、MTUサイズを1500にすることができ、一度に送信できるパケットサイズが増加します。

 結論としてipv6化することで多くの場合は速度向上が期待できます。しかしPOIの遅延が起きているかはキャリア側でしか把握出来ないため注意が必要です。それ以外にも利用しているサービスがipv6化しているか確認が必要です。まだ普及が進まないipv6化ですが、早めに移行することで、より恩恵を受けることが出来るため、検討の価値はあると思います。

 

 

 

WPA3

IoT WiFi

Wi-Fi Allianceは米国時間の2018/1/8にWPA3について明らかにしました。今回の発表ではおおまかに以下の機能が判明しました。

  1. 総当り攻撃に対するセキュリティ向上
  2. 任意の端末での別端末の認証
  3. 端末～ルータ間の暗号化
  4. デフォルトの鍵長を192bitへ

1番目は任意の回数だけログインに失敗するとブロックするようです。

2番目はIotのように画面がない端末でも、他の端末を利用してWiFi認証が可能になります。

3番目は現在は多くのフリースポットではユーザの接続の手間を減らすために意図的に暗号化がされていない箇所が多く存在しますが、WPA3からすべて暗号化されるようになります。

4番目は現在のデフォルト値である128bitから、よりセキュアな192bitに変更されます。

少し前にWPA2の脆弱性 KRACKsが発表されるなど、WPA3によってより安全な無線通信が期待されますが、WPA3はAPとクライアントのどちらも対応している必要があります。どちらもファームウェアのアップデートで対応可能になれば良いですが、専用機材が必要であれば普及には時間がかかると思われます。

BGP+vrf

bgp

BGPはaddress-familyを使用することでvrfごとにネイバーを形成することが可能です。今後のプロジェクトではOSPFとBGPを使用する頻度が高くなりそうなので設定例を書き起こしておきます。

f:id:hy0:20180107191516p:plain

AS10000#
ip vrf VRF-1
 rd 10001:1
!
ip vrf VRF-2
 rd 10002:1
!
no ip domain lookup
ip domain name lab.local
no ip ips deny-action ips-interface
!
interface Loopback1
 ip vrf forwarding VRF-1
 ip address 1.1.1.1 255.255.255.255
!
interface Loopback2
 ip vrf forwarding VRF-2
 ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
 ip vrf forwarding VRF-1
 ip address 10.0.0.1 255.255.255.252
!
interface FastEthernet0/1
 ip vrf forwarding VRF-2
 ip address 10.10.0.1 255.255.255.252
!
router bgp 10000
 no synchronization
 bgp log-neighbor-changes
 no auto-summary
1
 address-family ipv4 vrf VRF-2
 neighbor 10.10.0.2 remote-as 10002
 neighbor 10.10.0.2 activate
 no auto-summary
 no synchronization
 network 2.2.2.2 mask 255.255.255.255
 exit-address-family
 !
 address-family ipv4 vrf VRF-1
 neighbor 10.0.0.2 remote-as 10001
 neighbor 10.0.0.2 activate
 no auto-summary
 no synchronization
 network 1.1.1.1 mask 255.255.255.255
 exit-address-family
 
AS10001#
interface Loopback1
 ip address 100.0.0.1 255.255.255.255
!
interface FastEthernet0/0
 ip address 10.0.0.2 255.255.255.252
!
router bgp 10001
 no synchronization
 bgp log-neighbor-changes
 redistribute connected
 neighbor 10.0.0.1 remote-as 10000
 no auto-summary
AS10002#
interface Loopback1
 ip address 100.100.0.1 255.255.255.255
!
interface FastEthernet0/0
 ip address 10.10.0.2 255.255.255.252
!
router bgp 10002
 no synchronization
 bgp log-neighbor-changes
 redistribute connected
 neighbor 10.10.0.1 remote-as 10000
 no auto-summary

vrfを使用しているAS10000のshow コマンドが 若干馴染み無いものでした、、、

AS10000#show ip route vrf VRF-1 bgp
 100.0.0.0/32 is subnetted, 1 subnets
B 100.0.0.1 [20/0] via 10.0.0.2, 01:02:42

AS10000#show ip route vrf VRF-2 bgp
 100.0.0.0/32 is subnetted, 1 subnets
B 100.100.0.1 [20/0] via 10.10.0.2, 00:58:08
AS10000#

 show ip bgp summuryの代わりが見つからない、、、

AS10000#show ip bgp all
For address family: IPv4 Unicast

For address family: IPv6 Unicast

For address family: VPNv4 Unicast
BGP table version is 71, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
 r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10001:1 (default for vrf VRF-1)
*> 1.1.1.1/32 0.0.0.0 0 32768 i
r> 10.0.0.0/30 10.0.0.2 0 0 10001 ?
*> 100.0.0.1/32 10.0.0.2 0 0 10001 ?
Route Distinguisher: 10002:1 (default for vrf VRF-2)
*> 2.2.2.2/32 0.0.0.0 0 32768 i
r> 10.10.0.0/30 10.10.0.2 0 0 10002 ?
*> 100.100.0.1/32 10.10.0.2 0 0 10002 ?

For address family: IPv4 Multicast

For address family: IPv6 Multicast

For address family: NSAP Unicast

なるほど、どうやらすべてallをつけるんですね。

AS10000#show ip bgp all summury
For address family: VPNv4 Unicast
BGP router identifier 1.1.1.1, local AS number 10000
BGP table version is 71, main routing table version 71
6 network entries using 822 bytes of memory
6 path entries using 408 bytes of memory
4/3 BGP path/bestpath attribute entries using 496 bytes of memory
2 BGP AS-PATH entries using 48 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 1774 total bytes of memory
BGP activity 16/10 prefixes, 22/16 paths, scan interval 15 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.0.2 4 10001 569 571 71 0 0 08:05:14 2
10.10.0.2 4 10002 568 567 71 0 0 08:00:25 2

 

 

 

 

 

 

 

 

 

TLS実装の脆弱性 ROBOTO

脆弱性 https

2017/12/13にTLS実装の脆弱性が発表されました。この脆弱性はFacebookやPayPalなど有名なサイトも影響対象であり、RSA暗号の解読やトラフィックの暗号解読を目的とした鍵署名を実行できます。本脆弱性はサーバ側の問題のため、クライアント側では回避出来ないのが問題となっています。

本脆弱性の対象方法は以下となります。

  • 製品のアップデートを適用する。

  • TLS において RSA アルゴリズムを無効にする（暫定対処)

各メーカの対応状況は以下となります、対象製品がある場合はメーカに指示に従ってアップデートが必要となります。

Vendor Status Date Notified Date Updated
Cisco Affected 15 Nov 2017 12 Dec 2017
Citrix Affected 15 Nov 2017 12 Dec 2017
Erlang Affected - 12 Dec 2017
F5 Networks, Inc. Affected 15 Nov 2017 20 Nov 2017
Legion of the Bouncy Castle Affected 15 Nov 2017 12 Dec 2017
MatrixSSL Affected 15 Nov 2017 12 Dec 2017
Oracle Corporation Affected 15 Nov 2017 12 Dec 2017
wolfSSL Affected 12 Dec 2017 12 Dec 2017
Botan Not Affected 15 Nov 2017 20 Nov 2017
Dell EMC Not Affected 15 Nov 2017 29 Nov 2017
GnuTLS Not Affected 15 Nov 2017 13 Dec 2017
IAIK Java Group Not Affected 15 Nov 2017 06 Dec 2017
Microsoft Corporation Not Affected 15 Nov 2017 12 Dec 2017
OpenSSL Not Affected 15 Nov 2017 20 Nov 2017
RSA Security LLC Not Affected 15 Nov 2017 13 Dec 2017

最近では暗号化やSSLの問題が発表されることが多い気がします、いたちごっこになるのは仕方ないですが、改めてエンジニアはこの手の問題に注視し続ける必要があると思いました。

 

メールクライアントの脆弱性 Mailsploit

脆弱性

複数のメールクライアントで「Mailsploit」という脆弱性が発表されました。この脆弱性を利用することで、一部のスパム対策が無効化され、正常なメールとの見分けが困難になります。この攻撃の恐ろしいところは、スパム対策の回避だけでなく、受け取ったメール送信者の表示名を偽装することでユーザをも欺こうとするところです。

この仕組みは、RFC-1342 を使った攻撃で、非ASCII文字をメールヘッダー内で用いるためにQuoted-printableとBase64でエンコードされた文字列を、ほとんどのメールクライアントはデコードする際にサニタイズしません。そのため、ヌルバイト文字や改行文字などをここに混入させることで攻撃が可能になっています。iOSのメールクライアントだとヌルバイト文字を混入させることでそれ以降の文字列は無視されます。つまりそれ以前の文字列のみが表示されるという問題があります。

www.mailsploit.com

本問題を回避するためには以下の対策を実施する必要があります。

  •  対応済みのメールクライアントを利用する
  •  不審なメールはメールヘッダーを確認する
  •  PGP/GPG などの仕組みを利用する

JPCERT/CCは各メーカの対応状況を記載しています。

メールクライアント 対象環境

Mailsploitの

影響

 対応状況
Apple Mail iOS, MacOS 有り 対応中
Mozilla Thunderbird ≤ 52.5.0
SeaMonkey ≤ 2.4.8		 MacOS, Windows 有り 対応しない
Mail for Windows 10 Windows 有り 対応中
Microsoft Outlook 2016 MacOS, Windows 有り 対応中
Yahoo! Mail iOS, Android 有り 修正済み(2017/10/19)
Spark ≤ 1.4.1.392 MacOS 有り 報告済み
Spark iOS 有り 報告済み
ProtonMail iOS, Android 有り 修正済み(2017/9/1)
Polymail MacOS 有り 報告済み
Airmail ≤ 3.3.3 MacOS 有り 報告済み
BlueMail ≤ 1.9.2.62 Android 有り 報告済み
TypeApp iOS, Android 有り 報告済み
AquaMail Android 有り 報告済み
Opera Mail MacOS, Windows 有り 対応しない
Postbox ≤ 5.0.18 MacOS, Windows 有り 報告済み
Newton Android, MacOS,
Windows		 有り 対応中
Guerrilla Mail Android 有り 報告済み
Email Exchange + by MailWise Android 有り 報告済み
AOL Mail Android 有り 報告済み
TouchMail Windows 有り 報告済み
Mailbird Windows 無し  
Gmail / Inbox by Gmail iOS, Android 無し  
eM Client Windows 無し  
Claws Mail / Sylpheed Windows 無し  
OE Classic Windows 無し  
Webメールクライアント 対象環境

Mailsploitの

影響

 対応状況
Hushmail Web 有り 修正済み(2017/8/27)
Openmailbox.org Web 有り 修正済み(2017/8/27)
Open Xchange (Mailbox.org) Web 有り 修正済み(2017/9/25)
ProtonMail Web 有り 修正済み(2017/9/1)
Yahoo! Mail (new interface in beta) Web 有り 修正済み(2017/11/12までに)
Mailfence Web 有り 対応中
Microsoft Outlook Web Web 無し  
Microsoft Exchange 2016 Web 無し  
Microsoft Office 365 Web 無し  
Gmail Web 無し  
Fastmail Web 無し  
GMX / Mail.com / 1&1 Web 無し  
サポートチケットシステム 対象環境

Mailsploitの

影響

 対応状況
Supportsystem Web 有り 報告済み
osTicket Web 有り 報告済み
Intercom Web 有り 修正済み(2017/9/12)
コミュニティで見つけた候補 対象環境

Mailsploitの

影響

 対応状況
Vivaldi Web 有り 報告済み
K-9 Mail Android 有り 報告済み
MailMate MacOS 有り 修正済み(2017/9/12)
eM Client Windows 無し  
Tutanota Web 無し  
Sylpheed 3.6.0 Linux 有り(※)  
Jolla Mail Sailfish OS
by JOLLA		 有り(※) 報告済み
RainLoop Web 有り(※) 報告済み
IBM Notes Web 有り(※)  
IBM Verse Web 有り(※)  
IBM Verse iOS, Android 有り(※)  
NINE Email & Calendar Android 有り(※)  
Roundcube Web 無し(※)  
KMail Linux 無し(※)  
※発見者やベンダーが未確認

Cisco VoIP環境作成時の注意点

VoIP WLC Ciisco

SkypeやLINEなど、最近ではスマートフォンを利用したVoIPが市民権を得ています。企業でも内線通話が可能なVoIP環境が浸透してきており、通話品質も以前より安定しています。しかしVoIP環境には多くの考慮すべき設計があるため、企業向けVoIP環境作成時の注意点を記載します。

１. チャンネル設計

  • 802.11gを使用する場合、1ch 6ch 11chを固定で使用してください。自動は推奨さしません。
  • 802.11aを使用する場合、36ch 40ch 44ch 48chを使用してください。DFSの影響を受けるW53 W56は推奨しません。
  • 同一エリアだけでなく、上下階の干渉にも注意してください。壁の素材によっては頻繁にすり抜けて干渉します。 
  • 無線LANはCSMA/CAのため、同一キャリアセンスドメイン内ではAPを増やしても同時通話数は増えないので注意してください。

2. 出力設計

  • 端末の受信レベルは周囲の人や端末の持ち方で5～10dbほど変動します。変動を考慮にいれたエリア設計を行い、サーベイによる確認を実施してください。

3. 低レート抑止

  • 低レート通信はAirtimeを占有するためなるべく抑止すべきですが、端末によっては低レートを制限することで不安定になる場合があります。利用する端末で動作確認を行い、不要な低レート通信を抑止して下さい。

4. ステルスモード設定

  • スマートフォンを使用する場合、ステルスモードを有効化していないとハンドオーバに時間がかかったり、帰属外れを起こす場合があるため、ステルスモードを有効化して下さい。

5. DTIM設定

  • iPhoneを使用する場合はDTIMは1にして下さい。
  • Androidを使用する場合はDTIMは10にして下さい。iPhone混在時も同様です。

6. IPアドレス設定

  • IPアドレスは余裕を持った設計をしてください、アドレスのリース時間も短縮することを検討して下さい。
  • ハンドオーバが想定されるAP間では、同一サブネットに収容されるように設計して下さい。
  • iPhoneではDNSサーバのIPアドレスが設定されないとWiFiに帰属しません。DNSのIPアドレスも払い出すか設定するようにして下さい。

7. SIP-CAC設定

  • WMM/TSPECとSIP-CACは混在出来ません。一般的にはSIP-CACを使用するとか思われます。
  • SIP-CACでは帯域超過時のロードバランスがサポートされていないため、発信/着信時に使用しているAPで帯域が確保できない場合、帯域が開放されるか帯域が確保可能な他のAPへハンドオーバするまで発着信が不可となります。
  • Preferred Calls機能を利用することで、APに設計した帯域値を超過した場合でも緊急電話は規制されずに発信可能です。事前にWLCに緊急通話番号の登録が必要なため、要件に応じて設計して下さい。ただし、アプリが対応していない場合があるので注意して下さい。

SD-WAN

SD-WAN

先日、SD-WAN(Software Defined WAN)について説明を受けてきました。今までSD-WANについてあまり詳しく触れたことがなく、漠然とOpenFlowのような構成を想像していたのですが、実態はちょっと違っていました。

まずSD-WANサービスの定義がメーカによってマチマチのようです。また、新しい技術を利用しているのかと思いましたが、説明を受けたメーカのサービスは簡単に言うとIPSecやQoSをGUIで簡単に出来ますよ！ついでにトラフィックも可視化しますよ！というものでした。実際にCiscoのルータで同じことが設定出来ないか聞いてみると、出来てしまうそうです。可視化に関してはMRTGなりNetflowが必要ですが、技術的に革新的なものではなく、既にある技術を簡単に実装できるというのが話を聞いて受けた印象です。今流行のAIもそうですが、今後は煩雑だったCLIの設定も簡単になっていき、Sierとしての仕事のあり方も変わってくるのかなと思いました。

HP 法人向けプリンタの脆弱性

脆弱性

HPの法人向けプリンタ「LaserJet」「PageWide」「LaserJet Managed」「OfficeJet」の各シリーズはSolution DLLの署名検証に不備があり、任意コードが実行される可能性があるそうです。CVSSスコアは 8.1と高く、HPはファームウェアを公開済みで早急にアップデートするように呼びかけています。

www.itmedia.co.jp

プリンタを狙った攻撃は数年前から実在しますが、記事によるとセキュアなプリンタは全体の2%に過ぎないそうです。実際私が担当した案件でもプリンタとの通信を厳密に規制したことはあまり無かったような、、、
今後はプリンタも脆弱性を意識し、必要なポート番号以外の通信を許可しないことが当たり前になってくるのかもしれません。とは言ってもプリンタと端末が同一セグメントにいることは珍しくないかもしれません。そうするとNW機器で実現出来る現実的な設計はプリンタのアップリンクポートにPACLを使用することですかね。。

Palo Alto SSL Decryption

ssl Palo Alt

最近ではSSL Decryption(復号)機能は殆どのUTM/Proxy製品が対応していると思います。Palo Altoの場合、SSL Decryptionに3種類の方式があるため、要件に応じて使い分ける必要があります。

(1) SSL Forward Proxy

一般的なSSL Decryption機能であり、ClientからServer向けのSSL通信上にProxyとして存在します。サーバ証明書をPalo Altoが再署名(発行元、RootCAとして署名）するため、クライアントのWebブラウザにPalo Altoの証明書をインポートしなければなりません。また、TAPモードでは使用出来ません。

＃公的証明書をインストールすればクライアントのWebブラウザにインストールしなくてもよいとマニュアルには書いてあるんですが出来ないらしい、、Palo自体に証明書自体入りませんでした。

 

(2)SSL Inbound Inspection

Proxy処理をせずに透過的に検閲します。これは事前にPalo Altoにサーバ証明書と秘密鍵をインポートしておくことで実現します。当然ですが復号化したいサイトのサーバ証明書が必要なため、特定のサイトを対象とした機能です。

(3)Decryption Port Mirror

復号化したトラフィックをミラーリングにより転送します。利用には機種制限と追加ライセンスが必要です。また、アプリケーションデータのみミラーされるため、L2～L4のデータはミラーされません。

SSL復号化機能を有効化すると正常に表示されないサイトや、正しく動作しなくなるアプリケーションが存在するため、導入は慎重に行うべきです。基本的に正しく動作しないサイトに関しては除外設定するしかありません。

以下のケースではSSL復号化に失敗します。

  • Windows Updateなど特定の証明書からの通信を許可することが実装されたクライアントソフト
  • 独自またはRFC非準拠のプロトコルを仕様したアプリケーション
  • Skype/bitTorrentなど回避的アプリケーション
  • SSL VPN
  • TLS1.3など使用するPalo Altoが対応していない暗号方式
  • Palo Altの証明書を利用できないクライアントソフト