netstatで外部との不正な通信を見極める(windows)。

netstatコマンドを使って、使用しているPCが不正な通信をしていないか確かめる方法です。netstatはコンピュータの通信状況を一覧表示するコマンドで、いろんなオプションを指定できます。

windowsではコマンドプロンプトから実行します。その際、管理者権限で実行します。windows10の場合は、「左下のウィンドウマークをクリック → Windowsシステムツール → コマンドプロンプトを右クリック → その他 → 管理者として実行を選択」で管理者権限でコマンドプロンプトが立ち上がります。

以下のように、netstatコマンドを打ちます。

C:¥WINDOWS¥system32>netstat -bn -p TCP

オプションの意味は以下です。

  • -b:それぞれの接続またはリッスンポートの作成に使われた実行可能ファイルを表示します。管理者権限が必要です。
  • -n:アドレスとポート番号を数値形式で表示します。
  • -p:TCPプロトコルの接続を表示します。他にも、UDP、TCPv6、UDPv6が指定できます。

※ここでは指定しませんでしたが、待受状態(リッスンポート)も表示したい場合は「-a」オプションを追加することで表示可能です。

実行した結果は以下です。

上記の結果から、僕のPCでは「svchost.exe」と「SearchUI.exe」が外部と通信を確立してなんらかの情報のやり取りをしているようです。

svchost.exe
→ プロトコルは443(HTTPS)を使用して、IPアドレスが「52.230.83.250」、「52.230.85.180」のサーバと通信をしている。

SearchUI.exe
→ プロトコルは443(HTTPS)を使用して、「13.107.42.254」、「13.107.51.254」、「13.35.55.30」、「204.79.197.222」のサーバと通信をしている。

それで、これらのサーバの宛先をwhoisデータベースで調べてみました。以下のサイトを利用しました。
http://whois.threet.co.jp/ ※リンクが廃止されてました。

「13.35.55.30」はAmazon、それ以外はすべて Microsoft のサーバのようです。そもそも、svchost.exe と SearchUI.exeが何者なのか?これも調べてみました(ウィルスだったら大変ですし)。svchost.exe はwindowsにもともとある必要なプロセスらしいです。また、SearchUI.exe は Cortana(コルタナ) に関わるプロセスらしいことがわかりました。通信相手もMicrosoftとAmazonだったため大丈夫と思います。インストールしているウィルス対策ソフトもウィルス検知をしていないので(※)。

(※)の補足:
今回の svchost.exe は本物だったのですが、ウィルスが「svchost.exe」というファイル名で活動している可能性があります。 svchost.exe はwindowsに必要なプロセスであるため、怪しまれないようにウィスルのファイル名を「svchost.exe」とするものがあるようです。

ただ不思議なのは、SearchUI.exe がAmazonのサーバと通信していたこと。なんでだろう?と思っていたらネットで記事を見つけました。Windows 10端末からAlexaのサーバーにアクセスしたり、AmazonのEcho端末からCortanaのサーバーにアクセスできるようになるみたいですね。

次回は、Linuxでのnetstatの使い方を書いてみようと思います。

Let’s Encrypt でTLS証明書を更新する。

Let’s Encrypt のTLS証明書を更新してみました。試した環境は以下です。

CentOS 6.10 + Apache 2.2.15

有効期限を確認します。ブラウザのURL入力欄の鍵マークをクリックし、ウェブサイトの識別情報で確認します。Firefoxの例です。※他のブラウザでもURLの鍵マークをクリックして証明書の内容を確認できると思います。

有効期限は、10/17です。前回の記事「Let’s EncryptでTLS化する(前編)」で Let’s Encrypt のインストールのときに使用した certbot-auto を使用します。作業は root ユーザで行います。certbot-auto があるディレクトリまで移動して、以下のコマンドを実行します。

# ./certbot-auto renew

※Let’s Encrypt では有効期限が30日未満になると更新ができます。それ以上あると更新されません。強制的に更新するオプションもあるので、有効期限が30日以上残っている場合で更新したいときは「certbot-auto renew --force-renew」とすることで更新できます(これは試していませんけれども・・)。

このとき、Apacheは起動したままにしておいてください。僕はApacheを一旦停止して「certbot-auto renew」を実行したため、一度更新に失敗しました。。。

[広告]

気を取り直して、、Apacheを起動して実行すると、以下の結果が表示されます。

念の為、Apacheを再起動します。また、ブラウザの表示もリフレッシュさせます(再読込、もしくは、F5キー押下)。ブラウザのウェブサイトの識別情報で有効期限が延長されたことを確認します。

これで、無事、TLS証明書の更新ができました!

ちなみに、、TLS証明書の更新により何が変更されたのかサーバーの設定ファイルを確認してみました。certbot-auto でTLS証明書をインストールしたときにはコンフィグファイルの書き換えを行っていましたが、更新のときは書き換えは行われていないようです(以下のファイルはいづれも変更はなし)。

/etc/httpd/conf/httpd.conf
/etc/httpd/conf.d/ssl.conf
/etc/httpd/conf/httpd-le-ssl.conf
/etc/letsencrypt/options-ssl-apache.conf

TLS証明書が格納されているディレクトリは、confファイルに以下のように定義されています(僕の場合は ssl.conf に記載しています)。

SSLCertificateFile /etc/letsencrypt/live/(サイトのサーバ名)/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/(サイトのサーバ名)/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/(サイトのサーバ名)/chain.pem

/etc/letsencrypt/live/(サイトのサーバ名) 配下には証明書が配置されていますが、これはシンボリックリンクとなっており、このリンクが更新されていました。リンク先は「/etc/letsencrypt/archive/(サイトのサーバ名)」です。

リンク先のほうのファイルを確認すると、新たに証明書が新規作成されていました(2018/09/22に作成されているものが該当)。証明書ファイルを新規作成し、リンク先を古いものから新しいものに切り替えることでコンフィグファイルの修正はなしとしているようです。

あと、やってみて気づいたのですが、有効期限が「10/17」だったものを更新したので「10/17」から3ヶ月延長されると思ったのですが、そうではなくて、実施日「9/22」から3ヶ月延長されたようです。

その後だけれど、「Let’s Encrypt Expiry Bot」という差出人から「Let’s Encrypt certificate expiration notice for domain “(サイトのドメイン名)”」というタイトルでメールが届きました。内容は、Let’s Encrypt で取得したTLS証明書の有効期限が近づいたので更新してください、というもの。すでに更新したのですれ違いになったようです。更新期限が近づくとメールでも案内していたんですね。そういえば、TLS証明書をインストールするときに連絡先のメールアドレスを設定したのを思い出しました。こういう連絡のときにメールアドレスが使われるのですね。。

以上。