ProxmoxのWeb画面で This page isn’t working と表示される → httpではなくhttps を使っていますか？
TL;DR
ProxmoxはデフォルトではHTTPでのリクエストをHTTPSにリダイレクトしないため、管理画面にHTTPでアクセスすることはできません。
This site can’t be reached との違い
ブラウザのインスペクターでTiming breakdown を見ると分かります。
This site can’t be reachedの場合、リクエストがStalledになっていますが、
This page isn’t working の場合、Initial Connectionまでは進んでいます。つまり、IPレベルでは疎通できており、TCPレベルでのやり取りが始まっているということですね。
せっかくなのでWiresharkでパケットも見てみました。
This site can’t be reached の場合、TCP Handshakeでお断りされていることが分かります。
This page isn’t working の場合、TCP Handshakeは成功しています。
ただし、HTTPを送るやいなや会話を打ち切られるかのようにFINパケットが飛んできます。この辺もうちょっと勉強したいところ
補足
Proxmoxにnginxをインストールしてリダイレクトする、という方法もあります。
まとめ
ChromeのTime breakdownを活用して管理画面にアクセスできない原因が分かりました。
書評 - 図解で明解 MacOS Xのしくみ
defaultsコマンドについて調べているうちに、NeXTSTEP時代からのユーザーがMac OS Xをどう思っているかをぜひ知りたくなって購入、通読しました。
著者の海上忍さんは、マイナビニュースで OS Xハッキング! という連載をお持ちだった方です。defaultsコマンドの隠しオプションを探す記事があまりにも面白く、Amazonで著者名で検索して手頃な価格の本書を購入した...というわけです。
感想が多くなるので、本書について触れた後、特に気になった前半について章ごとに述べます。
本書について
表紙に「Aquaを超えて。」とあるように、GUIだけでは分からないOS Xの魅力を語っている本です。要するに開発者かオタク向けの本と言っていいと思います。
著者は単にMac OS Xに詳しい人というわけではなく、BSDの特徴やNeXTSTEP（Amazonの著書を見る限りはBeOS）など、コンピューターが本当にお好きな方だと推察します。
図解と言っても昨今よくある操作のスクショを貼って水増しした本ではなく、OSの起動の仕組みやDarwinの仕組み、OS Xに連なるOSの系譜などの概念図が盛りだくさんです。しかも全部で300ページ以上あり、それでいて発売時の値段は2,000円弱というカルピスの原液を煮詰めたような本です。
もちろんスクショもあるのですが、それにしてもNeXTSTEPやOS X Serverのスクショなど、本当にコンピューターが好きでないと撮れないスクショが多くて驚きました。
MacOS Xの基本
この本を通読して思いましたが、OSを知るには意識高くOSを自作するより手元のmacOSを徹底的に知ったほうが近道だと思います。そうした要求に応えてくれる章でした。 また、全体を通してMac OX 9以前との比較で書かれている点が興味深いです。
ホームフォルダとマルチユーザーに関する解説は、これまで業務でLinuxを触ってきてなんとなく分かっていたものが他人の言葉で整理された感じでありがたかったです。特に「職場や学校など大人数が1台のコンピュータを共有することを前提として」UNIXがマルチユーザーのモードを備えていたことは納得がいきました。同時に、マルチユーザーが前提ではなかった（と推測される）OS 9以前に思いを馳せて、現代の当たり前にも歴史があるのだと思いました。
2003年の本ということもあり、当時のOS X（10.2 Jaguar）と私が使っているmacOS（11.5.2 Big Sur）だと違う点もあります。
例えばシステム起動時の舞台裏として解説されている、Open Firmawreから起動される /System/Library/CoreServices/BootX ）は 、Big Surでは（歴史的には OS X 10.6から） /System/Library/CoreServices/boot.efi に取って代わられています（というか BootXというのは PowerMac の場合のファイル名かもしれません。要調査）
その後に起動する initは launchd に取って代わられているし、 /etc/rc は /etc/rc.common と /etc/rc.netboot に変わられているようです。
しかし、本質的な理解に障るほどではないし、現代のmacOSについてここまで解説した本があるのかも疑問なので、やはり有り難いと思って読んでいます。
（Oreillyの Running Mac OS Xは同様の本かもしれません。今度読んでみます）
その他の箇所でいうと、仮想メモリが常に有効なこと（そういえばmacOSでWindowsみたいなデフラグをしたこと無いな）、OS 9以前はApple Talkが基本だったこと（TCP/IPじゃない低レイヤーが想像つかない...）も興味深かったです。
MacOS Xの基礎技術
macOS...というかDarwinがハイブリッドカーネルで、MachとBSDの系譜である...というのがイマイチ分かっていなかったのですが、本章で少し理解が進みました。
DarwinがBSDの系譜であるというのには2つの意味がありそうです。まずDarwinのカーネルであるXNUがMachとBSDの両方の特徴を併せ持つということ。次に、ユーザー向けシェルやコマンドはBSDから移植したものが多いこと 。とはいえ以下にツイートしたとおり全然分かっていないので勉強を勧めたい所存です（そろそろmacOSアプリ作るなりDarwin動かすなりしたほうが早いかも）
XNUに関する文章を書こうとしてたんだけど全然理解できてないことに気づいてしまった。多分こんな感じ...? pic.twitter.com/7CaFmHAQSr
— さわら (@xhiroga) 2021年12月29日
実は、 defaults コマンド（そして前身の dread, dwrite, dremove ）の由来がBSDではないか？と疑っていたのですが、今回調べておそらく違うという思いを強めました。
（defaultsコマンドはプロパティリストを編集するコマンドだが、プロパティリストはCoreFoundationのオブジェクトであり、それはNeXTのカーネル部分というよりは開発者向けキットが由来のため）（なのでどちらかというとSmallTalkに源流がある気がしないでもない。要調査）
実行可能なバイナリに旧Mac OS用とOS X用の違いがあることを初めて知りました。MacOS 9以前との後方互換性を一応保とうとしていることが伺えるのも面白かったです。
これに関連して、手元のBig Surのアプリケーションのバイナリ形式を見てみたら Mach-O で、歴史を感じて嬉しくなりました。
こんなところに Mach の名前が残っており歴史を感じる。 pic.twitter.com/vP2BUdqask
— さわら (@xhiroga) 2021年12月29日
他、ルートディレクトリに関する解説もためになりました。そういえばLinuxも体系的に学んだことが無い気がするのですが、これを気に学んでもいいかもしれません（Dockerfileでバイナリをどこに配置するか、とかで悩んでしまうので）
BSDとしてのMaxOS X
この章ではBig Surとの違いが面白かったです。
一番衝撃を受けたのはリソースフォークです。Apple独自のファイル形式（ファイル内にメタデータの領域を持つ。リソースフォークはメタデータ領域の名前）があるのは不思議ではないですが、それにしても互換性がなさすぎる...と思いました。ちゃんと廃れたようで良かったです。
他、基本のシェルが tcsh だったことも驚きました。私が OS Xを使い始めた頃にはすでに bash で、現在は zsh なので、2回も変わっていて驚きです。
まとめ
macOSの歴史を知りたい私にピッタリの本でした。知れば知るほど知らないことが増えていく感じがするので、自分のペースで本やソースを読んでいきたいなぁ、と思います。
書評 - 実践 CSIRTプレイブック
会社でプロダクト横断的な業務が増えてきたこともあり、SREチームで読み合わせました。
TL;DR
- 複数のプロダクトを持つ企業の現場担当者向けに書かれた本
- プレイブックの考え方は、アプリケーション開発チームとは異なり勉強になった
本書について
CSIRTってなんだろう？と気になったので読んだ本。
勤務先はまだアプリケーション開発者がSREとセキュリティエンジニアを兼ねているような状態なので、CSICOの取り組み自体は正直あまりピンとこない箇所もあった。
Yahoo!JapanやDeNAなどの大企業のセキュリティ担当者に転生したら...と想像しながら読むと面白いかもしれない。
プレイブックの考え方
スタートアップでセキュリティを意識するにあたって、以下の点が気になっていた。
プレイブックはそうした問題への解決策だった。すなわち、
- イベント駆動型で機能する組織にする。問題発生時にプレイブックを用いて分析する（つまり手順書）
- プレイブックにクエリなどを埋め込み、日々改善を重ねる
本書の後半には具体的なクエリまで紹介されていて、実感が湧いた。ただ、小規模な組織なら実務ではAmazon GuardDutyのようなベンダー提供のルールセット（または機械学習）を使うほうが現実的かもしれない。
まとめ
チームの運営モデルとしてプレイブックを知ることができたのは有益でした。自分たちの組織に合わせてマネージドサービスを使って運用をカスタムしていければいいのかな、と思います。
書評 - CSIRT 構築から運用まで
SREチームとしてプロダクト横断的な仕事が増えるに従って、CSIRTを参考にしようと思って手にとった本の一冊です。
TL;DR
- どちらかというと大企業の役員・部長クラス向けに書かれている本
- 運用における対外連携は規模に関わらずあり得る、参考になった
- ケーススタディが具体的で参考になった。もっとあっても良い
本書について
NTT関連会社に勤めるセキュリティ関係者が書いた本です。他の方のレビューにもありましたが、教科書的な印象があります。
セキュリティインシデントの分類はありがたいのですが、やや古い上に粒度が揃っていない印象を受けました。
2021年現在、JPCERT/CCの分類で用いられているのは以下の7種類です。
しかし、分類方法に攻撃手法と攻撃対象の2軸があることが気になります。また、エディタやライブラリの汚染、SaaSの脆弱性によるトークンの窃取などをどこに分類するか（マルウェアサイト？）も疑問が残ると思いました。オンプレで開発・運用が完結する業界ならこれでいいのかもしれません。
インシデント発生時の対外連携
スタートアップの規模でゼロデイや日本初の脆弱性を突かれるケース、あるいはフィッシングサイトを作られるケースは多くないのかな？と考えています。
（もっとも、暗号資産の取引所はガンガン攻撃されていそうですが）
特にフィッシングサイトが海外に建てられているようなケースは、言われてみればどうやって対応するのか分かりませんでした。本書を読み、フィッシング対策協議会やJPCERT/CCに相談して停止を調整すればいいことが分かりました。
ケーススタディ
セキュリティインシデント発生時の組織内でのシーケンス図が載っており、対応の実感がわきました。
2016年の本にも拘らずランサムウェア感染時のケーススタディが載っているのは先進的かもしれないです。
それまではセキュリティインシデント発生時の対応といっても（アプリケーションチームが主役なのでは？）という感じでしたが、たしかに脆弱性やアクセスログの横串調査は誰かが旗を振らないと難しいな、と思った次第です。
まとめ
やや古い感はありましたが、特に対外組織との連携など会社の規模が大きくなったときに発生するプロセスを知ることができたので良かったです。
RSSリーダーと「後で読む」の再選定 (2012)
TL;DR
RSSリーダーおよび「後で読む」として、Inoreaderを選定しました。
動機
勤務先のjustinCaseで、SREのメンバーと #justInCaseWeeklySRE を始めました。先輩の @laplace1984 さんの情報量が圧倒的なので、これは負けてられないと思い体制を整えています。
また、Log4Jの脆弱性についてTwitterで知ったことにも不安を覚えました。もしTwitterで知らなかったら...と思うと怖いので、JPCERT/CCを正しく購読しようと思ったのです。
比較表
FeedlyとInoreaderを比較しました。
| Feedly | Inoreader | |
|---|---|---|
| Initial Release | 2008 | 2013 |
| ❤️ at alternative.io (2012-12-26) | ❤️1805 | ❤️1393 |
| AppStore Rating | ⭐️4.6 (7643) | ⭐️4.5 (3631) |
| Read it later from Chrome | Offical: 🙅♂️ | 🤔（Webページの保存は可能だが、後で読むへの追加は不可能） |
| Read it later from iOS app | 🙆♂️ | 🤔（Webページの保存は可能だが、後で読むへの追加は不可能） |
| Subscribe without RSS | 🙆♂️ | 🙆♂️ |
| Idempotent import | 🙆♂️ | 🙆♂️ |
| Googleアラート | $12で購読可能 | 無料で購読可能 |
| Auto mark as read | 30日 | 30日 |
| Feed limit of free plan | 100 | 150 |
大差はないものの、Googleアラートが無料で購読可能なこと、いくつかブログを読んでFeedly → Inforeaderへの乗り換えが多く見られたことなどから選定しています。
後で読む機能が無い点のみ惜しいのですが、Webページの保存機能を代わりに使うことにしました。それによって、Pocketを廃止してツールをまとめられるのも嬉しいです。
まとめ
ニュースを確実にインプットしつつ、実質ゴミ箱だった「あとで読む」もうまく運用できることを期待しています。
書評 - Property Lists, Preferences and Profiles for Apple Administrators
dotfiles 好きが高じて、plistファイルとdefaultsコマンドの歴史に興味を持つようになりました。
なかなか体系的に学ぶための情報を見つけられずにいたのですが、この本はまさにピッタリの一冊です（ちなみに洋書です）
Appleでのソフトウェア開発経験を持ち、かつ現在は情シスとしてApple製端末の管理に情熱を燃やしている方が書かれた本です。
TL;DR
- タイトルの通り、plist, preferences, profileの3部に分類できる
- iOS/macOSアプリ開発者以外には馴染みのない plist ファイルについて、エコシステムと合わせた紹介
- アプリケーションが設定を読み込む仕組みについて（defaults や cfprefsdの挙動）
- WiFi設定などで目にするProfileの設定方法や作り方
Property Lists
そもそも .plist ファイルって何？という方に説明すると、macOSで動くアプリケーションがユーザーごとに個別の設定を持つためのファイルの一般的な形式です。
本の中でも解説されていますが、例えばアプリバンドル内の info.plist など、様々な用途で使われています。
しかしながら、同じ .plist 拡張子のファイルだとしてもファイルごとに形式が異なります。NeXTSTEP時代のASCIIテキスト形式や、OS X初期のXML形式、その後のバイナリ形式など。
plistを読み書きするユーティリティはたくさんありますが、本章では読み書き可能な形式などに注目してそれらを整理しています。
個人的な発見は以下の通り。
PlistBuddyで対話実行ができること/usr/libexecには様々なライブラリが含まれるので、うかつにパスを通してはいけないことfileコマンドでファイル形式が確認できること
Preferences
macOSの設定を管理するデーモン cfprefsd について初めて知りました。cfが気になって調べたところ、Core Foundation の略のようです。
前章までの内容と合わせ、 defaults, PlistBuddy, plutil の使い分けが整理できたのが良かったです。
- 基本的に
defaultsを用いる。defaultsだけがcfprefsdにも設定変更を通知するため、アプリ側の変更のファイル書き込みキューに後から設定ファイルを上書きされる心配がない。 - 2階層以上ネストしている項目を編集したい場合、
PlistBuddyを用いる。 - plistファイルを丸ごと変換するようなケースでは
plutilを用いる。
なお、この本では取り上げられていないものの、他に pl というコマンドもあるようです（NeSTSTEP時代の形式を表示するためのコマンド）
また、なぜdefaults コマンドだけはplistファイルのパスを指定しないでも設定を編集できるかについても解説がありました。
Profiles
この章は現時点では私の興味の範疇ではないものの、いずれはProfileを使って管理することもあるのかな、と思って眺めました。
会社などでDEP（Device Enrollment Program）を使うことになるような場合、Profileからシェルスクリプトを実行してplistを編集できることを知っているのは嬉しいかもしれません。
まとめ
断片的な知識しかなかったplistについて、Apple端末の管理者という観点と確かなバックグラウンドから書かれた良書でした。dotfilesやdefaultsコマンドのオプションの解析が好きな人は読んで損しないと思います。
Synology NASにおける暗号化の挙動の整理
Synology NASには、ボリュームを暗号化するオプションがあります。ドキュメントだけでは挙動が分かりづらかった部分を実際に試して整理しました。
TL;DR
- 暗号化キーを知らない人間による暗号化ボリュームへのアクセス → ボリュームがマウントされているかどうかによる
- 暗号化ボリュームの非暗号化とその逆 → できる。ただし、ファイルまたはフォルダの名前の文字数が143文字の英語文字または47文字のアジア文字を超過できない
- キーマネージャーを外部USBデバイスに設定してUSBを紛失した場合の暗号化ボリュームの読み書き → できる（ボリュームの暗号化キーを覚えていれば）
Synology NASの暗号化とは
Synology NASにおける暗号化とは、Windowsのファイルまたはフォルダの暗号化のような機能ではなくHDDのボリュームの暗号化です。
macOSにおける FileVault に近いと思います。
したがって、暗号化キー（パスワード）を尋ねられるタイミングはボリュームのマウントのタイミングです。一度マウントすれば、アンマウントするまで暗号化キーは不要です。
暗号化・非暗号化の切り替え
いつでも可能です。ただし、暗号化したい共有フォルダに長い名前のファイル・フォルダが含まれていると失敗します。
また、それなりに時間がかかります。次のようなポップアップが表示されました。
キーマネージャーの役割
キーマネージャーの役割は、HDDを暗号化するキーを自動で指定してくれるものではありません。
どちらかというと1Passwordのようなパスワードマネージャーに近いです。つまり、複数の暗号化されたボリュームがある場合でも、キーマネージャーがあれば覚えておくのはキーマネージャーのパスフレーズでOK、というもの。
実際のユースケースでは、ボリュームの暗号化キーを超複雑にし、かつキーマネージャーのパスフレーズを覚えやすくしておく。そしてキーマネージャーはUSBなどに保存し、必要な場合に取り出す、というのが一番セキュアかもしれません。
まとめ
HDDのボリュームの暗号化についての知識がないとなんだろう？と思ってしまう仕様でした。Synology NASにはSSHでのログインも可能なので、CUIでも確認して理解を深めたいです。
付録 Synology NASのドキュメント
3種類あり、どれがどれか分からなくなりました。簡単な順に並べると以下の通り（主観です）
ドキュメントは Synology ナレッジセンターの検索で見つけました。
