血と汗となみだを流す

個人の思ったこと、やったことの吐き出し口です。

ssmjp 2018/05 行ってきた！(20180524)

前置き

  • 「blog書くからLINEに行かせて枠」で参加させて頂きました。
  • 諸事情で開始に間に合わず、KYTの話の途中から参加しました。
  • 正直内容についていけていないところが多々あり、以下を書こうと思います。
    • 気になるワードを拾う
    • わかったところは感想
    • よくわからない箇所は雑なまとめ・・・

お題目と資料

KYTの話

概要

  • Kiken Yochi Traning(危険予知トレーニング)のこと
  • 危険工程をケーススタディで学ぶ
  • 目的は、危険工程に対する嗅覚を磨くこと

危険の例を挙げて、対策を考える

  • FTPサーバの操作で、cpコマンドのオプションをミスって重要ファイルを消してしまう
  • crontabの操作(-eオプションと-rオプション)
  • tarコマンドのオプションの指定忘れ
  • hostnameコマンドでFQDN確認しようとしたが、オプション忘れてhostnameが変わって・・・
  • killコマンドで、「-」忘れてPID9を削除
  • 容量を確認せずに圧縮ファイルを解凍

対策例

  • 手順書のドキュメント化
  • Enter前に今一度確認
  • 安全なディレクトリにコピーして作業
  • etc...

他にも経験者のあるあるに由来する危険など

  • 「最初のポートのケーブルを抜け」という表現が #1 じゃなくて #0 だった

感想

  • 「嗅覚を磨く」これはかなり重要だと思った
  • 今、自分が持っている嗅覚は過去の経験から養われたものなので、これをケーススタディで学ぶのはとても良いと思った

DNSの話

ゴール

  • DNSやドメインにまつわるちょっと耳寄りな話
  • DNS運用品質をあげる、トラブルを未然に防止する
  • DNS Summber Day 2018に興味を持ってくれる人が増えると良い

まぎらわしいよね

  • 以下3つを区別することがDNSを的確に理解するための重要
    • スタブリゾルバ：クライアント
    • フルリゾルバ：キャッシュDNSサーバ
    • ネームサーバ：ゾーン情報を保持

ドメイン登録管理のメカニズム

WHOIS

  • ドメインの各情報を記載した誰でも参照可能なデータベース
  • 「状態」がキーポイント
  • Contact Informationで問い合先を知る

はてなドメイン名ハイジャック事件

ドメインハイジャックへの対策

ドメインの「状態」

  • 知っておきたい状態
    • serverHold
    • ClientHold

ネガティブキャッシュ

  • ドメインが利用できない状態をキャッシュしてしまう
    • JP ccTLD:900sec
    • gTLD:86400sec
  • ドメインによっては完全復旧まで24h

WHOISは適切に登録、レジストラからの通知を見落とさない

  • 以下の様なことが発生して、ドメインの有効性が切れるなど・・・
    • メールを見落とす
    • 担当者がやめてしまっている

自前運用からの脱却

  • DNS運用には苦労が多い
    • 脆弱性対応
    • 高可用対策
    • 管理者不在
  • DNS自前で運用する必要がある？
  • 熊本地震での例
    • 庁舎のDNSサーバが2台とも死んだ

DNSSEC

  • 仮想通貨盗難事件
    • 経路ハイジャックと不正なDNS応答のあわせ技
    • ユーザを不正なサーバに誘導して仮想通貨を摂取
  • 被害を防ぐために必要だったもの
    • RPKI
    • DNSSEC
  • 社会インフラとして安全安心な通信インフラにはDNSSECが必要

DNSブロッキング

  • SNS投稿禁止！

DNS Summer Day 2018やるよ

まとめ

  • 常に利用している重要インフラでありながら、余り意識しない空気のようなものだが、ひとたび運用に問題が発生すると影響が広範囲に発生する
  • みんなDNSに関心もとうぜ！

おまけ

  • シンセンいってきた
  • 人・者・金が溢れている・・・！
  • 働きやすい環境ができあがっている
  • サバイバルというのを意識する必要がある

DNSトンネリングの手法

DNSトンネリングとは

  • DNS通信に別の目的を情報を含めること

暗号化通信との違い

  • 偽装通信
    • 意味のあるデータを送信していることを知られないようにする

利用例

マルウェアのHTTP通信

  • 殆どのOSでHTTP通信が可能
  • Proxyがあってもクライアント通信ほぼそのままで外部に行ける
  • 様々なデータを表現できる

マルウェアのDNS通信

  • 殆どのOSでHTTP通信が可能
  • フルリゾルバがあってもクライアント通信ほぼそのままで外部に行ける
  • 様々なデータを表現できる

マルウェア一覧

  • PlugX
  • MULTIGRAIN
  • pisloader
  • Feederbot
  • DNSMessanger
  • FrameworkPOS
  • C3PRO-RACOON
  • ...

使われるのはTXTが多い

  • サーバからクライアントへの命令はTXTが多い
  • TXTは任意のデータを含められるため

疑似マルウェアによるDNSトンネリングのデモ

  • Aレコードを用いたC2通信
  • TXTレコードを用いたC2通信
  • 1個1個のデータは少ないけど確実にデータを送れる

まとめ

  • DNSの通信に別の目的のデータを含める
  • 標的型に使われている
  • DNS通信でデータを含めるデモをやってくれた
  • 細かいデータを送っていた
  • マルウェアの通信の実体を知った

「宣言型デプロイツールの「正しい」使い方 (考え方編)」

運用自動化

  • 運用標準化の1つ

自動化のフロー

  • 社内制手運用：個々人が独自
  • 運用の定型化：手順書レベル
  • 運用自動化：コードレベル

自動化でやってしまいがち

  • 定型化をやらずに、一足飛びで自動化に行くと標準化が薄くなる

自動化した状態しか知らない人が増えると

  • 作業の目的が希薄化
  • ブラックボックス化
  • 自動化ツール不具合時の手動対応までを想定するのがプロの自動化

宣言型デプロイツールにフォーカス

  • CloudFormation
  • Ansible, Chec,...

メリット

  • 再現性が高い
  • 操作がシンプル
  • 再利用性が高い

だが・・・

  • 実運用とコンセプトのギャップが埋まらない
  • コレじゃない感が消えない

宣言型デプロイツールの落とし穴

手順書とコードが連動していることが重要

  • 現実では意図が不明になっているものが多い

宣言型デプロイツール界隈で気づいたこと

  • 「他人から引き継いだけど、宣言型デプロイツールイイネ」っている人を見たことがない
  • 他人から引き継いだChefレシピをすてて、Ansibleにクラスチェンジあるある
  • テンプレート、レシピがあればOK、では上手く行かない

宣言型デプロイツールの二律背反

  • 再現性
  • 汎用性

デプロイツールに何を求める

  • 再現性？汎用性？
  • 両立させようとするほぼ確実に破綻する
  • 本番環境を考えると再現性を期待
  • 「汎用性」は未定義と同義
  • 無限の汎用性は存在しない = 汎用性は幻
  • 汎用性を捨てると再現性が高くなる
  • 多機能を諦めると再現性が高くなる
    • 制御構造が減る
  • 変更や更新をやらないと再現性が高くなる
    • 都度作成、使い捨て

まとめ

  • 「再現性/汎用性」は考えさせられる内容だった
  • たしかにterraformの構成に汎用性もたせようとしたら失敗したことが・・・
  • 発表内容の通り、「再現性」重視が良いと思った
プライバシーポリシー