2022年3月25日金曜日

Windowsのモニタ認識番号でどうしようもなくハマったので覚書

仕事でマルチモニタで作業をすることが多い私。今回はその中で「あんちきしょう!」と叫びたくなるくらいハマったので、自分用の覚書的に記事にしてみました。

なお、今回の記事ではレジストリを弄りまわしているので、自力で元に戻す自信のない方や、レジストリって何?って方は不用意に試さないで下さいね。失敗すると本気でPC壊れちゃうので。 

では、本題。仕事上で使うツールの中に、マルチモニタ環境で複数のツール画面を展開できるものがあるんですが、この中のとあるウィンドウが、表示して欲しいモニタに出てくれない!という事態に遭遇。当初「プライマリディスプレイになってないからでしょ?」程度に軽く考えていたものの、プライマリディスプレイの設定はきちんと行われており、何ら問題ないことを確認。接続を変えてもダメ。

困り果ててリファレンスに目を通すと

「本ツールのウィンドウ制御は、ディスプレイの識別番号によって表示位置を認識しています」との記述を発見。

つまり、プライマリディスプレイを起点とした絶対座標でもなければ、ツールのメインウィンドウを起点とした相対座標でもなく、各ディスプレイ毎の絶対座標をディスプレイ識別番号で設定し、表示していたわけです。

で、困ったのがモニタの接続は入れ替えられるけど、モニタ自体は入れ替えられないって事。いや、入れ替えようと思えば入れ替えられるんですが、モニタアームを使用している環境だったので「めんどくっさ!」となった訳ですね。

何とか設定変更で解決できないものかと色々調べたところ、どうもレジストリでディスプレイ毎のハードウェア的な情報と表示時に付与する番号を管理しているらしい、ということが判明しました。

HKLM\Systems\CurrentControlSet\Control\GraphicsDrivers\Configuration
HKLM\Systems\CurrentControlSet\Control\GraphicsDrivers\Connectivity

 要はこの2つのレジストリを消しちゃえば、過去に当該端末へ接続したディスプレイの識別情報は綺麗さっぱりなくなるということ、ですね。

※作業時に接続するディスプレイは、識別上1番で認識して欲しいディスプレイのみに限定する必要はあるみたいです。

まぁレジストリはレジストリなわけで、下手に弄ると取り返しのつかないことになるわけですね。ええ、訳も分からず弄るとOS壊すって事です。やはり作業前に消そうとしているレジストリはバックアップを取るべきでしょうね。

 ただこの作業、結構な頻度で発生しそうなので(仕事柄マルチモニタ環境を作る機会が結構多い)全部ひっくるめてbatファイルにしちゃうことにしました。

 以下ソース

@echo off

REM カレントディレクトリを保持します
SET CAL_DIR=%~dp0

REM バックアップしたレジストリの出力先
SET TmpFile=%CAL_DIR%%date:/=-%


ECHO 本バッチプログラムを実行すると、過去に端末に接続されたディスプレイの認識情報をすべて初期化されます。
SET /P USR="処理を続行します。よろしいですか?(y/n)"

REM 第1段階チェック処理
IF NOT %USR%==y (
 ECHO ユーザ操作により中止されました
 GOTO END
)

ECHO 本バッチプログラムを実行する前に、ディプレイ認識番号1番で認識させたい
ECHO ディスプレイのみ、接続されている状態であることを確認してください。
SET /P USR="処理を続行します。よろしいですか?(y/n)"

REM 第2段階チェック処理
IF NOT %USR%==y (
 ECHO ユーザ操作により中止されました
 GOTO END
)

REM バックアップしたレジストリファイルの格納先を用意
IF NOT EXIST %TmpFile% (
 MKDIR %TmpFile%
)

REM 既存レジストリをバックアップ
REG EXPORT HKLM\System\CurrentControlSet\Control\GraphicsDrivers\Configuration %TmpFile%\GraphicsDriversConfiguration.reg /y
REG EXPORT HKLM\System\CurrentControlSet\Control\GraphicsDrivers\Connectivity %TmpFile%\GraphicsDriversConnectivity.reg /y

REM 既存レジストリのバックアップ実行状態チェック
IF NOT EXIST %TmpFile%\GraphicsDriversConfiguration.reg (
 ECHO 既存レジストリのバックアップに失敗しました。処理を中止します。
 GOTO END
)
IF NOT EXIST %TmpFile%\GraphicsDriversConnectivity.reg (
 ECHO 既存レジストリのバックアップに失敗しました。処理を中止します。
 GOTO END
)

ECHO 最終確認 過去に端末に接続されたディスプレイの情報を初期化します。
ECHO 実行しているプログラム等によっては、予期しない不具合が生じる可能性があります。
SET /P USR="処理を続行します。よろしいですか?(y/n)"

REM 最終段階チェック処理
IF NOT %USR%==y (
 ECHO ユーザ操作により中止されました
 GOTO END
)

REM 既存レジストリを削除
REG DELETE HKLM\System\CurrentControlSet\Control\GraphicsDrivers\Configuration /f
REG DELETE HKLM\System\CurrentControlSet\Control\GraphicsDrivers\Connectivity /f

:END
pause

はい、わかる方からしたらかなり無駄な事してるなぁと思われそうな(笑)。

処理の流れとしては、

1.既存のレジストリをバックアップするフォルダを日付でカレントディレクトリに作成

2.キー「Configuration」とキー「Connectivity」をバックアップ

3.キー「Connectivity」とキー「Connectivity」を削除

って感じです。気を付けないといけないのは、本処理を実施する場合、事前に認識番号1番で認識して欲しいディスプレイのみ接続されている状態になるようにしなきゃいけないって事と、管理者での実行が必須って事ですかね。 

ちなみに、実行後に認識番号2番以降で接続して欲しいディスプレイをつなぐ場合、必ず再起動すること。というのも、本バッチプログラムで削除したふたつのキーは、ディスプレイの「再接続」時に生成されるため、実行直後は空っぽの状態になっています。これがちょっと厄介。

どういうことかというと、認識番号1番で拾って欲しいディスプレイの接続情報、バッチ実行直後(レジストリ削除直後)には再作成されていない為、「うほーい!レジストリが消えたぜ!」と意気揚々と認識番号1番で拾って欲しいディスプレイが接続されている端末に、認識番号2番で拾って欲しいディスプレイを再起動せずに接続しちゃうと、後から接続したディスプレイに認識番号1番が付与されてしまい、本来1番で認識して欲しかったディスプレイの認識番号が2になっちゃうんですね。何とまぁ。。。

コレ、環境によって再現したり再現しなかったりマチマチで、気づくまでに滅茶苦茶時間がかかりました。あうあうあー。

 

というかこれ、UIレベルで修正できるようにならないものなんですかね。。まったく。

 

 2022/4/4 追記

その後調査してみたところ、オンボードグラフィックと別にUSB接続のグラフィックアダプタや、一部のマザボでは上記手順を実施してもうまくいかないケースがあることが判明。要はUSBアダプタのディスプレイ番号を、オンボード接続のディスプレイ番号の間に割り込むような形(オンボード DVIがNo1,USBアダプタがNo2,オンボードD-SubがNo3)みたいな認識は出来ないみたいです。面倒くさいなぁ。。。

 

ではまた!

2022年3月16日水曜日

ASUSTOR製NASのDEADBOLT騒動とその後

今回の記事ですが、相当に個人的主観と独断と感情盛り盛りでお送りしておりますので、不愉快だと思われる方いらっしゃいましたら、ブラウザバック推奨致します。それでも構わないぜ!って方だけ読んでもらえれば嬉しいです。

大丈夫です?本当に大丈夫です?

読み終わった後に「不快な気持ちになった!」とか言われても困りますよ。


では、本編。




えー、我が家で動いていたASUTOR製のNASですが、運用を停止しましたッ!!

イントラネット内での接続ならともかく、ASUTOR社が売りにしている外部アクセスサービス等をフル活用してオンラインに復帰することは、今後二度とないでしょうね。

理由は、Twitterにも書いてましたランサムウェア騒動。

被害に遭った当初、検索してみると「復帰のめどが立っている!」「ランサムウェアの被害に遭った場合でも、ユーザー自身でデータの復元や修復をしないように!」「イーサネットケーブルを抜き、初期化せず電源を切った上で、ASUSTORのサポートに連絡するように!」なんてアナウンスが出ていましたので

「なにぃ!!ランサムウェアでやられたデータを復元する手段を見つけたのか!?すごいぜASUSTOR!」

なんて考えていたんですが、後日出た公式の対応は

・サービス止めたよ!

・とりあえず緊急アプデ出すよ!

・暗号化されたデータ?バックアップ取ってなかったら初期化するしかないよ!

・バックアップ無しで暗号化されたデータの復元?無理じゃね?

 でした。うん、まぁ期待はしてなかったんですけども。「復帰のめど」って、なんのことだったんですかね?電源投入出来たら復帰??止めてたサービス再開したら復帰?うーん。

とまぁ、色々とがっかりっぷりが尋常じゃなかったので、今回こうして記事にしようかなーと思い立ったわけです。ハイ。

 

対応が後手後手

 先ずは事態が発生した後のメーカサイトの対応。被害を確認して即座に自社のサービスを停止に踏み切ったのは良かったものの、ユーザ登録している私のアカウントに今回の件のメールが来ることはなく(現時点でも届いていない)、この騒動を知ったのは被害に見舞われて検索をかけたときというお粗末さ。

しかも、調べてみると今回のトラブルの元となった脆弱性について、QNAP社から1月26日の時点でセキュリティアドバイザリが公開されていたようです。

Take Immediate Actions to Stop Your NAS from Exposing to the Internet, and Update QTS to the latest available version. Fight Against Ransomware Together | QNAP 

 つまるところ、他社からの発信情報とはいえ、エンドユーザに通知を出すきっかけはあったわけで、被害を未然に防ぐだけの情報はASUSTORで被害報告があった2月22日のひと月近く前にあったことになります。にも関わらず、ASUSTORからの修正版ADMの公開と暫定措置が講じられたのは被害の発生を確認した後。せめて、1月26日の時点でアナウンスを出すなり、ユーティリティや各種サービスを停止する措置を取っていれば、ここまで深刻な事態には成らなかったでしょう。

 

今後の対策に対する雑さに呆れる

 加えて、再発防止策?に対する各種初期設定の内容についても、予防措置を本気で取るつもりなのか?と疑問が残る結果でした。例えばNASの管理アカウントの件や接続ポート番号の件。仮にNASの管理アカウントをデフォルトに設定しないことでトラブルを防げるというのであれば、初期セットアップ時にデフォルトアカウントの使用は非推奨である旨の通知を出すべきだと思いますし、ポート番号にしても初期セットアップウィザード上で変更が可能なUIであれば、多少なり被害は少なかったんじゃないでしょうか?(ポート番号を変えることが対策になるという前提ですが)

 あと、メーカサイトではしきりに「バックアップを!」とおらび倒しておられますが、この点にも疑問が残ります。というのも、個人的には今回の例、仮にメーカサイトに記載されている方法でバックアップを取っていた場合、スナップショットであっても、外付けHDDへのスケジュールバックアップであっても、殆ど意味をなさなかっただろうなぁと考えています。

理由は至極簡単な話で、NASにアクセスした際にバックアップ用に接続したストレージ、領域が丸見えなんですよね。同一ネットワーク上にいる端末から見えるドライブが、NAS上から見えない訳は当然ないわけで、仮に外付けHDDにバックアップなりスナップショットなり取られていた場合であっても、相手がランサムウェアなら、まぁ普通にやられてお終いだった事と思います。

HDDの物理故障に対するバックアップという考え方ならばともかくとして、今回のようなランサムウェアに対する対策としてスナップショットやバックアップを用いるのであれば、バックアップ・スナップショットの取得中以外のバックアップ領域へは参照のみとし、更新処理は不可能にする、もしくは更新可能にする特殊な権限を当該ストレージに与え、通常使用するアカウントから直接更新出来ないようにする仕組みが無ければ役に立たないでしょうね。

今回私が殆ど被害を受けなかったのは、ASUSTORが提唱しているいずれのバックアップ方法も取らず、独自にバックアップを取る仕組みを採用していた(というより、以前のNASで使っていた方式をそのまま流用していた)からだったんだろうなぁ、と考えています。

別に難しいことをしているわけではなく、NASに入っているデータをWindows機経由で外付けのUSB HDDに手動で同期していただけなんですよね。で、HDDってのは動かせば動かすだけ劣化が進むので、バックアップが済んだらPCから切断して電源を落とし、普段は起動しないって方法で管理してたわけです。つまるところ、完全なオフラインですね。正月のセールで買った外付けHDDに完全に救われた形となった訳です。

 

 

来ないサポート連絡に痺れを切らす

公式からサポートフォームから連絡をして、対応を待つようにとの情報があり、即座に連絡を入れてはや半月、その後の返信等は一切なし。ASUSTORのTwitter公式アカウントにDMを送らせて頂いた所、再度送ってみて欲しいとのお話でしたので再送しましたが、やはり音沙汰なし。私が使っていたモデルが被害報告が集中していたモデルでは無かったのかも知れませんが、ADMの更新がリリースされたことさえ連絡してこない体制に、心底うんざりしてしまいました。

ここまで来ると「対策版のファームをリリースしました!」と言われても、本当に大丈夫なのか?また次回似たような事態が発生したとき、後手後手の対応に振り回されるんじゃないのか?と疑心暗鬼になってしまいました。今回はNASだけで済んだからまだよかったものの、そこから他のネットワークに繋がっている家電製品に被害が波及したら?なんて考えてしまうと、正直もう我が家のインフラに繋いでおくこと自体、億劫になっちゃったんですよね。

んで、運用自体は滅茶苦茶めんどくさくなるけれど、各端末のストレージ容量を拡充して、比較的頻繁にアクセスするファイルについては、各端末内にコピーをばら撒いてしまおう!となったわけです。それ自体も冗長化されたバックアップみたいなものですしね。

加えて、複数個所から情報の更新をするかもしれないと導入したNASですが、結局一番マシンパワーのある端末からしか弄ることが無かった(特に写真)ので、じゃあもう内臓HDDにしちゃったらいいじゃん、となりました。

運用を切替えて間もなく1週間経過しますが、殆ど不便は感じていません。


便利さと引き換えのリスクについて理解すべきだった

NASは便利です。それは間違いありません。ただ、これらのネットワーク機器を導入することにどのようなリスクが伴うのか、どのような事態が起こりうるのか、そしてどう対策を打てばいいのか、この辺りをもう少し真剣に考えるべきだったなぁと思っています。

まぁ、今更ネットのない生活なんて考えられませんから、適度にうまーく付き合っていくしか無いんですけどね。


今度の更新は、もう少し楽しい話題にしたいところです!

ではまた!!