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

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

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の証明書を利用できないクライアントソフト

Palo Alto User-ID機能の注意点

Palo Alt

Palo AltoのUser-ID機能はActive Directoryと連携することでユーザ単位の通信制御を実現することが出来ます。本機能の大前提として、1 ユーザ = 1 IPアドレスでの利用となります。これはPalo AltoではIPアドレス単位で通信制御を行うためです。

f:id:hy0:20171122233940g:plain

実際の動きとしては、まずPan-Agentが連携するADサーバの監視ログからIPアドレスとユーザIDの対応テーブル(user_ip_map.txt)を作成します。その後、Palo Alto本体はuser_ip_map.txtを元にuser_ip_mapを作成します。つまりADサーバに監視ログの登録設定がされていないと動作しません。

Palo Altoに正しくユーザを識別させるため、以下のポリシーを遵守します。

  • 同一ドメインのサーバにアクセスする場合、同一のユーザでアクセスする
  • 複数ユーザの同時ログインを禁止する
  • ローカルアカウントでログインさせない

ローカルアカウントでログインされた場合、IPアドレスと通信制御を紐付けているため、Palo Altoでログオフ検知が出来ないとログオフ前のポリシーが適用されてしまい、結果的になりすましによる権限昇格を許してしまいます。ADサーバの監視ログからログオフを追跡することは出来ないため、Pan-AgentではNetBios/WMIプローブによるログオフ監視機能を保有しています。この機能を使ってuser_ip_mapからIPアドレスを参照し、該当IPアドレスにプローブを送ることでユーザのログインを確認することが出来ます。つまり端末側にNetBios/WMIプローブが許可されている必要があります。許容出来ない端末に関してはuser_ip_map.txtのタイムアウトタイマー(デフォルト45分)を最適化する必要があります。

 

proxy-arp

proxy-arp

proxy-arpは他のデバイス向けのarp要件を代理応答する機能です。proxy-arpが有効なインターフェースでarp要求を受信すると、その機器が代理応答してくれるため、arp要求を行った端末からは同じセグメントにいるように見せることができます。

下記図ではPC01とPC02は別セグメントになりますが、RT01はproxy-arpを有効にしているため、PC01はルーティング設定を行わずにPC02と通信可能です。

f:id:hy0:20171120213950p:plain

PC01#ping 172.16.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.10.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/34/44 ms
PC01#

ルーティング設定を行いたくない事情がある場合は便利ですが、セキュリティ上は望ましくないので無効化したほうが良いと思います。特にCiscoはデフォルトで有効のため注意してください。

全体で無効化したい場合は以下のコマンドを使用します。

RT01(config)#ip arp proxy disable

インターフェース単位で無効化したい場合は以下のコマンドを使用します。

RT01(config-if)#no ip proxy-arp

 動作確認をする場合は都度arp-cacheをクリアすることを忘れないでください。

 

Catalyst9300シリーズ

Catalyst9300シリーズは高度な学習機能と自動制御を実現できる新しい製品群です。Catalyst9300シリーズから従来とは異なるパッケージ体系で提供されます。新しい体系は「ADVANTAGEパッケージ」および「ESSENTIALSパッケージ」の2種類となります。DNAライセンスはサブスクリプションとなり、有効期限が存在します。

以下に従来との比較を記載します。価格帯は「Catalyst 9300」→「Catalyst 3850」「Catalyst 9400」→「Catalyst 4500E」「Catalyst 9500」→「Catalyst 4500X」と同等程度になる予定だそうです。

f:id:hy0:20171116232110p:plain

f:id:hy0:20171116232847p:plain

ADVANTAGEパッケージはESSENTIALSパッケージの機能を含んでいます。現時点ではESSENTIALSからADVANTAGEへのアップグレードは出来ないため、アップグレードしたい場合は、筐体毎購入しなおす必要があります。また、DNAライセンスは３年分が標準添付されていますが、DNAライセンス機能を使用する場合は更新を忘れないようにして下さい。ライセンスの有効化には再起動を伴うため注意が必要です。

DHCP Relayについて

DHCP

通常DHCPによるIPアドレス取得はDHCP ClientとDHCP Serverが同一セグメントに存在する必要があります。IPアドレス取得時にDHCP Clientからの発信する要求(DHCP Discover)がブロードキャストを使用するためです。しかしDHCPサーバをDHCP Clientと同一セグメントに設置することは稀なので、ユニキャストに変換して通信を行うDHCP Relay機能を使います。先日DHCPサーバを評価しているときに「DHCP Serverは何を元にDHCP Clientに対して払い出すセグメントを決めているんだろう」と思い、キャプチャしたパケットを確認しました。

検証構成図は以下となります。

f:id:hy0:20171115222120p:plain

 

てっきりDHCP Discoverを確認すればサブネットマスク情報が載っていて、送信元IPアドレスとの組み合わせで払い出すセグメント(プール)を決めているのかな～と思ってキャプチャを確認すると、、、サブネット情報がどこにも無い、、

f:id:hy0:20171115222410p:plain

 

もちろんDHCP Offerにはサブネットマスクもデフォルトゲートウェイ載っています。これはDHCPプールで設定しているので当然ですね、、、

f:id:hy0:20171115222741p:plain

つまりDHCP Serverは自身のプールの中から送信元IPアドレスにマッチしたものを払い出すだけなんじゃないか？と仮説を立ててプールを172.16.0.0/16にしてみました。

DHCP_Server#
!
ip dhcp pool DHCP_POOL
 network 172.16.0.0 255.255.0.0
 default-router 172.16.0.254
DHCP_Client#
*Nov 15 22:29:42.551: %DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0/0 assigned DHCP address 172.16.0.1, mask 255.255.0.0, hostname DHCP_Client

想定どおり172.16.0.0/16のIPアドレスが払い出されました。このことからDHCP Serverが払い出すプールは送信元IPアドレスだけ見ていることがわかります。確かにサブネット情報はルーティングプロトコル以外あまりやりとりされないのですが、根拠も無くサブネットマスクも見ているものだと思い込んでいました。ちなみに送信元IPが同じでもDHCP ServerがDHCP Clientを見分けられるのはDHCP Discoverの中にClient Macが格納されているからです。

f:id:hy0:20171115223548p:plain

今まで当たり前にやってきたことも掘り下げる必要があることを痛感しました。。各機器のconfigは以下のとおりです。 

DHCP_Server#
!
ip dhcp pool DHCP_POOL
 network 172.16.0.0 255.255.0.0
 default-router 172.16.0.254
!
interface FastEthernet0/1
 ip address 172.16.10.100 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 172.16.10.254
!
DHCP_Cient#
!
interface FastEthernet0/0
 ip address dhcp
!
interface FastEthernet0/0
 ip address 172.16.0.254 255.255.255.0
 ip helper-address 172.16.10.100
!
interface FastEthernet0/1
 ip address 172.16.10.254 255.255.255.0
!