2023年 09月 12日
今すぐできる Windows リモートデスクトップの脆弱対策：医療機関でのランサムウェア被害からの反省で私達が学ぶもの
大阪の医療センターで発生したランサムウェア被害は、まず、Fortigate が破られ、ここから傍系の給食システムが踏み台となって、メインの電子カルテなどの医療システムがランサムウェアの侵入を許してしまうという流れだった様です。ここで問題となったのは、おそらく踏み台となったシステムが、脆弱なパスワード、おそらく「よくあるパスワード」で Administrator アカウントで RDP 接続できたこと。また、構内ネットワークの多くの Windows マシンが Administrator は「右にならえ」の構成だったことが推測できます。
実際には、その裏にある医療業界全体にある、「医療システムはネットワークから分離している」という業界全体に盲目的に信じられている「閉鎖網神話」が大きな原因なのですが、じゃあ、私たち IT 業界の技術者にとって、予算をかけずに今すぐできる対策って何だろう、と考えると、 今回のインシデントで被害を拡大させた Windows Server のリモートデスクトップ（RDP) の設定をどうするか、という点です。
大病院で起きた大規模サイバーテロ：閉塞網が作る慢心が産んだ惨事
調 査 報 告 書 2023 年 3 月 28 日 地方独立行政法人大阪府立病院機構大阪急性期・総合医療センター
という事で、ここでは無料で Windows Server のリモートデスクトップ (以下RDP) をどう設定すべきかという点を、より具体的に取り上げてみます。全て費用がかからないことなので、今すぐ実践できることです。
Windows11 以降のリモートデスクトップ：よくあるトラブルWindows11po 23H2 ローカルアカウントのパスワードを変更できない
府立総合医療センターでの復旧後の運用ポリシー
府立総合医療センターでの調査報告では、復旧後、次の点を取り上げて運用ポリシーとしている層です。
管理者パスワード長：１２文字ログイン失敗でロックアウト：３回失敗で１５分ロックアウトBuiltin-Administrator ; 無効管理者用 ID / パスワード：ユニークで使いまわし厳禁リモートデスクトップポート：デフォルト√ 以外
現在は、プライベートネットワークでも、システムの仮想化は一般化しています。多くの顧客環境ではベアメタルサーバーのコンソールを使うのではなく、RDP で操作することが一般的になっているでしょうから、 RDP 接続のセキュリティの確保は重要です。Windows Server 2022 を対象に RDP の設定内容を検証してみます。
Windows リモートデスクトップの有効化
Windows RDP を有効化するには、スタート（田）＞ 歯車 ＞ システムにある「リモートデスクトップ」を有効化することに始まります。
次に、「サーバーマネージャー」のローカルサーバーから、「リモート管理」、「リモートデスクトップ」を有効化します。
これで、 Administrator から MSTSC を使った RDP 接続ができるのですが、デフォルトポート3389 は使わずに、安全のため別なポートに割り当てる事になります。
以下のレジストリに、ポート番号が設定されるため、別なポート番号を割り当てます。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
値は１６進数で表示されますが、十進表示に変えてランダムな値を与えます。
ここで重要なのは、小手先の下一桁を変えるのではなく、大胆に数値を変えること。また、運用中のサーバ毎にポート番号を変えることを検討します。攻撃者にとっては少しでも近寄りがたい設定にすることです。
接続する時は
C:\> MSTSC /V:IP-adder:Port
で接続するか、リモートデスクトップアプリケーションから接続先に「IP-Adder:Port」 を指定する形になります。
ビルトイン Administrator アカウントから一般ユーザへ
スタート（田）右ボタン＞ コンピュータの管理、から、Administrator とは異なるユーザを登録して、 Administrators と Remote Desktop グループに所属するユーザを作成します。
ここで重要なのは、ユーザは二人以上作成し、それぞれ異なるパスワードを設定すること、つまり Administrator 権限を同じユーザとパスワードで使い回さないことです。
Administrator ビルトインアカウントの無効化
実際に、Administrator 以外の管理者アカウントを作成したら、作成したユーザで、 RDP 接続して、ビルトイン Administrator の無効化をチェックして、無効化します。
ここで無効化できなければ、 Administrator 権限は正しく設定できていないということですね。
パスワードの厳格運用
グループポリシーエディタで、パスワードのポリシーを変更します。
C:¥ > gpedit
を実行して、アカウントのパスワードポリシーをより厳しいポリシーに設定します。
・パスワード長：８文字から１２文字程度にするのが良いでしょう。長すぎても辛くなるばかりです。・パスワードの有効期間：何日おきにパスワードを変更すべきか。近年、このポリシーでパスワードを強制的にへんこうさせるのはデメリットという意見も多く見られます。・パスワードの履歴保存：３から１０回程度は変更履歴を残して、パスワードを変更するたびに使い回さない様に設定します。・複雑さの要件を満たすパスワード：有効にします。大文字、小文字、数字、記号を使ったパスワードが強制されます。
パスワードを複雑化することで、辞書などを使ったブルートフォースアタック（力任せ総当り攻撃）に対して有効です。パスワードを間違えると１分とかの間ロックされるので、一瞬で破られるパスワード攻撃に非常に有効です。
ロックアウト期間：数回のパスワードミスで、数分間ログインできなくなります。
グループポリシーエディタを終了したら、グループポリシーをアップデートします。
C:¥ > gpupdate
このパスワードポリシーは、管理者が自らに設定するもので、当然自分で解除もできてしまうという事。つまりこの設定は自分に課すものであり、管理者は自らの根性でパスワードのセキュリティを管理しなくてはなりません。結局はセキュリティ根性論です。
Windows のパスワード管理はユーザ任せの根性論
Windows でのパスワード変更ルールは、複雑さを求めるこのルールしかなく、基本的に「セキュリティ根性論」に基きます。セキュリティ根性論は、システムの機能によってセキュリティが維持することができず、人的機能（ユーザが複雑なパスワードを覚えて自分で管理すること）に頼る事です。
Linux のパスワード管理の様に、一文字だけ変えた、ほぼ使いまわしに近いパスワードや、ユーザ ID と同じパスワード、Crack-Lib に登録されている、「よくあるイケナイパスワードのリスト」をチェックするような機能はありません。自分自身のルールに従って、複雑で覚えやすく、他人にわかりにくいパスワードを自己管理しなければなりません。セキュリティ根性論に基づく管理が必要です。Windows はセキュリティ機能が低く、人的リソースによる力技、セキュリティ根性に依存するケースが多くあります。
パスワードポリシー強化各種設定のいろいろ、文字数、文字種を指定
他に、 RDP の接続数制限（一つか2つのセッションしか許可しない）とか、ファイアウォール設定を使って、特定のターミナルしか接続できない様に設定するなどの対策を検討しても良いでしょう。
単一のプラットフォームに依存する危険
今回のインシデントの中に、仮想環境のプラットフォーム自体が侵食されて壊滅的な損害を受けています。おそらく Windows の Hyper-V 環境ではないかな、と想像できます。
もし、仮想化基盤が Windows ではないプラットフォームを使っていれば、仮想プラットフォーム自体の侵害は受けなかったかもしれません。また、ニップンの事例ではバックアップ自体もランサムウェアに侵食されたようです。
国内の製粉大手がサイバー攻撃の被害に、ランサムウェア対策にはオフラインバックアップが有効
BCP想定を上回ったニップンへのサイバー攻撃についてまとめてみた
果たしてバックアップシステムも Windows である必要があるのかどうか。というか、システム全体を Windows だけのモノ・プラットフォームで構成するのはどんなものなのかという危機感を改めて感じてしまいます。もちろん、人的リソースの不足もあり、モノプラットフォームで構築したほうが、導入コスト、メンテナンスコストも削減できるという意見は充分承知していますが、どこかキーとなる重要部分に別なプラットフォームを選択する、という手段も一つの防御手段としてありえるのではないかと考えていますが如何でしょうか。異なるいくつかのプラットフォームがあれば、攻撃する側も複雑なテクニックが必要となるはずです。攻撃者が、第一のターゲットを克服して、次を狙った時に、同じプラットフォームで同じコンセプト、同じ ID とパスワードで管理されているシステムがずらりと並んでいる姿を見たときの「シメシメ、やった！」感は想像に難くない。もし違ったプラットフォームがあれば、それほど被害は拡大しなかったのではないかという事は言い得るでしょう。攻撃する側の心理としては、第一弾が突破できればすぐに攻撃する、という事はおそらくやりません。脆弱性を見つけた後、ターゲットとなるシステムの価値を見極めるために、必ず自分の活動が見破られることなく、数日間、あるいは数週間に渡って潜伏して内部を痕跡が残らぬよう走査するでしょう。システム全体のセキュリティポリシーに共通する脆弱性を確認しつつ、最大の効果を得られる手段を最小の技術、手間で攻撃に移ることでしょう。悪意のある侵入者は痕跡をできるだけ残したくないものです。そこにもう一つの異なるシステムがあって、そこが攻撃する本丸だった場合、そのシステムが異なるプラットフォーム、ポリシーで運用されていたら、そう簡単に手を出せるでしょうか。忍び込んだ家の中に一見強固に見えるもう一つの金庫、ファイアウォールがあれば、果たしてバールのようなもので音を立ててこじ開ける危険は侵したがらないはずです。できれば引き出しの中をチェックして終わりにしたい。できれば引き出しを開ける時に使えた鍵が使える範囲で最大限の獲物を得たい。もっとも、 Windows を単一の AD ドメインで運用すること自体が問題なのかもしれません。ドメインに依存しない場合は、スタンドアローンで運用するような構成も工夫すべきかもしれませんね。Windows そのものは、脆弱性がなくても、Windows の管理自体を Administrator でログインして行わねければならないことです。複雑なシステムを、単一のプラットフォームで運用することは、運用コストの削減に繋がります。しかし、単一のコンセプトで運用すると、セキュリティのリスクも均一に広がってしまい勝ちになります。単一の Windows ドメインで運用することは、管理者アカウントの漏洩に対して脆弱性を晒す場合があるのかもしれません。そこで、傍系のシステムを別アカウントや、別なプラットフォームで運用管理することは、安全性の担保にもなりますが、一方では運用コストの増大にも繋がります。システムの複雑さは、セキュリティ自体を複雑化させ、安全性を高めますが、一方では運用の複雑さによる不具合やエラーや誤処理を生み出します。結局はセキュリティ根性論であり、セキュリティの担保は人的リソースへの投資がどれだけできるのかの問題なのですね。
対策そのものは無料です。その代わり人的資源が必要だという点です。
by islandcenter
| 2023-09-12 15:47
| システム管理
|
Comments(0)
