ハムっぽい何かのレシピ

ハムっぽい何かのレシピ

概要

「ハム」を作りたいのだが、モモ肉が手に入らず、肩ロースで作っている「ハムっぽい何か」のレシピです。（wikipedia曰く『英語のhamとは元々は「豚のもも肉」の意味であるが、「豚のもも肉を塩漬けにした加工食品」を指す場合が多い。』）

なお、手順３で燻製しますが、燻製機がなければ2までで食べてもよいです。

材料

  • 豚の肩ロースの塊肉  1kg(約 500g x 2)
  • ソミュール液（水 200ml、塩 20g、砂糖 10g、胡椒 5粒、クローブ 5粒）

 

作り方

  1. ビニール袋に豚肉とソミュール液を入れて、できるだけ空気を抜いて冷蔵庫で保存（５~7日）※保存中、袋の上下を逆にするなど味が全体に馴染むようにする

    f:id:eval_error:20201209183451j:plain

    ソミュール液に漬けている
  2. 豚肉をビニール袋から取り出し、70度のオーブンで4時間焼く（100度なら90分）

    f:id:eval_error:20201209184232j:plain

    オーブンで火を通す
  3. さくらやリンゴなどのスモークウッドで1時間程度、温燻する
  4. 薄く切って完成！

    f:id:eval_error:20201209183616j:plain

    完成

以上

「#ssmjp 2019/04 DNSの話を聞く会」に参加した

概要

2019年4月23日（火）＠IIJ飯田橋で開催された #ssmjp のDNSの話を聞く会の感想です。

会のスケジュール

時間 登壇者 内容
19:30-19:40 @tigerszk 前枠/会場諸注意
19:40-20:00 @sischkgさん 「BINDのメモリリークとRoot KSK Rollover」
20:00-20:20 @fj_twtさん 「DNS BOM-BA-YE!! 〜DNS[をで]止め(ろ|るな)!〜」
20:20-20:25   DNS Summer Dayのおしらせ
20:25-20:35 休憩  
20:35-21:35 @tss_ontapさん 「黒塗りの DNS (萎縮編)」

 

「BINDのメモリリークとRoot KSK Rollover」

資料：

概要：

  • BINDのメモリリーク
    • BINDのメモリリークの脆弱性（CVE-2018-5744）は、複数のKey Tag Option を持つDNSクエリを受信するとメモリリークするというもの
    • 対象は、権威サーバ、フルリゾルバの両方(詳しくは、上記のCVE参照）
    • 検証コードの作成は容易、回避策はないが、悪用するためには多数のDNSクエリ（１GBのメモリをリークさせるためには合計１GB以上のクエリ）が必要
    • バージョンアップをしましょう
  • Root KSK Rollover
    •  Root Zone のKSK（＝Trust Anchor）を新しいものに変更する作業
    • Validator（フルリゾルバ）に、対応する新しいTrust Anchor（＝KSK）を設定する必要がある
  • Signaling Trust Anchor Knowledge
    • RFC8145 Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)
    • 新しいTrust AnchorをValidatorへ設定したか調査するために導入
    • Validatorが使用しているTrust AnchorのKey Tagを送信
    • その際、複数のKey Tagを含むクエリを送信する（→ 前述の脆弱性）
    • 新しいValidatorのみ実装のため、全てを観測できない（参考にならなかった）
    • 次回のRoot KSK Rollover時には役立つかも（個人の感想）

 感想：

「DNS BOM-BA-YE!! 〜DNS[をで]止め(ろ|るな)!〜」

資料：

概要：

補足：

感想：

  • BINDのリリースを予測するやり方は面白い。ただ、これが広まると cron.dailyで、privateの更新日を毎日変えられそう。

「DNS Summer Dayのおしらせ」

名称

DNS Summer Day 2019

主催

日本DNSオペレーターズグループ (DNSOPS.JP)

日時

2019年6月28日 (金) 10:00-18:00(予定)
会場

 フクラシア東京ステーション 5階 会議室H
〒100-0004 東京都千代田区大手町2-6-1 朝日生命大手町ビル5F

協賛

ご興味のある方は、事務局(sec@dnsops.jp)までご連絡ください。

参加費

無料

参加申込

必要ありません。直接会場にお越しください。

https://dnsops.jp/event20190628.html

「黒塗りのDNS（萎縮編）」

資料：

概要：

  •  m.chukyo-u.ac.jp が、中華料理屋のサイトに変わっている！
    • 原因：m.chukyo-u.ac.jpとして利用していたレンタルサーバの契約を終了したが、Aレコードの設定を削除し忘れていた。レンタルサーバの運営者が別契約者にm.chukyo-u.ac.jpで使用していたIPアドレスを再度割り振ったため（乗っ取りではない）
    • 契約を解除した後もリソースレコードを設定したままにしてはならない
    • 放置されたCNAMEの先も狙われている！
  • ■■■■.CO.JP 事件
    • NSに廃止済みの e-ontap.com のホストが指定されている
    • 3990円で登録
    • e-ontap.com の昔のWebページには、「Reduce the IT operation risk to your Internet business.」と書いてあった！
    • 詳しい経緯は e-ontap.com へどうぞ
    • レジストリ側だけ修正していた（これだけでは不十分）、権威DNSサーバ側の修正が必要
  • 共用サーバでの lame delegation 乗っ取り（まとめ）
    • 誰でもゾーンが作成できる共用権威サーバが危ない
    • ドメイン名の権利確認がないと危ない（初期運用のドメイン名はどうするのか？）
    • ゾーン作成前に委任すると危ない
    • 委任のキャッシュがどこかに残っているうちにゾーンを削除すると危ない
    • 移管したとたんゾーンが消えるサービスは危ない
    • ずっと消さないのもトラブルの元
    • 親子同居は委任がなくても危ない
    • example.jpのゾーンがなく www.example.jp だけあって偽親が作られる可能性もある（サービスのUIと説明に問題があるのでは？）
    • 借りた任意のサブドメイン名を返すのも危ない
    • CNAMEを向けられていることはサービス運営者にはなかなかわからない
    • そもそもの話、他人のドメイン名を借りること自体が色々危ない
    • さらにいうと中古ドメイン名は危ない（中古を使うのの中古にするのも）
  • 共用レンタルサーバでのメールの窃盗／盗聴の要点
    • ドメイン名の権利確認しないサービスはたくさん存在する
    • （共用レンタルサーバに）ターゲットのメールアドレスのドメイン名を設定される
    • 上位ゾーン（JPなど）からのDNS委任はいらない
    • 同じサーバから送信されたメールが内部（Virtual）配送される
    • 中継されたらまずわからない（盗聴）
    • 一般的なメールサーバの仕組みとしてあたりまえ
    • 問題は権利確認していないこと／対策は権利確認してもらうこと（権利は移動するので常に確認が必要）
    • 対策されていないサービスからは逃げるしかない（どこへ？）

感想：

  • 共用サーバでの lame delegation 乗っ取り
    • 私が利用していたDOZENSやGoogle Cloud DNSではドメイン名の権利確認をしているので、権利確認しないサービスがたくさん存在することに驚いた！
    • ただ、上記のDOZENSやGoogle Cloud DNSの権利確認は、「現在の権威DNSサーバに指定のDNAMEにTXTレコードに指定のランダム文字列を記載させる」方法だった。（他の方法もあったけど使っていない）
    • ドメイン名登録直後でも簡単にドメイン名（DNSサーバ）を利用するためにも、ドメイン名の登録は登録者だけが利用できるDNSホスティングサービスがあるところがいいだろう
    • ただし、NSレコードを任意の値に設定できないサービスやレジストラを移転すると利用できなくなる場合は、レジストラ以外のDNSホスティングサービスを利用するべきでしょう
  • 共用レンタルサーバでのメール窃盗について
    • 前職で20年前（Postfixのない時代）に、qmailを使って共用レンタルサーバを作ったときに問題点として認識していたので、権利確認をしないサービスがたくさん存在することに驚いた！
    • 前職の時は、人手で権利確認（認証）していたが、今ならサーバ証明書の発行で使用している認証方法を利用するのが良いだろうと思った。

 

2018-10-18 「Ansibleもくもく会 (サーバ編)2018.10」に参加した話

はじめに

Ansibleを使い始めて4日目ですが、「Ansibleもくもく会 (サーバ編)2018.10」に参加したので、内容をまとめます。

 

イベント概要

「Ansible 及び Ansible Towerに関してもくもく勉強をしていく場になります。今回はGitHubに公開もされている、Ansible Tower含むハンズオンコンテンツ(英語)を活用しながらもくもくしてみましょう!今回はレッドハットのメンバー数名が支援いたします。」（募集ページから引用）

 

Ansibleのハンズオン。課題は既存のコンテンツのようだ。

アジェンダ

19:00-19:05  イントロ（会場案内）

19:05-19:15  環境、及びコンテンツのご案内

19:15-21:00  もくもく作業

21:00-21:30  成果共有

 

イベント内容

もくもく作業

Google docsで、以下の課題が共有されました。課題はレベルに合わせて、途中から開始してもOK。（私は始めから）

 

  • Ansible Lightbulb

 

  • Ansible初めての方はGuide（ハンズオン）から始めるのがオススメ
  • Ansible入門ができて、Ansible Towerの感触を掴めたい方はGuide（ハンズオン）がオススメ
  • 復習したい、課題を解いてみたい方にはWorkshopがオススメ

 

Ansibleがインストールされているサーバー、Ansibleで設定するノード（サーバー）の情報を開場到着時に貰い、その情報（IPアドレス、ユーザー名、パスワード）で課題を進めていきます。

 

質問は、Google docsで共有されている課題ファイルに、書き込むとメンターが回答してくれる。（つまづくところは同じところの場合が多いから、この方法はいいですね）

質問も　しゃべる 必要がないので、みんな「もくもく」と課題を解いていきます。（とても静かなので、BGMが流れています）

 

成果共有

成果共有枠の参加者1名と、飛び入りで発表される方がいました。

成果共有

 

感想

私は残念ながらPCがWifiに接続できてもインターネットにうまく接続できず、半分、試行錯誤していました。（外部にpingは通るけど、sshは通らなかった...）

 

スマホにsshアプリをインストールして、その端末で課題を解いていました。

ansibleのアドホック・コマンドまでしかできませんでしたが、続きは次回やりたいと思います。

 

以上