勉強メモ2015

● セキュリティ
  • Sender Policy Framework
    • 受信側メールサーバが、「受信したメールが他のドメインになりすましているものではないか」を確認するもの。
    • 具体的には:
      1. 受信側メールサーバは、受信したメール中のエンベロープの中の「送信元IPアドレス」を調べる。
      2. 受信側メールサーバは、メールアドレスのドメイン(@以降の部分)について、送信元にDNS問い合わせをおこなう。
        • MXレコード→Aレコード→TXTレコード
      3. TXTレコードの "v=sfp1" 行(SPFレコード)に書いてある許可IPアドレスと一致していたら、正規のメールだと判断する。
      • そうでなかったら(許可アドレスにどれも一致しなかったら、すなわち拒否アドレス "-all" に一致していたら)、なりすましメールだと判断する。
    a-sha.co.jp      IN  MX   10 msv.a-sha.co.jp
    msv.a-sha.co.jp  IN  A    x1.y1.z1.4
    a-sha.co.jp      IN  TXT  "v=spf1 +ip4:x1.y1.z1.4 -all"  # ←「a-sha.co.jp から送るのは x1.y1.z1.4 だけやで〜」
  • DMZ
    • 宇宙船のエアロックみたいなもん。
      • 「非武装地帯」と聞くと、そこに入った時点で「安全ゾーン」みたいなニュアンスを自分は受けてしまうが、そうではない。
        • そうするためのものではあるが。
    • 公開サーバ群は、(FWをかませているとはいえ)グローバルなセグメントに晒されている。
  • リバースプロキシ
    • Webサーバを公開する際、クライアントに直接Webサーバにアクセスさせるのではなく、いったんリバースプロキシを介してアクセスさせるようにする。
      • リバースプロキシは、クライアントとWebサーバのやりとりを仲介する。
      • その名の通り、プロキシサーバみたいなことを、ダウンリンク側で行う。
    • こうすることで、たとえば「リバースプロキシをDMZに配置し、Webサーバを別の(内側の、守られた)セグメントに配置」することで、Webサーバをインターネットに晒さずに済む。
      • 仮にリバースプロキシが乗っ取られても、被害を少なくできる(Webサーバが乗っ取られたときと比べると)。
● ネットワーク
  • HTTPのメソッド
    • GET
      • ボディなし。
      • 基本的にはデータ受信用だけど、クエリ・ストリングで送信もできる。送信内容モロバレだけど。
    • POST
      • ボディあり。
      • レスポンスを返すのは、実は必須ではない(普通は、投稿後のページ情報とかを返すけど)。