セキュリティ・キャンプミニ@26in東京 Bトラック応募課題

Transcript

1. セキュリティ・キャンプ 2026 ミニ （東京） Bトラック 回答 属性 埼玉県出身 / ミニは2回目の参加 1
2. 問１：応募動機 背景・目的 大学では情報理論を学んでおり、自主的に数学も合わせて勉強をしています。そして、将来は高校 の情報科教員を目指しています。 情報科教員を目指すうえで、理論に加え、実際のサイバー攻撃の手法や防御策を現場の視点から知 りたいと考え、応募しました。 2
3. 期待していること 低レイヤでの通信の流れを体験できること セキュリティインシデントの運用に関するプロセスの設計について知れること 多様な分野を専攻している同世代の参加者との交流とコンピュータ科学に関する情報交換 受講後にやってみたいこと キャンプで得た知見をもとに、セキュリティに関する授業用資料を作成する 検証用ネットワークを自分で構築する 他学部のC言語を履修済みの学友と意見交換を行う 不安な点 ログの分析やネットワークを運用した経験がないため、実習に向けての事前準備に不安を感じてい ます。 3
4. 問２：セキュリティの考え方 以下のシナリオを読んで、(1)(2)に回答してください。 シナリオ： ある日、 「ログインしていないのに、他人の注文履歴が見えた」という問い合わせがありました。 調査の結果、URLの order_id=123 を order_id=124 に書き換えると、他人の注文が見えてしまう ことがわかりました。 (1)：この問題を防ぐために、アプリケーション側でどのような対策が必要だと思いますか。 あなたの考えを書いてください。 （150字程度） 4
5. 回答 認証・認可の強化 未ログインユーザーのアクセスを弾く認証を実装 データ取得時に「要求をしたユーザー」が「データの所有者」と一致するかをサーバー側で必ず 検証 注文IDを UUID に変更することでID推測を困難にし、他人のIDを特定されるリスクを大幅に低減 アクセス制御はクライアント側ではなく、必ずサーバー側で行う。 5
6. (2)：この問題が起きていたことに「気づける」ようにするには、どのようなログを残し、どの ように監視すればよいと思いますか。 （150字程度） 6
7. 回答 ログに記録する情報 項目 内容 通信元IPアドレス アクセス元の特定 ユーザーID 誰がアクセスしたか 要求された注文ID 何にアクセスしたか ステータスコード アクセス結果 監視アラートの設計 権限外アクセスには 404 を返す実装を施し、情報を与えないようにする 同一IPから短時間に大量の404エラーが発生した場合にアラートを出す 連番 での不自然な連続アクセスが検出された場合でもアラートを出す 7
8. 問３：技術問題 以下の仕様を満たすスクリプトを作成してください ※ 私は Python で作成しました 8
9. 仕様 入力：テキストファイル（1行に1つのJSON） 処理：各行をJSONとして読み込み、 user_id ごとに出現回数をカウント 出力：ユーザーごとのカウントを表示 例 入力例： 　{“user_id”:“alice”,“action”:“login”} 　{“user_id”:“bob”,“action”:“view”}　 　{"user_id":"alice","action":"purchase"} 出力例： 　alice: 2 　bob: 1 9
10. 提出したコード import json from collections import Counter import sys def count_users(file_path): user_counts = Counter() with open(file_path, 'r', encoding='utf-8') as f: for line in f: # 1行ずつ読み込み（メモリ節約） try: data = json.loads(line.strip()) if 'user_id' in data: user_counts[data['user_id']] += 1 except json.JSONDecodeError: continue # 不正な行はスキップ for user, count in user_counts.items(): print(f"{user}: {count}") if __name__ == "__main__": if len(sys.argv) > 1: count_users(sys.argv[1]) else: print("Usage: python script.py <filepath>") 10
11. 実装の際にした工夫 with open と for line in f ファイルを1行ずつ処理することで読み込みの際にメモリを圧迫しないようしました。 collections.Counter 　キーの初期化判定を省きました。 try-except JSONとして不正な行はスキップし、処理を継続できるようにしました。 11
12. 問４： 「DNSを使ったデータ持ち出し（DNSトンネリング等）の防御」 というテーマについて、 1：持ち出しが成功する理由 2：持ち出しが行われている兆候を3つ以上 3：対策案 4：あなたが担当者だとして、最初の一歩として何を行うべきか（理由付きで） を記載してください。 12
13. なお、対策案は、次の4つの箱に分けて提案してください。 検知（Detection） ：何を見て怪しいと判断するか 抑止（Prevention） ：どう制限・遮断するか（やりすぎ注意も含む） 運用（Operations） ：誤検知や例外が出た時にどう回すか（誰が何をするか） 副作用（Trade-off） ：正当な通信が壊れる可能性／プライバシーへの配慮 ヒント： 本問は防御側の理解と設計を目的にしています。 講義では「DNSサーバを作る」だけでなく「ログ（可観測性）→分析→運用設計」まで扱いま す。 13
14. 回答 1. 持ち出しが成功する理由 DNSは通常のインターネット利用に不可欠なサービスであるため、ネットワークで遮断されること は稀だが、 データ伝送用プロトコルではないため、監視の目が 届きにくい 攻撃者はこの仕様を悪用し、DNSクエリ／レスポンスにデータを埋め込む → 感染したクライアントとC&Cサーバー間の トンネルを確立 する。 14
15. ２．持ち出しが行われている兆候 ① クエリの異常な増加 DNSは一回に少量しか送受信できないため、まとまったデータ持ち出す際には特定のドメインに対 するDNSクエリの通信量や発生頻度が異常に増加します。 ② エントロピー サブドメイン部分に分割されたデータが直接埋め込まれるため、通常ドメインと比べて不自然に長 く、エントロピーが高いランダムな文字列になります。 ③ 特殊なレコード種別の増加 TXTレコード・NULLレコードなどWeb閲覧ではあまり使われない特定のレコード種別の問い合わせ が極端に増えたり、NXDOMAINエラーといった名前解決の失敗の割合が高まったりする。 15
16. ３．対策案 カテ ゴリ 内容 検知 DNSログを分析し、単一クライアントからの異常なクエリ数、FQDNの長さや文字列を精査。特定 のレコードタイプへの偏りを閾値として設定して、怪しい通信を見つけ出します。 抑止 外部DNSサーバへの直接通信をFWで遮断し、必ず社内指定の再帰リゾルバを経由させる。その上 で、悪意のあるドメインへの名前解決自体をブロックします。 運用 アラート発報時、直ちに該当する発信元クライアントを特定し、マルウェア感染・不審プロセス を調査するフローを回します。誤検知の場合はホワイトリストに追加して例外として学習させま す。 副作 用 プライバシーへの配慮とログの目的外利用の防止を念頭において、従業員が「いつ・どのWebサ イトを閲覧しているか」を把握するために全てのDNSクエリを監視する。 16
17. ４.最初の一歩 担当者として最初に行うべきこと 社内の全DNSクエリのログ取得の開始と、その集約 理由 組織内ネットワークにおける「通常 のDNS通信のベースライン」を把握できなければ、攻撃による 「異常な兆候」に気づくための分析や閾値設計が不可能であるから。 通信内容をログという事実を基に可視化することが必要だと考えます。 17
18. 【 問５：ネットワークの流れを説明 】 調査の際は、インターネット検索、YouTube、ChatGPTやGeminiなどの生成AIを積極的に活用してください。 なお、問5-1のみ必須 であり、問5-2と問5-3は余裕があれば解答してください。 問５-１： あなたがブラウザで Webページを開くとき、裏側で起きることを説明してください。説明には、以 下に示す単語を必ず使用してください（順番は自由です） 。 可能であれば、送受信されるデータの例（短い例でOK）も書いてください。 18
19. 使用する単語： ・ スタブリゾルバ ・ 再帰リゾルバ（リカーシブリゾルバ） ・ 権威DNSサーバ ・ DNSクエリ ・ DNSレスポンス ・ Aレコード（またはAAAAレコード） ・ TTL ・ TCP 3-way handshake ・ HTTP GETリクエスト DNSに詳しくなくても大丈夫です。 ポイントは「名前をIPに変える流れ」 「その後にHTTP通信が始まる流れ」を、あなたの言葉で筋道 立てて説明することです。 19
20. 回答 ユーザーがブラウザにURL（例: http://example.com ）を入力してからページが表示されるまで、 「名前解決」と「HTTP通信」の2つのフェーズが実行されます。 １. 名前解決のフェーズ 　ブラウザがURLを受け取ると、OSに組み込まれたスタブリゾルバが、ドメイン名をIPアドレスに 変換するために、設定されている再帰リゾルバに対して「example.comのIPを教えて」というDNS クエリを送信します。 再帰リゾルバは自身にキャッシュがない場合、ルートサーバーから順に権威DNSサーバへ反復的に 問い合わせを行い、対象ドメインのIPアドレス（例: 93.184.215.14）が記載されたAAAAレコードを 取得します。 その後、再帰リゾルバからスタブリゾルバへDNSレスポン スが返却されます。この際、応答データ にはTTL（例: 86400秒）と呼ばれる有効期間が設定されており、指定された時間内はキャッシュと して保持されます。これは、次回以降の高速化に役立ちます。 20
21. ２. HTTP通信のフェーズ IPアドレスが判明すると、ブラウザはそのIPアドレスを持つWebサーバーに対して、通信の信頼性 を確保するためのTCP 3-way handshake（データの例: SYNパケット → SYN-ACKパケット → ACKパ ケット）を行い、接続を確立します。接続が確立された後、ブラウザはWebサーバーに対して 「GET / HTTP/1.1」のようなHTTP GETリクエストを送信し、サーバーから返されたHTMLなどのデ ータを解釈して画面にWebページを表示します。 21
22. 任意課題について、 5-2 DNSを“体験”してみてください。 B オンラインのDNSチェックツール等で調べ、結果を貼って説明（ツール名も書く）を選択。 最低限やってほしいこと： 何か1つドメインを選んで、名前解決の結果を示す（出力貼り付け） その結果から分かることを3つ書く（例：IPが返ってきた、TTLが見える、CNAMEがある等） 「ログを取るなら、どの情報があると嬉しいか」を3つ書く（理由も） だけ、メモ程度に書いていましたが、どこかに消えました。 。 。 22
23. 問６：自由記述 以下のいずれか1つを選択し、回答してください。 （300字程度） 選択肢A： あなたがセキュリティに興味を持ったきっかけと、これまでに取り組んだこと（CTF、学習、開発 など）を教えてください。 選択肢B： 「攻撃手法を学ぶこと」は「防御に活かすこと」にどうつながると思いますか。あなたの考えを 書いてください。 選択肢C： AIがサイバーセキュリティの分野でどのように活用できると思いますか。期待することと懸念す ることを書いてください。 23
24. 回答 ( B を選びました ) 攻撃手法を学ぶことは、防御策を考えるうえで不可欠だと考えます。 私はこれまで代数学など暗号理論の基礎となる数学の学習に注力してきました。 昨年、広島で開催されたセキュリティミニキャンプに参加し、システムがどう破られるかを実践的 に知らなければ真の防御策は考えられないと痛感しました。 参加後は指導教員と面談し、卒業研究ではC言語等で仮想環境を構築して脆弱性を自ら分析・改善す る研究を行う予定です。 将来、情報科教員として教壇に立つ際も、この経験を活かし「なぜその防御が必要か」を生徒に伝 えたいと思います。 24
25. 問７：トラック希望順位 第2希望 併願していて希望順位が重複している場合は、運営側の任意で決定。 25