2017年8月11日金曜日

次回予定

・Chromeブラウザでパスワード管理しないための設定
・パスワード管理ソフトKeePassの使用
・KeepassデータベースファイルをDropboxではなく自前のサーバーに置いてSFTP・公開鍵認証でアップロードダウンロード

SSHでトンネルを掘りVPS経由で実家のPCへVNC接続する(その2)

利便性だけを優先すれば、このような目的にはTeamviewerを使い、アカウントに二段階認証を設定すれば問題ないのかもしれない。だが、二段階認証を設定してないTeamviewerアカウントのパスワードリセットの手順があまりにも脆弱なこと、第三者に侵入される可能性のあるマネジメントコンソールの存在、アカウント情報の流出の懸念など、Teamviewer使うには多くの不安がある。
もちろん、自らバックドアを踏んでしまえは元も子もないが、それはWindows Firewallで対応するなど別の課題となる。今回は、パスワード管理もコネクションフローもすべて自分の管理下にあるより閉じた方法でリモートデスクトップ接続をおこなう方法を試す。
使うもの:
  Windows 10 Home 64bit デスクトップPC(こっち)
  Windows 10 Home 32bit タブレットPC(あっち)
  VPSサーバー CentOS 5.4 (sshdの公開鍵認証が有効になっていること)
  TigerVNC 1.8.0
  Open SSH Win 32/64

VPS=Virtual Private Server なので、「VPSサーバー」と書いたけれどもそれは冗長である。VPSとは要するにLinuxが動作する格安レンタルサーバーだ。具体的には「DTI SERVERSMAN@VPS エントリープラン」を使っている。こういった趣味の実験用途には打って付けのサービスで、格安のたった504円/月(税込み)で自分だけの固定グローバルIPアドレスとルート権限がもらえる。
VNCには色々なバージョンがあるが、本家RealVNCの最新バージョン6はTeamviewerのようにクラウドを使う仕組みのようなので除外する。今回TigerVNCを使っているが、UltraVNCでも構わない。UltraVNCの場合、Mirror Driverという専用のディスプレイドライバをインストールすることで描画の高速性が実現するというのだが、やってみたところ大差ないように感じ、ドライバも古臭くWindows10との相性が不安なため、それを使わないシンプルなTigerVNCを選択した。
WindowsでSSHトンネリングをする場合、クライアントソフトはPuTTYを使う場合が多いが、以下の問題により、今回はVNCサーバー側になるあっち側PCではOpen SSH Winを使う。PuTTYの問題点は以下のとおり。

・リモートデスクトップ上でトンネルを張っているPuTTYのウィンドウをドラッグしたり最小化するためにタイトルバーを左クリックすると、マウス左ボタンが押下状態のままリモート側に制御が奪われ、リモート側でマウス左ボタンを物理操作しない限りコントロールがロックされる。クライアントからVNCを切断してもリモート側は切断されず再接続が不可能になる。TigerVNCだけでなくUltraVNCサーバー・ビューワでも同様。コマンドプロンプトや他のプログラム、接続後に開いた別のPuTTYウィンドウに触れてもこの現象は発生しない)
・タスクスケジューラでシステム起動時にPuTTYを起動したときに、PuTTYプロセスは起動されるもののどうしてもトンネルが張れない。コマンドラインオプションがうまく渡されていないのかもしれない。

OpenSSH Winの場合、トンネルを起動しているウィンドウに触れてもPuTTYのようにハングアップすることはなく、また、タスクスケジューラでWindows起動時にスタートさせたときにはOpenSSHの実行ウィンドウ自体が非表示となり、ウィンドウに触れる心配がない。Windows UpdateでPCが勝手に再起動されてもリモート操作でWindowsへのログイン操作を可能にするため、システム起動時にトンネルを張って(掘って?)おく必要があるのだ。VNCクラアント側PCからのトンネル作成にPuTTYを使用することについてはとくに問題はないが、今回は両側ともOpen SSHというシンプルな方法にする。

TigerVNCの設置(あっち側PC)
ダウンロード
tigervnc-1.8.0.exe
tigervnc64-1.8.0.exe
環境に合わせていずれかのファイルをインストール。

Register VNC Serviceを実行(あっち側PC)
ユーザーがWindowsからログアウトしてもVNCサーバーが終了しないように、ユーザーモードではなくWindows起動時にTigerVNCサーバーをサービスで起動すように設定する。

Register VNC Serviceを実行

Configure VNC Serviceを開く(あっち側PC)


SecurityタブでVNCパスワードを設定する(あっち側PC)

SSHトンネリングで暗号化されるため、VNC間でSession encryptionをするのは冗長なのでNoneにする。

ConnectionタブでAccessControlを設定(あっち側PC)
トンネルからの接続だけを受け入れるように、"Only accept connections from the local machine"をチェックする。VNCサーバーの動作確認のために、同じLAN内の別のPCからトンネルを使わずに接続するには、ここにチェックを入れないか、チェックを入れない上に更にAddで192.168.0.0/8のようにローカルネットワークを追加する。運用時は上の状態にしておき、LAN内の別のPCから接続する場合もVPS経由のトンネルで接続するのが安全。

Desktopタブの設定(あっち側PC)
Remove wallpaperをチェックする。この設定は意外に重要で、VNCサーバーが着信しているときは一目でわかるように、デスクトップの壁紙が削除されるようにしておかなければならない。(ただしVNCではない別のバックドアで侵入された場合は無意味)
When last client disconnectsでVNC切断後の挙動を設定できるので、必要に応じて、Lock workstationやLogoff userを設定しておけばいい。今回の方法ならLoggoff userを行ってもリモートデスクトップ操作でWindowsにログインできる。

Start VNC Serviceを実行(あっち側PC)

ディスプレイのスケーリングが設定されている場合(あっち側PC)
今回VNCサーバー側になるタブレットPCは ASUS T100Chiという機種で、ディスプレイのサイズが10.1インチと小さい割に解像度が1,920×1,200ドット (WUXGA)と高く、デスクトップPCと同じ設定では文字が小さく扱い辛いので、デフォルトでは150%の拡大表示が設定されている。このままVNCサーバーを起動するとリモートデスクトップ時にマウスを動かしてもあっちのPCとカーソルが一致せず、ポイントする位置がずれる現象が起こる。解像度を落としてスケーリングを100%にすればマウスのズレはなくなるがそれでは高解像度ディスプレイの性能がもったいない。

スケーリング設定を変更せずにVNC接続時にマウスカーソルのズレを解決するには、エクスプローラーでVNCサーバー側PCの実行ファイル C:\Program Files\TigerVNC\winvnc4.exeを右クリックし、プロパティを変更する。互換性タブの「高いDPIスケールの動作を上書きします」のチェックを有効にし、拡大縮の実行元「アプリケーション」を選択して適用する。
これでOK。
備考:
TigerVNC Viewerはあっちの画面がこっちのよりもでかい場合、縮小スケーリング表示する機能がないため、あっちの画面がこっち側の画面からはみ出してしまい扱い辛くなる。Viewerについては互換性のある別のVNCクライアントを使う手もある。
また、Tiger VNC ViewerはX11サーバー相手の場合にウィンドウをリサイズするとリモート側のデスクトップサイズをダイナミックに変化させるする機能があるが、WindowsのVNCサーバーが相手の場合は機能しない。

OpenSSH Winを設置(ここではあっち側PCのみ。後程の手順でこっち側PCもおこなう)
ダウンロード
https://github.com/PowerShell/Win32-OpenSSH/releases
OpenSSH-Win32.zip
OpenSSH-Win64.zip
環境に合わせていずれかのファイルをダウンロード。インストーラーは無いので任意のフォルダに展開する。ここではC:\Users\Downloads\OpenSSH-Win32 に展開。

SSH接続用の公開鍵を作成する(ここではあっち側PCのみ。後程の手順でこっち側PCもおこなう)
鍵の作成にはOpenSSH-Win32 を展開したフォルダ内にあるssh-keygen.exeを使う。
元々サーバーへログインするために使っている鍵がpassphrase無しの場合は、新しい鍵やサーバ側に新しいユーザーを作成せずに、それをそのままトンネル用に使ってもいい。
元々サーバーへログインするために既に使っている鍵がこのフォルダーにある場合は、新しい鍵を上書きしてしまうとサーバーへログインできなくなり大変なことになる。既存の鍵をバックアップし、新しい鍵を作成する前にはPuTTYやTeratermなどであらかじめサーバーのコンソールへログインしておいた方がいい。
ssy-keygen.exeコマンドは、既存の鍵を上書きしないように、コマンドラインから-fオプションをつけて、作成される鍵のファイル名を指定して実行する。
例)C:\Users\Downloads\OpenSSH-Win32\ssh-keygen -f tunnel1_id_rsa
この場合、カレントディレクトリにtunnel1_id_rsaとtunnel1_id_rsa.pubが作成されるので、Windowsのユーザーフォルダー内の.sshフォルダ内へ2つのファイルをコピーする。
現在サーバーへの接続にパスワード認証だけを使っている場合には、新しく鍵を作成する。展開したフォルダ内のssh-keygen.exeをダブルクリックで実行れば、鍵のペアがWindowsのユーザーフォルダー内の.sshフォルダ内に作成されるのでこれを使う。

いずれの場合も、ssh-keygen実行時にpassphraseは無しに設定する。


ssh-keygen.exeを実行
(既存の鍵がない場合のみ)

エクスプローラーの表示オプションで隠しファイルを表示させる




id_rsa   が秘密鍵
id_rsa.pub が公開鍵
秘密鍵はサーバー側に登録する必要は無く、自分がサーバーに接続する際にSSHクライアントに読み込ませて使う。

トンネル専用ユーザーの作成(VPSサーバー)
普段サーバーで使っているユーザーでトンネルを張るのでも構わないが、サーバー側にトンネル専用ユーザーを作成しておいた方が良い気がする。
[root]$ useradd tunnel1
Pwassword:  これは公開鍵認証でログインする際のpassphraseとは別なので、ユーザーのパスワードを任意に指定する。別のユーザーでログインし、cu -コマンドでこのユーザーになるときにこのパスワードを使う。
シェルコマンドの実行ができないようにrbashが起動されるタイプのユーザーにすればより安心だが、サーバー側のsshd_configでpassword認証を禁止してしまえば、第三者が秘密鍵を持っていない限りSSHログインすることはほぼ不可能と考えられるので、rbashにする設定は必ずしも必要ないと思う。
備考:
PuTTYを使えばコマンドラインオプションにパスワード/パスフレーズを指定し、非対話でログインできるが、前述の事情により今回PuTTYが使えない。sshpassというプログラムを使えば、ユーザー名とパスワードまたはパスフレーズを指定して、一行でssh接続をすることができるが、これのWindows版を探してみたものの見つからなかった。

authorized_keysファイルへの追加(VPSサーバー)
id_rsa.pubはテキストファイルなので、id_rsa.pubファイルをメモ帳で開いてクリップボードにコピーし、VPSサーバー側の端末ウィンドウ内で開いたviエディタに張り付ける。
サーバーに自分のユーザー名または作成したトンネル専用ユーザーでログインし、

$ vi ~/.ssh/authorized_keys
~./.ssh/authorized_keys ファイルの最後にクリップボードにコピーしたものをペーストして追加する。
ファイルの最後にid_rsa.pubの内容をペーストしてセーブする。

トンネル専用のユーザーを今回作成したばかりの場合や、これまでパスワード認証だけを使っていたユーザーの場合は、~/.ssh/authorized_keys ファイルがないので作成し、パーミッションを644にする。

$ touch ~/.ssh/authorized_keys
$ chmod 644 ~/.ssh/authorized_keys 
$ls -la ~/.ssh/
drwx------ 2 user1 user1 4096 Aug  6 13:16 .
drwx------ 3 user1 user1 4096 Aug  5 23:48 ..
-rw-r--r-- 1 user1 user1  816 Aug  6 13:16 authorized_keys

後ほど、「こっち側PC」でも同様にssh-keygen.exeを使用して鍵を作成し、公開鍵の文字をこのファイルの最後にそれを追加する。

備考:
sshdで公開鍵認証を有効にするためには
 /etc/ssh/sshd_config の設定でPubkeyAuthentication yes になっている必要がある。
パスワード認証を禁止するために PasswordAuthentication no にするのが安全。

うまくログインできない場合は、/var/log/secure ファイルを確認する。
成功した場合:
Aug 12 11:10:52 myserver sshd[14223]: Connection from 202.101.103.114 port 51701
Aug 12 11:10:52 myserver sshd[14223]: Found matching RSA key: 86:3d:25:67:9f:4f:86:83:ec:cb:0b:8f:71:fa:aa:aa
Aug 12 11:10:52 myserver sshd[14224]: Postponed publickey for tunnel1 from 202.101.103.114 port 51701 ssh2
Aug 12 11:10:52 myserver sshd[14223]: Found matching RSA key: 86:3d:25:67:9f:4f:86:83:ec:cb:0b:8f:71:fa:aa:aa
Aug 12 11:10:52 myserver sshd[14223]: Accepted publickey for tunnel1 from 202.101.103.114 port 51701 ssh2
Aug 12 11:10:52 myserver sshd[14223]: pam_unix(sshd:session): session opened for user tunnel1 by (uid=0)

パスワード認証が無効なサーバーにパスワード認証でログインして失敗した場合:
Aug 12 11:12:01 myserver sshd[14228]: Connection from 202.101.103.114 port 51703
Aug 12 11:12:02 myserver sshd[14229]: Received disconnect from 202.101.103.114: 1: User Auth Failure


接続テスト (あっち側PC)
パスフレーズ無しでログインできれば成功。
C:\Users\ore\Downloads\OpenSSH-Win32\ssh.exe tunnel1@123.123.123.12 -p 22 -i C:\Users\ore\.ssh\tunnel1_id_rsa
Last login: Sun Aug  6 13:19:49 2017 from xxx.xxx.xxx.xxx
-rbash-3.2$

・-i オプションで、秘密鍵のファイル名をフルパスで指定する。
・-p オプションはサーバー側sshdのポート番号。SERVERS@MANの場合、sshは標準の 22ではなく3843になる。

トンネルを張るコマンドをテスト
C:\Users\ore\Downloads\OpenSSH-Win32\ssh.exe -N -R 6666:localhost:5900 tunnel1@123.123.123.12 -p 22 -i C:\Users\ore\.ssh\tunnel1_id_rsa
新しく黒いウィンドウが開いてそのままになればOK。切断するにはウィンドウ右上のバッテンをクリックする。
・-N オプションをつけることで、サーバー側のコマンドラインを表示しないようにする。(notty)
・-R 6666 サーバー内で中継に使用する任意のリッスンポート番号。使われていないポート番号を任意で決める。このポートはサーバー内部でループバック接続に使われるだけなので、ファイアーウォール(iptables)に外部からの接続ルールを追加する必要は無い。
・localhost このまま記入。
・5900 WindowsPC VNCサーバーのリッスンポート番号。5900はデフォルトの値で、VNC Server ConfigのConnectionタブで変更することができる。

トンネルを張るコマンドをタスクスケジューラーに登録(あっち側PC)
これはをやるのは後でも構わない。差し当たりコマンドプロンプトでトンネルを張るコマンドを手動で実行し、こっち側PCからVNC Viewerを使っての接続テストを先にやるのがいいかもしれない。

タスクスケジューラを起動する。

タスクスケジューラの右側ウィンドウ内のメニューで「タスクの作成」を選択。
タスクの名前は任意。ここではtunnel_vncという名前にしている。
「全般」タブの設定

「ユーザーがログオンしているかどうかにかかわらず実行する」を選択し、「最上位の特権で実行する」にチェックを入れる。Windows 10 Homeは、Windows Updateの際に強制的に再起動が実行されるため、VNCを使ってWindowsにユーザーがログイン(ログオン?)するにはこのようにしてシステム起動時にトンネルを張っておく必要がある。

「トリガー」タブの設定

ネットワークへの接続が完了していないと、トンネルを張るのに失敗してしまう。Wi-Fiの接続が完了し、DHCPサーバーからアドレスの取得が完了するまで少し時間がかかることを想定し、「遅延時間を指定する」にチェックを入れ、「30秒間」を指定する。もしインターネット接続やWi-Fi接続が切れた場合はプロセスが終了してしまうため、プロセスが自動的に再起動されるように「繰り返し間隔」に「30分間」にチェックを入れ、定期的にコマンドが実行されるように設定する。プロセスを重複起動しないための設定は、この後の「設定」タブでおこなう。

「操作」タブの設定
「プログラム/スクリプト」のボックスにSSHコマンドをフルパスで入力。
C:\Users\ore\Downloads\OpenSSH-Win32\ssh.exe
「引数の追加」のボックスにコマンドラインオプションを入力。
 -N -R 6666:localhost:5900 user1@123.123.123.12 -p 22 -i C:\Users\ore\.ssh\tunnel1_id_rsa

「条件」タブの設定
電源の項目は任意に設定する。今回はAC電源でもバッテリー動作時でも挙動を違わせる必要は無く、いずれの場合も実行して構わないと思う。
ネットワークの項目は、チェックを入れないことにした。システム起動時にネットワーク接続が完了していなければトリガー条件で設定した30分後に再度プロセスが起動される。

「設定」タブの設定

プロセスが重複起動されないように、一番下で「新しいインスタンスを開始しない」を選択する。
「タスクが失敗した場合の再起動の間隔」を指定することができるが、トリガータブの設定で30分毎に繰り返されるので、ここで設定すると冗長なためチェックをOFFにする。
全てのタブを設定し終えたら、PCを再起動し自動的にトンネルが張られているか確認する。スケジューラでssh.exeを起動すると、手動でテストした際のような黒いウィンドウは現れずにバックグラウンドでssh.exeが起動する。
Windowsにログインし、タスクマネージャーで「ssh.exe」が起動していることを確認する。
タスクマネージャーの表示



TigerVNC Viewerのインストール(こっち側PC)
ダウンロード
vncviewer-1.8.0.exe
vncviewer64-1.8.0.exe
環境に合わせていずれかのファイルをインストール。

OpenSSH Winを設置(こっち側PC)
ダウンロード
https://github.com/PowerShell/Win32-OpenSSH/releases
OpenSSH-Win32.zip
OpenSSH-Win64.zip
環境に合わせていずれかのファイルをダウンロード。インストーラーは無いので任意のフォルダに展開する。

SSH接続用の公開鍵を作成する(こっち側PC)
先にやった、あっち側PCでの作成手順と同じ。サーバーへログインするために既に公開鍵認証を使っている場合は既存のユーザーと鍵が使える。トンネル専用に新しいユーザーを作成する場合は、そのユーザー用に新たにssh-keygen.exeを使って接続用の鍵のペアを作成する。
あっち側PCではタスクスケジューラーにより非対話でSSHログインをおこなう必要があるため、Passphrase無しの鍵を使う必要があるが、こっち側PCでトンネルを張るのは手動操作なので、鍵はPassphrase付きのものでも構わない。

authorized_keysへの追加(VPSサーバー)
サーバーへログインするために既に公開鍵認証を使っている場合はこの手順は不要。
これまでパスワード認証だけを使っていた場合や、トンネル専用に新しいユーザーを作成した場合におこなう。
先にやった、あっち側PCの公開鍵を追加する手順と同じ。サーバー側で先ほどあっち側PCの公開鍵を追加したのと同じ~./.ssh/authorized_keysファイルの最後に、こっち側PCの公開鍵(.pub)の内容を追加してセーブする。

OpenSSH Winの起動(こっち側PC)
VNC Viewerで接続を開始する前に、こっち側PCからもサーバーにトンネルを張っておく必要がある。
コマンドプロンプトでSSHコマンドを実行する。

C:\Users\kotti\Downloads\OpenSSH-Win64\ssh.exe -N -L 7701:123.123.123.12:6666 tunnel1@123.123.123.12 -p 22 -i C:\Users\kotti\.ssh\tunnel1_id_rsa

・-N オプションをつけることで、サーバー側のコマンドラインを表示しないようにする。(notty)
・-L 7701 こっち側PCの内のポート番号を任意で決める。
・-i オプションで、秘密鍵のファイル名をフルパスで指定する。
・-p オプションはサーバー側sshdのポート番号。
サーバーのIPアドレスとポート番号、サーバーへログインするユーザー名は「あっち側PC」と同じ。
このコマンドはVNC Viewerで接続する前に毎回実行することになるので、バッチファイルにしてショートカットをTigerVNC Viewerアイコンの隣にでも置いておけばいい。

tunnel_client.bat
CD /C %~dp0
START /MIN C:\Users\kotti\Downloads\OpenSSH-Win64\ssh.exe -N -L 7701:123.123.123.12:6666 tunnel1@123.123.123.12 -p 22 -i C:\Users\kotti\.ssh\tunnel1_id_rsa

TigerVNC Viewerの起動
TigerVNC Viewerを起動する。

Real VNC 5.3.3のViewerも使える
ダウンロード
https://www.realvnc.com/download/file/vnc.files/VNC-5.3.3-Windows.zip
TigerVNCは縮小スケーリングができないが、Real VNCのViewerは可能なので、向こうの画面の方がでかいという今回場合はこちらの方が適している。
TigerVNC Serverへ接続する場合、Encryptionの互換性がないようでNoneにしかできないが、今回の環境の場合SSHトンネリングを使っているのでEncryptionの必要は無い。
Real VNCのインストールファイルにはVNC ServerとVNC Viewerの両方が含まれているが、インストール時にはVNC Viewerだけを選択し、VNC Serverのチェックボックスは外す。Real VNCのバージョン5.x.xはVNCサーバーを起動するためのトライアルライセンス配布が終了しており、VNCサーバーをインストールしても起動することができない。(VNC Connectライセンスなるものを購入すると5.x.xのライセンスをもらえるようだが)

TigerVNC Viewerで接続
接続先に「localhost:7701」を入力し、Connectボタンを押す。

VNC Authenticationのウィンドウがすぐに表示されれば接続は成功している。
あっち側PCのConfigure VNC Serverの手順で、Securityタブで設定したVNCパスワードを入力し、OKボタンを押す。
あっち側PCの起動時にトンネルを張るのが成功していれば、Windowsにログインしていない状態でも接続することができる。


 ログイン時はデスクトップの壁紙が削除される設定にしてある。

接続中は、F8 キーを押すとコンテキストメニューが表示され、特殊キーの送信などができる。

コンテキストメニューではIMEをON/OFFできるキーを送ることができず、日本語が入力できない。こちらのメモ帳に記入した日本語をコピーしてVNC Viewerウィンドウ内にペーストすると、???となり、クリップボード経由では送ることができないようだ。あっち側PC全角/半角キーを手動で押してIME ONの状態にしてやるとVNC Viewerから日本語入力ができるようになる。なので、あっち側PCのIMEのキー割り当てを変更しておけばVNC ViewerからIMEのON/OFF操作をすることができる。送れるキーは英語版キーボードに存在するキーだけだと思わるので、あまり使うことのないファンクションキーの一つを割り当てることにする。

IMEのキー割り当て追加(あっち側PC)
タスクトレイのIMEアイコンを右クリックしてプロパティを表示させる。
詳細設定を押す。

全般タブの「編集操作」の変更ボタンを押す。

キー設定タブを選択。
既存の「全角/半角」を選んでから「キー追加」ボタンを押すと、同じ機能をコピーして別のキーに割り当てることができる。

元々一体なんの機能があるのかわからない「F12」キーを割り当てることにする。

これでF12キーでIMEのON/OFFを切り替えることができるようになった。

「SSHでトンネルを掘りVPS経由で実家のPCへVNC接続する」は以上で終了です。

2017年8月10日木曜日

SSHでトンネルを掘りVPS経由で実家のPCへVNC接続する(その1)

先日TeamViewerの乗っ取り被害に遭った。7月26日の朝、出かける前にふと目に入ったメインで使っているWindowsデスクトップPCの液晶画面が、なんだか壁紙が消えた状態なのを発見。まさかとは思ったがタスクトレイのTeamViewerを終了させると壁紙が戻り、血の気が引いた。もつれる手で反射的に回線ケーブルを抜き、しばらく呆然とする。何が起こった?慎重に被害を確認する。と、Amazonサイトの購入履歴が表示されない。すべて消えているようだ。1クリック注文ボタンの横に表示されている支払い方法のアイコンが「VISA」と表示されている。なんだろう?ポイントが目的で、つい先ごろ「Amazonマスターカードゴールド」作ったところだ。Amazonの支払いはそれを唯一の方法に設定している。VISAは過去にも登録したことがない。アカウントメニューから支払い方法のページへ進むと、無数の他人名義のクレジットカードが登録されている…戦慄。口がカラカラに乾く。ほとんどはカード番号だけの表示だったが少なくとも二件は日本人と思われるローマ字姓名が表示されており、そのうちの一つの「VISA」が現在の支払い方法に指定されていた。Amazonアカウントは何度操作してもパスワード変更ができない。取り急ぎAmazonカスタマーサービスの電話番号を調べて連絡。侵入のあったその日の内に既にAmazon側でセキュリティアラートが上がっており、幸いなことに発送は保留状態でアカウントもロックされているという。
 TeamViewerのログを確認すると、侵入時刻は2日前の7月24日の午前4時18分~5時40分頃。さらに2日前の未明にも数分間接続されている。TeamViewerに登録していた残りの2台のノートPCはオフラインだったかWindowsをログアウトしていたようで荒らされた形跡は無い。実家のノートPCはTeamviewerを使ってシャットダウンし家人に触らないように伝える。Wi-Fiでつながっていたもう一台のノートPCもネットワークから切り離す。TeamViewerのパスワードは変更したものの、あまりにもずさんなパスワードリセットの手順に驚愕。すぐにアカウント自体も削除し、TeamViewerもアンインストールする。だが今さら消したところでもう遅い。愚かにもデスクトップにショートカットを置いていた秘密の平文メモファイル・゚゚(ノД`)が盗まれたことを想定せざるを得ない。これには利用している数十のサービスのログインIDとパスワードが記入されている。情けない。一刻を争う緊急事態だ。
 飯も食わず便所にも行かずぶっ通しで作業を続ける。金融サービス、GoogleやYahooなどのポータルサイト、あらゆるショッピングサイト、VPS(レンタルサーバー)や使ってもいないFacebookやSNSなど過去にアカウント登録したことのあるすべてのサービスをチェックする。アカウントが有効ならパスワードを変更する。利用していないサービスは退会手続きをする。二段階認証の設定が可能なものはニコニコ動画に至るまですべてそれを設定する。深夜までかかって一通りの作業を終えた。結果、Amazon以外に異常を見つけることはできなかった。デスクトップに侵入された以上、バックドアがインストールされている可能性がある。「トレンドマイクロ オンラインスキャン」をダウンロードし、オフライン状態で全てのドライブに対してフルスキャンを行う。TeamviewerがインストールされていなかったLAN内PCもWindows Defenderとトレンドマイクロでスキャンを行う。すべてのドライブのスキャンを終えるのに3日間を要したが、それらしいものは検出されなかった。やられたメインのデスクトップPCの再インストールは行わず、ひとまずオンライン状態に復帰させることに。だがしかし、発見されなかったバックドアは見事に常駐していた。
 …数日後。第二の戦慄が。SSHトンネリングを使いVPS経由でデスクトップPCからノートPCへVNCを接続し、リモートデスクトップ操作をする実験を繰り返している最中だった。横目で見ていたデスクトップPCの画面に突然Chromeブラウザが起動し、ものすごい速さでカーソルが奪われアドレスバーに「あAa」という文字とバックスペースが次々と打ち込まれている。反射的にルーターからケーブルをひっこ抜く。その間約1秒。今入られた! 心臓がバクバクする。何が起こった!?
今まさにトンネルを張る実験をしていた。確かにVNCはインストールした。今の実験で入られた?? 万一VPSに侵入されたとして、すべての仕組みがバレたとしても、ここまで入る方法があり得るだろうか? 今の瞬間はトンネルも張っていなければVNCサーバーも起動させていない。2台のPC画面と今引っこ抜いたケーブルの先端を見つめながら30分程呆然とする。どう考えても今やっていた実験を関連付けることはできない…バックドアだ。
タスクマネージャーを起動してみる。「C:\INFO\Ser.exe」なるものが起動している。中国語のDescriptionが表示されている。露骨に完全にもうこれだ。3日かかったフルスキャンは何だったのか。最初にタスクマネージャーを確認するべきだった。不審なプロセスを終了させ、イーサネットアダプタのIPアドレスを通信できないアドレスに設定しケーブルを接続してリンクアップさせる。再びプロセスが上がってくるのかどうか挙動を観察するも、1時間くらい放置しても自動起動される様子はない。スタートアップには登録されているがタスクスケジューラやサービスには登録されておらず、ログイン後にユーザーモードで起動するだけのように見える。C:\INFOフォルダとSer.exeのタイムスタンプを見るとTeamviewerで長時間侵入された時間帯と一致する。数日間このプロセスが起動した状態でネットに接続されていたことになり、その間果たして何度入られたのかは知る方法が無い。AmazonはSMSを使う二段階認証に変更済みだ。ブラウザのパスワードはすべて削除し、必ずログアウトするようにした。「この端末は今後確認しない」のオプションは選択せず、このブラウザからAmazonへログインすれば必ずSMSが送られる。そしてこの数日間は身に覚えのないAmazonからのSMSは届いていない。ということは、危険にさらされていたこの数日間はこのPCのブラウザからAmazonへの不正ログインは試行されていない。今しがた勝手にアドレスバーに入力された文字からして、敵の第一目標がAmazonであるならば、たまたま居合わせたつい今しがたこそが、バックドアから初めて侵入された瞬間だったのではないだろうか。初回侵入された時間帯あたりのタイムスタンプですべてのファイルを検索する。気味が悪いので関連のファイルは後日消してしまいファイル名などは失念してしまったが、C:\に別のフォルダがあり、Ser.exeのログと思われる不思議なサムネイル画像が10個程格納されていた。ブラウザウィンドウの画面キャプチャのようで、横が100ピクセルほどの大きさのため詳細は分からないが、侵入中のAmazonの注文明細ページと思われる画像、自分が開いていたタブと思われるNikonサイトの画像、見覚えの無い中国風の腰痛だの健康グッズのサイトのような画像が数種類。後半はバックドアのダウンロードに使うサイトなのかもしれない。そのほかにいくつかのバイナリやテキストファイルがあり、テキストファイルの一つはBase64でエンコードされた受信メールのようで、From:にAmazonが含まれていたと思う。メーラーが受信する注文メールを抽出したのだろうか。使っているメーラーのThunderbirdのデータファイルの中にもタイムスタンプが該当するものがあった。普段自分では受信時にだけThunderbirdを起動させ、見終わったら終了させている。自分では起動させていない時間帯のタイムスタンプのファイルがあるということは、侵入した犯人がThunderbirdを起動し、注文確認メールを受信・削除する操作を行ったのだろうか。あるいはこのSer.exeが自分でそれを行う仕組みなのだろうか。Amazonのカスタマーサービスへ電話した際に、Amazonからのセキュリティアラートがメールで送信されている旨とその時刻(初回侵入時時間帯の約30分後)を教えてくれたが、その際「もしAmazonからのセキュリティアラートのメールが見つからなかったらまた連絡を」という意味ありげなことを言われた。Amazonからのアラートメールが消される事例があることを示唆しているのかもしれない。そして実際にそのメールは探しても受信トレイやジャンクフォルダには見つけることができなかった。
後にAmazonから受信した注文キャンセルメールによれば、ChromeブラウザがログインしていたAmazonサイトでNintendoやモバゲーなどのゲームプリペイドなど27件・23万円程の注文操作がされていた。Amazonアカウントスペシャリストなる対応部署により、不正操作による注文と変更をAmazon内ですべてキャンセルしてくれたため、今回の件での金銭的被害は無い。だが二次被害防止のためにパスワード変更やウィルススキャンに要した時間、この後おこなうメインPCの再インストールと復旧作業の負担、それに加え精神的ダメージは大きい。だがしかし、発見がもっと遅れていたり侵入者が日本人だったとしたら、各種サービスのログインIDとパスワードをメモした平文ファイルへのリンクがデスクトップに丸出しでネットバンキングや証券口座を操作することも可能な状態であったことを考えると、これが被害のすべてだとしたら幸運だと言うしかない。
 TeamViewerの二段階認証の存在を知らず、設定していなかったのが致命的だった。二段階認証を設定していない場合のTeamViewerアカウントのパスワードリセットの方法はおそろしく簡単で、ログインページでメールアドレスを入れてボタンを押すだけで、パスワードリセットのメールがアドレス宛に平文で送信される。届いたメールの本文内にある長いURLにアクセスするだけで、新しいパスワードを入力することができる。この方法は極めて脆弱と言える。今回の侵入被害を確認した直後、自分ではTeamViewerのアカウントにはログインすることができず、パスワードは変更されているようだった。実際に自分でパスワードリセットのボタンを押してみると一度目ではパスワードリセットのメールを受信することはできず、二度目で中国語バージョンのパスワードリセットメールが送られてきた。中国語のメールにあるURLをクリックするのは勇気がいるが、事件の二週間ほど前に日本語バージョンの同じフォーマットのパスワードリセットメールを二度受信していたので、今回のこれが何であるかはわかる。心当たりのないパスワードリセットのメールを受信した際には何が起こっているのかがピンと来ず無視しただけだったが、それらがなぜ届いていたのかが今やっと理解できた。自分でパスワードを変更した後、更にもう一度パスワードを変更しようとしたところ、パスワードリセットのメールを受信するまでは3回ボタンを押す必要があった。TeamViewerの乗っ取り被害は去年から多発しているそうだが、犯人の手口は流出した他のサービスのアカウントリストやパスワードの総当たりによる突破だけではなく、TeamViewer.comから送信されるパスワードリセットのメールの一部を不正な経路へ転送させてキャプチャしているのではないかと思う。