しばたテックブログ

気分で書いている技術ブログです。

Hokkaido.cap #4に参加してきました

勉強会・イベント

本日行われたHokkaido.cap #4に参加してきましたので簡単にレポートします。

ネットワークの遅延と戦う - 前編

最初にやまきさん(@)によるセッションから始まりました。
今回はネットワークの遅延が発生している様々なケースのキャプチャファイルを見ながらどういった点に注目すべきか学んで行きました。
以下に箇条書きですが内容をまとめておきます。

  • ダウンロードの遅延
    TCP Window Updateが多発する傾向にある -> Window Sizeの頻繁な変化のため
  • その他TCP遅延の例
    TCP Previous segment lostの発生 -> パケットの欠落が発生している
    TCP Dup Ackの多発 -> 同じ確認番号のACKが再送されている
    TCP Out-Of-Orderの発生 -> パケットの順番が乱れている
    TCP Retransmissionの発生 -> TCPによる再送信が発生している
  • ルーティングの不具合
    TraceRouteで確認してみる
  • パケットが二重に見える
    ルーティングの間違い、ポートミラーリング設定間違いの場合が多い
    本当に同一パケットかはIPヘッダのIDで確認する
    TTLの値まで同一ならミラーリングされたパケット、TTLが異なるならルーティングの間違いによるパケットになる
  • 一見通信出来ている様なデータ
    TCP Streamからデータの中身を追って判断する

セッション資料に関しては過去の資料がコチラにアップされているので、今回の分もそのうち上がるのでないかと思います。

CTF にチャレンジしてみよう

続けてCTF (Capture the Flag)にチャレンジという事で、お題のキャプチャファイルにあるメッセージを読み取る課題を行いました。
前回のHokkaido.cap #3でもCTFがありそれよりも大分簡単になっているという事でしたが…時間内に解けませんでした…
お題に関してどこまで公開していいか分からないので詳細は記述しないでおきます。

LT(Wiresharkで検知できないチャットプロトコル)

最後にSAPPORO WORKSのSINさん(@)による30分LTになります。もはやLTじゃないですw
資料がコチラにアップされていますので先ずは見てみて下さい。
デフォルトゲートウェイに対するARPリクエストパケットの、

    • 大量にパケットが発行されている -> 隠蔽しやすい
    • ARPリクエストである -> フィルタリングされない
    • ブロードキャストである -> 設定不要
    • 18Byteのパディングがある -> チャットデータを埋め込む

といった特徴を生かしたチャットプログラムを実際に動かしてみるという内容でした。
正直、よくもまあこんな事を思いつくもんだなぁwと思いました(褒め言葉です)。

まとめ

今回の内容は実践的な内容が多くとても勉強になりました。
当然実際のネットワーク遅延/障害はここまで分かりやすくはないでしょうが解析の指針にはできるなと思いました。
次回のHokkaido.cap #5は8/26(金)を予定しているそうです。ぜひまた参加したいですね。

stknohg 読者になる

関連記事