気がついたら一番前の演題の前に「blog枠」という席が用意されていて
そこに座っていました。
どうも、みむらです。
前回参加した際に、
知り合いに「実は５月は喋るんですよ！」と前回参加時に教えてもらいまして
その時から、これは行かねばならぬ、と使命感的なものを感じておりました。
うそです。前回が楽しかったから参加してます。
もちろん、知り合いの発表もわくてかですよ。
冗談はさておいて、#ssmjp です。
#ssmjp の勉強会について。
アウトプットしないのは知的な便秘
「インフラ／運用」がテーマの勉強会。
でも「面白ければ別に IT じゃなくても何でもいいんじゃない？」というポリシー。
@tigerszk 先生のクソコラが見られるのは ssmjp だけ！
大人数の前で喋ることの練習の場として利用するのも OK.
気軽な気持ちで参加をすればよい、とのこと。
喋りたい方はサイトを確認してくださいとのことですので、
チャレンジしてみてはいかがでしょうか。
http://ssm.pkan.org/
“KYT” の話
Speaker : @actanx93 さん
KYT とは？
危険予知訓練 (Kiken Yochi Training) のこと。
労働安全衛生法の中でも実施する事が述べられている。
ある事象に対して「危険の例」と「対策の例」を考えていく。
ex.) http://jafmate.jp/jmp/prediction_of_risks/
実際の IT のケースに適用してみる
たとえば「バックアップ」をするために下記のオペレーションを実施することを考える。
どのような危険があるか？
cd ~ftp
mkdir etc
cd etc
cp /etc/group /etc/passwd .
考えられること：
どこで読み書きしてる？
cp コマンドの末尾の “.” を忘れると、 /etc/group で /etc/passwd で上書きする危険性がある
..などなど…
では、どうすべきか？
→ 「作業用のディレクトリにまるっとコピーしてから」「全部フルパスで」 etc…
他にも色々と考えられる。
→ “tar cvzf backup.tar.gz *.html” と打とうとして “tar cvzf *.html” と打ってファイルを破壊する
→ “kill –9” と打とうとして “kill 9” と打って PID:9 のプロセスを殺してしまう..
危険予知トレーニングの実施の意義
はじめて実施する作業に対して適用し「危険工程」を見つける（嗅覚を磨く）ことで
オペミスやトラブルを少しでも未然に防げるようにする。
「暗黙知」をトレーニングを通して「形式知」に変換し、「共有知」に持って行くことができる。
→ 同時に “手順書” “ドキュメント化” の課程における手助けになる。
「ビギナー」や「若手」に KYT を適用するのも凄く有用。
続・広く知って欲しい DNS のこと
～DNSの運用をちょっとずつよくしていく話～
Speaker : 中島さん (DNSOPS.JP)
前回までのあらすじ
前回はこちら : https://www.slideshare.net/nakatomoorg/ssmjpdnssecurity
今回の内容
DNS やドメインにまつわるちょっと耳寄りの話を通じて、
DNS の運用品質がちょっと良くなる、トラブルを未然に防止できる。
DNS とは？
ネットワーク上で名前解決を行うためのプロトコル
SSL 証明書や送信ドメイン認証など、認証の目的としても使われている。
ネームサーバ
ゾーン情報の公開。権威 DNS サーバのこと。
フルリゾルバ
ネームサーバで公開されている情報をルートからたどって参照できるリゾルバ。
再起問い合わせとキャッシュの機能を持つ。
スタブリゾルバ
再起問い合わせ機能を持たない。単に名前解決をしたいだけ。
よくあるクライアントOSのDNS設定はこのスタブリゾルバの設定。
レジストラント
登録者（使いたい人）
レジストラ
登録取次事業者 （レジストラント <—[WEBUI など]—> レジストラント)
レジストリ
登録管理機関 （レジストラ <—[EPPなど]—> レジストリ)
ドメインハイジャックなどの危険から守る技術
・・・ドメインの情報を書き換えられたら、ビジネスにもかなりの影響が出る。
そのため、各種保護する機構が存在する。
「レジストリロック」
→ WHOIS の登録情報変更を制限する。
「レジストラロック」
→ ドメインの移転や削除を制限する機能。
また、各社において多要素認証なども始まっている。
ドメインが利用不可になることも。
example)
serverHold (Expire) : ドメイン有効期限切れ。
clientHold : 登録情報不備。無効なメールアドレスをずっと設定し続けた場合など。
ほかにも「ネガティブキャッシュ」という存在があり、ちゃんと見ていないとサービスが止まる可能性がある。
→ 「その名前が存在しないこと」をキャッシュするキャッシュ
JP ccTLD なら 900. gTLD なら 86400. が TTL として設定されている。
DNS は自前で運用する必要ありますか？
熊本地震の際に、ある自治体のウェブサイトが参照不可になった。
→ 権威 DNS サーバ２台が同一サブネット上にあり、２台とも到達出来なくなっていたことがある。
(ref : https://dnsops.jp/event/20160624/h28_kumamoto_earthquake.pdf)
DNSSEC, RPKI はできればしっかりと設定したほうがいい。
MyEtherWallet.com の事例は、これらで防げた。
なぜ？ : 経路ハイジャックと不正な DNS 応答の合わせ技だったため。
→ どちらか一方だけでも「攻撃成功の難易度」が格段に高まる。
余談
「ヒト」「モノ」「カネ」のバランスは重要。
深圳が特に回っている例。
GDPR対応
→ “GDPR Legal Analysis” 参照.
Registration Data Access Protocol (RDAP)
→ Whois に変わるドメイン登録者データへアクセスするプロトコル。
→ GDPR の対応に際し、こちらへの移行が後押しされている。
DNS トンネリングの手法
Speaker : shutingrzさん
DNS トンネリング？
DNS通信に別の目的を持った情報を含めること
偽装通信の一つ。
暗号通信
「どのようなデータが流れているか」を分からないようにする。
データが流れていることに関しては把握されてもよい。
偽装通信
「意味あるデータを送信していることを知られないようにする」こと
マルウェアの通信にもよく使われる。
マルウェアは Malicious Ware の通信。
悪意あるソフトの通信、ということで狭義のウイルスということになる。
普通は HTTP が使われる。ほとんどのPCで喋れて、なんだかんだ外に出られるから。
一方、DNS もまた、ほとんどの PC で喋れて、なんだかんだクライアントの通信が外に出られる。
→ HTTP と同じような属性を持っている一方で
HTTP 程ちゃんと見ていないことが多いために悪用されてしまう。
もちろん、正規の目的として VPN の手法としても使われる。
ソフトイーサ社の VPN で利用されているのが有名。
実際にどうやって通信するのか検討してみる。
1. まずは Basic に “TXT” レコード, “QNAME” を用いて通信してみる。
→ 行きは “QNAME” (雑に書けば 「ドメイン名」)
→ 帰りは “TXT” に直接や “A” に符号化した上で入れてみる。
2. EDNS0 や RRSIG といった、DNS クエリのあまり知られてなさそうなとこに押し込んでみる。
→ 「フルリゾルバ」を経由する場合は使えない。でも直接通信できるなら強力。
→ EDNS0 なら仕様に “PADDING” などもあるので隠せる。
ではこれを鑑みて、どう対策する？
直接通信させないようにフィルタを掛けるのが第一歩。
なぜ？：フルリゾルバを経由させると下記の利点があるから：
・同じ “qname” と “RR” は TTL秒キャッシュされるのでリアルタイム通信に適さなくなる。
（DNS の仕様からすると普通ではありますが・・。）
・再起問い合わせに不要なデータは削除される。
上記の理由から “QNAME” をガシガシ変えて頑張るパターンが鉄板となってくる。
また 「人間は何らかの既知の用語を使って名前を付けることが多い」 ことから
辞書との単語距離を取ることで、機械的に生成されたドメイン名を発見できる可能性がある。
(ex. http://blog.trendmicro.co.jp/archives/3799 )
宣言型デプロイツールの「正しい」考え方
Speaker : tcsh さん
やりたいこと「運用自動化」
よくある風景
管理職「現場に任せた」
実装者「ノリノリ」「おれすげー」
メンバー「なんとなくすごそう」
そして、実装者が居なくなってしまい、メンバーが気合いでリバースして調べたり・・。
宣言型デプロイツールでよくある光景
「宣言型デプロイツール、いいね！」 → 実装者の１０割。
「他人から引き続いたけど、宣言型デプロイツールいいね！」という人を見たことがない。
そして、Chef で書いていたものを引継担当者が Ansible で書き直したり・・。
こういう人は２つのことを目指すことに陥りがち
「再現性」
→ 「手を動かしたら負け。再現性！再現性！！ 全部自動化してやるぜ！！」
「汎用性」
→ 「みんなこのツール使おうぜ！！」
・・・・メンテできない標準ツール、工数掛けた割に汎用性もイマイチ
新規案件で使うのにも手間が掛かる・・・そんなものに２～３年後になっていることが多い。
さてどうするか。
もちろんまずは引き継げるように
何をやっているか、どういうモノなのかはちゃんとドキュメント化する
その上で「再現性」「汎用性」のどちらを取る？
→ 「汎用性」は多くの場合「幻」となる。
・範疇が不明な「汎用性」は未定義と同義
・「汎用性の定義」は上手くいかない。
・「汎用性の確保」は上手くいかない。
→ 「再現性は意外と確保できる」 （何かを「捨てる」ことで実現できる再現性）
・汎用性を捨てると再現性が高くなる
・多機能を諦めると再現性が高くなる
・変更や追加をやめると再現性が高くなる
宣言型デプロイツールのメリット
・再現性を追求して設計すること。
→ シンプルに、小さく。
→ デザインできない場合 UNIX コマンドの設計思想を考えるとイメージ化出来るかも。
巻末に
今回もとても面白かったです。
次回も同じ会場とのこと。 さて、申し込みますかねぇ・・！
