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

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

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が提示されていることは珍しくありませんが、セキュリティ対策はどこまで補償（対象条件/金額）するのか、明示することが難しいため、詳細情報を待ちたいと思います。

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の問題が発表されることが多い気がします、いたちごっこになるのは仕方ないですが、改めてエンジニアはこの手の問題に注視し続ける必要があると思いました。