7.1. 入門編: 手動での鍵処理

IPSEC は複雑な題材です。たくさんの情報がネットワーク上にありますが、 この HOWTO では動作できるようにすること、基本的な原理を 説明することに集中したいと考えています。 すべての例は、上記のリンクにある Racoon をもとにしています。

Note: iptables のたいていの設定では、IPSEC パケットを落としてしまいます! IPSEC を通すには、'iptables -A xxx -p 50 -j ACCEPT' と 'iptables -A xxx -p 51 -j ACCEPT' を使ってください。

IPSEC はセキュリティに優れたインターネットプロトコルです。 ここでの「セキュリティ」には、2 つの意味があります。 暗号化および認証です。わかってない人は、セキュリティすなわち暗号化であると 考えがちですが、それだけでは十分でないことは簡単に示せます。 通信は暗号化していても、通信先が自分の期待している通りかどうかの保証が 一切ないとしたらどうでしょうか?

IPSEC は暗号化には 'Encapsulated Security Payload (ESP)' を、 そしてリモートの通信先の認証には 'Authentication Header (AH)' を用います。 両方を使うようにも設定できますし、片方だけを使うこともできます。

ESP も AH も、security assosiation (SA) に依存しています。 SA は、発信元・送信先・手続きからなります。 例えば認証の SA は次のようになります。
	  add 10.0.0.11 10.0.0.216 ah 15700 -A hmac-md5 "1234567890123456";
	
これは「10.0.0.11 から 10.0.0.216 に向かうトラフィックのうち AH を必要とするものは、秘密鍵 123456789123456 を用いた HMAC-MD5 で署名できる」という意味です。 この手続きには SPI ('Security Parameter Index') の id 15700 が付けられています。 これについては後ほど詳しく説明します。 SA の興味深い点は、対称的だという点にあります。 通話を共有している両端は、まったく同じ SA を共有し、 他端の鏡映にはなりません。しかしながら、ここでは 'autoreserve' ルールがないことに注意しましょう。 つまりこの SA は、10.0.0.11 から 10.0.0.216 への認証が可能であることだけを示しています。 双方向のトラフィックに対しては、2 つの SA が必要となります。

ESP SA の例を挙げましょう。
add 10.0.0.11 10.0.0.216 esp 15701 -E 3des-cbc "123456789012123456789012";
	
これは「10.0.0.11 から 10.0.0.216 に向かうトラフィックのうち 暗号化を必要とするものは、鍵 123456789012123456789012 を用いて暗号化できる」 という意味です。この SPI id は '15701' です。

ここまでのところ、SA が可能な手続きを記述することを見てきましたが、 しかし実は SA は、いつそれが必要になるかに関するポリシーを記述していません。 実際のところ、SPI id のみが異なるほとんど同じ SA を、好きなだけ置くこともできるのです (先ほども述べましたが SPI は Security Parameter Index の意味です)。 実際の暗号化を行うには、ポリシーを記述しなければなりません。 このポリシーには、「可能なら ipsec を使う」とか 「ipsec が使えなければトラフィックを捨てる」とかいった内容を記述できます。

典型的かつ簡単な Security Policy (SP) は次のようなものです。
spdadd 10.0.0.216 10.0.0.11 any -P out ipsec
   esp/transport//require
   ah/transport//require;
	
ホスト 10.0.0.216 でこれが入力されると、 10.0.0.11 に向かうすべてのトラフィックは暗号化されなければならず、 かつ AH (authenticating header: 認証ヘッダ) でラップされなければなりません。 ただしここではどの SA を使うべきかは記述されていません。 これを決定するのはカーネルに残された仕事なのです。

別の言い方をすれば、Security Policy は我々が「何を」 必要とするかを指定するのです。Security Association は それを「どのように」必要とするかを記述します。

送り出されるパケットは、SA SPI (「どのように」) でラベル付けされます。 カーネルはこれを使って暗号化と認証を行い、 リモートからはそれに対応する検証と復号化の手続きを調べることができます。

以降に示すのは、ホスト 10.0.0.216 から 10.0.0.11 に対して 暗号化と認証を用いて通信する場合の、非常に簡単な設定です。 ただし最初の版では逆向きは平文ですので、 これは実際に用いてはなりません。

ホスト 10.0.0.216 では:
#!/sbin/setkey -f
add 10.0.0.216 10.0.0.11 ah 24500 -A hmac-md5 "1234567890123456";          
add 10.0.0.216 10.0.0.11 esp 24501 -E 3des-cbc "123456789012123456789012";

spdadd 10.0.0.216 10.0.0.11 any -P out ipsec
   esp/transport//require
   ah/transport//require;
	

ホスト 10.0.0.11 では同じ Security Association を用い、 Security Policy は指定しません。
#!/sbin/setkey -f
add 10.0.0.216 10.0.0.11 ah 24500 -A hmac-md5 "1234567890123456";
add 10.0.0.216 10.0.0.11 esp 24501 -E 3des-cbc "123456789012123456789012";
	

以上の設定を行えば (これらのファイルは 'setkey' が /sbin にインストールされていれば実行できます)、 10.0.0.126 から行った 'ping 10.0.0.11' は、tcpdump では次のように見えます。
22:37:52 10.0.0.216 > 10.0.0.11: AH(spi=0x00005fb4,seq=0xa): ESP(spi=0x00005fb5,seq=0xa) (DF)
22:37:52 10.0.0.11 > 10.0.0.216: icmp: echo reply
	
10.0.0.11 からの ping の戻りが、実際に平文で見えることに注目。 フォワードの ping は、もちろん tcpdump では見えません。 しかし 10.0.0.11 に伝えている AH と ESP の Security Parameter Index、 すなわちパケットの認証確認と複号化の方法、は見えています。

しかし、ここでいくつかの点に触れておく必要があります。 上記の設定は、多くの IPSEC の例で示されているものですが、 非常に危険なのです。問題は次の点にあります。上記におけるポリシーでは、 10.0.0.216 が 10.0.0.11 に向かうパケットをどう取り扱うかと、 10.0.0.11 がこれらのパケットをどう扱うかは定めていますが、 しかし 10.0.0.11 が認証できない/複号化できないトラフィックを どのように捨てるかを示していないのです!

これでは、誰かが途中でパケットを盗み、 完全に複号化されたパケットで置き換えると、 10.0.0.11 はそれを受け入れてしまいます。 これを避けるには、到着パケットに対する Security Policy が 10.0.0.11 に必要です。次のようにします。
#!/sbin/setkey -f 
spdadd 10.0.0.216 10.0.0.11 any -P IN ipsec
   esp/transport//require
   ah/transport//require;
	
これは 10.0.0.11 に対して、 10.0.0.216 から来たトラフィックに対して、 正しい ESP と AH が必要である、と指定しています。

さて、設定を完了するには、 もちろん帰りのトラフィックにも同様な暗号化・認証が必要です。 10.0.0.216 における完全な設定は:
#!/sbin/setkey -f
flush;
spdflush;

# AH
add 10.0.0.11 10.0.0.216 ah 15700 -A hmac-md5 "1234567890123456";
add 10.0.0.216 10.0.0.11 ah 24500 -A hmac-md5 "1234567890123456";

# ESP
add 10.0.0.11 10.0.0.216 esp 15701 -E 3des-cbc "123456789012123456789012";
add 10.0.0.216 10.0.0.11 esp 24501 -E 3des-cbc "123456789012123456789012";

spdadd 10.0.0.216 10.0.0.11 any -P out ipsec
           esp/transport//require
           ah/transport//require;

spdadd 10.0.0.11 10.0.0.216 any -P in ipsec
           esp/transport//require
           ah/transport//require;
	  
	

そして 10.0.0.11 では:
#!/sbin/setkey -f
flush;
spdflush;

# AH
add 10.0.0.11 10.0.0.216 ah 15700 -A hmac-md5 "1234567890123456";
add 10.0.0.216 10.0.0.11 ah 24500 -A hmac-md5 "1234567890123456";

# ESP
add 10.0.0.11 10.0.0.216 esp 15701 -E 3des-cbc "123456789012123456789012";
add 10.0.0.216 10.0.0.11 esp 24501 -E 3des-cbc "123456789012123456789012";


spdadd 10.0.0.11 10.0.0.216 any -P out ipsec
           esp/transport//require
           ah/transport//require;

spdadd 10.0.0.216 10.0.0.11 any -P in ipsec
           esp/transport//require
           ah/transport//require;

	

この例では、同一の鍵を両方向のトラフィックに用いています。 しかしこれは、必要条件ではまったくありません。

いま行った設定を確認するには、 setkey -D を実行して Security Association を表示するか、 setkey -DP を実行して設定されたポリシーを表示してください。