memo.

年: 2022年

  • ランチ：グリルチキンバーガー ソルト＆レモン（2022/2/10）

    雪が降る前に、マクドナルドへ買いにいってきた。限定バーガーのグリルチキンバーガー　ソルト＆レモン。

    丸いバーガーではなくて、四角いバーガーだった。ソルト＆レモンのソースがきいていて、美味しかった。チキンもしっかりとしているので、とても美味しい。マクドナルドのバーガーとしては、かなり美味しかった。ボリュームもあるし、このバーガーは気に入った。セットにしても、そこそこ高いのだけど。

  • ボラの大群がそじょうしていた

    真間川をボラの幼魚が大量に俎上していた。前にみた群れの2倍から3倍くらいの数になっていて、かなりの大群だ。

    この場所の下流の場所には鵜と鷺などの集団がいた。500mちょっとしか離れていないのだが。こちらにくれば食べ放題なわけだが、ここには捕食するような鳥はいない。ライギョはいるはずだが、こんなにたくさんはいらないだろう。面白いものだ。

  • 「情報セキュリティ10大脅威 2022」が発表された

    今年（2022年）の情報セキュリティの10大脅威がIPAから発表された。

    https://www.ipa.go.jp/security/vuln/10threats2022.html

    個人の情報セキュリティの脅威は、あまり昨年とかわらない。COVID‐19の影響でネットショッピングやキャッシュレス決裁が増えている状況が継続されているので、順位の変動はあるが、昨年と同じ脅威が継続している。

    個人ではなく、企業などの組織を対象にしたところをみると、昨年と同じく、リモートワーク（テレワーク）環境を狙った脅威が上位にいる。今年は、これらに加えて、「修正プログラムの公開前を狙う攻撃（ゼロデイ攻撃）」が増え、「脆弱性対策情報の公開に伴う悪用増加」の順位が上がっている。昨年後半のLog4Jの脆弱性が与えたインパクトが大きかったのだろう。

    いろいろと考えなければならないのは、「脆弱性対策情報の公開に伴う悪用増加」と「修正プログラムの公開前を狙う攻撃（ゼロデイ攻撃）」が注目されることによって、対策を求められるケースだ。何ができるかというと、常日頃からセキュリティパッチを継続的に当て続けること、緊急でセキュリティパッチが出たときにパッチを当てられる体制（テストも含めて）を整えていることだ。対策としては、当たり前とはいえ、日本の組織は、これが一番難しいかもしれない。メンテナンス時間を定期的に設定して、パッチを当て、最新に保つというのは、コストがかかるから理解されないから。パッチを当てるときのトラブルも考えると、作業者のスキルレベルが高くないといけないわけで、そういう人を抱え続ける必要もある（そうすると部門コストが上がる）。

    それから、ゼロデイ攻撃の対策としては、ログ監視や振る舞い検知が対策としては考えられる。ログの蓄積・分析は大容量の保存スペースが必要になり、分析ツールはログの量でコストが変わってくるので、コストが高い。クラウドサービスならば、というと、結局保存するログの量が増えるとその分コストがかかる。ログがあったとしても、分析できるだけのツールとツールを使うためのスキルが必要であり、難しい。アウトソースを行うという考え方もあるけれど、これまたコストがかかる。そもそもアウトソース先が機能してくれるかも業者によっては怪しい。それに最後は、普段の行動なのかどうかの見極めが必要になってくるので、業務パターン（の通信パターン？）に精通している必要がある。

    対策を迫られると、「修正プログラムの公開前を狙う攻撃（ゼロデイ攻撃）」と「脆弱性対策情報の公開に伴う悪用増加」への対応の解はあるが、実際に行うのは難しい。公開された脆弱性への対応は、対応できる人がいるかどうかと、常日頃からセキュリティに対する対策をしているかが一番のまっとうな対応だろう。ゼロデイは対応にコストをかけるかどうかだろう。

  • FreeBSDでpkgをアップデートしたらMariaDBが起動しなくなった

    FreeBSDで、”pkg upgrade”して、パッケージを最新の状態にしたところ、MariaDBが起動しなくなった。エラーログをみていると、DBのテーブルを修復したあとにDBがシャットダウンされている。DBのファイル破損が原因かと思い、いろいろと調べて対応したが、実はファイルの問題ではなかった。

    原因は、MariaDBのバージョンが「MariaDB 10.5」に上がったことによる「my.cnf」ファイルの変更だった。

    /usr/local/etc/mysql/conf.d/my.cnf

    このconf.dのディレクトリに、my.cnfがあることで、これを読みにいって、その設定で失敗して、サービスが落ちていた。同じところに、client.cnfもserver.cnfもあるが、これを読まずにmy.cnfを先に読みにいって、落ちていた。my.cnfは、１つ上の階層の「/usr/local/etc/mysql/」にもあり、conf.dの下を読み込むように書かれている。

    いろいろと行ったのだが、対応の正解は、conf.dの下のmy.cnfを消す（リネームでOK）。server.cnfとclient.cnfの設定を確認して、MariaDB（mysqld_safe）を起動させる。

    ちなみに、errファイルに記録されていたログは下記。あとは、ログ自体が出力されていない。ログがそもそも出力されていなければ、my.cnfを疑うべきだった。

    2022-02-05 15:36:39 0 [Note] /usr/local/libexec/mariadbd (initiated by: unknown): Normal shutdown
2022-02-05 15:36:39 0 [Note] Event Scheduler: Purging the queue. 0 events
2022-02-05 15:36:39 0 [Note] InnoDB: FTS optimize thread exiting.
2022-02-05 15:36:40 0 [Note] InnoDB: Starting shutdown...
2022-02-05 15:36:40 0 [Note] InnoDB: Dumping buffer pool(s) to /var/db/mysql/ib_buffer_pool
2022-02-05 15:36:40 0 [Note] InnoDB: Restricted to 2016 pages due to innodb_buf_pool_dump_pct=25
2022-02-05 15:36:40 0 [Note] InnoDB: Buffer pool(s) dump completed at 220205 15:36:40
2022-02-05 15:36:40 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2022-02-05 15:36:40 0 [Note] InnoDB: Shutdown completed; log sequence number 1363646560; transaction id 111190553
2022-02-05 15:36:40 0 [Note] /usr/local/libexec/mariadbd: Shutdown complete

  • 真間川の河津桜の蕾がふくらんできた

    2月に入り、真間川の河津桜の蕾が膨らんできた。1週間から10日くらいで開花しそうな感じだ。春が近づいて生きている感じだ。

  • oVice宴会のセット：星のなる木ジャパニーズBOX

    oVice宴会の「星のなる木ジャパニーズBOX」を食べた。手配する側は、楽で安いのだろうけれど、そんなに美味しくはない。ちゃんというと、美味しい料理と、お世辞にも美味しいとは言えないものが詰まっているので、微妙なBOXだった。お節料理になり損なったみたいな。

    それと飲み会のときのoViceの重さや操作性のクセがやっぱり気になる。

  • VMware vCenter Converter Standalone 6.2 でWindows Server 2003 の変換がエラーになる。

    VMware vCenter Converter Standalone 6.2 でWindows Server 2003 を仮想マシンに変換しようとしたところ、Agentのデプロイで「Error code: 1,603」でエラーになった。

    サポート範囲を調べてみると、Windows Server 2003は、Windows Server 2003 R2 SP2がサポート対象で、R2が付かないバージョンはサポート対象外だった。

    サポート外だが、無理やりP2Vできなかと、Converter Agentだけのインストールをためしてみたが、サービスをオンにするところで、失敗してロールバックした。

    調べてみると、VMware vCenter Converter Standalone 5.0 であれば、無印のWindows Server 2003にインストール可能。試してみたところ、5.0であればインストールはできた（過去にインストーラーを取得しておいてよかった）。しかし、VMware vCenter Converter Standalone 6.2からの接続は、接続経路の暗号化方式の不一致により、エラーになった。

    今度は、vCenter Converter Standalone 5.0 から、ESXi6.7に対して、P2V先を指定してみたが、これも通信時の暗号方式の問題で接続できずエラーになった。

    Veeam Backupのエージェントを、Windows Server 2003（無印）にいれて、イメージバックアップして、そのイメージを仮想マシンとして復元する方法も試した。Veeam BackupもVersion 9.5でも.net frameworkのバージョンが古すぎて、Windows Server 2003（無印）にエージェントのインストールができず。イメージバックアップを取得して、仮想マシンとしてリストアする方法についても失敗した。

    そのため、vCenter Converter Standalone 5.0を使って、Windows Server 2003（無印）を一度、VMware Workstation形式の仮想ファイルに変換した。次に、このVMware Workstation形式のファイルを、vCenter Converter Standalone 6.2で指定し、V2V（Virtual to Virtual）で、ESXi6.7に対して保存した。これで、なんとかP2Vは成功した。ネットワークの設定などは、変わっているため、仮想マシンの設定を編集して、新しくネットワークインターフェースの割り当てを行った。これで無事にWindows Server 2003（無印）のP2Vは完了した。

    仮想化すれば延命はできるが、物理サーバとして存在していると、そもそもP2Vでの仮想化の対象外になってしまう。延命するのであれば、早めに仮想化しておく必要がある。というのが、今回の教訓になった。

  • 北京冬季オリンピックではスマホやPCを使い捨て推奨なくらいセキュリティが危ないと思われるようだ。

    北京冬季オリンピックの開会式でスマートフォンで撮影しながら、入場してくる選手が多数いた。中国のネットワークを使っていてセキュリティは大丈夫なんだろうか。そういう疑問への回答の記事がWiredにある。

    “使い捨てスマートフォン”が欠かせない北京冬季五輪、そのセキュリティリスクの深刻度
    https://wired.jp/article/winter-olympics-2022-phones-security/

    なるほど。たぶん、国によって違うだろうけれど、アメリカは選手にプライベートのスマホではなく、オリンピックのときだけ使うスマホをすすめている。体調管理アプリをスマホにいれれば、行動が筒抜けだろう。中国のネットワーク網を使えば、そのエリアを保護する目的でファイアウォールが入れられていれば通信も筒抜けなわけだ。今回のオリンピックはバブル方式で、選手も関係者も報道陣も行動制限が厳しいので、監視の手間は少ないから、なおさらなのだろう。

    スマホもPCも、オリンピックのときだけの使い捨てを推奨とは、それほど危険視されているということ。日本の報道だと、COVID-19対策のことばかり報道されている。このようなセキュリティの話は聞かないので、偏りがあるなと思う。日本の報道各社や関係者は、どのような対策をしているのだろうか。していないような気がしなくもないけど。

    中国内から中国のネットワークを介さずに通信しようと思うと、衛星通信くらいだろうか。低軌道通信衛星を使いつつ通信を暗号化すればいけるか。無線通信だから、傍受する方法が編み出されるだけなのだろうけど。諜報系の対策はいたちごっこだから。

  • ランチ：ビックマックのコンビ（2022/2/2）

    ランチはマクドナルドに買いに行ってきた。ポテトがSサイズだけなので、ポテトのないビックマックのコンビにした。これだけでも、満足。

    ちなみに赤坂のマクドナルドは、普段はかなり混んでいるだが、今日はガラガラだった。人がいないのか、それともポテトの品薄の影響かな。

  • スギ花粉が飛び始めた気がする

    今週は、目のあたりがきつく、しょぼしょぼしている感じがする。身体も鈍い。今年も花粉が飛び始めた気がする。今年も長いスギ花粉との戦いの始まりかな。