機械学習型セキュリティソフトの注意
先日行われた情報セキュリティEXPOで興味深い説明を受けたのでメモを残しておきます。マルウェア対策としては機械学習型と振る舞い検知型が一般的です。最近は機械学習型のセキュリティソフトがトレンドなのか、各メーカがこぞって製品を出しています、どのメーカも検出率99.9%など非常に高い数値を出していて凄いな～と考えていたのですが注意事項があるそうです。まず一般的な機械学習型が検出可能なマルウェアは実行ファイルのみ対象だそうです。つまり実行メモリやレジストリに格納されるようなファイルレスマルウェアには無力な場合があるそうです。各メーカを比較する際は、何を対象とした検出率であるか確認する必要があります。
ファイルレスマルウェアに対応するためにはシグネチャベースによる振る舞い検知が有効ですが、機械学習型との違いは既存のマルウェアにしか効果が無いことです。シグネチャにマッチしないゼロデイ攻撃には対処できません。
また、機械学習型/振る舞い検知型に関わらずランサムウェア対策は別途行う必要があります。仮にランサムウェアを検知出来たとしても、プロセスを停止する前に一部のファイルが暗号化される可能性が高いためです。定期的なバックアップを取って復元するのか、ランサムウェアが最初に暗号化しがちな最も新しくアクセスしたファイルと過去にアクセスしたファイルにダミーファイルを用意し、ダミーファイルが暗号化された時点でプロセスをとめるような専用製品を使った対策を検討して下さい。Windowsはデフォルトでバックアップファイルを保持していますが、最近のランサムウェアはこのバックアップを消してから暗号化を開始するので、対策をしないと無力です。
今後のセキュリティ対策としてはゼロデイ対策として機械学習を、ファイルレスマルウェア対策として振る舞い検知型を、ランサムウェア対策に暗号化ブロックとバックアップの複合的なセキュリティ対策が必要だと思いました。
Webブラウザの仮想化
先日行われた情報セキュリティEXPOに行ったところ、気になっていたWebブラウザの仮想化についてデモがあったので説明を受けてきました。デモが行われていた製品は「Menlo Security Isolation Platform」です。
ブラウザを仮想化することで、クライアント端末には仮想化されたコンテナ内で実行した結果のみ描写されるため、ページの改ざんによるマルウェアの感染やリダイレクトによって悪意のあるサイトに飛ばされても影響範囲を仮想コンテナ内に閉じ込めることが出来ます。ダウンロードするファイルもHTML5に変換し、余計なものを取り除くことで無害化出来るそうです。また、クライアントレスでプロキシサーバとして設定するだけで導入でき、既存のプロキシサーバがある場合も上位サーバとして指定するだけで良いそうです。注意点として変換出来ない実行ファイル等は別途対策がいるとのことです。
この手の製品は他のメーカも出しており、複数メーカで検討する場合は金額はもちろんですが、描写遅延を比べると良いとのことでした。
最近の主なマルウェア感染経路は未認可のUSB等の外部媒体か、メール、Webブラウザ経由だと考えています。外部媒体はそもそも繋げられないのが当然になってきましたし、メールはOffice365のようにクラウド化され、API連携のセキュリティ対策が普及してくるかなと思っています。デモを見るとほとんど遅延もなく使い勝手は良さそうだったので、今後はWebブラウザも仮想化が当たり前になるのかな～と思いました。NSXの分散ファイアーウォールは非常に便利ですが、めちゃくちゃ高いので導入ハードルが高いですし、そもそもNWの仮想化はCPUがまだスイッチングに最適化できていないのでは？（専用品よりスループットが出ないのでは）と疑問があります。
デジタル署名付きマルウェア
過去にイラクの核プログラムを標的としたマルウェアが合法的なデジタル署名付き(コードサイニング)のマルウェアだったことは有名だと思います。この手法は年々増加しており、近年のマルウェアは正規の証明書で署名されているものが徐々に一般的となっています。
本来のコードサイニングとは実行ファイルの開発元を証明することおよび、実行ファイルが改ざんされていないことを証明します。攻撃者がマルウェアにコードサイニングを実施する主な理由としては、まずユーザにファイルを信頼させるためです。また、多くのセキュリティ対策ソフトでは署名している実行ファイルを検査せず、振る舞いをチェックしない（ホワイトリスト扱いにしている）ものが多いためです。これはスキャンする際のホストOSの負荷を下げるために実装されている場合があります。
検証として複数のマルウェアに署名をつけた状態とつけていない状態でマルウェア対策ソフトを実行したところ、TrendMicroやKaspersky Labなどメジャーな製品でも一部検知できなくなることが確認されています。検証の結果、平均して2割、製品によっては8割ほど検出率が低下したそうです。
使用されている正規の証明書は正規の会社と結託したり、架空の会社をでっち上げて正規の手順で認証局から証明書を発行してもらう場合もありますが、企業などから盗み出されている場合もあります、そして盗まれた企業はその事実を知ることは難しいのが現状です。さらに攻撃者は複数の証明書でデジタル署名するなど、今まで以上に検出されない工夫を行ってきています。
証明書の管理を徹底するのはもちろんですが、デジタル署名されているから安心という認識は改めたほうが良さそうです。
Savitech製USBオーディオドライバの脆弱性
2017/11/6 IPAはSavitech製USBオーディオドライバの脆弱性を発表しました。本脆弱性はSavitechのルート CA証明書を、ユーザーの許可なくWindowsの信頼されたルート証明機関ストアにインストールしてしまうそうです。仮にSavitechの秘密鍵が漏洩した場合、攻撃者が悪用すればウェブサイト等のなりすましや、悪意のあるソフトウェアの配布、暗号化されたデータやトラフィックの復号が行われる可能性があります。幸いなことに、現時点では秘密鍵の漏洩は確認されていないそうです。
本問題の対策として、以下のルート証明書がインストールされていれば削除する必要があります。確認方法は「スタートのプログラムとファイルを検索」に「mmc」と入力→「ファイル」→「スナップインの追加と削除」→「証明書」を選択→「ユーザーアカウント」を選択→「信頼されたルート証明期間」から該当の証明書が無いか確認します。
SaviAudio root certificate #1
有効期間: Thursday, May 31, 2012 - Tuesday, December 30, 2036
シリアル番号: 579885da6f791eb24de819bb2c0eeff0
Thumbprint: cb34ebad73791c1399cb62bda51c91072ac5b050
SaviAudio root certificate #2
有効期間: Thursday, December 31, 2015 - Tuesday, December 30, 2036
シリアル番号: 972ed9bce72451bb4bd78bfc0d8b343c
Thumbprint: 23e50cd42214d6252d65052c2a1a591173daace5
また、証明書の削除に関わらず、最新のドライバをインストールする必要があります。
GRE ( Generic Routing Encapsulation )
IPSecに引き続き、GREについても環境を作成する機会があったので整理します。GREはトンネリングプロトコルの一つです。トンネリングと言っていますが、実態はGRE機能を有効化した機器の両端でGREヘッダを付与および剥奪しています。
GREの良いところはGREを有効化した機器の経路上に存在する機器がGREヘッダに付与されたIPアドレス以外解決しなくて良いところです。下記の例だとGREヘッダの送信元 IP、宛先IPはLoopback0のIPアドレス(1.1.1.1および2.2.2.2)に設定しているため、RelayRT00はPC00/01のセグメント(192.168.0.0/24および192.168.10.0/24)のルート情報が不要になります。また、トンネリングによりマルチキャストアドレスも伝送できるため、直接接続していない場合もネイバー関係を形成することが出来ます。ただし、Loopback0のIPアドレスは解決できる必要があります。
GRERT00#show run interface tunnel 0
interface Tunnel0
ip address 10.0.0.1 255.255.255.0
tunnel source 1.1.1.1
tunnel destination 2.2.2.2
GRERT01#show run interface tunnel 0
interface Tunnel0
ip address 10.0.0.2 255.255.255.0
tunnel source 2.2.2.2
tunnel destination 1.1.1.1
実際にパケットキャプチャをしてみると送信元IPと宛先IPはTunnel Interfaceに割り当てたIPになりますが、GREは暗号化機能を保有していないため、実際のIPも確認できます。暗号化まで期待する場合はIPSecを組み合わせる必要があります。
Wiresharkは優秀なため、画面上部は実IPアドレスが表示されていますが、下部を見るとSrc:1.1.1.1 Dst:2.2.2.2とGREヘッダのIPアドレスが表示されます。中継機器はこの箇所を見てルーティングを行うため、内部のアドレス情報を理解する必要がありません。Arubaをはじめとした無線LANコントローラもAPとGREを形成するため、複数のSSIDとVLANを設定してもAPのアップリンクをTrunkにしなくて良いのは同じ理屈でGREヘッダだけ見て転送するからです。当然コントローラ障害時にAPが自立する場合は、APが各Vlan Tagを付与する必要があるのでアップリンクはTrunkにする必要があります。
GREの注意点として暗号化が実施されないこと、MTUが1476になるため、MTUサイズの設計を適切にする必要があります。
実際はIPSecもトンネリング技術なのですが、Ciscoの仕様でユニキャストしか伝送できないため、マルチキャストを伝送する場合はGREを使用するか、組み合わせる必要があります。個人的に拠点間でダイナミックルーティングを実現するためにIPSec+GREを使うパターンはあまり無い気がします。。設計をシンプル化したいのもありますが、大規模な環境を作る場合も一度に拠点展開することはあまりないので、拠点展開手順にStatic Routeを追加するところまで盛り込んでしまうことが多いので、、、
最終設定時の各コンフィグは以下となります。
GRERT00#
interface Tunnel0
ip address 10.0.0.1 255.255.255.0
ip ospf network point-to-point
tunnel source 1.1.1.1
tunnel destination 2.2.2.2
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
ip address 172.16.0.1 255.255.255.0
!
interface FastEthernet0/1
ip address 192.168.0.254 255.255.255.0
!
router ospf 1
router-id 1.1.1.1
log-adjacency-changes
network 10.0.0.0 0.0.0.255 area 0
network 192.168.0.0 0.0.0.255 area 0
!
ip route 2.2.2.2 255.255.255.255 172.16.0.254
GRERT01#
interface Tunnel0
ip address 10.0.0.2 255.255.255.0
ip ospf network point-to-point
tunnel source 2.2.2.2
tunnel destination 1.1.1.1
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
ip address 192.168.10.254 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 172.16.10.1 255.255.255.0
duplex auto
speed auto
!
router ospf 1
router-id 2.2.2.2
log-adjacency-changes
network 10.0.0.0 0.0.0.255 area 0
network 192.168.10.0 0.0.0.255 area 0
!
ip classless
ip route 1.1.1.1 255.255.255.255 172.16.10.254
no ip http server
no ip http secure-server
RelayRT00#
interface FastEthernet0/0
ip address 172.16.0.254 255.255.255.0
!
interface FastEthernet0/1
ip address 172.16.10.254 255.255.255.0
!
ip route 1.1.1.1 255.255.255.255 172.16.0.1
ip route 2.2.2.2 255.255.255.255 172.16.10.1
IPSecとNPAT併用時の注意点
久しぶりにIPSecとNAPTを併用した環境を作ったら動作に違和感を覚えたので書き出しておきます。
PC01(172.16.0.1)からPC02(172.16.10.1)にPing疎通時、以下のACLによってIPSecの暗号化トラフィック対象としていた場合、IPSecのセッションが形成され疎通可能になります。
crypto map CMAP 1 ipsec-isakmp
set peer 210.154.183.2
set transform-set TSET
match address 101
crypto map CMAP
!
access-list 101 permit ip 172.16.0.0 0.0.0.255 172.16.10.0 0.0.0.255
環境作成当初、誤ってNAPTされる対象トラフィックも同一の値を設定してしまい、IPSecが形成されませんでした。
ip nat inside source list 100 interface Dialer1 overload
!
access-list 100 permit ip 172.16.0.0 0.0.0.255 172.16.10.0 0.0.0.255
CERT01とWANのポイントをキャプチャすると以下のようなログが出ており、PC01のIPアドレスがCERT01のDialer interfaceのIPにNAPTされていることがわかりました。
あれ、、、CiscoってIPSecを設定している場合、ルータの処理順って暗号化トラフィックの指定のほうが早いんじゃなかったけ、、、と思って処理順序を調べてみました。
よく見るとIPSecのACLチェックは１番だけど暗号化は14番ですね、、だから暗号化前にNAPTさされてしまい、暗号化されず出力されるんですね、、、勉強になりました。
当然NAPT用のACLを変更し、IPSecの暗号化トラフィックは対象外にすれば問題なく通信が出来ました。
CERT01#show crypto isakmp sa
dst src state conn-id slot status
210.154.183.2 210.154.182.1 QM_IDLE 1002 0 ACTIVE
最終設定時の各コンフィグは以下となります。
hostname CERT01
!
crypto isakmp policy 1
encr aes
hash md5
authentication pre-share
group 2
crypto isakmp key hy address 210.154.183.2
!
crypto ipsec transform-set TSET esp-aes
!
crypto map CMAP 1 ipsec-isakmp
set peer 210.154.183.2
set transform-set TSET
match address 101
!
interface FastEthernet0/0
pppoe enable
pppoe-client dial-pool-number 1
!
interface FastEthernet0/1
ip address 172.16.0.254 255.255.255.0
ip nat inside
!
interface Dialer1
ip address negotiated
ip nat outside
ip virtual-reassembly
encapsulation ppp
dialer pool 1
dialer-group 1
ppp authentication chap callin
ppp chap hostname hy@hy.com
ppp chap password 0 hy
crypto map CMAP
!
ip route 0.0.0.0 0.0.0.0 Dialer1
!
ip nat inside source list 100 interface Dialer1 overload
!
access-list 100 deny ip 172.16.0.0 0.0.0.255 172.16.10.0 0.0.0.255
access-list 100 permit ip any any
access-list 101 permit ip 172.16.0.0 0.0.0.255 172.16.10.0 0.0.0.255
dialer-list 1 protocol ip permit
hostname CERT02
!
crypto isakmp policy 1
encr aes
hash md5
authentication pre-share
group 2
crypto isakmp key hy address 210.154.182.1
!
crypto ipsec transform-set TSET esp-aes
!
crypto map CMAP 1 ipsec-isakmp
set peer 210.154.182.1
set transform-set TSET
match address 101
!
interface FastEthernet0/0
ip address 172.16.10.254 255.255.255.0
ip nat inside
!
interface FastEthernet0/1
pppoe enable
pppoe-client dial-pool-number 1
!
interface Dialer1
ip address negotiated
ip nat outside
encapsulation ppp
dialer pool 1
dialer-group 1
ppp authentication chap callin
ppp chap hostname hy1@hy.com
ppp chap password 0 hy1
crypto map CMAP
!
ip route 0.0.0.0 0.0.0.0 Dialer1
!
ip nat inside source list 100 interface Dialer1 overload
!
access-list 100 deny ip 172.16.10.0 0.0.0.255 172.16.0.0 0.0.0.255
access-list 100 permit ip any any
access-list 101 permit ip 172.16.10.0 0.0.0.255 172.16.0.0 0.0.0.255
dialer-list 1 protocol ip permit
hostname WAN
!
username hy@hy.com password 0 hy
username hy1@hy.com password 0 hy1
!
bba-group pppoe PPP1
virtual-template 1
!
bba-group pppoe PPP2
virtual-template 2
!
interface Loopback1
ip address 1.1.1.1 255.255.255.255
!
interface Loopback2
ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
pppoe enable group PPP1
!
interface FastEthernet0/1
pppoe enable group PPP2
!
interface Virtual-Template1
ip unnumbered Loopback1
peer default ip address pool POOL1
ppp authentication chap
!
interface Virtual-Template2
ip unnumbered Loopback2
peer default ip address pool POOL2
ppp authentication chap
!
ip local pool POOL1 210.154.182.1
ip local pool POOL2 210.154.183.2
DDE機能を使ったマクロレスマルウェア
DDE(Dynamic Data Exchange)とはWindowsの機能であり、各種実行ファイルを起動することが出来ます。本機能を使うことでMicrosoft Wordにおいてマクロを使わずにマルウェアを実行させる方法が公表されました。
DDE自体は便利な機能ですが、本機能を使って実行ファイルの起動許可を求める文章は、以下のようにあまりセキュリティリスクを意識させません。
この文書には、他のファイルへのリンクが含まれています。リンクされたファイルのデータでこの文書を更新しますか？
実際にトロイの木馬やボットネットなど、本機能を使ったマルウェアが存在しています。この機能はMicrosoftの正当な機能であるため、ほとんどのウィルス対策ソフトは警告やブロックをすることはありません。 本マルウェアから身を守るためには各Officeの「開いているときに自動リンクを更新する」オプションを無効にする必要があります。Word2013であれば「ファイル」→「オプション」→「詳細設定」→「全般」にあるのでチェックを外しておくか、信頼できない送信元からの文章は常に疑いましょう。
Aruba Troubleshooting CLI
Arubaのtroubleshootingで使うCLIコマンドを以下に記載します。
＃随時更新してきます。
・接続User一覧
(Controller)#show user-table verbose
・接続AP一覧
(Controller)#show ap active
・ライセンス一覧
FlagがEになっているか確認してください
(Controller)#show license verbose
・ARMのチャンネル変更履歴を表示
頻繁に変更されている場合、干渉源がないか確認してください
(Controller)#show ap arm history ap-name <ap-name>
・WLCのshow tec
(Controller)#tar logs tech-support
(Controller)#copy flash: logs.tar tftp:<tftp address> logs.tar
・APのshow tec
(Controller)#show ap tech-support ap-name <AP-name>
ISDNサービス廃止に伴うIP網への移行
将来のISDNサービスの停止に伴い、NTT東西がIP網への移行計画を正式発表しました。実際のIP網への移行開始は2024年初頭から始まり、2025年初頭までに完了させる予定だそうです。これに伴う終了サービスは以下となります。
- INSネット64
- INSネット64ライト
- INSネット1500
NTT東西は移行対応が間に合わないユーザ向けに暫定対応策を用意する予定ですが、基本的にはシステムをIP網に移行することを推奨しています。補完策自体も現行サービスと完全に同等なサービス品質にはならないそうです。
移行後のイメージは以下のとおりです。IP網に移行するうえで１番気になるのは遅延です。検証データによると現行比で1.1~4.0倍程度のデータ遅延があるそうです。現在のサービスがIP化による遅延を許容できるか検討が必要です。許容できない場合はサービス自体のリプレイスを検討する必要があります。
NTT東西は検証環境を用意しており、配送費等は別として基本的に無償で利用出来ます。実際の検証はすべてユーザで実施する必要がありますが、現状のサービスがIP化に耐えられるか、一つの指標になるかもしれません。また、以下のリンク先に一部の検証結果を記載しています。リンク先にも記載されているとおり、NTTの検証結果でもIP化による遅延が確認されています。よくよく見ると「通信可能なことが確認できました」と記載されている箇所も、注意書きで「ISDN回線利用時と比べ、処理時間が増加しています」とあります。
もともとデータ目的でINS回線を使用している場合、(金融系を除いて)バックアップ回線や低料金の変わりに低速度で問題ないサービスを利用している場合が多いため、IP化による遅延が問題ない可能性もあります。現在のサービスの許容範囲を確認し、必要であればリプレイス提案をしていく必要があります。今後MVNOに対応したLTEルータなんて出てきたら選択肢が増えていいんですけどね、、、と思いましたが結局急なサービス終了が怖くて三大キャリアを選んじゃいそうです。。。
iOS版 AnyConnectについて
現在公開されているiOS版「AnyConnect (ver.4.0.07070)」は従来の同アプリと名称が異なります。以前の同アプリは「Cisco Legacy AnyConnect」としてver.4.0.05069が配布されています。
今後、同アプリは「AnyConnect」がスタンダート版になります。新しい「Any Connect」を使用する場合、新たにインストールが必要でかつ設定や証明書も引き継がれません。また、Emailやブラウザからの証明書取得が出来なくなりました。AnyConnect UIからの手動インストールかURI handlerで取得して下さい。
「Cisco Legacy AnyConnect」と「Any Connect」の同時インストールは非推奨です。「Cisco Legacy AnyConnect」は今後メンテナンスがされないため、同アプリを利用しているクライアントには新verに移行するように調整が必要です。
