ディスクがほとんど一杯な警告の消し方

% defaults write com.apple.diskspaced minFreeSpace 10

とかすると、10GB 以下になるまでは警告が出なくなる。
このパラメータは daemon が起動時に読むだけなので、

% killall diskspaced

とかやって監視デーモンを再起動。
diskspaced を止めちゃうという手もあるみたいだけど、まぁ、threashold を変える方が良さげ。

https://discussions.apple.com/thread/8198189

(mojave では動かないっぽい)

IPMI Serial over LAN でのコンソール

IPMI で serial over LAN を使って遠隔から boot 画面をとる方法
設定書かないと、boot 開始以後の出力が出ない。

以下のページが参考になった
 FreeBSD Forum: IPMI on supermicro: no keyboard => use console, howto

  • /boot/device.hints
    • COM1 とか COM2 なら標準で書かれているはずなので、IRQ と Port の値が違わないか確認する程度
    • COM3 とかで飛ばすなら、本体の Console Redirection の設定画面でIRQ, Port を確認して書く
    • 上記のページでは hint.uart.2.baud で速度設定とかあるけど、なくても行けた
  • /boot/loader.conf
    • 以下の設定を加える(COM2の場合)。comconsole_port 重要(これないと見えなかった)
    • ここまででboot中の出力はオッケ

boot_multicons="YES"
boot_serial="YES"
console="comconsole,vidconsole"
comconsole_speed="115200"
comconsole_port="0x2F8"

  • 起動後の console は ttys の設定
    • COM1 なら ttyu0、COM2 なら ttpy1
    • 3wire.115200 は std.115200 とかでも。/etc/gettytab にあるので、適切なものを書く。

ttyu1 "/usr/libexec/getty 3wire.115200" vt100 on secure

上記の参考ページには /boot.config に -Dh と書けとあるけど、loader.conf の記述で行けてる感じ。

FreeBSD 11.2-RELEASE

FreeBSD 久しぶりに入れたかも… でメモ

  1. DNS が EDNS 対応じゃないとダメな感
    • RTX の recursive だと割といろいろ引けない
    • まず pkg update でこけて、resolver 周りの設定修正(単にEDNSでいける奴見に行かせる)
  2. src を入れる

この辺りを参照
https://www.freebsd.org/doc/ja_JP.eucJP/books/handbook/svn.html

Office 2016 for Mac のライセンス

Office 2016 for Mac てばライセンスの種類によって微妙に挙動が違う(Excel で新しい関数が使えなかったり、新しい関数が使えなかったり)

でもって、一旦、削除して Office 365 から持って来てインストールし直してから、サインインしてみるもダメ

んーっと思ってよく見ると、最初に入れたときのボリュームライセンスで動いてる!
ということで、

この辺 から License Remover を持って来てインストール。インストールっていっても、インストールが済むとライセンスが削除されてそのままおしまいという、微妙に naming に反逆した挙動。

次に起動したときに、ライセンス認証走るので、Office 365 にサインインしたらオッケ。

ESXi のパッチ

vShpere Hypervisor (ESXi) にパッチを当てるとき(6.5で実施)

  1. VMware patch portal から使ってるバージョンのパッチを拾ってくる
    • ESXi (Embedded end Installable) で6.5.0とか選べばオッケ
  2. 拾ってきたpatchをESXiマシンの適当なとこ(例えば [datastore1] ESXi-patch)にupload
    • vSphere Web ClinetでStorage開いてDatastore browser使う
  3. ESXi にログイン。ssh でも他のでも(このへん
  4. 以下のコマンド
    • % esxcli software vib install -d "/vmfs/volumes/datastore1/ESXi-patch/patchファイル.zip
  5. Installation Result で ...completed successfully... とか出ればオッケ。あとはrebootの要否の指示に従う。

参照サイト: https://kb.vmware.com/s/article/2092895

BOM付きファイルとCSVクラス

BOM付きファイルを ruby CSV でヘッダをキーにして読もうとすると最初のカラムがアクセスできない。
open の際に "BOM | UTF-8" を指定すること。

HEADER_SYM_MAP = {
   "姓" => :familyName,
   "名" => :firstName,
   "ID" => :idnumber
}
header_converter = lambda { | h | HEADER_SYM_MAP[h] }
csv = CSV.read(ARGV[0], 'r:BOM|UTF-8', headers: true, header_converters: header_converter)


こんな感じ。
foreach を使うなら、

CSV.foreach ARGV[0], {encoding: 'BOM|UTF-8', headers: true, header_converters: header_converter } do | data |
...
end

以下を参考にさせてもらった。

https://qiita.com/buchiosan/items/a95acf45fbf8379eee6d

WPA2 key reinstallation attacks

10/16 に公開された WPA2 key reinstallation attacks についてのまとめ

  • 10/18 9:00に追記・更新しました(主として、はっきりしていることを断定調にしたのと、最後に参照リンクを追記)
  • この内容は、学内事務職員や非情報系のひとを想定して、細かい枝葉を切った説明になっています。学生や技術職の方は末尾リンクを参照下さい

何がされるか?

データ暗号化において使われる鍵を交換するフェーズに割り込んで一度使った鍵を再度使わせるという replay 攻撃の一種です。この鍵は、事前共有鍵(PSK、所謂 WiFi パスワード)や 1X 認証の証明書ではなく、認証が終わった後に通信の秘密状態の維持のために(ユーザの知らないところで)自動更新されているものです。したがって、この攻撃で事前共有鍵とか 1X の証明書が窃取されることはありません。

どこに問題があるか

クライアントのドライバで鍵交換をしている部分の実装の問題です。そのため、修正のためには各クライアントのドライバが更新される必要があります。技術まとめをしているサイトを見ると、この鍵管理は chip vendor のドライバより上の層で行われていて、WindowsmacOS は OS で処理されています。したがって、各OSベンダが出すセキュリティ update を確実に当てることが必要です。
一点、よくわかっていない点があって、intelのPROSetように、WiFi management software を出している vendor の場合、この処理が OSの機能を使っているのか vendor 実装しているのかが不明です。OS本来の機能以外のツールを使っている場合は、それも更新した方が安全でしょう。

AP側に対処がいるか

APとclientの通信は非対称で、今回の攻撃はclient側が受け取ったメッセージの処理の問題に起因しています。このprotocol attackの性質を考えると、基本は client 側の対処が必要です。そのためAP側の対処は必須ではありません。
一方で、この脆弱性を使った攻撃をする場合には MAC address 偽装をしてMan-in-the-middle attack (MITM) を仕掛けます。したがって、AP自身の MAC addressの偽装を検知して遮断する機能があると、側面的な対応は可能です。CISCO の AP は SSID の偽装(管理外のAPが自分のSSIDを騙るとかした場合)は検知する機能があるので、もしかしたら MAC 偽装も見ているかもしれません。このあたりは vendor に確認しないとわからないです。

すぐに何らかの対処が要るか?

NO
すぐにWiFi停止とか暗号方式を変えるとかのhardな対応が必要な話ではありません。現状は各 vendor の様子を watch して、update が出たら更新を強く勧める程度でしょう。Krackattacks.com にも「WEPに戻す?」みたいな FAQがありますが、著者は NO と答えています。
脆弱性といっても、現実的に割り込むのは簡単ではないですし、AES を使っている限りは盗み見られるだけなので、通常の WPA-PSK の同一 NW に参加している他の client から見えているのと同程度の状況になっているだけです。したがって、更に弱いものに degrade するとかは悪手です。*1

各社の対応状況は?

github にまとめができています。
https://github.com/kristate/krackinfo

  • Microsoftは既にupdate配付済みのようでアナウンスも出たようです(上記ページのリンクを辿って下さい)。
  • macOSについては、Krackattacks.com では攻撃が容易な対象として挙げられていますが、すでにbeta版のOS(macOS, iOS, tvOS共)には反映済みとの情報が出ているので、暫くしたら更新が配付されるでしょう。

もう少し詳しい説明はない?

いくつか良くまとまった情報が提供されています。

学生や技術職のひとは本家を…

*1:厳密には、MITMなので偽サイトへの誘導などのriskはありますが、clientが正しくupdateされ、適切なsecurity対策ソフトを入れてあって、browser等のalertを無視しなければ良い話なので、現状とほぼ変わりません(…この脆弱性なくてもMITMはあり得るし…)