Step5では「IPv6」のデータを検査します。
IPv6はVirus Totalでは調べられないので、Windowsのツール、Google検索、Wiresharkを使用して検査します。
検査用データには不要なデータが多数あるので、無視するものについて説明いたします。
上記のデータは今回の検査では無視します。 それぞれを次ページ以降で説明します。
3/58前の説明だけだと分かりにくいかもしれませんので、もう少し詳しく説明します。
上記のように、2文字の値が、コロン記号で 6つに区切られたものは「MACアドレス」というデータです。
7/58MACアドレスは、LANの内部で機器を識別するためのものです。
今回おこなっている検査は、外部の攻撃者によるハッキングの有無を確認する検査なので、MACアドレスは関係ないので無視して良いです。
先頭が「f」のデータは、ネットワークの内部で使用するデータです。
これも先程のMACアドレスと同様に、外部からのハッキングとは無関係なデータですので、無視して良いです。
このようなIPv6を検査します。 次ページから検査方法を説明します。
12/58画面左下の検索ボックスに「cmd」と入力して検索し、結果に表示される「コマンドプロンプト」を開いて下さい。
13/58前ページのようにnslookupを実行すると
下の見本のように、名前(FQDN)が見つかる場合と、見つからない場合があります。
ここではまず先に、名前が見つかった場合の説明をし、その後に見つからなかった場合の説明をします。
16/58nslookupで得た名前(FQDN)の通信先が、危険なホスト(遠隔操作の司令塔など)かどうか、Web検索をして調べる手順をご説明します。
18/58この見本では "nrt12s35-in-x03.1e100.net" を検索します。
19/58ただし検索結果のWebページに書いてあることが、必ずしも真実であるとは限らない点に留意してください。
今回の例ではGoogleのサポートページもヒットしているので間違いないと判断して良いかと思いますが、ネットには誤情報や嘘などが溢れていますので、情報の信憑性にご注意下さい。
結論から先に言いますと、名前が見つからなかったものはとりあえず無視して良いです。
その根拠を次から説明します。
名前(FQDN)が見つからない理由は
次のどちらかです。
【理由①】そもそも名前が無い機器だから
【理由②】名前が公開(登録)されていない機器だから
名前が無い/公開されていない機器に関して、分かりやすいよう大まかなイメージをご説明します。
インターネットの経路上で通過する機器や、通信先のシステムが内包する機器(主たるサーバに従属する機器)は、その機器自体は通信の目的地ではないので、名指しする必要がない、だから名前が無い、とイメージして下さい。
ただ通過するだけとか、主たるサーバに従属するものとかなので、その機器だけで(単独で)不正が完結するというケースはほとんどないです。
不正のメインは通過した先の目的地または主たるサーバとなりますので、それらが検査で引っかかるはずですし、通過や従属の機器を無視してもほぼ検査漏れは無いだろうと考えられます。
もちろん、100%大丈夫だと言い切ることはできませんし、僅かながら検査漏れするリスクはあるかも知れません。
しかし実際にはその確率はかなり低く、また、本気で調べるには大掛かりな調査が必要となりますので、簡易&無料でできる今回のセルフチェックでは、とりあえず無視して良いです。
(もしどうしても気になって仕方ないという場合には、マルウェア感染を精査する有料サービスを当社でおこなっておりますので、ご相談下さい。)
nslookupの結果:
edge-star6-shv-01-nrt1.facebook.com
検索するまでもなく facebook.com のドメインだと分かりますので、これも安全だと判断して良いです。
実はこれ、監視アプリ/ストーカーアプリ と言われるアプリに感染した端末の検査サンプルです。
2010年代に流行した「Cerberus(ケルベロス)」という有名なストーカーアプリが利用していたIPv6およびFQDNを検査した際のサンプルをご案内しました。
40/58IPv6のセルフチェックの精度を高めるために、さらに一段階深く調べる検査方法をご説明します。
41/58ここでは、先程にご案内した
例① 2404:6800:4004:821::2003 (GoogleのIPv6アドレス)
をさらに深く調べます。
このようにWiresharkで分析すると、
「2404:6800:4004:821::2003」は
firebase-settings.crashlytics.comの通信だということが分かりました。
Crashlytics はアプリの不具合を検知するためのシステムですので、これが検出されても問題ナシと判断して良いです。
ところで・・・
Wiresharkでの分析で得られたFQDNと、その前におこなっていた nslookupで得られたFQDNが違うことにお気づきでしょうか。
Wiresharkで分析すると、crashlytics.comという結果になりました。
nslookupで調査すると、Googleのサーバーという結果になりました。
Google社のサーバーの中にある、crashlytics.comのシステムと通信したため、調べ方によって結果が異なりました。
【補足】厳密に言うと上記の説明は正しくないケースもありますが、大雑把なイメージとしては分かりやすいかと思います。
例えば、
A社が貸し出しているAAAサーバを、
B社がレンタル契約した。
そしてB社が、
AAAサーバの中にBBBシステムを構築した。
このような構成の環境にアクセスするとAAA/BBBの両方に繋がるので、調べ方によってどちらの値が返されるか異なるのです。
AAA/BBBの両方とも重要なポイントですが、マルウェアの検査という視点に限りますと、BBBのほうが、より重要だと言えます。
そのため、仮にAAAサーバが安全なものだったとしても、中に入っているBBBシステムが危険なものだった場合には、危険性ありと判断するようにして下さい。
このStep5の検査までおこなえば、ほとんどのマルウェアを検出できます。
慣れない作業で大変かと思いますが、セルフチェックならお金がかかりませんので、ぜひお試し頂けたらと思います。
そんなきは有料のマルウェア検査サービスのご利用をご検討下さい。
57/58当社のマルウェア検査は専用システムで分析・解析しますので、セルフチェックで起こりがちな見落としや誤判断を防ぎ、高精度に検査できます。
さらに、スマホだけでなくパソコンの検査も対応。詳しくはお問い合わせ下さい。