isLandcenter 非番中

ブログトップ | ログイン

Windows 11 が公式にリリースされました。

正式版では、前回 Insider Preview 版で制は限がなかった TPM2.0 と UEFI セキュアブートが必須の様です。

こちらもご参考下さい。Preview 版です。

Windows11 を KVM on openSUSE Leap15.2 で動かしてみた(virt-manager でインストール)

virt-manager から、仮想VMを Create すると、ウィザード形式で作成されますが、最後に "Finish" ボタンを押す前に "Customaize configuration before install" を Check して、Finish から詳細な VM の作成画面に入ります。

Windows 11(公式リリース) を KVM 仮想環境でインストール openSUSE Leap15.2_a0056607_11054956.png

TPM 2.0

TPM 2.0 は Add Hardware ボタンを押して追加することができます。

Windows 11(公式リリース) を KVM 仮想環境でインストール openSUSE Leap15.2_a0056607_11064624.png



openSUSE Leap 15.2 ではデフォルトで swtpm がインストールされていないため、software.opensuse.org で swtpm パッケージを 1Click インストールします。SUSE Enterprise には含まれていないため TPM2.0 は有効化できませんでした。

重要:SLES 15sp2 では動きませんでした。


Windows 11(公式リリース) を KVM 仮想環境でインストール openSUSE Leap15.2_a0056607_11071941.png
YaST > Software Management で確認します。

Windows 11(公式リリース) を KVM 仮想環境でインストール openSUSE Leap15.2_a0056607_11074085.png


UEFI の有効化

Over view > Hypervisor Details の Firmware の項目を Bios から UEFIxxxx-mscode.bin に切り替えます。トグルして Apply しても、表示は BIOS のママですが、これで UEFI/Secure Boot が有効になります。

Windows 11(公式リリース) を KVM 仮想環境でインストール openSUSE Leap15.2_a0056607_11080448.png

Bios が代わったため、起動画面はこんな感じで TianoCore のロゴが出てきます。


Windows 11(公式リリース) を KVM 仮想環境でインストール openSUSE Leap15.2_a0056607_11084106.png
インストーラが立ち上がって「今すぐインストール」から、ライセンス条項が出てきたら、ハードウェアのチェックがクリアできてインストールすることができます。

Windows 11(公式リリース) を KVM 仮想環境でインストール openSUSE Leap15.2_a0056607_11090743.png

/etc/libvirt/qemu/win11pro.xml には tpm2.0 の記述があります。

: 略
<tpm model='tpm-tis'>
  <backend type='emulator' version='2.0'/>
</tpm>
: 略
<os>
  <type arch='x86_64' machine='pc-q35-4.2'>hvm</type>
 <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x86_64-smm-ms-code.bin</loader>
  <nvram>/var/lib/libvirt/qemu/nvram/win10pro_VARS.fd</nvram> <bootmenu enable='yes'/>
</os>
: 略

どうも、xml ファイルの記述にヒントがあるので SLES15 sp2 でも動きそう。



一連の KVM 上でのインストールの流れを動画にまとめました。(音出ます)



セキュアブートは有効ですが「デバイス暗号化のサポート」は動いていない様です。TPM2.0 は「ある」事が重要で。動いているかどうかは関係ないようです。

Windows 11(公式リリース) を KVM 仮想環境でインストール openSUSE Leap15.2_a0056607_11254735.png
-- おまけ

ネットワークに繋げない状態で動かしたい場合は、仮想VMの Nic をremove した状態から起動します。

Windows 11(公式リリース) を KVM 仮想環境でインストール openSUSE Leap15.2_a0056607_11380932.png

--
openSUSE Leap 15.2 の KVM 環境で Windows 11 の正式リリース版をインストールすることができました。残念ながら SUSE Linux Enterprise 15 sp2 では TPM2.0 がなく動作確認できませんでした。UEFI セキュアブートも不安定です。Insider Preview 版では問題なかったので、バージョンアップしてもう少し調査が必要です。ちょっとSLE15 SP3のドキュメントを読んだだけでは面倒くさそうです。一応前述の xml ファイルを編集する事で何とかなりそうですが、つぎの機会に試してみます。

SUSE Linux Enterprise Server 15 SP3 Virtualization Guide


おそらく Windows 11 には肯定的な意見、いや、スキップすべきバージョンだろう、と言った喧々諤々な意見が出てくることでしょう。個人的にはエンタープライズ用途で無理してアップデートする必要はないと思います。

しかし、出荷されたことは事実であり、今後メーカーのプリインストールPCが増えてくると、ソフトウェアベンダーのテクニカルサポート、ヘルプデスクでは避けて通る事の出来ないバージョンになってしまいます。異なるUIや、設定方法を一通りチェックする必要があります。

だからと言って最新のプロセッサ、最新のファームウェアを装備したコンピュータ一式を揃える必要があるわけではないので、これで仮想化環境でテスト用の環境は用意できるでしょう。

Windows11 を再展開、やり直し、Sysprep で、失敗しやすいポイント

Windows11 でいらない新機能

Windows 11(公式リリース) を KVM 仮想環境でインストール

モバイルワーク時代の Windows11 の意義、Chrome Remote Desktop でシンクライアント



# by islandcenter | 2021-10-09 11:33 | SUSE | Comments(1)

Windows 11 pro でリモートデスクトップを使うには


エクスプローラから "PC" の右クリックで "プロパティ"、または、タスクバーの「歯車」アイコンを開き

「システム」をスクロールダウンして "リモートデスクトップ"を開きます。

Windows 11 pro でリモートデスクトップを使う_a0056607_11495081.png



「リモートデスクトップ」を On にします。必要に応じてリモートデスクトップユーザを追加します。

Windows 11 pro でリモートデスクトップを使う_a0056607_11501067.png

モバイルワーク時代の Windows11 の意義、Chrome Remote Desktop を使う





# by islandcenter | 2021-10-05 11:51 | Windows11 | Comments(0)

この世から消えてほしいブラウザがあります。消えてほしいほどなのに、詳しく「良さ」も「悪さ」も分からないのは、全く使ったことがないからです。

消えてほしいブラウザ

Safari

iPad も Mac も iPhone も使っているけど、全然使っていないブラウザが Safari。使っていないから評価できない。どうせ使わないなら削除してしまいたい。なぜ Safari を使わないのか、それは Apple 製品でしか使えないからに他ありません。特にブラウザシェアの中で特筆すべきシェアではないので、簡単に削除できる様にして欲しいと思うのは私だけでしょうか。困ったことに Safari の削除はかなり困難な様で、OS のアップデートで復活してしまう事もあるようです。

Edge

Microsoft Edge も消えてなくなって欲しいブラウザです。これもやっぱり Windows10 以外では使えない。そもそも Microsoft には、モバイル端末用のシステムがないのですね。携帯デバイスとの連携プレーができないので、完全にアウトオブ眼中なのです。ついでに携帯デバイスとの連携が簡単ではないから OneDrive も要らない。Apple の AppStore に iOS 版はあるけど、評判はイマイチの様ですね。かつて PC 用ブラウザのシェアを圧倒した IE でしたが、今やPC同士の連携プレーより、携帯デバイスとの連携が重要なのです。Microsoft には携帯デバイス用のシステムがないから、Safari よりタチが悪い。さっさと削除したいのですが、PoweShell から削除するため一般的なPCユーザでは簡単に削除できない様です。OS との連携なんて、今時、セキュリティホール見たいなものなんです。

グループポリシーと連携できるというのが、ウリの一つなのですが、そもそも使っているヒトが居ないのに何を制限するのでしょうか。ほとんどのヒトが、Google Chrome とかダウンロードしてつかっているのではないでしょうかね。

じゃどのブラウザを使う?
*
opera

ひと時ブイブイ言わせたノルウェー製ブラウザ。はじめてタブブラウジングできるという事で初期の日本語版から使い続けています。私の場合デフォルトブラウザです。初期版はメチャクチャ軽くて妖しかった。

ノルウェー製とは言え、今は中国資本なのが難点。

ポイントは、シェアの圧倒的な低さ。だから一般的なブラウザクラッカーには耐性がありそうなんですが、今は Chromium エンジンなので、危なさは Chrome と同じかな。

まぁ Chrome から乗り換えたいのなら、割とお勧めできます。

やっぱりChrome

何しろ世界シェア60%以上。誰もが使っている Google Chrome。私も使っていますよ。

でもね、使っている履歴や検索情報、 あなたの IP アドレスから住んでいる所、年齢性別、cookie なんかも全部 Google サマはお見通しなんです。adsense の広告みたら、ひょっとしたら今日のパンツの色も知っているんじゃないかと言う位、何でも把握しています。

これが怖い。

だから Google Chrome には、ウスラ妖しさを感じるんですね。イケナイ目的には使っちゃいけない。履歴が全部のデバイスに同期されてしまいます。 Chrome を使う場合は「正しい目的」に使うべきで、ウラ情報なんかを探す時は使わない。

FireFox

これは sync して使わない。iOS でも mac でも Windows でも使える。Linux ではデファクトスタンダード。sync しないので、履歴は消しても構わない目的で使っています。プライバシーの高さがポイントですかね。割と特種な目的では安心してつかえるところが良い。例えば、PC で Chrome 検索した後、スマートフォンでクッキーと履歴消した FireFox では検索結果変わらないかなぁ、みたいな時にですね。

Chromium じゃないので、Chrome 狙いのマルウェアには強いかも、と思っています。


番外

Vivaldi

Opera の代わりになるかな、と思ってタマに使っています。使い勝手はイマイチだけど、Opera の後継と思えばそこそこ使えます。

SeaMonkey

Netscape suite の後継版ですね。HTML オーサリングツールとしても使えるので入れてみたけど、吐き出すコードが余りにも難解で、デザインセンスなさすぎの私には無理。HTML コードの勉強では BlueGriffon の方が入門しやすいので、最近は使ったことがない。


# by islandcenter | 2021-10-04 15:56 | 雑文 | Comments(0)

ここでは、SUSE Linux (openSUSE Leap15/SUSE Linux Enterprise 15)から、Windows Share (Windows 共有)や、Samba をマウントしてバックアップする方法について説明しています。

ニップンのランサムウェア被害の様に、わずかなセキュリティリスクを突いた「その気に情熱を持つヒトビト」から防御を高めるためにも、若干のコストや手間がかかってもシステムの多様性は必要だと思います。

ニップンランサムウェア被害から私達にできること

マウントするには mount か mount.cifs コマンドを使います。

バックアップは cp や rsync, tar などの色々なコマンドが使えます。

通常は # mount -o user=myname,password=mypassword //Samba_or_Windows/share /MountPoint (/ です \ ではありません)でマウントできるのですが、vers=n.n でSMB のバージョン指定をしなければならない場合があります。

※ Windows サーバーのバックアップなどで、シェルスクリプトで自動化するには user=myname,password=mypasswd とパスワードを記述しなければなりません。あるいは /etc/fstab にも記述して、パーマネントマウントさせる事もできる様ですが、ここでは割愛します。

-- openSUSE Leap 15.2 の場合

mount.cifs で Windows10 の共有をマウント

opensuse152:~ # mkdir /mnt/cifs
opensuse152:~ # mount.cifs -o user=myname //192.168.1.33/D /mnt/cifs
Password for myname@//192.168.1.33/D: ********
opensuse152:~ # ls /mnt/cifs
$RECYCLE.BIN System Volume Information download tmp
.DS_Store Downloads apps pagefile.sys
opensuse152:~ #
opensuse152:~ # umount /mnt/cifs


mount コマンドで SMBv2 でsamba に接続する場合

opensuse152:~ # mount -o user=myname,vers=2.0 //192.168.1.240/share /mnt/cifs
Password for myname@//192.168.1.240/share: *******
opensuse152:~ #
opensuse152:~ # ls /mnt/cifs/

mount.cifs コマンドで SMBv2 で接続する場合

opensuse152:~ # mount.cifs -o user=myname,vers=2.0 //192.168.1.240/share /mnt/cifs
Password for myname@//192.168.1.240/share: *******
opensuse152:~ #

-- SLE15sp2 の場合

vers= オプションを付けないと、"Operation not supported" になる場合があります。明示的に SMB プロトコルのバージョンを指定します。

sle153:~ # mount -o username=myname //192.168.1.239/share /mnt/cifs
Password for myname@//192.168.1.239/share: *******
mount error(95): Operation not supported
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
sle153:~ # mount -o username=myname,vers=2.0 //192.168.1.239/share /mnt/cifs
Password for myname@//192.168.1.239/share: *******
sle153:~ #
sle153:~ # umount /mnt/cifs
sle153:~ #
sle153:~ # mount -o username=myname,vers=3.0 //192.168.1.239/share /mnt/cifs
Password for myname@//192.168.1.239/share: *******
sle153:~ #


-- mount.cifs のヘルプを見てみましょう(抜粋)

vers=arg
SMB protocol version. Allowed values are:

· 1.0 - The classic CIFS/SMBv1 protocol.

      : 中略

. · 3.1.1 or 3.11 - The SMBv3.1.1 protocol that was introduced in Microsoft Windows 10 and Win-
dows Server 2016.

      : 中略

· default - Tries to negotiate the highest SMB2+ version supported by both the client and
server.

If no dialect is specified on mount vers=default is used. To check Dialect refer to
/proc/fs/cifs/DebugData

Note too that while this option governs the protocol version used, not all features of each
version are available.

The default since v4.13.5 is for the client and server to negotiate the highest possible ver-
sion greater than or equal to 2.1. In kernels prior to v4.13, the default was 1.0. For ker-
nels between v4.13 and v4.13.5 the default is 3.0.

version 4.13.5 では、より新しいバージョンか、2.1 でネゴシエーションしますが、デフォルトでは SMBv2.0 で通信するようです。

opensuse152:~ # smbd -V
Version 4.11.14-git.247.8c858f7ee14lp152.3.19.1-SUSE-oS15.0-x86_64
opensuse152:~ #

どうも古いバージョンの様です。


-- SMB のバージョンの確認方法

実際 SMB 接続したコンピュータと、SMB プロトコルのバージョンを確認してみました。

smb のプロトコルバージョンの確認方法(Samba 側)

opensuse152:~ # smbstatus -b
Samba version 4.11.14-git.247.8c858f7ee14lp152.3.19.1-SUSE-oS15.0-x86_64
PID Username Group Machine Protocol Version Encryption Signing
----------------------------------------------------------------------------------------------------------------------------------------
6126 myname users 192.168.1.33 (ipv4:192.168.1.33:61470) SMB2_10 - -
23487 myname users 192.168.1.44 (ipv4:192.168.1.44:50304) SMB3_11 - partial(AES-128-CMAC)
26401 myname users 192.168.1.240 (ipv4:192.168.1.240:55066) SMB3_00 - partial(HMAC-SHA256)
opensuse152:~ #


smb のプロトコルバージョンの確認方法(Windows 側)

管理者モードで PowerShell を起動します。

PS C:\WINDOWS\system32> Get-SmbConnection

ServerName ShareName UserName Credential Dialect NumOpens
---------- --------- -------- ---------- ------- --------
abianca share GOBLIN\kenn GOBLIN\myname 3.1.1 1


PS C:\WINDOWS\system32>

サンプルスクリプト

仮に、シェルを作ってマウントからバックアップ、アンマウントを行うとすれば、次の様なスクリプトを実行すればよい事になります。ここでは、コピーなどの操作を行った後、 sync でディスクキャッシュを書き込み、5秒スリープさせてから umount で強制アンマウントさせています。

cron で自動化してもよいでしょうし、アテンドして手動で動作を確認して実行しても良いでしょう。マウントされているかどうかの判断は、マウント先に特定のファイル(ここでは /mounted.txt ) を置いて、このファイルがあれば、マウントされている、と判断しています。

#!/bin/bash
mkdir /cifs
mount.cifs -o user=backupuser,vers=2.0,password=password //192.168.1.240/share /cifs
FILE="/cifs/mounted.txt"
if [ -e $FILE ];then
echo "Mounted."
##### Your Backup operation Here ! ######
sync
sleep 5
fi
umount /cifs
umount -f /cifs
umount -l /cifs
rmdir /cifs

なお、バックアップそのものの操作は次の様な操作が想定されます。詳細はそれぞれのコマンドの man ページで確認してください。

cp コマンドで、ファイルの新規ファイルかアップデートがあれば、/backup にディレクトリごとに表示しながらコピーする

cp -vRu /cifs/* /backup

rsync コマンドで、進捗情報を表示しながらアーカイブモードでコピーする。バックアップ元を誤削除してもバックアップ先にはファイルが残る。

rsync -av /cifs/ /backup/

or

バックアップ元のファイルが削除された場合、-- delete オプションで、バックアップ先も削除して同期させる。週に一度程度やっておくと良いでしょう。

rsync -av --delete /cifs/ /backup

tar を使ってアーカイブファイルに圧縮する。

tar cvzf /backup/backup.tar.gz /cifs/*

tar を使って、テープ装置に金庫にオフライン保管を作成する場合 ( /dev/st0 はあくまでも一例です)

tar cvzf /dev/st0 /cifs/

- 参考 -

mount.cifs — Common Internet File System (CIFS) を使用したマウント



Windows11 を再展開、やり直し、Sysprep





# by islandcenter | 2021-09-26 11:01 | SUSE | Comments(0)

今考えるBCP対策

「バックアップからリストアが必要な状況を起こしてはいけない」

これは、ある中堅会社のシステム担当者が宣った言葉です。

不思議な事に、彼のシステムは深刻なトラブルやバックアップから戻すような作業は日常はありませんでした。彼の担当するシステムのバックアップは、NASへのミラーコピーと日次の仮想テープライブラリへのバックアップ、週次の物理テープメディアへのバックアップとテープメディアのオフライン保管です。物理テープは一か月保管して再利用していました。

とある外資系企業の担当者は、バックアップジョブに何等かのエラーが記録されると、必ず私とマネージャ宛にメールで報告してきました。バックアップソフトウェアが余りにもバカなのか、あまりにも彼のメールがシツコイので閉口したくなるほどでしたが、それは彼の責任範囲でできる最大の業務だったようで、彼が在籍中は、「リストア」が必要な案件は全くありませんでした。

彼の後を継いだ担当者(女性)は、引き継ぎが充分でなかったのか、彼女はテープの交換手順だけは行っていましたが、ログの確認は行っていませんでした。知らせがない事は良い事。そう思っていましたが、彼女が担当している間、重要なインシデントが発生して、テープからリストアを行う必要がありました。

しかし、ログを確認すると、複数のテープに跨ってバックアップが行われるはずのジョブが途中でテープフルになってキャンセルされていたのです。

その後のリカバリ作業が大変だった事は、費用、手順、共に膨大な作業だったことは言うまでもありません。死にそうになるくらい複雑で面倒で退屈な作業でした。

とある司法書士事務所さんは、小さな組織の割には先進的な事が大好きな司法書士の先生が経営していました。90年代にまだ大手企業ですら導入していなかった、所内LANのシステムを導入したのです。DOS から Windows への移行も早かったのですが、少しコストを掛けすぎていた感があり、NAS が普及し始めた頃、「ファイルサーバー」を止めて NAS へのダウングレードを提案しました。営業面では、「わざわざダウングレードするとは何事か!」と怒られましたが、事業規模からその程度のサイズが最適だと判断したのです。バックアップは当時一般的だった、MOドライブを使ってもらいました。毎日 NAS のデータをMOにバックアップして、経営者の先生が自宅に持ち帰る、という方式です。その後はリムーバブルディスクにバックアップを取ってもらいました。

不思議とその司法書士事務所では大事故は起こっていません。その先生とは、まだ年賀状の付き合いがあります。


--
何が言いたいか? と問われれば、

「BCP対策には万全はない」

という事と

「バックアップできてもリストアできなければBCP対策は意味がない」

事です。

また、不思議とバックアップを管理されているシステムは深刻なトラブルに陥る事は少ない、という事です。つまりそれほどシステム担当者がシステムの日常に気を遣っていた、という事です。

--
ニップンで起こったランサムウェアの対策に就かれている担当者、サポートエンジニアの皆さん。大変だと理解しています。

バックアップシステムも被害に遭って、リストアも困難だと言う記事を読みました。また、運用が杜撰だったというネガティブな情報もないので、一般的な企業が実施するセキュリティ対策、BCP 対策を行っていたと思います。どこの企業でも行っている平均的な対策だったようです。

ただ、ワタクシ視点で見た場合。

1. オフラインのバックアップ保管はあったのか
2. システムの多様性はあったのか

という二点が気になりました。

ここから、「ニップンじゃないヒト」の私たちが、このような「わが身にも降りかかる可能性がある」インシデントに対して「私達が学びたい事」、BCP対策として考えてみたい事です。

--オフラインバックアップメディア保管の重要性

今回のニップンのインシデントの中で、バックアップシステムも被害を受けた事は重要です。一昔前なら面倒なバックアップシステムでしたが、やれクラウドだのハードウェアレベルのミラーリングやストレージプールを使っても、バックアップシステムは手軽で簡単になりました。それと同じ位に致命的な障害を与えるオペレータのトリガーも軽いでしょう。瞬時にバックアップメディアをフォーマットしてしまった、などという事故も簡単に発生します。

対して、物理的にオフライン保管するのは、バックアップもリストアもテープストックに取りに行くだけでも面倒なだけ、オペレータの誤操作にも「その種のやる気があるヒトビト」にもトリガーは重い。

クラウドは確かに便利で楽かも知れないけれど、バックアップとリストアの自由度は低く、無事だったシステムの最新の世代だけが頼りになってしまう。柔軟性やカスタマイズの自由がないのですね。おまけに「クラウドにバックアップがある」と言っても、オンプレミスの負荷分散のためであったり、プライベートクラウドの一部分であったりすれば、軽いトリガで簡単に消去できてしまう。万能ではないのです。

大体ニップン程の規模でクラウドを使っていないはずがないのです。負荷分散やバックアップ、BCP目的のプライベートクラウドも多分やられたのでしょうね。クラウドストレージを暗黙に信頼すべきではない。

バックアップを実施中はオンラインで、終わったら物理メディアを取り外したりバックアップサーバーを停止させたり、せめてボリュームをアンマウントするくらいの意識は持っておきたいですね。

バックアップ先のファイルを R/O フラグにしておくのも一つの手段かも知れません。




-- システムの多様性

今回のニップンのランサムウェア被害で感じた事として、「システムの多様性」はあったのか、という事が気になりました。システムに多様性があると、「何かおかしなことに熱中」する側としては複数の脆弱性を狙った手段を考えなくてはなりません。システムに壊滅的なダメージを与えるアタックの難易度は格段に上がります。

自然環境保護の話題として「多様性」はよく言われますが、システムも全体の多様性も壊滅的なパンデミックを避けるためにも必要なのではないでしょうか。もちろんシステムの多様性は、複雑さとコストの増大を意味するのですが、経営的判断が必要な出費になります。

大きな被害を受けたファイルサーバーや会計システム、バックアップシステムも同じプラットフォームで動いていたのでしょうか。単一のセキュリティ上の問題点を突かれて一挙に全部が「ヤラレタ」という感じがします。

単純な話、運用上のスキルを平準化したいから Windows だけにしよう、となっていたんじゃないかな、と思ってしまう。

もしバックアップシステムが別なプラットフォームで動作していたら、少なくともバックアップが全滅という事はなかったのではないか、と余計な事を考えてしまいます。

-- 仮想化イメージのバックアップ

つくづく SUSE+XEN/KVM を扱ってみて、仮想化システムは重要なBCPプランの一つの回答だな、と考えています。何しろコールドダンプができる訳なので、導入しているお客様の重要で、復旧が面倒なシステムは週次単位で仮想システムのシャットダウンとコールドイメージのコピーバックアップをするようにお勧めしています。

まだ、ベアメタルサーバに直接アプリケーションを導入しているのであれば、是非検討してもらいたいところです。

--

「前例がない程」と言われたニップンへのランサムウェア攻撃。「あり得ない」事は日常もある事です。

いま、対岸の火事として眺めている私達が、「今、お金を掛けずにできる事」を考える機会を与えてくれたように思います。


SUSE Linux から Samba/Windows 共有をマウントしてバックアップ(openSUSE Leap15/SLE15)


# by islandcenter | 2021-09-22 14:30 | 雑文 | Comments(0)