アカウント名:
パスワード:
どこにも「カスペルスキーのサーバーと通信」なんて書いてないでしょ
他にどこと通信するんだ、社員の方ですか
「カスペルスキーのドメイン(正確にはPC内のカスペルスキーアプリケーション)に対してHTTPリクエストを発信している」
これですね。カスペルスキーのアプリがローカルホストに立てているHTTPサーバーと通信している、と。JSが外部サーバーと通信しているわけではないようですね。(このアプリがさらに外部サーバーと通信しているかどうかは別問題)
私ならローカルホスト内での通信を、「サーバーと通信している」とは表現しないかな…。
> カスペルスキーのアプリがローカルホストに立てているHTTPサーバーと通信している、と。
ローカルホストと通信しているだけなら、その記事で書かれている対処法の「hostsを書き換えて、それらのドメインのアドレスを127.0.0.1にする」というので事が済むはずないと思うんだけど。
nslookupでie.kis.scr.kaspersky-labs.comgc.kis.scr.kaspersky-labs.comff.kis.scr.kaspersky-labs.comme.kis.scr.kaspersky-labs.comのそれぞれのアドレスを引くと、ちゃんと外部のIPアドレスが出てくるよ。
Kaspersky Internet Security 2016 のユーザーなので検証してみました。
無駄に長文になるので結論を先に書くと、スクリプトの取得元・通信先ともにローカルホストに Kaspersky が立てているHTTP(とHTTPS)サーバで正しいようです。
~ 以下は調査方法・根拠 ~
今、Google Chrome でスラドを見ていますが、HTMLのソースには下記の外部 Java Script が注入されています。
<script type="text/javascript" src="http://gc.kis.scr.kaspersky-labs.com/1B74BD89-2A22-4B93-B451-1C9E1052A0EC/main.js" charset="UTF-8"></script>
nslookupで ie.kis.scr.kaspersky-labs.com gc.kis.scr.kaspersky-labs.com ff.kis.scr.kaspersky-labs.com me.kis.scr.kaspersky-labs.com のそれぞれのアドレスを引くと、ちゃんと外部のIPアドレスが出てくるよ。
について、試してみましたが、
ie.kis.scr.kaspersky-labs.com (http://ie.kis.scr.kaspersky-labs.com/1B74BD89-2A22-4B93-B451-1C9E1052A0EC/main.js) = 185.85.13.154gc.kis.scr.kaspersky-labs.com (http://gc.kis.scr.kaspersky-labs.com/1B74BD89-2A22-4B93-B451-1C9E1052A0EC/main.js) = 127.245.107.154ff.kis.scr.kaspersky-labs.com (http://ff.kis.scr.kaspersky-labs.com/1B74BD89-2A22-4B93-B451-1C9E1052A0EC/main.js) = 127.245.107.154me.kis.scr.kaspersky-labs.com (http://me.kis.scr.kaspersky-labs.com/1B74BD89-2A22-4B93-B451-1C9E1052A0EC/main.js) = 185.85.13.154※今使ってる環境には Edge が入っていないので Edge は nslookup のみ検証
でした。
IE と Edge 用のスクリプトのIPアドレス(185.85.13.154)は、Kaspersky Lab ZAO(ロシア連邦モスクワ)に割り当てられているものです。
しかし、Kaspersky をインストールしていない環境からは http://ie.kis.scr.kaspersky-labs.com/1B74BD89-2A22-4B93-B451-1C9E1052A... [kaspersky-labs.com] にアクセスできません(なお、185.85.13.154 では HTTPD かプロキシが一応動いてるっぽいですが、極めてレスポンスが悪く、応答が無い場合が多く、応答がある場合でも長時間経過後 504 Gateway Timeout のレスポンスが返されます)。
上記のURLには、カスペルスキーがインストールされている環境からは、どんなブラウザでもアクセスでき、JavaScript コードの取得が可能です。しかし、LAN内のカスペルスキーがインストールされていない環境や、スマホ(LTE接続)からアクセスしてみましたが、JavaScriptコードは取得できませんでした。
また、Chrome 用と Firefox 用(127.245.107.154)は、ローカル・ループバック・アドレスなので、JavaScript の取得元がローカルであることは明らかです。
つまり、Kaspersky Internet Security 2016 に含まれるソフトウェア(ファイアウォールのようなもの)が 185.85.13.154 や 127.245.107.154 宛ての通信を受信して、それに応答しているということです。
また、JavaScript のプログラムが GET や POST で通信している先についても、http(s)://ie.kis.scr.kaspersky-labs.com/長い英数字/from や http(s)://ie.kis.scr.kaspersky-labs.com/【長い英数字】/【長い英数字】/to/ob.disconnect/?get&nocache=【ランダムっぽい英数字】 などで、ホスト名は JavaScript ソースの取得元と同一でした。
IE と Edge 用の JavaScript コードの取得元とJavaScriptによる通信先のIPアドレスについて、実際の通信先がローカルなのに、グローバルIPアドレスを使用しているというのは、非常にトリッキーに感じます。
この理由については、IE や Edge は、インターネットゾーンと、ローカルホストあるいはローカルイントラネットゾーンで、セキュリティ権限が異なる扱いをするため、それを回避して「インターネットゾーン」として扱わせるためかと思います。Firefox と Chrome についてはそういったことがないので、インターネット上のサーバに情報を送信しているという誤解を招かないため、ローカル・ループバック・アドレスにしたのではないでしょうか。
127.0.0.1 ではなく 127.245.107.154 にしたのも、余計な通信の中継を防ぐための配慮でしょう。
今のブラウザは、プラグイン(拡張)の権限が制限されたり、頻繁なアップデートで仕様変更されたりしまうため、カスペルスキーのような HTTP / HTTPS 通信を中継してチェックする動作(別の言い方をすると傍受・改竄)は、セキュリティソフトの動作として合理的・最善であると思います。
ブラウザのレンダリング前に、悪意のあるコードを検出あるいは排除するためには、ブラウザの動作に割り込むか(拡張など)、HTTP / HTTPS の通信を検閲するしかありません。ブラウザのアップデート・仕様変更が頻繁に行われる現状では、後者の方が不具合が少なく安定して動作するでしょう。
ローカルホストに Kaspersky が立てているHTTP(とHTTPS)サーバ(あるいは別プロトコル)は外部のサーバと接続しているんでしょうかね?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
元ネタ読みましたけど (スコア:0)
どこにも「カスペルスキーのサーバーと通信」なんて書いてないでしょ
私も元ネタ読みましたけど (スコア:-1)
どこにも「カスペルスキーのサーバーと通信」なんて書いてないでしょ
他にどこと通信するんだ、社員の方ですか
ローカルに立っているサーバーを「○○○のサーバー」と表現するか否か (スコア:1)
これですね。
カスペルスキーのアプリがローカルホストに立てているHTTPサーバーと通信している、と。
JSが外部サーバーと通信しているわけではないようですね。(このアプリがさらに外部サーバーと通信しているかどうかは別問題)
私ならローカルホスト内での通信を、「サーバーと通信している」とは表現しないかな…。
Re: (スコア:0)
> カスペルスキーのアプリがローカルホストに立てているHTTPサーバーと通信している、と。
ローカルホストと通信しているだけなら、その記事で書かれている対処法の
「hostsを書き換えて、それらのドメインのアドレスを127.0.0.1にする」
というので事が済むはずないと思うんだけど。
nslookupで
ie.kis.scr.kaspersky-labs.com
gc.kis.scr.kaspersky-labs.com
ff.kis.scr.kaspersky-labs.com
me.kis.scr.kaspersky-labs.com
のそれぞれのアドレスを引くと、ちゃんと外部のIPアドレスが出てくるよ。
【検証結果】 JSの取得元と通信先はローカルホスト上のHTTPサーバで正しい (スコア:5, 参考になる)
Kaspersky Internet Security 2016 のユーザーなので検証してみました。
無駄に長文になるので結論を先に書くと、スクリプトの取得元・通信先ともにローカルホストに Kaspersky が立てているHTTP(とHTTPS)サーバで正しいようです。
~ 以下は調査方法・根拠 ~
今、Google Chrome でスラドを見ていますが、HTMLのソースには下記の外部 Java Script が注入されています。
について、試してみましたが、
でした。
IE と Edge 用のスクリプトのIPアドレス(185.85.13.154)は、Kaspersky Lab ZAO(ロシア連邦モスクワ)に割り当てられているものです。
しかし、Kaspersky をインストールしていない環境からは http://ie.kis.scr.kaspersky-labs.com/1B74BD89-2A22-4B93-B451-1C9E1052A... [kaspersky-labs.com] にアクセスできません(なお、185.85.13.154 では HTTPD かプロキシが一応動いてるっぽいですが、極めてレスポンスが悪く、応答が無い場合が多く、応答がある場合でも長時間経過後 504 Gateway Timeout のレスポンスが返されます)。
上記のURLには、カスペルスキーがインストールされている環境からは、どんなブラウザでもアクセスでき、JavaScript コードの取得が可能です。しかし、LAN内のカスペルスキーがインストールされていない環境や、スマホ(LTE接続)からアクセスしてみましたが、JavaScriptコードは取得できませんでした。
また、Chrome 用と Firefox 用(127.245.107.154)は、ローカル・ループバック・アドレスなので、JavaScript の取得元がローカルであることは明らかです。
つまり、Kaspersky Internet Security 2016 に含まれるソフトウェア(ファイアウォールのようなもの)が 185.85.13.154 や 127.245.107.154 宛ての通信を受信して、それに応答しているということです。
また、JavaScript のプログラムが GET や POST で通信している先についても、http(s)://ie.kis.scr.kaspersky-labs.com/長い英数字/from や http(s)://ie.kis.scr.kaspersky-labs.com/【長い英数字】/【長い英数字】/to/ob.disconnect/?get&nocache=【ランダムっぽい英数字】 などで、ホスト名は JavaScript ソースの取得元と同一でした。
IE と Edge 用のIPアドレスがグローバルIPアドレスな理由 (スコア:2)
IE と Edge 用の JavaScript コードの取得元とJavaScriptによる通信先のIPアドレスについて、実際の通信先がローカルなのに、グローバルIPアドレスを使用しているというのは、非常にトリッキーに感じます。
この理由については、IE や Edge は、インターネットゾーンと、ローカルホストあるいはローカルイントラネットゾーンで、セキュリティ権限が異なる扱いをするため、それを回避して「インターネットゾーン」として扱わせるためかと思います。Firefox と Chrome についてはそういったことがないので、インターネット上のサーバに情報を送信しているという誤解を招かないため、ローカル・ループバック・アドレスにしたのではないでしょうか。
127.0.0.1 ではなく 127.245.107.154 にしたのも、余計な通信の中継を防ぐための配慮でしょう。
今のブラウザは、プラグイン(拡張)の権限が制限されたり、頻繁なアップデートで仕様変更されたりしまうため、カスペルスキーのような HTTP / HTTPS 通信を中継してチェックする動作(別の言い方をすると傍受・改竄)は、セキュリティソフトの動作として合理的・最善であると思います。
ブラウザのレンダリング前に、悪意のあるコードを検出あるいは排除するためには、ブラウザの動作に割り込むか(拡張など)、HTTP / HTTPS の通信を検閲するしかありません。ブラウザのアップデート・仕様変更が頻繁に行われる現状では、後者の方が不具合が少なく安定して動作するでしょう。
Re: (スコア:0)
ローカルホストに Kaspersky が立てているHTTP(とHTTPS)サーバ(あるいは別プロトコル)は外部のサーバと接続しているんでしょうかね?