安全にリモート接続！TeamViewerでセキュリティ最優先の設定
自宅では基本席にMac生活なのですが、Windowsでしかできないソフト利用も一部あり、仕方なく仮想マシンとしてWindowsを起動しています。今まではMacでMicrosoft純正の「Microsoft Remote Descktop」を利用していたのですが、MSパッチの都合でRDPに不具合が発生してしまい、代替方法を検討しました。
結論を先に記すと、TeamViewerでいいかなって思いました。小生はTeamViewerのような第三者設備を経由する仕組みが嫌い（気持ち悪い）で極力避けるようにしているのですが、設定次第でそこそこ安全に使えるかなと思ったので、利便性とのバランスが良いと感じています。
Microsoft Remote Descktop 代替の選定
まず、定番のVNCでいいかなと思って数年ぶりに「UltraVNC」を利用。ある程度の操作はできるのですが、テキスト入力が非常に不安定で、なぜかVNCの画面転送が止まってしまいます。
- Windows側環境: Windows 7 (64bit), UltraVNC, 既にTeamViewerも存在
- Mac(Client)環境: Chicken of the VNC
競合しているのかもしれませんが、あまり本気でないところの事象切り分け・深堀をするのが面倒だったので、さっさと次を探すことにしました。次に、稀に外出先から繋げられるようにインストールをしておいたTeamViewerをもっと安全に使えないか？という方向で検討をはじめます。
TeamViewerをセキュアに利用する設定
ソフトウェアそのものの安全性は、公式ページの情報を鵜呑みにすると、セキュリティ要求の高い銀行でも採用されている実績などを踏まえると信用してよいと考えられます。（信じるしかない、とも言う）
TeamViewerは「使用中のID」「パスワード」「個人的なパスワード」「サインイン用のID（電子メールアドレス）」など、いろいろあってわかりにくいです。小生も完全には理解していませんが、この複雑さは第三者から接続して支援してもらうようなシーンも想定されていることが要因と考えられます。
自分だけがセキュアに使う前提ならば、もっとシンプルに考えられます。以下考え方を記載します。
目指すTeamViewerリモートアクセス環境
以下のポリシーで検討します。
- 自分だけが使えればいい
- 何より安全（セキュア）を優先して考えたい
- 自宅内（同一LAN）でリモート接続する場合はインターネット経由にしたくない
これらが目標となります。
先ほどいろいろなID／パスワードがあると記載しましたが、上記のポリシーに当てはめると次のように使い方を整理できます。
| 設定項目 | 利用方法 |
|---|---|
| 使用中のID | 遠隔操作受付用。本来、他人からの接続を受け付ける時などに相手へ教える情報となるが、自身での利用に限れば不要。設定上無効にはできないので無視することになる。 |
| パスワード | ^ |
| 個人的なパスワード | 該当デバイスへのリモート接続時に入力するPW |
| WebサインインID(メアド) | アカウントへのログインに利用。アカウントには複数端末がひも付き一覧化されるので、それを選択することでリモート接続できる。かつホワイトリストで接続元を限定する際にも利用（詳細後述） |
| WebサインインPW | ^ |
part1: ここは絶対にやっておきたい！設定
TeamViewerはもともと他人からも接続しやすいようになっているので不安が残ります。そこで、下記の通り二重の対策で他人からの接続リスクを最小限にします。
- TeamViewerをインストールした端末へのリモート接続は、許可したアカウントでしか許可しない設定とする（ホワイトリスト）
- 遠隔操作受付用のパスワードは最もセキュリティレベルが高い設定とする（※ホワイトリストにした時点で事実上意味はなくなりますが念のため）
- 個人的なパスワードもそれなりの強度にしておく
１のホワイトリスト設定が最も重要なところで、ここさえ守れればその他は補足的なものになりますが、しっかりやるに越したことはありません。
パスワードのセキュリティは「非常に安全（10文字）」を選びます。また、最下部の「設定」ボタンからホワイトリスト設定を行います。
自身のアカウント（Webサインインのメアド）を入力して接続を限定します。
遠隔操作用のパスワードは、見ての通り記号を含む強固なものになっています。
part2: 必須ではないけど可能ならばやりたい！設定
part1でどんなに遠隔操作対策をしたところで、肝心のアカウントが乗っ取られては意味がありません。ここのパスワードを強固にしておくのは当然ですが、加えて二段階認証もやっておくとベストでしょう。
二段階認証は、Google, Evernoteなどと同様の一般的な方法（Google認証アプリ）が利用可能です。別の話題になりますが、Google認証アプリは1デバイスにしかインストールできないため、複数デバイスでワンタイムコードを確認できるAuthyアプリもお勧めです。
自宅内での利用の場合はLAN接続で高速化
これが結構びっくりしたのですが、TeamViewerでは接続先としてLAN内のIPアドレスも指定できるようです。てっきりインターネット経由が必須だと思い込んでいたので非常に有り難い。
LAN接続を許可するには、「受信LAN設定」の項目を同意としておく必要があります。
| 設定項目 | 動作 |
|---|---|
| 非アクティブ化済 | LAN接続はできず、インターネット接続のみになる |
| 同意 | LAN接続とインターネット接続が共存できる |
| 同意のみ | LAN接続しか許可しない |
余談：徹底的にセキュリティを追い求める場合
自宅へのVPN接続＋RDP/VNC等でのリモートアクセスがベストでしょう。しかし、ガチガチすぎるが故に利便性の低下は否めません。
- 外出先のスマホからリモート接続したいと思った場合、一度VPN接続をしたうえでRDPアプリの起動を行うので、一手間多い
- VPN接続時のバッテリ消費は少なからず早くなる
- RDP接続先のブラウザでFlashのページ（艦これなどのFlashゲームなど）を表示すると、かなりカクカクして話にならない（TeamViewerだと割と快適。RDPの問題であって、VNCでは問題ないかもしれない）
- そもそも、VPN接続用のLinuxサーバを建てるのも面倒。VPN可能なルーターを買ってもよいが、製品縛りが発生してしまうので嫌。
これらは、実際にこの環境で運用を続けてきて常々思っていた不満でもあります。致命傷とまではいかなかったのでそのまま使い続けていましたが、今回RDP接続が不良になったのを機に完全に見直すこととしました。
TeamViewerの場合はそれぞれの環境にアプリをひとつインストールするだけなので非常に楽ですね。本記事に示したとおり、セキュリティを意識した設定を行えばそれなりに安全ですので、この選択肢は非常にアリだと思いました。
PMSの検知が遅延するのでF/Wを疑った結果正解だったので対策した
PMS (PS3 Media Server) と PlayStation3 を利用したDLNA環境での動画再生がお気に入りの環境なのですが、PMSのサーバをUbuntuからCentOSに変えて以降、DLNAサーバを認識するのに時間がかかるようになってしまいました。
從來は即DLNAサーバを認識していたのですが、CentOSに変更後は体感で2分程度の無応答時間の後にDLNAサーバが現れる感じ。
しばらく放っておいたのですがストレスもたまってくるので、原因追求を行いました。結論としては、F/W（iptables）が悪さをしていた様子です。後述するF/W許可ルールを適用したらDLNAサーバ（PMS）検知のレスポンスが非常に良くなりました。
PMS: Playstation Media Server 利用ポートの一覧
以下、iptables のリストを記述します。
-A INPUT -s [YourNetwork] -p tcp --dport 5001 -j ACCEPT -A INPUT -s [YourNetwork] -p udp --dport 5001 -j ACCEPT -A OUTPUT -d [YourNetwork] -p tcp --sport 5001 -j ACCEPT -A OUTPUT -d [YourNetwork] -p udp --sport 5001 -j ACCEPT -A INPUT -s [YourNetwork] -d 239.255.255.250 -p udp --dport 1900 -j ACCEPT -A OUTPUT -d [YourNetwork] -p udp --dport 50733 -j ACCEPT
- [YourNetwork]部分は、DLNAクライアントとなるPS3本体またはPS3が所属するネットワークアドレスを記載します。
- port 5001 部分は、PMS.confの「Server Port (port = xxxx)」に記述しているポート番号を記載します。何も指定ない場合はデフォルト5001になるようですが、念のためにあえて明記しています。
- iptablesのDROPログを見ているとPS3宛のUDP通信がいくつかのポートから発生していました。1個1個対応するのはイタチごっことなり面倒だったので、PS3宛UDP通信を全て許可しています。
- 同じくDROPログを見ていたらマルチキャスト通信が発生していました。具体的にどのシーケンスでなのかは深堀りしていませんが、DLNAクライアントがサーバを見つける時にマルチキャスト（IGMP）を利用していることを知れてひとつ理解が深まりました。
iptablesのDROPログ確認方法
CentOS 6.4標準環境をベースとした場合に以下の手順を踏めば取得可能になるかと思います。
ls -l /var/log/iptables mkdir -p /var/log/iptables ls -l /etc/rsyslog.d/ vi /etc/sysconfig/iptables # 前述したiptablesルールを適用 vi /etc/rsyslog.d/35-iptables.conf :msg,contains,"DROP:" -/var/log/iptables/iptables.log sudo service rsyslog restart
PRIMERGY(富士通)カスタムESXi5.1を5.5にバージョンアップする
ESXi 5.1(無償版)を5.5にアップグレードするでも記したとおり、無償版ESXi(VMware)では下記の問題があるため、アップグレードの方法は限られるようです。
- 無償版ライセンスではVMware Update Managerは使えない
- 無償版ライセンスの場合アップグレード用のファイル「ESXi Offline Bundle」をダウンロード出来ない
しかし、PRIMERGY版オフラインバンドルの場合はTechnical Support pages from FujitsuサイトでOffline Bundleが入手できましたのでこれを利用します。
PRIMERGY版の Offline Bundle を適用するとどうなるのかについては、マニュアルにある以下記載の通りです。
5.1.2 オフラインバンドルの適用
オフラインバンドルとは、弊社のサーバ向けにパッチやドライバと CIM Provider をまとめたものです。 オフラインバンドルを適用することにより、最新のインストールイメージを用いてインストールした状態と同等の環境にできます。 オフラインバンドルの適用には Update Manager もしくは vSphere CLI を利用できます。
WEB経由でのアップグレード方法はこちらの記事も参考にしてください。
-> ESXi 5.1(無償版)を5.5にアップグレードする
Offline Bundleを利用したバージョンアップ作業の流れ
- オフラインバンドルファイル（カスタムイメージ）を入手
- ESXi ホストで実行しているすべての仮想マシンの電源を OFF にする
- ESXi ホストをメンテナンスモードにする
- オフラインバンドルを ESXi ホストに転送する
- 4.1. VMware vSphere Client を使用する方法
- 4.2. SCPで転送する方法
- オフラインバンドルを ESXi ホストにインストールする。方法は次の3種類
- 6.1. ESXi ホスト上で実行する場合
- 6.2. クライアントからリモートでインストール場合 (Offline Bundle がオンライン上)
- 6.3. クライアントからリモートでインストール場合 (Offline Bundle が ESXi ホスト上)
ここでは4.2及び6.3の方法で実施するケースを記載します。
いろいろ関連情報が多くて一瞬面倒に感じますが、要領をつかむとアップデート作業そのものは非常にシンプルです。むしろ Offline Bundle のダウンロード時間の方が長く待たされるくらいです。
Offline Bundle の入手
富士通版のImageファイル類はこちらのサポートページからダウンロードできます。
「Driver Quicksearch:」の検索フォームへ「image ESXi 5.5」と入力。
今回利用するバージョンは以下のとおり：
Description:
File: FTS_FujitsuCustomOfflineBundleESXi55_30021331820_1101110.ZIP
Version: 300.2.1331820
Date: 09.12.2013
Size: 333,99 MB
Language: Language: English / English
Manufacturer: Fujitsu
Offline Bundle を SCP で転送する
SSHでESXi(VMwareKernel)に接続できていることを前提として記載します。
# scp ./FTS_FujitsuCustomOfflineBundleESXi55_30021331820_1101110.ZIP root@esxihost:/vmfs/volumes/datastore0/images/
[注1] esxihost部分は接続先サーバのFQDN又はIPアドレス
[注2] /vmfs/volumes 配下のディスク構成及び保存場所は環境に応じて要変更
Offline Bundle を適用してアップグレードする
lsiproviderがインストールされているOK。大文字を含む LSIProvider が入っている場合は削除が必要になるとのこと。
~ # esxcli software vib list | grep lsi
lsiprovider 500.04.V0.34-0012 LSI VMwareAccepted 2013-05-04
この結果は問題無い場合。
そして Offline Bundle を指定してアップグレードします。
~ # esxcli software vib install -d FILE_PATH
// FILE_PATH = zipファイルのフルパス。SCP転送先のパスを記載(相対パスはNG)
コマンド実行後、応答が返ってくるまで2,3分程度の時間がかかりました。
!! このコマンド(software vib install)でも目的のバージョンアップは可能ですが非推奨ですので software profile update を利用しましょう。詳細は後述します
Installation Result
Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
Reboot Required: true
VIBs Installed: (省略)
VIBs Removed: (省略)
VIBs Skipped:
正常に完了したらリブートします。
~ # esxcli system shutdown reboot -r "update to ESXi5.5"
ESXiアップグレード前のバージョン確認
~ # esxcli system version get
Product: VMware ESXi
Version: 5.1.0
Build: Releasebuild-1065491
Update: 1
~ # esxcli software profile get
Fujitsu-VMvisor-Installer-5.1.0.update01-1065491-v260-1
Name: Fujitsu-VMvisor-Installer-5.1.0.update01-1065491-v260-1
Vendor: Fujitsu
Creation Time: 2013-05-04T00:21:45
Modification Time: 2014-02-11T11:51:30
Stateless Ready: False
Description:
Fujistu customized ESXi5.1 Update 1 Image, based on VMware build
1065491
ESXiアップデート後のバージョン確認
再起動するまでバージョン表示は変わりません。
~ # esxcli system version get
Product: VMware ESXi
Version: 5.5.0
Build: Releasebuild-1331820
Update: 0
~ # esxcli software profile get
(Updated) Fujitsu-VMvisor-Installer-5.1.0.update01-1065491-v260-1
Name: (Updated) Fujitsu-VMvisor-Installer-5.1.0.update01-1065491-v260-1
Vendor: yourHostName
Creation Time: 2014-02-11T11:52:23
Modification Time: 2014-02-11T11:54:15
Stateless Ready: False
Description:
2014-02-11T11:52:23.225778+00:00: The following VIBs are
installed:
...(中略)...
----------
Fujistu customized ESXi5.1 Update 1 Image, based on VMware build
1065491
(以下略)
バージョンが正常にあがっていることを確認したら、メンテナンスモードを解除します。
~ # esxcli system maintenanceMode get
Enabled
~ # esxcli system maintenanceMode set -e false
~ # esxcli system maintenanceMode get
Disabled
アップデート作業を追えて理解できた注意事項
vib install ではなく profile update を使うべき
アップデート関連コマンドとして esxcli software profile update があります。
VMware KB2020972(VMware Security Patching Guidelines for ESXi and ESX) にて、パッチのアップデートはプロファイルを指定する esxcli software profile update が推奨されています。
今回の作業手順で利用した esxcli software vib install はアップデートというよりもクリーンインストールに近い趣旨のコマンドです。これを実行すると自分で入れたドライバー等、Hypervisorインストール後に導入したものが消失してしまいます。
カスタムイメージを利用している場合は次のコマンドを利用しましょう。
esxcli software profile update -d <depot url or offline bundle zip file> -p <profile_name>
Offline Bundle を入手して配置するまでの手順は全く同じです。
Offline Bundle に含まれるプロファイル名を確認するコマンド
esxcli software profile update では -p オプションでプロファイル名を指定する必要がある為、Offline Bundle に含まれているプロファイルを確認します。
~ # esxcli software sources profile list -d /vmfs/volumes/datastore0/images/FTS_FujitsuCustomOfflineBundleESXi55_30021331820_1101110.ZIP
Name Vendor Acceptance Level
---------------------------------------------- ------- ----------------
Fujitsu-VMvisor-Installer-5.5.0-1331820-v300-2 Fujitsu PartnerSupported
今回のケースでは1個しか含まれていません。
プロファイルを指定してアップデートする
確認結果を踏まえ、プロファイル名を指定してアップデートを実施します。
esxcli software profile update -d <depot url or offline bundle zip file> -p <profile_name>
example:
esxcli software profile update -d /vmfs/volumes/datastore0/images/FTS_FujitsuCustomOfflineBundleESXi55_30021331820_1101110.ZIP -p Fujitsu-VMvisor-Installer-5.5.0-1331820-v300-2
参考：ESXi 5.1 コマンドラインによるパッチ適用 | Japan Cloud Infrastructure Blog - VMware Blogs
この間違いに気付いたきっかけ
ESXiアップデート後のバージョン確認で記した結果を見て、次の点が気になりました。
- (Updated) という記載は何なのか
- そもそも未だ 5.1.0.update01 という記載が残っている
- vendor 部分が何故か自身のホスト名になっている
これらの原因を明確にすべく調べた結果、利用コマンドの違いが分かりました。今どういう状況なのかというと、アップデート前の5.1版プロファイルをベースに5.5への差分修正が加わった（Updatedされた）独自プロファイルになった状態といえます。
このままでも ESXi 5.5 として動いています。
vib install してしまった後に修正できるのか
上記 "プロファイルを指定してアップデートする" で記載した方法で改めてコマンドを打ち込んでみましたが、以下の表示がされ何も修正されずに終了してしまいました。
Update Result
Message: Host is not changed.
Reboot Required: false
VIBs Installed:
VIBs Removed:
VIBs Skipped: Emulex_bootbank ... (以下省略)
しかし、software profile にも install コマンドがありますので、結果以下のとおり実施することで上書きが可能でした。
~ # esxcli software profile install --ok-to-remove -d /vmfs/volumes/datastore0/images/FTS_FujitsuCustomOfflineBundleESXi55_30021331820_1101110.ZIP -p Fujitsu-VMvisor-Installer-5.5.0-1331820-v300-2
Installation Result
Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
Reboot Required: true
VIBs Installed:
VIBs Removed: VMware_bootban
..(以下略)..
--ok-to-remove オプションを設定しています。これが無いと Exception が発生し「いくつか消してもよいか？」という趣旨の警告が表示されます。
なお、–dry-run オプションで先に検証できますので本適用前の実施を推奨します。
結果、以下のとおり正常にアップデートできました。先ほどとは異なり、profileは最新が利用され、"(Updated)"の字も消えました。
~ # esxcli system version get
Product: VMware ESXi
Version: 5.5.0
Build: Releasebuild-1331820
Update: 0
~ #
~ # esxcli software profile get
Fujitsu-VMvisor-Installer-5.5.0-1331820-v300-2
Name: Fujitsu-VMvisor-Installer-5.5.0-1331820-v300-2
Vendor: Fujitsu
Creation Time: 2014-02-11T14:16:04
Modification Time: 2014-02-11T14:16:04
Stateless Ready: False
Description:
Fujistu customized ESXi5.5 Image, based on VMware build 1331820
(参考) esxcli software vib xxx も2種類ある
~ # esxcli software vib --help
Usage: esxcli software vib {cmd} [cmd options]
Available Commands:
install Installs VIB packages from a URL or depot.
VIBs may be installed, upgraded, or downgraded.
WARNING: If your installation requires a reboot,
you need to disable HA first.
update Update installed VIBs to newer VIB packages.
No new VIBs will be installed, only updates.
WARNING: If your installation requires a reboot,
you need to disable HA first.
esxcli software vib update は古いパッチをスキップする
このような表示でSkipされます。
VIBs Installed:
VIBs Removed:
VIBs Skipped: VMware_bootbank_ata-pata-amd_0.3.10-3vmw.510.0.0.799733,・・・
esxcli software vib install は古いパッチでも強制的にアップデートする
以上の結果から、ただアップデートしたいだいたいのケースでは esxcli software vib update で満足できると思います。
参考：VMware ESXi5.1検証 第9回 ESXiへのパッチ適用について | g/re/p
(参考) ESXi 5.x のイメージ提供方法は2種類ある
以下の記載は 公式ブログ（VMware ESXi イメージ管理ベストプラクティス） からの引用です。
ESXiのイメージには、ISO、ZIPの2種類があり、以下のような特徴があります。
ISO
- CDに焼くことによりBootableとなり、ESXiのインストールが可能
- オフラインバンドルから作成することも可能
ZIP
- オフラインバンドルの1つであり、ESXi独自のユニークなバイナリ提供方法
- ESXiを起動・インストールするために必要な複数のVIBやイメージプロファイルなどで構成される
- 様々なカスタマイズや、 ISOファイルへの書き出しが可能
ESXiのイメージ管理にはISOファイルではなく、ZIPファイル（オフラインバンドル）を利用します。
※ オフラインバンドルはESXiイメージ全体の提供だけではなく、デバイスドライバやエージェント類の提供方法としても利用されています。この場合は、単一のVIBかつイメージプロファイルを含まない形が主となっています。
オフラインバンドルは下記の通り構成されています。
VIB・・・VMware Infrastructure Bundle
ESXiの構成上必要なパーツで、以下のような物があります
- ESXiベースイメージ（ESXi Kernel）
- デバイスドライバ
- CIMプロバイダ
イメージプロファイル
起動（インストール）に利用する複数のVIBを選択・定義した物
- 上記VIBの内、ここで定義された物が起動（インストール）時に読み込まれる
- インストーラー（ISOファイル）を書き出す事が可能
- カスタマイズが可能
ESXiアップデート作業のまとめ
長くなりましたが結局必要なコマンドは以下の通りです。単純なことが分かります。
~ # esxcli system maintenanceMode set -e true
~ # scp ./FTS_FujitsuCustomOfflineBundleESXi55_30021331820_1101110.ZIP root@esxihost:/vmfs/volumes/datastore0/images/
~ # esxcli software sources profile list -d /vmfs/volumes/datastore0/images/FTS_FujitsuCustomOfflineBundleESXi55_30021331820_1101110.ZIP
~ # esxcli software profile update -d /vmfs/volumes/datastore0/images/FTS_FujitsuCustomOfflineBundleESXi55_30021331820_1101110.ZIP -p Fujitsu-VMvisor-Installer-5.5.0-1331820-v300-2
~ # esxcli system shutdown reboot -r "update to ESXi5.5"
参考リンク
