勉強メモ2015
● セキュリティ
- Sender Policy Framework
- 受信側メールサーバが、「受信したメールが他のドメインになりすましているものではないか」を確認するもの。
- 具体的には:
- 受信側メールサーバは、受信したメール中のエンベロープの中の「送信元IPアドレス」を調べる。
- 受信側メールサーバは、メールアドレスのドメイン(@以降の部分)について、送信元にDNS問い合わせをおこなう。
- MXレコード→Aレコード→TXTレコード
- 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サーバが乗っ取られたときと比べると)。
- Webサーバを公開する際、クライアントに直接Webサーバにアクセスさせるのではなく、いったんリバースプロキシを介してアクセスさせるようにする。
● ネットワーク
- HTTPのメソッド
- GET
- ボディなし。
- 基本的にはデータ受信用だけど、クエリ・ストリングで送信もできる。送信内容モロバレだけど。
- POST
- ボディあり。
- レスポンスを返すのは、実は必須ではない(普通は、投稿後のページ情報とかを返すけど)。
- GET